Synchronisation Drift

What Synchronisation Drift Actually Means

Synchronisation drift appears when an upstream identity or access source says one thing, but a downstream application is still enforcing something different. The result is not just stale data, but a live mismatch between governance intent and operational access.

This term is useful because it describes a state problem, not a single control failure. Drift can involve delayed entitlement removal, outdated group membership, old attributes, or access that persists after the authoritative record has already changed.

Why Synchronisation Drift Matters in IAM Operations

In practice, synchronisation drift erodes confidence in the directory, the provisioning workflow, and the application’s own access state. When the recorded identity state and the enforced state diverge, organisations can no longer assume that access reviews, joiner-mover-leaver events, or attribute-based decisions are reflecting reality.

That matters most where downstream systems cache permissions, replicate attributes on a schedule, or accept only partial updates. A user or service can appear correctly deprovisioned in one system while still retaining active entitlements elsewhere, which creates a hidden control gap.

Good IAM design tries to minimise this gap by making one system authoritative for identity state and by limiting where derived copies are allowed to persist. For a broader control view of identity, privilege, and access governance, see NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines.

Common Causes of Drift

Drift usually comes from timing, dependency, or translation problems rather than a single obvious outage. Batch synchronisation, failed provisioning jobs, schema mismatches, stale caches, manual exceptions, and connector failures can all leave two systems with different views of the same identity.

It is especially common when access is distributed across SaaS applications, federation layers, and local application stores. The more places that hold copied identity attributes or derived entitlements, the more opportunities there are for state to diverge.

Where drift affects tokens, federation, or integrated SaaS access, the issue can resemble stolen or stale-authority paths that outlive the original change. NHIMG’s Salesloft OAuth token breach shows how identity state and downstream access can become dangerously misaligned when trust relationships persist longer than intended.

How to Think About Synchronisation Drift

The easiest way to understand drift is as a consistency problem across the identity lifecycle. Creation, update, deprovisioning, and attribute propagation all need to converge quickly enough that downstream systems do not keep acting on old authority.

That makes drift a governance signal as much as a technical one. If the organisation cannot prove how quickly changes propagate, which systems are authoritative, and which applications lag behind, then the access model is already operating with blind spots.

Risk and Threat Considerations

Synchronisation drift creates a durable exposure because stale access can survive after the source of truth has changed. The risk is highest when offboarding, role changes, or attribute updates are delayed across multiple systems, leaving permissions active long enough to be abused or simply forgotten.

Failure mechanism: A downstream application or cache fails to receive, process, or enforce the latest identity state, so the effective access posture no longer matches the governed record.

Impact: Organisations can end up with excessive access, delayed revocation, audit discrepancies, and a larger attack window for misuse of stale entitlements or tokens.

Practitioner Guidance

What to watch for: Treat drift as an operational control metric, not just an integration annoyance. Reconciliation delays, repeated manual overrides, and inconsistent entitlement counts between the source system and target applications are strong signs that the identity pipeline is losing fidelity.

Governance implication: Define which system is authoritative for each identity attribute and entitlement, then verify that downstream systems are actually enforcing that source within an acceptable time window. If the answer differs by application, document the exception rather than assuming the sync process is reliable by default.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• Runtime Drift
• Privilege Drift