Supplier Access Drift

Expanded Definition

Supplier access drift describes a control failure in third-party access governance, not just a procurement problem. It appears when a supplier’s originally approved access scope is not continually revalidated as work changes, so accounts, tokens, and permissions outlive the business purpose they were meant to serve. In identity-heavy environments, this often affects service accounts, API keys, and delegated admin access, where renewal is informal and ownership becomes unclear. The issue sits at the intersection of IAM, PAM, and NHI governance because suppliers frequently use machine credentials with broad reach and weak lifecycle discipline.

Definitions vary across vendors, but the security meaning is consistent: access expands quietly over time and no one restores the original boundary. That is why NHI Management Group treats supplier access drift as a lifecycle and authorization problem, not a one-time onboarding defect, especially where OWASP Non-Human Identity Top 10 concerns around secret exposure and excessive privilege apply. The most common misapplication is assuming a contract end date automatically ends access, which occurs when offboarding is not linked to identity and credential revocation workflows.

Examples and Use Cases

Implementing supplier access controls rigorously often introduces operational friction, requiring organisations to weigh fast vendor delivery against stricter approval, review, and revocation steps.

• A cloud integrator receives temporary read-only access for deployment, then later accumulates write access to production data during a support incident and never loses it after the project closes.
• A SaaS supplier keeps an OAuth token active across multiple renewals, but the token scope is never reduced when the original integration changes, creating excess exposure. NHIMG’s Salesloft OAuth token breach illustrates how token persistence can become a live attack path.
• A contractor account is reused across teams because “the same vendor still needs access,” even though the underlying service work moved to another supplier months ago.
• A support partner is granted emergency admin rights in a staging environment and then later uses the same access path to troubleshoot production, bypassing the original change-control intent.
• Security teams discover that a supplier’s API key still works long after the statement of work ended, because the key was embedded in a pipeline and never rotated or disabled.

These patterns are consistent with the broader NHI lifecycle problems documented in Ultimate Guide to NHIs, where access often persists after the original business need disappears. The same governance logic maps to NIST SP 800-53 Rev 5 Security and Privacy Controls because periodic review and credential lifecycle controls are what prevent supplier permissions from drifting unchecked.

Why It Matters for Security Teams

Supplier access drift matters because third-party access is a common path from legitimate business relationship to unintended exposure. When privileges accumulate, security teams lose confidence that least privilege still holds, and incident responders must treat supplier accounts as potentially over-scoped until proven otherwise. That increases the blast radius of credential compromise, weakens segregation of duties, and makes offboarding a control activity rather than an administrative clean-up task. NHIMG research shows that 92% of organisations expose NHIs to third parties, raising the likelihood that supplier relationships will create hidden credential sprawl across environments.

The risk becomes sharper when supplier access includes NHI assets such as service accounts, tokens, certificates, or automation keys. If those identities are not tied to clear owners, expiry dates, and rotation requirements, they can survive long after the commercial relationship has changed. This is where security teams need visibility across contracts, IAM, PAM, and secret stores, not just user directories. The operational lesson is straightforward: organisations typically encounter supplier access drift only after an audit finding, a breach, or a vendor dispute, at which point revocation and containment become operationally unavoidable to address.

For governance teams, the practical benchmark is whether access can be proven necessary, bounded, and revocable at every stage of the supplier relationship. If not, the environment is already drifting beyond the approved trust boundary.

Related resources from NHI Mgmt Group

• How should security teams handle third-party access that looks legitimate after a supplier breach?
• How can IAM teams reduce risk from supplier access and machine identities together?
• Who is accountable for access drift when protocol-specific controls create exceptions?
• How should organisations phase an IGA programme without creating more access drift?