Skip to main content
Identity Authority
Category: Identity Lifecycle

Account Correlation

Also known as: Identity Correlation, Account-to-Identity Correlation
Simply put

Account correlation is the process of matching user accounts found in various source systems to the correct person's identity record. It answers the question of which real individual owns a given login account, so that scattered accounts across different systems can be tied back to one identity. This helps organizations understand what access each person actually has.

Formal definition

Account correlation is an IGA lifecycle process that reconciles and validates the ownership of disparate source accounts by matching them to identities, typically by comparing the values of specific account attributes against corresponding identity attributes (for example, a key value on the identity compared to a key value on the source account). In common deployments this is implemented through attribute-matching correlation configurations or rules; some platforms also support custom correlation rules for accounts that do not share a strong, directly matchable attribute. Correlation is distinct from runtime access enforcement and instead supports downstream governance functions such as account ownership validation and access visibility; the exact matching logic, rule capabilities, and handling of uncorrelated accounts vary by vendor and configuration.

Why it matters

Account correlation is foundational to access visibility in an IGA program. Without it, accounts discovered across source systems remain orphaned data points, and the organization cannot answer a basic governance question: which real person owns and controls a given login. When accounts are correctly correlated to identity records, scattered access across directories, applications, and platforms can be consolidated into a single view per individual, which is a prerequisite for meaningful access reviews, certifications, and segregation-of-duties analysis.

Poor or incomplete correlation directly undermines downstream governance. Accounts that fail to correlate typically fall into an uncorrelated or orphaned pool, and depending on vendor and configuration these accounts may escape access reviews or ownership validation entirely, leaving unmonitored access in the environment. Conversely, incorrect correlation can attribute access to the wrong person, distorting certification decisions and audit evidence. Because correlation quality determines the completeness and accuracy of the identity picture, it materially affects an organization's ability to demonstrate who has access to what.

The handling of accounts that lack a strong, directly matchable attribute is a common source of gaps. Service accounts, legacy logins, and accounts created with inconsistent naming conventions may not align cleanly with any identity attribute, and how those cases are resolved, through custom rules, manual assignment, or being left uncorrelated, varies by platform and deployment. Getting this right is what separates a governance dataset that auditors can trust from one that quietly omits meaningful access.

Who it's relevant to

Identity Governance Leads
Correlation quality determines whether access reviews and certifications reflect a complete, accurate picture of who owns which accounts. Governance leads rely on correctly correlated data so that certification campaigns and ownership validation cover the right accounts and attribute access to the right individuals.
IAM Engineers
IAM engineers design and maintain correlation configurations, choosing the attributes used for matching and, where needed, authoring custom rules for accounts that lack a strong, directly matchable attribute. They also own the process for triaging accounts that remain uncorrelated after automated matching.
Compliance and Audit Officers
Auditors depend on correlation to establish that access data can be traced back to accountable individuals. Uncorrelated or mis-correlated accounts represent gaps or errors in access evidence, so compliance officers should understand how uncorrelated accounts are handled in a given deployment.
System Administrators
Administrators managing source systems influence correlation success through the consistency of account attributes and naming conventions. Accounts such as service or legacy logins that do not align cleanly with identity attributes often require attention to be correlated or explicitly managed.

Inside Account Correlation

Correlation Identifier
The attribute or set of attributes (such as employee ID, email, userPrincipalName, or a normalized username) used to match accounts across disparate systems to a single identity. In most deployments the choice of a stable, unique identifier is the primary determinant of correlation accuracy.
Authoritative Source
The system of record (often an HR system or primary directory) whose identity records serve as the anchor against which accounts discovered in target systems are correlated. Correlation typically joins downstream accounts to this authoritative identity rather than to each other.
Matching Logic
The rules or algorithms that determine whether a discovered account belongs to an existing identity. This can range from exact attribute matching to multi-attribute or fuzzy matching, depending on data quality and configuration.
Orphan and Unmatched Accounts
Accounts that fail to correlate to any known identity. These are surfaced as exceptions for investigation, as they may represent orphaned access, service accounts, or data-quality gaps in the correlation attributes.
IGA Context
Account correlation is an identity governance and administration (IGA) concern that supports downstream processes such as provisioning reconciliation, access reviews, and certification. It is distinct from runtime access enforcement and does not itself validate tokens or make real-time authorization decisions.

