Deployment drift is the gap between how a system is documented or intended to operate and how it actually runs in production. In identity and access management, drift can weaken trust boundaries, hide dependencies, and create failures that appear only when support or response is urgently needed.
Expanded Definition
Deployment drift describes the divergence between intended configuration and live production state. In NHI security, that includes service accounts, API keys, certificates, roles, token lifetimes, secret storage paths, and automation logic that no longer match the documented control model. The term overlaps with configuration drift, but deployment drift is broader because it captures changes in identity behavior, not just infrastructure settings. Usage in the industry is still evolving, so teams should be explicit about whether they mean application configuration, access policy drift, or runtime identity state. A practical way to understand it is through the control plane: if NIST Cybersecurity Framework 2.0 requires governed, measurable protection, deployment drift is the evidence that those controls have lost fidelity in production. It often appears after hurried hotfixes, emergency exceptions, or poorly recorded automation changes.
The most common misapplication is treating drift as a one-time compliance issue, which occurs when teams check a baseline but never verify whether identities, secrets, and permissions still match that baseline after deployment.
Examples and Use Cases
Implementing drift detection rigorously often introduces more release overhead, requiring organisations to weigh stronger assurance against slower delivery and additional review gates.
- A CI/CD pipeline rotates a secret in staging, but production keeps the old value in a fallback environment variable. The release passes tests, yet authentication fails only when traffic shifts.
- A service account is granted temporary write access during an incident and the entitlement is never removed, creating silent privilege expansion that audit logs do not immediately reveal.
- An AI agent is redeployed with a new tool connector, but the documented approval workflow still reflects the prior scope. The agent can now reach systems that the change record does not acknowledge.
- A certificate renewal succeeds in one cluster while a sibling cluster still trusts an expiring certificate chain, causing intermittent trust failures during failover.
These failures resemble the drift patterns described in the Salesloft OAuth token breach, where token handling and operational assumptions diverged from the intended trust boundary. They also align with the identity governance emphasis in NIST Cybersecurity Framework 2.0, which expects ongoing control verification rather than static documentation.
Why It Matters in NHI Security
Deployment drift is dangerous because NHI controls fail quietly. A secret may still exist but no longer be rotated, a service account may still function but now holds excess privilege, or a policy may still be approved but no longer reflect the actual dependency graph. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, so drift can spread faster than manual review can catch it. That visibility gap is exactly why Salesloft OAuth token breach matters as a cautionary case: once live authentication state departs from intended governance, attackers can exploit the gap before defenders notice. In NIST Cybersecurity Framework 2.0 terms, this undermines ongoing protection and continuous monitoring, not just initial hardening.
Organisations typically encounter deployment drift only after an outage, an unauthorized access event, or a failed recovery drill, at which point the drift itself 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 secret sprawl and unmanaged NHI credentials that drift from intended state. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed continuously, not only at release time. |
| NIST Zero Trust (SP 800-207) | 3.2 | Zero Trust requires continuous verification as identities, devices, and context change. |
Inventory NHI secrets and verify production state against approved deployment baselines.
Related resources from NHI Mgmt Group
- What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
- When should organizations reconsider the deployment of AI agents?
- Why is it necessary to address authorization challenges in AI agent deployment?
- How should security teams think about a compromised integration like Drift?
