Access Drift: How Continuous Identity Reconciliation Prevents It

Last Updated date: October 13, 2026

Identity governance is built on the assumption that the account inventory inside the platform matches what is actually live inside connected applications. The moment that assumption breaks, every downstream control breaks with it. Reviews certify access that no longer exists. Risk scores miss permissions that were granted directly inside an app. Auditors find accounts that the governance program never knew about.

The disparity in this case isn't small. According to the Orchid Security's Identity Gap: 2026 Snapshot report, which was based on telemetry from thousands of enterprise apps in both North America and Europe; there are more identities outside of an organizations' IAM systems than within them (57% vs. 43%). Over half of all enterprise apps have multiple ways to authenticate through their respective apps that do NOT utilize the organization's central identity provider.

The technical name for that gap is access drift. It happens quietly, in the spaces between scheduled review cycles, every time a developer grants a permission directly inside an application, an admin creates an account outside provisioning, or a contractor's status changes in the identity provider but lingers untouched in the apps they use.

Identity Confluence closes that gap through continuous identity reconciliation, comparing what the platform knows against what the application actually holds, on every sync cycle, and surfacing every mismatch in a structured way.

TL;DR

Access drift is the silent gap between what your governance platform thinks exists and what the application actually holds
Most drift accumulates between quarterly reviews, when permissions are added directly inside apps or accounts are created outside provisioning
Continuous reconciliation runs on every sync cycle, comparing the identity provider list against the live application account list
Every mismatch sorts into one of four buckets so admins know exactly what action each one needs
The output feeds reviews, risk scoring, ownership, and audit evidence with a current, accurate inventory

Where Does Access Drift Actually Come From?

Drifts do not occur in isolation; there are many smaller drifts taking place over time and during different cycles.

A developer requires elevated permissions to release a fix and obtains them from the application administrator directly, without going through any process for access requests. A contractor's IDP role changes once their contract expires; however, his/her application account stays active since nobody triggered the de-provisioning process. A new service account is created within an integrated application for an integration project and does not have any entry within the governance platform. Role changes within the application increase a certain user's scope of work, and such changes are never documented in Identity Confluence.

Each of these is small. Together, they produce the excessive permissions and orphaned accounts that audits keep finding. The same research puts numbers on both: 70% of enterprise applications hold an excessive number of privileged accounts, and 40% of accounts belong to users who no longer appear in HR systems.

By the time the quarterly review runs, the picture inside the governance platform no longer matches reality, and the reviewer is certifying access that has already changed.

Point-in-time reconciliation (the kind that runs once a quarter or once a year) cannot fix this. It catches drift only after months of accumulation, when the volume of mismatches is too large to remediate quickly, and its fix must be continuous.

Why The Timing Of Reconciliation Decides The Workload

How Continuous Reconciliation Works

Continuous reconciliation runs the comparison itself on every sync cycle, not on a calendar. The mechanics are the same as the foundational discovery process covered in our discovery and classification deep dive but applied as an ongoing control rather than a one-time inventory.

How Continuous Identity Reconciliation Works

For each onboarded application, the Identity Confluence gathers two lists. First is the list of active identities from the identity provider (Okta, Azure AD, Ping, and more). Second is the list of all live accounts within the on-boarded application. Each account of the onboarded application is then matched to the identity provider by email, and each match is categorized into one of the four categories that are visible in the Reconciliation tab of the Application Detail page.

Accounts in Sync

The email is present at the identity provider level as well as the application level, and the access is consistent with what is expected by the platform. No drift signal? In a healthy environment this bucket holds the large majority of accounts, and its size is itself a health indicator

Permission Mismatch

The email matches, but the access level inside the application differs from what the identity provider assigned. This is the classic drift signal. Someone gave the account access directly inside the app, or a role definition changed without flowing back into governance. The reviewer's job here is to decide whether the elevated access is legitimate (and update the policy) or unauthorized (and revoke it).

Orphan Accounts

The email address is active within the application but is inactive within the identity provider. This is most often the result of a contractor whose contract with the company has ended, an employee who has left the company, or a user who has deactivated within the application but whose access has never been cleaned up. Every one of these is an offboarding gap with credentials still attached - hence the reason they go straight to revocation

Potential Non-Human Identities

The email does not exist in the identity provider at all. The account was created outside the standard provisioning process. Some of these are legitimate service accounts that were never formally registered. Some are leftovers from old integrations. The admin's decision here is the same one covered in our human and non-human identity governance blog: classify it as an NHI with a named owner, map it to a human identity if it was misidentified, or deprovision it if no longer needed.

What Continuous Reconciliation Produces

The reconciled output feeds several downstream systems in Identity Confluence.

Access reviews and certification campaigns work from the current inventory rather than a stale snapshot, so reviewers spend their time on access that actually exists. The reviewing workflow itself, including bulk and offline review, operates on accurate data from the same reconciliation engine.

The identity risk score recalculates whenever reconciliation surfaces a new permission, a new orphan, or a new NHI. The connection is direct: when reconciliation catches drift early, the risk score moves early too.

Compliance evidence stays current. Every reconciliation event is logged, and the resulting account state flows into the Evidence Center as clause-level audit evidence across SOC 2, ISO/IEC 27001, and NIST, with regional frameworks including DPDPA and SAMA also supported.

For applications that cannot support a live integration, the disconnected application workflow provides a parallel path that maintains the same governance discipline through CSV-based user lists, refreshed manually but governed through the same workflows.

Want to assess your current review process first?

See how consistently access reviews are executed and where audit findings are most likely to land.

Why Reconciliation Accuracy Decides Everything Downstream

Every governance control downstream of reconciliation (reviews, certifications, risk scoring, ownership, audit evidence) is only as accurate as the inventory it runs on. A platform that reconciles on every sync cycle gives its governance program a current picture to work from. One that reconciles on a calendar gives it a snapshot that was already aging when it was taken.

That is the difference between catching access drift the day it happens and finding it three months later, when the volume is too large to remediate cleanly, and the audit window is already closing.

With Tech Prescient's Identity Confluence, you can run continuous identity reconciliation across every connected application, surface every mismatch in one of four structured buckets, and feed the result into the rest of the governance program.

FAQs

Access drift is the gap between what an account has within the governance platform and what the application allows the account. The difference between these two permissions is caused by permissions being assigned within the application, accounts being created outside of the provisioning system, or the identity provider not reflecting changes to the application.

Reconciliation compares the identity provider with the live application to see what the differences are. An access review asks a person if the access that exists for that individual is still appropriate. Reconciliation supplies the inventory the review runs on, so a review built on stale reconciliation data certifies access that may no longer exist.

On every sync cycle rather than on a calendar. Quarterly reconciliation surfaces drift only after months of accumulation, when the volume of mismatches is usually too large to remediate before the audit window closes.

The reviewer decides whether the elevated access is legitimate, in which case policy is updated to reflect it, or unauthorized, in which case it is revoked. Either way, the decision is logged as audit evidence.