Vendor privilege drift

Vendor privilege drift is the gradual expansion of external access beyond the original purpose, followed by weak revocation when the work changes or ends. It often appears when ownership is unclear, inventories are incomplete, and access reviews focus on contracts instead of actual usage.

Expanded Definition

Vendor privilege drift is the slow, often invisible expansion of a third party’s access beyond the original business need. In NHI security, it typically involves service accounts, API keys, OAuth grants, or support access that remains active after the vendor’s role changes, scope narrows, or the engagement ends. The risk is not just excessive privilege at issuance, but failure to continuously align access with actual use.

Definitions vary across vendors, but the common pattern is the same: access is approved for a project, then inherited by follow-on work, renewals, and exception handling until nobody can explain why it still exists. That is why NHI Management Group treats vendor privilege drift as a lifecycle control issue, not only a procurement problem. The OWASP Non-Human Identity Top 10 frames this as a recurring exposure tied to poor secret and entitlement governance, while the Ultimate Guide to NHIs — Key Challenges and Risks highlights how weak visibility turns temporary access into durable attack surface.

The most common misapplication is treating contract renewal as proof that the same privileges are still required, which occurs when access reviews check vendor status instead of live usage.

Examples and Use Cases

Implementing controls for vendor privilege drift rigorously often introduces review overhead and remediation friction, requiring organisations to weigh faster vendor delivery against tighter access governance.

• A SaaS implementation partner receives admin API keys during migration, then keeps the same access long after the platform goes live because no one re-baselines the scope.
• A managed security vendor is allowed read-only access for monitoring, but later gains write permissions through a temporary troubleshooting exception that never expires.
• A development contractor uses a shared automation account for one integration, then the account is reused across multiple environments without a fresh approval trail.
• A support provider’s OAuth token remains valid after the engagement ends, similar to the pattern described in the Salesloft OAuth token breach, where lingering delegated access became the path of least resistance.
• An identity team aligns revocation with offboarding, rotation, and entitlement reviews using guidance from the OWASP Non-Human Identity Top 10 rather than relying on vendor attestations alone.

Vendor privilege drift also shows up in multi-party delivery chains, where subcontractors inherit the original vendor’s access and no one maintains a complete inventory of who can still reach production systems. That is especially common when secrets are embedded in CI/CD tooling or ticket-based exceptions are used to bypass formal provisioning.

Why It Matters in NHI Security

Vendor privilege drift matters because third-party access is one of the easiest ways for excessive NHI permissions to accumulate without immediate visibility. NHI Management Group research shows that 92% of organisations expose NHIs to third parties, and that 97% of NHIs carry excessive privileges, which means vendor access is not a corner case but a primary risk channel. When drift persists, it weakens Zero Trust assumptions, undermines least privilege, and creates ambiguity about who is accountable when an access path is abused.

This is also where governance failures become breach conditions. If ownership is unclear, inventories are incomplete, and revocation is delayed, a vendor account can remain active long after the work it was created for has ended. The Ultimate Guide to NHIs — The NHI Market reinforces that third-party NHIs are now a routine part of enterprise operations, not an edge case. In practical terms, vendor privilege drift turns a valid business relationship into a hidden persistence mechanism.

Organisations typically encounter the consequences only after a vendor leaves, a contract changes, or a token is found still active during an incident, at which point vendor privilege drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Privilege Creep
• Privilege Inflation
• How can security teams reduce privilege drift in Kubernetes RBAC?
• How can security teams reduce privilege drift in AWS IAM?