Identity correlation across siloed accounts is the real IAM gap

At a glance

What this is: This analysis argues that the core IAM problem is not account volume but the inability to correlate multiple platform accounts to one employee identity.

Why it matters: It matters because joiner-mover-leaver control, access reviews and entitlement decisions fail when organisations cannot reliably tell which accounts belong to the same person.

Context

Identity correlation is the process of determining which accounts belong to the same real-world person across separate systems. In this article, the problem is not that employees have many accounts, but that IAM teams cannot reliably unify Azure AD, AWS IAM, Jenkins, Artifactory and HR records into one governed identity view.

When correlation fails, onboarding, offboarding and access review decisions become fragmented. That creates a governance gap for human identity programmes because the organisation may know an account exists without knowing whether it still belongs to the intended employee or whether related accounts have fallen out of sync.

Key questions

Q: What breaks when employee accounts are not linked across platforms?

A: Access reviews, offboarding, and privilege cleanup all become partial because teams cannot tell which accounts belong to the same person. That leads to duplicate access, missed leavers, and incorrect certification decisions. In practice, the failure is not only technical. It is a governance failure that weakens accountability across the identity lifecycle.

Q: Why do lifecycle changes matter so much in identity governance?

A: Because access is rarely static in real organisations. Joiner, mover, and leaver events create repeated opportunities for privilege to become outdated, excessive, or orphaned. When lifecycle handling is weak, certification becomes noisier, remediation slows down, and security teams lose confidence that access state matches business reality.

Q: How should IAM teams decide whether two accounts belong to the same person?

A: 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.

Q: How can organisations tell whether identity assurance is actually working?

A: Look for consistency across onboarding, recovery, and re-verification events. If those processes use the same quality of proof, the same audit trail, and the same ownership model, assurance is behaving like a control rather than a slogan. If one path is much easier than the others, the programme has a bypass.

Technical breakdown

Why identity attributes alone do not solve correlation

Usernames, principal IDs, email addresses and platform-specific identifiers are useful signals, but none of them is guaranteed to be stable across all systems. Correlation engines have to compare overlapping attributes and infer identity matches from patterns, which means the outcome depends on data quality, consistency and the completeness of upstream identity records. Federation helps when it is available, but many environments still need separate accounts for operational or security reasons. The technical problem is therefore not authentication alone. It is the lack of a reliable identity spine that can reconcile distinct account objects back to one governed person.

Practical implication: treat account attributes as correlation inputs, not proof of identity on their own.

How siloed accounts break lifecycle control

Joiner-mover-leaver processes depend on knowing which entitlements belong to which person across the full account estate. If a new hire exists in one system but not another, or if an employee changes role and some accounts are not updated, the lifecycle record becomes inconsistent. That inconsistency is what creates residual access, missed deprovisioning and incomplete recertification. In other words, lifecycle governance is only as good as the system that maps many account records to one identity record. Without correlation, IAM teams are managing parallel account lists instead of a single access story.

Practical implication: validate joiner-mover-leaver workflows against correlated identities, not against a single source system.

Identity correlation as an access decision layer

Correlation is not just a reporting feature. It becomes an access decision layer because entitlement review, anomaly detection and security response all depend on knowing whether separate accounts belong to the same employee. Once identities are linked, IAM teams can see where privilege is duplicated across tools, where approvals diverge across systems and where an account may represent the same user operating under different principals. That turns identity correlation into a governance mechanism that supports consistency across the estate rather than a post-hoc cleanup exercise.

Practical implication: design correlation outputs so they can feed access reviews, offboarding checks and entitlement decisions directly.

Threat narrative

Attacker objective: The objective is to exploit identity fragmentation so access decisions become unreliable and stale or excess accounts persist unnoticed.

1. Entry begins when a new account is created in one system but the corresponding identity is missing or misaligned in another, creating a fragmented identity record.
2. Credential or account handling then becomes inconsistent because separate systems hold different fragments of the same person's access history.
3. Escalation occurs when lifecycle or entitlement decisions are made against incomplete identity context, leaving excess or stale access in place.
4. Impact is a weakened identity governance posture, with harder review, weaker offboarding and reduced confidence in who really has access.