Common questions

Answers to the questions practitioners most commonly ask about Account Correlation.

Is account correlation the same as identity provisioning?
No. Account correlation is the process of matching existing accounts discovered in a target system to an authoritative identity, typically during onboarding a system into an IGA platform or during reconciliation. Provisioning, by contrast, creates, updates, or deactivates accounts based on identity data. Correlation determines which accounts already belong to which identities; provisioning acts on that relationship afterward. Blurring the two leads to duplicate accounts or orphaned entitlements, so most IGA deployments treat correlation as a distinct step that precedes and informs provisioning and reconciliation.
Does account correlation authenticate users or determine their access rights?
No. Correlation is neither authentication nor authorization. It is an identity governance and administration activity that links an account record to an identity record so that lifecycle and certification processes can operate on it. Authentication verifies who a principal is at runtime, and authorization determines what that principal may do; correlation happens outside those runtime flows. A correlated account still relies on separate authentication mechanisms to establish a session and on access control decisions to enforce entitlements.
What attributes are typically used as correlation keys?
Correlation logic typically relies on one or more matching attributes such as employee ID, email address, username, or a normalized name. In most deployments a unique, stable identifier like an employee or HR record ID produces the most reliable matches, while weaker keys such as display names risk false correlations. Many platforms support layered rules, attempting an exact match on a strong key first and falling back to secondary attributes, depending on configuration.
How are accounts that fail to correlate handled?
Accounts that do not match any identity are commonly flagged as unmatched or orphaned and routed for manual review or exception handling. Depending on policy and configuration, they may be assigned to a service or non-human identity, manually correlated by an administrator, or targeted for remediation such as deactivation. Treating uncorrelated accounts as governance exceptions helps address segregation-of-duties and access review gaps, since an account with no owning identity cannot be reliably certified.
How does correlation relate to reconciliation in an IGA platform?
Correlation is generally a component of the broader reconciliation process. Reconciliation compares the actual state of accounts and entitlements in a target system against the expected state derived from identity data. Correlation supplies the account-to-identity mapping that reconciliation needs before it can detect discrepancies such as orphaned, rogue, or missing accounts. In most deployments an initial correlation pass runs when a system is first connected, and ongoing reconciliation re-evaluates matches as data changes.
Can correlation rules produce incorrect matches, and how is that mitigated?
Yes. Weak or ambiguous matching attributes can cause false positives, where two distinct identities are linked to one account, or false negatives, where a legitimate account is left uncorrelated. Mitigations typically include prioritizing strong unique keys, normalizing attribute values before comparison, requiring manual confirmation for low-confidence matches, and reviewing correlation results before they drive downstream provisioning. The appropriate balance depends on the sensitivity of the target system and the quality of the source identity data.

Common misconceptions

Account correlation authenticates users or verifies who they are at sign-in.
Correlation is an identity governance and administration activity that associates existing accounts to an identity record for lifecycle and review purposes. It is separate from authentication, which verifies a principal at runtime, and from authorization, which determines what a principal may do.
Correlation and provisioning are the same thing.
Provisioning creates, updates, or deactivates accounts, while correlation matches already-existing accounts to a known identity. Correlation typically supports reconciliation and detection of orphan accounts rather than performing the account creation itself.
A single correlation rule will match all accounts reliably.
Correlation accuracy depends heavily on data quality and attribute consistency across systems. In most deployments some accounts remain unmatched and require exception handling, and multiple or fallback matching strategies are often needed.

Best practices

Select a stable, unique correlation identifier (such as an employee ID) where available, rather than mutable attributes like display name or email that may change over time.
Establish and maintain an authoritative source as the anchor for correlation, and reconcile discovered accounts against it rather than correlating target systems directly to one another.
Define explicit handling for unmatched and orphan accounts so they are surfaced as exceptions for investigation instead of being silently ignored.
Use layered or fallback matching logic where a single attribute is insufficient, and document the precedence of matching rules to make results auditable.
Regularly review and remediate data-quality issues in correlation attributes, since accuracy depends on consistency across the connected systems.
Keep correlation results tied to downstream IGA processes such as access reviews and certification, and treat correlation as separate from runtime access enforcement.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide