Purpose
Identity is the control plane
Care charities depend on email, collaboration platforms, care systems, remote access and shared operational services. When an identity is compromised, an attacker may inherit the same reach as the person or service account behind it. Identity and Access Management (IAM) reduces that risk by verifying who is requesting access, limiting what they can reach and reviewing whether that access is still justified.
RACF-CC treats identity as a connected trust fabric. Cloud authentication cannot be assessed separately from an on-premises directory, device compliance, privileged roles or legacy applications. The objective is consistent, proportionate enforcement—not the purchase of a large enterprise identity platform.
What good looks like
People use strong authentication; access decisions consider role, risk and device state; privileged access is exceptional and reviewable; inactive identities are removed; and both cloud and on-premises trust are included in assurance.
Risk picture
Where identity risk accumulates
Uneven MFA coverage
Unprotected staff, guests, administrators or recovery paths can allow a stolen password to become a successful sign-in.
Standing privilege
Too many permanent administrative accounts increase both the likelihood and potential impact of compromise.
Stale and unclear ownership
Inactive users, old guests and undocumented service accounts create access that may no longer have a legitimate owner.
Inconsistent access policies
Gaps, broad exclusions and untested policies can leave important applications, users or device types outside enforcement.
Unmanaged device access
A valid user identity may still connect from a personal, non-compliant or unknown device that lacks organisational safeguards.
Hybrid trust weaknesses
Long-lived credentials, excessive directory privilege and unsafe legacy configurations can undermine stronger cloud controls.
Prioritised action
The RACF-CC identity control set
Priority reflects likely risk reduction, cost, delivery effort and potential disruption. It is a decision aid rather than a substitute for local risk assessment.
| Priority | Control direction | Why it matters | Useful evidence |
|---|---|---|---|
| First | Require MFA for staff, guests and privileged accounts. | Reduces the chance that a stolen password alone results in access. | Registration, methods and enforcement coverage reports. |
| First | Protect administrative access and remove inactive or unjustified privilege. | Reduces attack impact and limits persistence through powerful accounts. | Cloud role and directory privileged-group reviews. |
| First | Block legacy authentication where compatibility has been confirmed. | Closes older sign-in paths that may not support modern controls. | Sign-in logs, application testing and exception register. |
| Next | Standardise access policies and move tested policies from observation to enforcement. | Turns security intent into consistent access decisions. | Policy inventory, report-only outcomes and sign-in results. |
| Next | Separate managed, personal and unknown device trust. | Prevents a valid identity from automatically making an unsafe device trustworthy. | Device ownership, compliance and access-policy reports. |
| Next | Review stale users, guests, service identities and password exceptions. | Removes access that lacks current need, ownership or appropriate safeguards. | Lifecycle review records and approved exception register. |
| Next | Assess and harden hybrid directory trust. | Cloud controls cannot contain compromise if underlying directory trust remains exposed. | Directory assessment, remediation records and change evidence. |
| Develop | Adopt phishing-resistant authentication for administrators and high-risk groups. | Improves resistance to interception, adversary-in-the-middle phishing and prompt fatigue. | Authentication-strength and sign-in-method coverage. |
| Develop | Move toward time-bound privilege and automated lifecycle governance. | Reduces permanent privilege and manual joiner, mover and leaver gaps. | Activation, approval, review and deprovisioning records. |
Safe implementation
A four-phase roadmap
Phase 1 • Stabilise
Close obvious access gaps
- Inventory users, guests, administrators and service identities
- Close MFA registration and enforcement gaps
- Remove inactive privilege and exposed credentials
- Confirm protected emergency access
Phase 2 • Enforce
Make access policy consistent
- Use pilot groups and report-only evaluation
- Cover important resources and identity types
- Restrict unmanaged-device access proportionately
- Review exclusions and failed-sign-in impact
Phase 3 • Harden
Reduce hybrid persistence
- Reduce directory privilege and stale accounts
- Review certificate and authentication trust
- Address long-lived or poorly owned credentials
- Record residual legacy risk and ownership
Phase 4 • Mature
Strengthen assurance over time
- Expand phishing-resistant authentication
- Introduce time-bound privileged access where feasible
- Improve automated identity lifecycle controls
- Repeat evidence reviews and refine policy
Avoid accidental lockout or service disruption
Do not enable broad access policies or make high-impact directory changes without tested emergency access, pilot users, communication, monitoring, change approval and a rollback plan. Shared devices, frontline workflows and legacy care applications require explicit compatibility testing.
Use staged enforcement for access controls
Audit/report-only → pilot → validate → enforce → monitor → reviewConditional Access, authentication-strength and device-based access policies should progress through representative testing, communications, emergency-access validation and rollback planning. Use the Safe Enforcement Pattern →
Supplier access is still organisational access
Record supplier identities, privilege, authentication, remote routes, internal ownership and offboarding before relying on a contract to manage the exposure. Use the Supplier and Third-Party Risk guide →
Managing a mixed Windows and Mac estate?
Microsoft's planned Entra change makes this a useful time to compare Windows Hello for Business coverage with macOS Platform SSO configuration, policy behaviour and recovery arrangements. Read the mixed-estate preparation guide →
Start here
Six practical first actions
Build a trustworthy identity inventory
Record staff, guest, administrator, shared and service identities, with an owner and purpose for every exception.
Measure MFA coverage and enforcement separately
Registration does not prove that MFA is required. Check both capability and actual policy coverage.
Review privileged access first
Remove inactive administrators, separate normal and administrative use, and justify every standing role.
Review guests and dormant accounts
Use a repeatable process with service-owner confirmation rather than deleting accounts solely because of age.
Test access policies before enforcement
Observe expected effects, test real workflows and investigate exclusions before turning controls on.
Include the underlying directory
Review privileged groups, credential hygiene and certificate trust so that cloud improvements are not undermined by legacy identity paths.
Current Entra dependency deadline
Microsoft plans to stop processing dynamic rules that use the memberOf operator after 3 November 2026. Affected membership can remain in its last-known state, so access, licensing and policy dependencies require discovery, replacement and validation. Use the practical migration guide →
Evidence and assurance
Measure outcomes, not tool ownership
Use several evidence sources
Aggregate security scores can help direct attention, but they should not be treated as definitive proof. Combine authentication reports, sign-in logs, access-policy results, device data, directory reviews, change records and operational feedback.
Residual risk and escalation
Record identity exposure that cannot yet be removed
What may remain unresolved?
Legacy authentication, poorly owned shared or service identities, access-policy exclusions, inactive directory objects and unresolved hybrid-directory or certificate trust can remain after cloud-side improvements.
Care-application compatibility, shared-device workflows, supplier dependencies, licensing constraints or incomplete account ownership may prevent immediate remediation.
Restrict scope and privilege, segment access, strengthen monitoring, protect credentials, shorten review intervals and document emergency alternatives.
The accountable service or data owner should own the business exposure, supported by identity administrators and organisational governance.
Review at the agreed risk interval and after application change, identity redesign, supplier change or any material access-policy update.
Active exploitation, risky privileged sign-in, credential compromise, expanding exclusions, failed emergency access or continued dependence on unsupported authentication.
Recording does not equal acceptance. Any accepted exposure requires accountable approval, safeguards and a time-bound review through Domain 8 governance.
Standards alignment
Research and implementation references
RACF-CC adapts recognised control intent to resource-constrained care environments; it does not replace the source standards or vendor guidance.
- NIST SP 800-207: Zero Trust Architecture — resource-focused, continuously evaluated access principles.
- NIST SP 800-53 Revision 5 — relevant identity, authenticator and access-control families.
- Microsoft: Plan a Conditional Access deployment — staged rollout, report-only evaluation and testing.
- Microsoft: Manage emergency access accounts — resilient administrative access and validation.
- Microsoft: Phishing-resistant MFA — stronger methods, rollout considerations and useful measures.
Continue the framework
Identity does not operate alone
Device compliance strengthens access decisions, monitoring identifies suspicious use, incident response contains compromised accounts, and governance keeps ownership and exceptions visible. Continue with the RACF-CC overview to see how all eight domains connect.