Category: User Provisioning

Reconciliation

Also known as: Identity Reconciliation, Account Reconciliation

Simply put

In identity management, reconciliation is the process of comparing what a system believes should exist against what actually exists in a target application or directory, then flagging or fixing the differences. It is similar in spirit to how account reconciliation in finance checks that internal records match an external statement. The goal is to keep accounts and access aligned with an authoritative source of truth.

Formal definition

Reconciliation is an identity governance and administration (IGA) process that periodically detects discrepancies between the authoritative identity data held in an IGA or provisioning system and the actual account and entitlement state present in connected target systems (for example directories, applications, or databases). It typically identifies orphan accounts, rogue or out-of-band changes, missing accounts, and entitlement drift, and can either report these for remediation or trigger corrective provisioning/deprovisioning actions depending on configuration. Reconciliation is a lifecycle and governance concern focused on maintaining data alignment and detecting deviations; it is distinct from runtime access enforcement (such as PDP/PEP token validation) and, depending on the deployment, may feed downstream processes like access certification or segregation-of-duties analysis. The specifics of scheduling, matching rules, and remediation behavior vary by vendor and deployment. Note: the general concept of reconciliation as comparing records against an authoritative reference is well established (as in account reconciliation), but the IAM-specific mechanics described here are not detailed in the provided evidence and are drawn from general practitioner usage.

Why it matters

Identity systems drift over time. Accounts get created directly in a target application during an emergency, an administrator adjusts group memberships out of band, or a departed employee's account survives a failed deprovisioning job. Without a process to compare the authoritative identity data against what actually exists in connected systems, these deviations accumulate silently. Reconciliation is the control that surfaces them, turning an unknown and unmanaged access surface into a set of discrepancies that can be reviewed or remediated.

The governance stakes are significant. Orphan accounts and out-of-band entitlement grants are exactly the kind of gaps that attackers and malicious insiders exploit, and they are also the findings that auditors look for when testing whether access truly reflects an organization's authoritative source of truth. Reconciliation gives IGA programs an evidentiary basis for asserting that accounts and entitlements match policy, and it feeds downstream governance activities such as access certification and segregation-of-duties analysis.

It helps to keep the boundaries clear: reconciliation is a lifecycle and governance concern about data alignment, not a runtime enforcement mechanism. It does not decide whether a given request should be permitted at the moment of access, that is the role of policy decision and enforcement points. Instead, reconciliation ensures that the account and entitlement state on which those and other processes rely stays consistent with what the organization intends to exist.

Who it's relevant to

Identity Governance Leads

Reconciliation is a core IGA control for demonstrating that accounts and entitlements align with an authoritative source of truth. Governance leads rely on it to detect orphan accounts and entitlement drift and to feed findings into access certification and segregation-of-duties processes.

IAM Engineers

Engineers configure the connectors, scheduling, matching rules, and remediation behavior that determine how reconciliation compares target state against authoritative data. Because behavior varies by vendor and deployment, they are responsible for validating that correlation and any automated corrective actions perform as intended.

Compliance Officers and Auditors

Reconciliation produces the evidence that access reflects policy and that out-of-band changes are caught. Auditors examine reconciliation findings and remediation records to test whether accounts and entitlements match the organization's stated source of truth.

System Administrators

Administrators managing target directories and applications are often the source of, and the responders to, reconciliation discrepancies. They act on flagged orphan or missing accounts and out-of-band changes, either correcting the target or reconciling the authoritative record.

Inside Reconciliation

Source-of-Truth Comparison

The core activity of comparing account and entitlement data held in a target system against the authoritative identity source (typically an HR system or identity governance platform) to detect divergence. Reconciliation is a detective control within IGA, not a runtime enforcement mechanism.

Account Matching

The logic that correlates accounts discovered in a target system with known identities, usually via a matching key or correlation rule. Accounts that cannot be matched are typically flagged as orphaned or unmatched, depending on configuration.

Orphan Account Detection

Identification of accounts in a target system that have no corresponding active identity in the source of truth, which often indicates residual access left after a lifecycle event such as termination or transfer.

Rogue or Out-of-Band Change Detection

Detection of accounts or entitlements created or modified directly in the target system outside the governed provisioning workflow, so that they can be reviewed, corrected, or remediated.

Remediation Handling

The response to detected discrepancies, which may be automated corrective provisioning/deprovisioning or the generation of review tasks for a human approver, depending on policy and deployment configuration.

Reconciliation Modes

