← All terms
Identity Reconciliation

What is Identity Reconciliation?

Identity reconciliation compares accounts in target systems against authoritative identity data to find orphaned, rogue, and mismatched accounts and fix them.

Last updated: 15 July 2026

How identity reconciliation works

Reconciliation is a comparison between two pictures of the truth. On one side is the authoritative source — typically HR data and the central directory — describing who should exist and what they should hold. On the other side are the accounts and permissions that actually exist in each connected application.

The reconciliation engine correlates accounts to identities using matching rules: employee IDs, email addresses, usernames, or combinations of attributes. Every account then falls into a category — correctly matched, orphaned (no owning identity), rogue (created outside the provisioning process), or drifted (attributes or entitlements differ from what policy says they should be).

Discrepancies trigger responses: automatic correction, disabling the account, or routing the case to a human for a decision. Reconciliation typically runs on a schedule and after bulk changes such as migrations.

Why reconciliation matters

Provisioning automation only controls the changes it makes itself. Administrators still create accounts directly in applications, integrations fail silently, and migrations leave debris. Without reconciliation, the identity system's picture of reality drifts further from the truth every day.

The accounts reconciliation finds are precisely the dangerous ones. Orphaned accounts belonging to departed employees are a classic attack vector, and rogue accounts created outside process are invisible to access reviews. Auditors increasingly ask not just "do you deprovision leavers" but "how would you know if an account escaped that process".

Implementing reconciliation well

Correlation rules are the heart of the exercise. Prefer stable, unique keys such as employee IDs over fragile ones like display names, and define an explicit queue for accounts that cannot be matched automatically rather than letting them accumulate unseen.

Decide response policies per system: in low-risk applications drift can be auto-corrected, while in critical systems a human should confirm before an account is disabled. Track the orphan and rogue counts over time — a healthy program drives them toward zero and keeps them there. Monosync performs this correlation across AD, LDAP, HR, and SQL sources, flagging unmatched accounts and producing audit reports usable as evidence for SOC 2 and ISO 27001 programs.

Frequently asked questions

What is the difference between reconciliation and synchronization?
Synchronization pushes changes from a source to targets so systems stay aligned. Reconciliation is the audit in the other direction: it reads what actually exists in targets and compares it against what should exist. Sync keeps systems aligned; reconciliation proves they are and catches whatever slipped through.
How often should reconciliation run?
Daily or weekly scheduled runs are typical for most systems, with more frequent runs for critical applications. Reconciliation should also run after events that commonly create drift: migrations, mergers, directory restructures, or recovery from an integration outage.
What should happen to orphaned accounts found during reconciliation?
Disable first, delete later. Disabling immediately removes the risk while preserving data and the ability to investigate ownership. After a defined retention period with no legitimate claim, the account and its entitlements can be removed permanently, with the decision recorded in the audit trail.