When should organisations revoke third-party access credentials?

Why This Matters for Security Teams

Third-party access credentials should be treated as time-bound trust, not as a permanent convenience. The moment a supplier’s scope changes, a support engagement closes, or an integration is no longer actively validated, the security case for continued access weakens. This is where NHI governance, PAM, and RBAC often diverge in practice: RBAC can describe who should have access, but it does not prove the credential still matches a current business purpose.

That distinction matters because standing access expands blast radius. The Guide to the Secret Sprawl Challenge shows how credentials accumulate across tools, pipelines, and vendors until no one can confidently say which secrets are still needed. The broader pattern is visible in the 52 NHI Breaches Analysis, where poor lifecycle control turns access into an incident multiplier. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST SP 800-63 Digital Identity Guidelines both reinforce that identity assurance is not just issuance, but also timely removal and revalidation.

In practice, many security teams discover stale third-party credentials only after a vendor change, not through deliberate review.

How It Works in Practice

The safest operating model is simple: every third-party credential needs an owner, a purpose, an expiry or review date, and a revocation trigger. In a mature NHI program, the question is not whether a supplier once needed access, but whether the access still maps to a current service ticket, contract scope, or approved integration. When that mapping disappears, the credential should be removed or replaced with a narrower, shorter-lived alternative.

That is why dynamic secrets and Ultimate Guide to NHIs — Static vs Dynamic Secrets are so important. Static secrets tend to survive the business need that created them, while JIT credentials reduce exposure by issuing access only when the task is active. The Ultimate Guide to NHIs frames this as a lifecycle problem, not a one-time provisioning decision. In practice, teams should combine PAM with secret inventory, approval workflows, and automated checks that compare active access against contract status, repo activity, ticket closure, or vendor attestations.

• Revalidate on a fixed cadence and after every material scope change.
• Revoke immediately after incident response, offboarding, or failed revalidation.
• Prefer short-lived, explicitly scoped credentials over shared long-lived secrets.
• Log revocation decisions so audit teams can prove access removal was intentional.

This guidance tends to break down in legacy integrations where a vendor credential is hardcoded across multiple systems and no authoritative owner exists.

Common Variations and Edge Cases

Tighter revocation controls often increase coordination overhead, so organisations must balance security with operational continuity. That tradeoff is real when a third party supports production workloads, emergency break-glass access, or multi-environment automation that cannot tolerate frequent disruption. Current guidance suggests those cases still need revocation discipline, but with stronger change control, separate emergency paths, and more granular scoping rather than indefinite standing access.

One common exception is a vendor relationship that is technically active but operationally idle. If the account remains enabled because of a “just in case” rationale, that is not an exception to revoke rules. It is usually a sign the organisation has not separated business necessity from convenience. Another edge case is shared service access across multiple applications. In those environments, revocation should be preceded by dependency mapping so one stale credential removal does not interrupt unrelated services. The Guide to the Secret Sprawl Challenge is useful here because it highlights how quickly dependency chains become invisible. The Shai Hulud npm malware campaign also illustrates why exposed secrets should be treated as revocation candidates, not just rotation candidates, especially when supply-chain compromise is suspected.

There is no universal standard for revocation timing beyond the principle that access should end when justification ends. In practice, the right answer is to shorten credential lifetimes until the organisation can defend every remaining exception on business and technical grounds.

Related resources from NHI Mgmt Group

• When should teams review third-party healthcare app access?
• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• How should organisations govern third-party identity access more tightly?