They should create a canonical identity record that links every account to one governed subject. That record should include HR, directory, cloud, SaaS, and build-system identities so reviews, offboarding, and entitlement analysis are performed once across the whole person, not separately in each system.
Why This Matters for Security Teams
Employees rarely stay inside one identity boundary. A single person can have an HR record, one or more directory accounts, privileged admin accounts, SaaS logins, cloud roles, and build-system access. If IAM teams review those accounts separately, they miss cumulative risk, duplicate entitlements, and orphaned access after a transfer or termination. That is why canonical identity resolution is a core control, not just an admin convenience.
Current guidance from the NIST Cybersecurity Framework 2.0 aligns with this approach because identity governance depends on knowing who the subject really is across systems. NHIMG’s Ultimate Guide to NHIs reinforces the broader lesson: identity sprawl creates blind spots when ownership, access, and lifecycle events are fragmented. The same operational failure pattern appears in human IAM when entitlements are treated as system-local instead of person-centric.
In practice, many security teams discover the problem only after an access review, incident, or offboarding delay exposes that no one had a complete view of the employee’s effective privileges.
How It Works in Practice
The practical answer is to build one canonical identity record per governed subject and link every account back to it. That record should aggregate authoritative attributes from HR, directory services, cloud IAM, SaaS platforms, PAM, and build or DevOps systems. The goal is not to merge every login into one username, but to create one identity graph that supports review, certification, and revocation decisions across the full person.
Operationally, teams usually need four layers:
-
Authoritative source mapping, with HR as the lifecycle source of truth for employment status, manager, and department.
-
Account correlation rules, using stable identifiers such as employee ID, immutable subject IDs, email history, and federation links.
-
Entitlement aggregation, so access reviews show all related permissions together rather than one system at a time.
-
Lifecycle enforcement, so joiner, mover, and leaver events update every linked account, including privileged and shadow accounts.
This is especially important where people have parallel roles, such as an engineering employee with a standard directory account, a break-glass admin account, and a CI/CD service principal they can operate. Without canonical linkage, offboarding can leave behind credentials that are invisible to a system-by-system review. That is exactly the kind of fragmentation highlighted in NHIMG research on identity sprawl and privilege exposure, including the Azure Key Vault privilege escalation exposure analysis, where one identity path can cascade into broader access than expected.
Best practice is evolving toward policy-as-code checks and continuous reconciliation rather than annual spreadsheet-based recertification. These controls tend to break down when subsidiaries, contractor platforms, or acquired environments use different identity attributes and no shared subject identifier exists.
Common Variations and Edge Cases
Tighter canonical identity controls often increase integration cost, requiring organisations to balance completeness against data quality, privacy, and administrative overhead. That tradeoff becomes more visible in mergers, outsourced support teams, and highly regulated environments where one employee may legitimately hold multiple legal, contractual, or regional identities.
There is no universal standard for this yet, but current guidance suggests three common exceptions need explicit handling:
-
Distinct legal personas: a person may legitimately need separate records for employee, contractor, or board-member status, but those records should still be cross-referenced where policy allows.
-
Shared or delegated access: some accounts represent a team function, emergency role, or service desk workflow and should not be collapsed into a personal identity without governance review.
-
Acquired systems: temporary duplication is common after mergers, but the IAM team should time-box it and define a migration path to a single governed subject.
The key test is whether the account can be reviewed, revoked, and attributed back to a responsible subject when something goes wrong. If the answer is no, the identity model is too fragmented. NHIMG’s research on offboarding and lifecycle control shows how quickly unmanaged access accumulates when identity records are not normalized, and the same logic applies to human access portfolios.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity is only manageable when each person can be uniquely correlated across systems. |
| NIST CSF 2.0 | PR.AA-03 | Account lifecycle control depends on knowing every account tied to one employee. |
| NIST AI RMF | The Govern function supports accountable identity ownership and traceability across records. |
Assign a single owner for identity correlation and enforce traceable subject mapping across platforms.
Related resources from NHI Mgmt Group
- How should IAM teams handle identity attributes that live across multiple apps?
- What should security teams do when device identities are spread across operational technology systems?
- How should security teams implement phishing-resistant MFA across multiple IAM systems?
- What breaks when AWS access logs are split across multiple systems?
