Provisioning drift is the gap between the access state an organisation intends and the access state that actually exists in applications. It appears when manual workflows, delayed syncs, or custom integrations cause permissions to diverge from the source of truth.
Expanded Definition
Provisioning drift is the operational mismatch between intended access and the access that actually exists across applications, directories, and SaaS platforms. In NHI environments, it most often emerges when service accounts, API keys, or workload identities are created, updated, or removed through manual steps, delayed synchronization, or brittle custom integrations rather than a single governed lifecycle. It is closely related to identity lifecycle control, but it is not the same as ordinary entitlement sprawl: drift specifically describes divergence from the source of truth after provisioning decisions have already been made.
Definitions vary across vendors on whether drift includes only permission changes or also account state, ownership, and credential age. NHI Management Group treats it as a governance problem because the business intent and the live access state no longer match, which weakens auditability and makes revocation unreliable. The concept aligns with lifecycle discipline described in the NHI Lifecycle Management Guide and is reinforced by the identity governance expectations in NIST Cybersecurity Framework 2.0.
The most common misapplication is assuming that successful initial provisioning guarantees ongoing correctness, which occurs when teams do not continuously reconcile live entitlements against the source of truth.
Examples and Use Cases
Implementing provisioning controls rigorously often introduces synchronization overhead, requiring organisations to weigh faster developer delivery against the cost of tighter reconciliation and change control.
- A CI/CD pipeline creates temporary deployment credentials, but a failed deprovisioning step leaves them active in production after the release window closes.
- An HR-driven offboarding workflow removes a human employee cleanly, yet the downstream service account they owned remains privileged because the application team manages it separately.
- A SaaS tenant sync updates group membership overnight, but a manual hotfix grants broader permissions in the afternoon and never gets rolled back.
- A microservice is replatformed, and its API key rotates in the vault, but old tokens stay valid in a legacy integration that was not reconfigured.
- A new control plane reflects the intended owner record, while the actual application permissions still show access inherited from an earlier project assignment.
These patterns often appear alongside broader lifecycle failures documented in Top 10 NHI Issues, and they mirror identity-state divergence risks discussed in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Provisioning drift matters because NHIs often carry machine-speed privileges that are reused continuously by applications, scripts, and agents. When the live state diverges from the intended state, access reviews become misleading, incident response slows down, and deprovisioning may fail exactly when the organisation assumes control has been removed. NHI Mgmt Group notes that only Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That gap makes drift more than an administrative nuisance, because stale access can persist long after the business owner believes it is gone.
Drift is also a common precursor to compromise when attackers exploit forgotten tokens, unreviewed service accounts, or custom integrations that were never reconciled. The security impact becomes especially visible in breach postmortems such as the Salesloft OAuth token breach, where token lifecycle control and access state integrity were central concerns. Organisations typically encounter the consequences only after a token leak, unauthorized data access, or failed offboarding event, at which point provisioning drift becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret and lifecycle management that often causes access-state drift. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential management expectations require access to match current authorization. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuously verified identity state, not once-only provisioning. |
Map provisioning workflows to current authorization and verify live access against the source of truth.
Related resources from NHI Mgmt Group
- How should teams implement SCIM provisioning without creating account drift?
- How should security teams think about a compromised integration like Drift?
- How can security teams reduce privilege drift in Kubernetes RBAC?
- What is the difference between just-in-time provisioning and just-in-time access?
