Manual edits, local exceptions, and duplicate ownership create entitlement drift. Downstream services start to reflect conflicting states, so provisioning becomes inconsistent and offboarding misses accounts that should have been removed. The practical failure is not just inefficiency, but lingering access that no one can confidently reconcile across systems.
Why SCIM Breaks Without a Single Source of Truth
SCIM works best when it is fed by one authoritative identity record, because the protocol is designed to synchronize a target system with a source system, not arbitrate between competing masters. When HR, an app admin, and a local directory can all change the same identity state, SCIM becomes a transport layer for inconsistency rather than a control point for lifecycle management.
That is why the failure mode is usually not a single bad sync. It is a steady accumulation of conflicting attributes, manual exceptions, and mismatched entitlement state that makes provisioning behavior hard to predict across systems.
What Becomes Inconsistent in Practice
The most visible break is that create, update, and deactivate events no longer mean the same thing everywhere. One system may treat the identity as active, another may still hold an old username or group membership, and a third may have already removed access based on a different record. A SCIM connector can move data reliably and still produce the wrong outcome if the upstream source is fragmented.
This is why provisioning drift often shows up as duplicate accounts, stale group memberships, and contradictory ownership records. The most common pattern is that local fixes are made to solve an immediate business problem, then those fixes quietly bypass the central lifecycle logic that was supposed to keep the estate aligned.
Why Offboarding and Auditability Suffer
Offboarding is where single-source failure becomes most dangerous, because revocation depends on confidence that the deactivate signal reaches every relevant system and is not overwritten by another source later. When multiple systems can assert their own version of truth, a user may appear removed in one console while retaining access somewhere else, which is exactly the kind of lingering entitlement that is hardest to defend during review.
SCIM and Automated Provisioning Guide is useful here because it explains both the intended provisioning flow and the common integration failures that appear when SCIM is treated as a standalone fix. The broader lifecycle problem is also covered in Joiner-Mover-Leaver (JML) Guide, which frames provisioning and deprovisioning as one continuous lifecycle rather than separate admin tasks.
Risk and Threat Considerations
When there is no single identity source of truth, the security risk is persistent overprovisioning and failed revocation. The environment can look controlled at the directory layer while downstream services continue to honor stale entitlements, which creates a hidden access path that is difficult to reconcile after the fact.
Failure mechanism: Conflicting masters let manual edits, local exceptions, and delayed syncs overwrite lifecycle decisions, so access removal does not propagate consistently and orphaned or duplicate accounts remain live.
Impact: Attackers and insiders benefit from longer access dwell time, while defenders lose confidence in whether offboarding actually worked across the full application stack.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SCIM lifecycle depends on managed credential and token changes across systems. |
| AC-2 — Account Management | The question is about creating, updating, and removing accounts from one authoritative source. | |
| AU-2 — Event Logging | Conflicting identity state requires audit evidence to reconcile who changed what and when. | |
| Recommendation — Apply IA-5 to rotate and revoke provisioning credentials and tokens on a controlled lifecycle. Use AC-2 to centralize account provisioning, modification, and deprovisioning decisions. Use AU-2 to log provisioning, exception, and deprovisioning events for reconciliation. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Single-source identity governance directly supports controlled identity lifecycle and ownership. |
| A.5.18 — Access rights | The issue is lingering or conflicting access rights across downstream services. | |
| Recommendation — Define one authoritative identity lifecycle process and enforce it across connected systems. Review and revoke access rights from the authoritative identity record, not local exceptions. | ||
Practitioner Guidance
What to verify: Treat the source-of-truth decision as an architectural control, not a process preference. Verify that every authoritative attribute, especially status, manager, department, and entitlement ownership, has exactly one write source and that all other systems are downstream consumers.
Decision rule: If a system can change identity state locally, decide whether that exception is temporary and explicitly owned, or whether it is a design defect that should be removed. Unowned exceptions are usually the point where SCIM drift starts.
Practitioner takeaway: SCIM does not fail because synchronization is impossible, it fails because lifecycle authority is split, and once authority is split, offboarding becomes probabilistic instead of provable.
Related resources from NHI Mgmt Group
- What breaks when identity reviews do not have a single source of truth?
- What breaks when offboarding is not tied to the source identity record?
- What breaks when identity is tied too tightly to a single device?
- What breaks when digital identity data is tied too closely to a single device or private key?