Because the credential still represents trust even when the relationship has ended. If revocation is incomplete, a former vendor can retain access to backups, archived data, or integrated systems that were never fully removed. This is especially dangerous when credentials sit outside the identity provider or are embedded in automation, where they are harder to find and harder to prove gone.
Why This Matters for Security Teams
Former vendor credentials are high-risk because they often outlive the business relationship that justified them. When a contract ends, teams may disable a user in one system but leave API keys, shared accounts, VPN tokens, mailbox access, backup consoles, or service principals untouched. That creates a silent trust path into systems that still contain live data, operational secrets, or administrative functions. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats access lifecycle, auditability, and system isolation as control problems, not just HR offboarding tasks.
The practical risk is not only direct misuse. Former credentials can also be reused in lateral movement, identity spoofing, or hidden automation, especially where the vendor integrated with multiple environments over time. In many organisations, the hardest part is not granting access safely but proving that every copy, token, and delegated path has been removed. In practice, many security teams encounter former vendor access only after a breach review exposes accounts that were never tied to the original offboarding workflow.
How It Works in Practice
The risk usually emerges from fragmented ownership. Procurement ends the contract, IT disables the obvious login, and the business assumes the vendor is gone. Meanwhile, the vendor may still hold standing access to S3 buckets, ticketing systems, CI/CD pipelines, remote support tools, or embedded automation used for maintenance and reporting. If credentials were issued outside the main identity provider, they can be missed by standard deprovisioning checks.
Security teams reduce this exposure by treating vendor offboarding as a complete trust revocation exercise. That means finding every identity type the vendor may have used and verifying removal across the control plane, not just the directory.
- Inventory all vendor-related accounts, tokens, certificates, and shared secrets before contract closeout.
- Revoke authentication paths in the identity provider, SaaS apps, cloud platforms, and privileged access tools.
- Rotate any secrets the vendor could have seen or stored, including API keys and service credentials.
- Review indirect access through integrations, jump hosts, support channels, and delegated admin roles.
- Confirm removal with logs, access reports, and owner sign-off rather than relying on a ticket closure.
This is where Non-Human Identity governance matters. Vendor access is often a mix of human credentials and machine identities, and the machine side is commonly missed. The OWASP Non-Human Identity Top 10 is relevant because it highlights the risks of orphaned secrets, excessive permissions, and poor lifecycle control for non-user access paths. NIST Cybersecurity Framework 2.0 also helps by framing this as an asset, identity, and resilience issue rather than a one-time admin task.
These controls tend to break down when vendor access is embedded in automation across hybrid environments because no single team can see the full access graph.
Common Variations and Edge Cases
Tighter vendor offboarding often increases operational overhead, requiring organisations to balance rapid contract closure against complete access verification. That tradeoff becomes sharper when the vendor relationship is recurring, when support is transferred through subcontractors, or when the vendor owns a business-critical integration. In those cases, access removal may need a controlled transition plan rather than immediate revocation.
There is no universal standard for this yet, but current guidance suggests treating each access path by trust level. Human logins should be removed first, then privileged sessions, then API credentials, then certificate-based and service-to-service trust. Shared accounts are especially problematic because they can hide attribution and make it impossible to prove which former vendor still has a valid path.
Edge cases also include backups, archived mailboxes, and data export tools. These are often excluded from normal access reviews even though they may contain the most sensitive records. If a former vendor had administrative or support access, the organisation should also check whether cached secrets, recovery codes, or break-glass procedures were exposed. NIST SP 800-63 is relevant where identity proofing or credential binding influences how strong the original trust relationship was, but it does not replace the need for technical revocation. For emerging AI-assisted monitoring and investigation workflows, the threat picture is evolving; Anthropic’s first AI-orchestrated cyber espionage campaign report is a reminder that once access persists, automated abuse can scale faster than manual response.
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, NIST SP 800-63, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI lifecycle management | Former vendor access often persists as unmanaged machine identities and secrets. |
| NIST CSF 2.0 | PR.AC | Access control and revocation are central to preventing post-contract misuse. |
| NIST SP 800-63 | IAL/AAL/FAL | Credential assurance affects how strongly the vendor identity was bound and trusted. |
| NIST AI RMF | GOVERN | AI-assisted detection and response still need governance over access persistence risk. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management controls govern timely disabling and removal of former vendor access. |
Use formal account lifecycle controls to remove every vendor identity and related secret.