Reconciliation is commonly run as a scheduled batch job (full or incremental), and in most deployments is separate from real-time provisioning. Full reconciliation examines the entire target population, while incremental reconciliation processes only changes since a prior run.

Common questions

Answers to the questions practitioners most commonly ask about Reconciliation.

Is reconciliation the same as provisioning?

No. Provisioning is the act of creating, updating, or deactivating accounts and entitlements in a target system, typically driven from an authoritative source. Reconciliation is the detective process of comparing the actual state of accounts and entitlements in a target system against what the IGA system believes should exist, then flagging or remediating discrepancies. Provisioning writes intended state; reconciliation verifies actual state against intended state. In most deployments they are distinct functions, though reconciliation results may trigger corrective provisioning actions.

Does reconciliation enforce access decisions at runtime?

No. Reconciliation is an identity governance and administration (IGA) concern focused on lifecycle accuracy, not a runtime enforcement mechanism. It does not sit in the request path the way a PEP or PDP does, and it does not validate tokens or make real-time authorization decisions. Reconciliation typically runs on a schedule or event basis to detect drift between expected and actual account state; enforcement of what a principal may do at request time is handled separately by runtime access control components.

How often should reconciliation runs be scheduled?

Frequency depends on the risk profile of the target system, the rate of change, and connector capabilities. In most deployments, high-risk or high-change systems are reconciled more frequently, while lower-risk systems may be reconciled on a longer interval. Some environments combine periodic full reconciliation with more frequent incremental or event-driven runs. The appropriate cadence is a configuration and policy decision rather than a fixed standard.

What is the difference between full and incremental reconciliation?

Full reconciliation typically reads the complete set of accounts and entitlements from a target system and compares it against expected state, which is thorough but can be resource-intensive. Incremental reconciliation processes only records that have changed since a prior run, using timestamps, change logs, or similar markers where the connector and target support them. Many deployments use full runs less frequently and incremental runs more often, depending on connector capabilities and system load considerations.

How are unmatched or orphan accounts typically handled during reconciliation?

Reconciliation commonly classifies discrepancies such as accounts that exist in the target but have no corresponding identity in the IGA system (often termed orphan or rogue accounts) and identities expected to have an account that is missing. Handling depends on configured policy: some deployments flag these for manual review or certification, while others apply automated remediation such as correlation to an owner, deactivation, or corrective provisioning. The chosen response varies by risk tolerance and governance policy.

How does reconciliation relate to access certification and segregation of duties?

Reconciliation provides an accurate, verified picture of actual account and entitlement state, which downstream IGA processes such as access certification and segregation-of-duties analysis rely upon. Reviewing certifications against stale or inaccurate data undermines their value, so reconciliation is often positioned as a data-quality prerequisite. It remains a distinct function, however: reconciliation detects drift in account state, whereas certification is the periodic attestation of whether granted access remains appropriate.

Common misconceptions

Reconciliation is a real-time access enforcement control that blocks unauthorized access as it happens.

Reconciliation is a detective IGA process, typically run on a schedule, that identifies discrepancies after the fact. Real-time enforcement decisions are handled by runtime components such as a PDP and PEP, which are out of scope for reconciliation.

Reconciliation and provisioning are the same thing.

Provisioning pushes intended changes from the authoritative source to target systems, whereas reconciliation reads back the actual state of targets to detect drift from that intended state. In most deployments they are distinct, though complementary, processes.

A clean reconciliation run means access is correct and appropriate.

Reconciliation confirms that target-system state matches the source of truth; it does not by itself validate whether the granted access is business-appropriate. Access appropriateness is addressed through separate governance activities such as access certification and segregation-of-duties review.

Best practices

Define explicit account correlation rules and a policy for handling unmatched and orphaned accounts before enabling automated remediation, to avoid incorrect matches or unintended deprovisioning.

Run full reconciliation periodically to establish a complete baseline, and use incremental reconciliation between full runs to detect drift efficiently, depending on the scale and change rate of the target system.

Route out-of-band and rogue changes to a review queue rather than always auto-remediating, so that legitimate exceptions can be evaluated before corrective action is taken.

Keep reconciliation clearly separated from runtime enforcement, and treat it as a detective control that feeds governance workflows such as access reviews and certification.

Log and retain reconciliation results and remediation actions to support audit, segregation-of-duties analysis, and investigation of how discrepancies arose.

Tune remediation policy per target system, since appropriate automated versus manual handling typically varies by system criticality, data sensitivity, and vendor capability.