Vendor privilege persistence

Expanded Definition

Vendor privilege persistence is the governance failure that occurs when a third party retains privileged access after the business purpose has ended or materially changed. It is not just “too much access”; it is access that remains active without a current, auditable justification, making offboarding, rotation, and entitlement review central to the control model. In NHI programs, this often involves service accounts, API keys, certificates, SSH keys, or delegated admin roles tied to a vendor-operated workflow. The issue sits at the intersection of PAM, RBAC, and Zero Trust Architecture, but definitions vary across vendors because some tools focus on human vendor users while others extend the concept to machine identities and agent access. NIST’s OWASP Non-Human Identity Top 10 frames the underlying problem as excessive standing privilege and weak lifecycle control. The most common misapplication is treating vendor access as a one-time approval, which occurs when procurement or onboarding gates are recorded but deprovisioning is never tied to contract end, task completion, or key expiry.

Examples and Use Cases

Implementing vendor privilege persistence controls rigorously often introduces operational friction, requiring organisations to weigh faster support delivery against tighter access expiry and review cycles.

• A cloud integrator retains admin API keys after a migration project ends, so a forgotten token can still change production settings weeks later.
• A managed security provider keeps a VPN and privileged shell account active “for break glass,” but no one revalidates whether the contract still requires it.
• An ERP vendor is given RBAC roles for quarterly patching, yet the roles remain assigned year-round because the offboarding step was never attached to ticket closure.
• A CI/CD vendor stores secrets for deployment automation, but the keys are not rotated when the vendor’s staff or scope changes, creating hidden continuity risk. This pattern is covered in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and is consistent with the access-sprawl concerns highlighted by OWASP Non-Human Identity Top 10.
• A telecom operations partner keeps delegated monitoring credentials after a remediation window, which becomes especially dangerous when attackers abuse stolen credentials as seen in NHIMG’s Salt Typhoon US telecoms breach.

Why It Matters in NHI Security

Vendor privilege persistence matters because it converts temporary trust into standing access, which expands blast radius and undermines Zero Trust assumptions. In practice, the problem is often invisible until a breach review reveals that a vendor account, token, or certificate was still valid long after the job ended. That is exactly why NHIMG emphasises lifecycle governance in the Ultimate Guide to NHIs — The NHI Market: only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. In other words, persistence is usually not a one-off failure. It is the predictable result of weak ownership, poor inventory, and missing expiry enforcement. Security teams should treat vendor access as time-bound by default, with automatic revocation, documented reapproval, and continuous review. Organisations typically encounter the consequences only after an incident review, at which point vendor privilege persistence becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Privilege Creep
• Privilege Inflation
• What is the principle of least privilege and how does it apply to NHIs?
• What is Zero Standing Privilege (ZSP) and how does it apply to NHIs?