Teams should use a policy-based threshold that combines stable attributes, system context and review for ambiguous cases. The decision should be auditable and reversible, because identity correlation is a governance judgement as much as a data matching exercise.
What makes “same person” a policy decision rather than a pure matching problem?
IAM teams should treat account correlation as an identity resolution judgement, not a mechanical deduplication task. Two accounts can share enough evidence to be linked for governance purposes without being identical in every system. The practical question is whether the linkage is strong enough to support access review, investigation, lifecycle actions and audit trail retention.
The safest approach is to define the threshold before review starts. That means specifying which stable attributes matter, how much system context can be used, when manual adjudication is required, and what evidence is sufficient to reverse a prior decision.
Which signals should carry the most weight?
Stable attributes usually matter more than transient ones. A consistent legal name, employee or customer record, verified email, immutable directory identifier, or a shared authoritative source can support correlation, but each signal has limits. IAM teams should separate attributes that identify a person from attributes that merely describe a device, mailbox, session, tenant or workflow.
System context then fills the gaps. Shared login patterns, common recovery factors, similar employment records, linked HR events, or the same authoritative upstream identity source can increase confidence. For identity governance, this is where the decision often intersects with identity governance, because the decision affects who owns the account, how often it is reviewed, and when a mismatch should trigger escalation.
Where correlation is likely to affect privilege, teams should also consider whether the accounts could expose a broader access path. A person who appears behind multiple accounts may be operating across roles, environments, or business functions, and that is a signal to validate intent rather than assume duplication. The same discipline appears in directory hardening guidance, where understanding account relationships helps reduce privilege confusion and attack-path ambiguity.
How should teams make the decision auditable and reversible?
The decision should produce a traceable record that shows the evidence set, the threshold used, the reviewer, and the reason the conclusion was reached. If the threshold is not explicit, the process becomes hard to defend during access review, incident response or compliance testing. If the conclusion is not reversible, a mistaken merge can pollute downstream entitlement decisions and create lasting governance error.
That is why the underlying evidence should be stored as a decision artifact, not just a one-time analyst judgement. Teams need to be able to show why two accounts were linked, why a human override was accepted, and what would cause the linkage to be undone. This is especially important when the outcome affects privileged access, shared accounts, or separation of duties, because a bad merge can hide overreach as easily as a bad split can hide orphaned access.
For teams managing large estates, the operational challenge often becomes identity-provider selection and lifecycle design: the source system must preserve enough provenance to support later review, not just authentication at login time. Without that record, teams end up guessing after the fact.
Where do these decisions usually go wrong in practice?
The most common failure is overconfidence in partial matches. Two accounts may share a name or email fragment but belong to different people, or they may belong to the same person across different roles while requiring separate governance treatment. Another frequent error is over-merging, where teams collapse accounts too quickly and lose visibility into distinct privileges, business purposes, or segregation requirements.
The opposite error also matters: under-merging accounts that should be linked can leave recertification incomplete and hide duplicated access. That risk is most visible when the same person uses different identities across business units, cloud platforms, or administrative functions. In cloud and workload-heavy environments, the same judgement problem appears in workload identity management, where correlation decisions must preserve both accountability and boundary separation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Account correlation here affects how external or non-employee identities are linked and governed. |
| IA-5 — Authenticator Management | Correlation decisions often depend on credential and authenticator history across accounts. | |
| AC-2 — Account Management | The question is fundamentally about governing whether multiple accounts should be treated as one person. | |
| Recommendation — Use IA-8-backed evidence and provenance to link external accounts only when the identity match is strong enough. Retain authenticator history so account linkage decisions remain auditable and reversible. Apply AC-2 review and lifecycle controls before merging accounts into a single governance view. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity management explicitly covers associating accounts with a person and maintaining that relationship. |
| A.5.18 — Access rights | Account linkage affects whether rights and reviews are assigned to one identity or several. | |
| Recommendation — Define identity correlation criteria and keep them under formal identity management control. Verify access-right ownership before reusing a merged identity for review or recertification. | ||
Practitioner Guidance
What to prioritise: Establish a written correlation policy that ranks evidence types, defines ambiguous-case review, and states which downstream actions are permitted when the match is uncertain. Use a higher threshold for any decision that would expand privilege, collapse ownership, or alter audit scope.
What to verify: Check that every merge decision can be reproduced from stored evidence, and that every reversal leaves an auditable trail. If the team cannot explain why the decision was made, the process is too informal for identity governance.
Common mistake: Treating account matching as a one-time data quality task. In practice it is a governance control that must survive lifecycle changes, role changes, and later dispute.
Practitioner takeaway: The right question is not “Do these records look similar?”, but “Is the evidence strong enough to safely govern them as one person without hiding privilege, ownership, or review risk?”
Related resources from NHI Mgmt Group
- How should teams decide whether CIAM belongs in the same IAM programme as workforce access?
- How should security teams decide whether IAM backups belong inside their own cloud account or outside the identity perimeter?
- How should security teams govern non-human identities alongside human accounts?
- How should security teams govern Active Directory service accounts?