Breaches seen in the wild

• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity correlation is the missing control plane for human IAM. Account counts are not the governing problem. The governing problem is whether one person can be reliably represented across Azure AD, AWS IAM, HR and application accounts without ambiguity. That is what makes access reviews, offboarding and role changes defensible. Practitioners should stop treating correlation as an enrichment task and treat it as a core IAM control.

Joiner-mover-leaver governance collapses when the identity record is split across systems. If HR, cloud, CI/CD and application accounts do not resolve to the same employee, lifecycle actions become partial by design. The organisation can believe it has completed onboarding or offboarding while access remains distributed across disconnected records. The practical conclusion is that lifecycle governance must start with identity linkage, not after it.

Statistical similarity is useful, but governance must still decide the threshold for a match. Correlation engines can surface likely matches by comparing principals, emails and usernames, but the policy question is who accepts that linkage and under what evidence standard. That is an identity governance decision, not a pure data problem. Practitioners should require auditable correlation rules so identity merging is explainable, reviewable and reversible.

Identity correlation reduces entitlement drift by making the same person visible across multiple systems. Once access is tied back to one employee, duplicate privileges, inconsistent approvals and stale accounts are easier to spot. That does not eliminate account sprawl, but it turns fragmentation from an unknown into a governed state. The implication is that IAM teams should measure whether identity linkage is strong enough to support decisions, not merely whether accounts exist in inventory.

Unified identity views matter most when federation is incomplete or unsuitable. Federation is helpful, but it does not remove the need to understand who a user is across every operational system. Many environments still rely on separate accounts because of application constraints, security boundaries or business design. The field should therefore treat correlation as a durable IAM capability, not a temporary workaround for legacy systems.

What this signals

Identity correlation becomes the control that ties together fragmented human IAM. As soon as a person exists across cloud, developer and enterprise systems, the question is no longer whether accounts can be created. The question is whether the programme can prove that those accounts still belong to the same employee at the moment a lifecycle or access decision is made.

Identity drift is the risk pattern to watch. When correlation is weak, the same employee can accumulate inconsistent entitlements across systems without any one platform having the full picture. That is why correlation should be treated as a prerequisite for governance rather than a cleanup task after onboarding or offboarding.

Correlation quality should be measured through decision confidence. If access reviewers cannot trust the unified identity view, then the programme is still operating on siloed records. Practitioners should watch for unresolved matches, duplicated person records and lifecycle actions that succeed in one system but leave residual access elsewhere.

For practitioners

• Map every employee to a correlated identity record Create a governed identity graph that links HR, cloud, developer and business application accounts to one person before relying on lifecycle actions.
• Define evidence thresholds for account matching Set policy for which attributes and similarity scores are sufficient to merge or relate accounts, and require human review for ambiguous matches.
• Re-test joiner-mover-leaver workflows against the correlated view Validate that onboarding, transfers and offboarding succeed when a person has multiple account types across separate platforms.
• Use correlated identities in access reviews Run certification and recertification against the unified person view so reviewers see all linked entitlements, not isolated account records.
• Track unresolved identity splits as governance exceptions Report accounts that cannot be confidently matched back to a person as a control gap, not as a harmless data quality issue.

Key takeaways

• The central risk is identity fragmentation, not simple account volume, because separate systems cannot govern access consistently when they cannot resolve one person across them.
• Correlation improves access visibility by linking cloud, developer and HR accounts into one governed identity view, which strengthens onboarding, offboarding and review decisions.
• IAM teams should treat identity linkage as a core control and measure whether it is strong enough to support lifecycle actions, not just reporting.

Key terms

• Identity correlation: Identity correlation is the process of linking multiple account records to one governed subject. It lets IAM and IGA teams understand that separate usernames, principals, or emails may belong to the same employee or workload, which is essential for access review, offboarding, and entitlement analysis.
• Identity Graph: An identity graph is a relationship map that connects identities, assets, data, and permissions so teams can see how access actually flows. In NHI programmes, it helps explain which agent is related to which owner, which system, and which policy boundary.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
• Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.