It's March. An employee resigns. HR marks them as terminated in Workday. An IT ticket is raised to disable the account. The Active Directory account is disabled the same day — good. But the Okta account? Still active. And there's a service account on the legacy ERP system they provisioned eighteen months ago, still using their email as the owner, still authenticating. And they were a member of the "Finance-Approvers" security group — a group that can approve payment runs up to £50,000. Nobody removed them when they left.
Three months later, the annual access review catches it. If you even have one.
This is identity drift. And it isn't a rare edge case. It is the default state of almost every enterprise identity environment that hasn't invested in continuous monitoring.
What Is Identity Drift?
Identity drift is the delta between what your identity governance policy says should exist and what actually exists across your connected systems.
It's not a single problem — it's a category of problems that compound over time:
Existence drift — Accounts that should be disabled or deleted remain active. Terminated employees, expired contractors, decommissioned service accounts. The account exists, but according to policy it shouldn't.
Privilege drift — Permissions that exceed what a role or policy allows. A user who moved from Finance to Engineering still holds access to the financial reporting system. A service account that started with read-only access has accumulated write permissions through incremental administrative changes.
Temporal drift — Accounts that have aged past policy thresholds. No login in 90 days. A password that hasn't been rotated in 365 days. An API key created for a project that ended two years ago.
Attribute drift — Account attributes — department, manager, job title, cost centre — that are mismatched between the authoritative source (typically your HRIS) and downstream systems (Active Directory, Entra ID, Okta, SaaS platforms). The user's manager changed six months ago. The directory still shows the old one.
Each category of drift is independently exploitable. Together, they represent your actual attack surface — not the theoretical attack surface described in your policy documentation.
Why Drift Accumulates
The optimistic explanation for identity drift is that joiner/mover/leaver processes are imperfect. The realistic explanation is that they are fundamentally manual, and manual processes degrade under operational pressure.
Consider what has to go right for a clean leaver process: HR marks the termination. The ITSM ticket is auto-created or manually raised. IT sees it in time and action it. Every system the user had access to is captured in that ticket. Service accounts they owned are identified and reassigned. Group memberships are audited and removed. SaaS access that was provisioned outside the formal process — the Slack workspace someone invited them to directly, the Confluence space they were added to for a project — is found and revoked.
In practice, this rarely happens completely. Systems don't talk to each other. Service accounts don't have discoverable owners. Shadow IT exists by definition outside the visibility of IT governance. Acquisitions bring in populations of identities with no mapping to existing policy. And the "we'll clean it up later" ticket moves to the backlog and is never revisited.
The result: drift accumulates at every organisational transition. Each joiner, mover, and leaver contributes to it. Without continuous detection, it compounds silently.
Why Identity Drift Is a Security Problem
This is where the stakes become concrete. Identity drift isn't an audit finding or a compliance gap in the abstract — it is the attack surface that adversaries exploit.
MITRE ATT&CK Technique T1078 (Valid Accounts) is one of the most commonly observed techniques in real-world intrusions. Attackers don't need to find a zero-day if a legitimate credential is sitting dormant and unmonitored. Existence drift is an open invitation.
Privilege escalation via accumulated access (T1134, T1098) frequently relies not on technical exploitation but on discovering that a compromised account already has more access than it should. Privilege drift delivers that directly.
Persistence — an attacker maintaining a foothold after initial access is evicted — often relies on a secondary account or service account that wasn't in scope for the incident response effort. Existence drift creates exactly these footholds.
The numbers are not abstract. IBM's Cost of a Data Breach report consistently places mean breach dwell time — the time between initial compromise and detection — above 200 days. In that window, attackers using legitimate drifted credentials look indistinguishable from normal users. They are not triggering malware detections. They are not generating signature-based alerts. They are logging in with valid credentials to systems they have legitimate-looking access to.
Identity drift is the precondition. Long dwell time is the consequence.
How to Detect Drift
Detecting identity drift requires two things: an authoritative source and a comparison mechanism.
The authoritative source is typically your HRIS (Workday, BambooHR, HiBob) for human identity attributes, and your IGA platform (SailPoint, Saviynt, Omada) for access policy. These systems define what should exist.
The comparison mechanism is a system that can read the current state of every downstream system — Active Directory, Entra ID, AWS IAM, Okta, your SaaS estate — and compare it against what the authoritative source says.
For each identity, the comparison asks: does the canonical record match what the downstream systems say? Does the account exist where it should? Does it not exist where it shouldn't? Do the permissions match the role policy? Have the attributes propagated correctly from the HRIS?
Where they don't match — that's drift. Each mismatch is a finding. Each finding has a severity: a stale Global Administrator account is not the same risk as a stale attribute on a standard user account.
How IdentityFirst Detects Drift
IdentityFirst builds a unified identity graph by ingesting data from all connected sources — HR, IGA, directories, cloud IAM, SaaS connectors. Each source record is normalised and mapped to a CanonicalIdentity: a single record representing a real-world identity across all its digital representations.
The DriftEngine runs after the identity graph is built. It compares the current CanonicalIdentity records against the state captured in the previous run, and against the expected state defined by your connected policy source. Each mismatch becomes a DriftFinding — typed by drift category, attributed to the specific identity and source system, and assigned a severity score based on the risk weighting of the permissions involved.
Findings are surfaced in the assessment report with remediation recommendations. High-severity findings — stale privileged accounts, active accounts for terminated employees with elevated access — are flagged for immediate action. The platform tracks findings across runs: a finding that was present in the last run and is still present in the current run is escalated in severity, because persistence increases risk.
The entire process runs continuously, not on a quarterly schedule.
What to Do About It
Start with visibility. You cannot fix what you cannot see, and most organisations significantly underestimate the volume of drift in their environment until they measure it. A first drift assessment consistently surfaces surprises: accounts that IT believed were disabled, permissions that no one recalled granting, service accounts with no discoverable owner.
Once you have visibility, prioritise by severity:
Stale privileged accounts — Global Admins, Domain Admins, PAM accounts for departed users. These are your highest-risk findings and should be your first remediation target.
Stale standard accounts — Active user accounts for terminated employees with standard access. Lower severity individually, but often high in volume.
Stale service accounts — Accounts with no human owner, often with broad permissions in legacy systems. Harder to remediate because reassignment requires operational investigation.
Attribute mismatches — Department, manager, and role attribute drift. Lower immediate security risk, but material for compliance and for ensuring downstream access decisions (group membership, Conditional Access policy) are made on accurate data.
Then build the processes that prevent drift from accumulating in the first place: automated deprovisioning triggered by HRIS termination events, periodic access reviews with documented reviewer decisions, policy-driven attribute synchronisation that propagates HRIS changes to all downstream systems within hours, not weeks.
Drift is not a one-time problem to solve. It is an ongoing consequence of organisational change. The organisations that manage it well are not the ones that run the best cleanup projects — they are the ones that make drift detection a continuous operational process.
See Your Drift Today
IdentityFirst connects to your identity sources and surfaces your first drift report on day one of your trial. Free for 14 days, no infrastructure changes required.
Start your trial at identityfirst.net/demo. Your drift is already there — you just can't see it yet.