TL;DR: Third-party access often remains open after contracts end, and SecurityScorecard argues that offboarding failures create breach risk because teams lose ownership, visibility, and revocation discipline at the point when access should disappear. NHIMG sees this as an identity lifecycle problem, not an administrative cleanup task.
At a glance
What this is: This is an analysis of vendor offboarding as a security control, with the central finding that access often remains open after a third-party relationship ends.
Why it matters: It matters because IAM, PAM, and third-party risk teams have to treat vendor termination as a revocation event across accounts, keys, integrations, and physical access, not just a procurement closeout.
By the numbers:
- More than 35.5% of breaches now involve a third party.
- In 2023, attackers stole data on 8.9 million AT&T customers from the cloud environment of a former vendor.
- The FCC concluded AT&T was responsible for the lapse and reached a $13 million settlement in 2024.
- Ransomware groups increasingly use the same path, with 41.4% of ransomware attacks now carrying a third-party nexus.
Context
Vendor offboarding is the point at which third-party access should disappear, but many programmes still treat it as paperwork rather than a security event. That creates a lifecycle gap in identity governance, because the same accounts, API keys, service accounts, VPN paths, and integrations that enabled work can remain active after the relationship ends.
The article shows why the problem is broader than procurement closeout. In practice, offboarding spans IAM, PAM, third-party access governance, and verification that a former vendor can no longer reach data, systems, or backup environments. When ownership is scattered, stale access becomes an orphaned identity problem rather than a completed business process.
Key questions
Q: What breaks when vendor offboarding is not verified?
A: Orphaned access survives. That means vendor accounts, tokens, or integrations may still reach sensitive systems after the supplier no longer needs them, which turns a closed relationship into a standing exposure. The failure is lifecycle control, not simply a missed administrative task.
Q: Why do former vendor credentials increase breach risk after a contract ends?
A: 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.
Q: How do security teams know whether offboarding is actually working?
A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.
Q: Who is accountable for third-party access when a vendor relationship ends?
A: Accountability should sit with the business owner of the relationship, but IAM, PAM, and security teams must own the technical revocation and validation steps. If no one is responsible for proving access removal, the organisation has governance in name only.
Technical breakdown
Why vendor offboarding fails as a control
Vendor offboarding fails when organisations confuse contract end with access end. Third-party relationships usually create multiple identities and paths, including SSO accounts, API keys, service accounts, VPN credentials, badges, and embedded integrations. If each path sits in a different system or team, no single owner can confirm removal. The failure is not that the work is difficult, but that identity and asset inventories are usually incomplete at the moment the relationship terminates. A checklist can record intent, yet it cannot prove that every access path has actually been revoked across all environments.
Practical implication: build offboarding around verified discovery of every vendor access path, not around a contract-closure tick box.
Why orphaned vendor credentials become breach entry points
Orphaned vendor credentials are dangerous because they preserve trust after the business relationship has ended. A service account, token, or API key does not know that a contract expired, and downstream systems will still accept it until someone revokes or rotates it. That makes stale third-party access a live identity issue, not a dormant record. In security terms, the problem sits at the intersection of identity lifecycle, secret management, and external trust boundaries. Once the vendor is gone, any unrevoked credential becomes an unnecessary authentication path that attackers can reuse.
Practical implication: treat every vendor credential as active until revocation is confirmed in the systems that actually authenticate it.
Why offboarding needs continuous visibility, not point-in-time review
Point-in-time review breaks down because vendor exposure changes after termination. Backups, archived data, lingering integrations, and shadow IT can all keep a former vendor connected even when the official process says the relationship is over. Continuous visibility is therefore a governance requirement, not a monitoring luxury. It lets teams confirm whether externally reachable assets still answer to a former vendor, whether data remains present where it should have been deleted, and whether the access surface has truly collapsed. Without that feedback loop, offboarding remains an assumption rather than a control.
Practical implication: pair termination workflows with continuous external discovery so stale vendor exposure is caught after the paperwork closes.
Threat narrative
Attacker objective: The objective is to exploit retained third-party trust to reach systems and data that should have been inaccessible after offboarding.
- Entry occurs through a legitimate third-party relationship that originally granted the vendor access to systems, data, or integrations.
- Credential access persists after termination because accounts, API keys, tokens, or service accounts were not fully revoked or rotated.
- Impact follows when former vendor access is used to reach customer data, backup files, or other exposed resources long after the contract ended.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Vendor offboarding is an identity lifecycle control, not a procurement task. The article is strongest when read through that lens, because the risk arises when access outlives the business relationship. IAM teams already understand that issuance without revocation creates exposure; third-party access works the same way, only across more systems and more owners. Practitioners should treat termination as a governed identity event with explicit revocation evidence.
Standing third-party trust is the failure mode this article exposes. Once a vendor is offboarded, any surviving account, token, or integration becomes an unowned trust path. That is the governance assumption that breaks, because the system still honours the old relationship even though the business no longer does. The practical conclusion is that access ownership must end with the contract, not remain implicit in disconnected teams.
Offboarding gaps reveal how weak external identity inventory really is. If security cannot say where a former vendor still exists, the programme does not have control, it has memory. That is especially relevant for NHI governance, where service accounts and API keys are often invisible until something fails. Practitioner conclusion: inventory, revocation, and verification must be treated as one control surface.
Vendor offboarding blind spot: the article names a specific governance gap where teams assume deprovisioning happened because a contract ended. In reality, access can persist across shadow IT, archived data, and forgotten integrations. This is the same class of failure that drives orphaned NHI exposure, and the control lesson is simple: offboarding must prove closure, not just record intention.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Vendor offboarding blind spot: many programmes still equate contract end with access end, but that assumption breaks as soon as accounts, keys, or integrations live outside a single owner. Security leaders should expect offboarding to behave like a lifecycle control, not a cleanup activity, and measure whether every exit produces verifiable revocation evidence.
The practical shift is toward external discovery plus lifecycle governance. That means former vendors must be tracked the same way teams track dormant NHIs, because stale access often persists in backup systems, shadow IT, and forgotten integrations even after internal paperwork is complete.
For practitioners
- Map every vendor identity path Inventory accounts, API keys, tokens, service accounts, VPN access, badges, and integrations before termination begins. A complete offboarding review should include systems outside the identity provider and any shadow IT that may still trust the vendor.
- Require revocation evidence per system Do not accept a general confirmation that access was removed. Capture system-level proof that each vendor account, secret, and integration was disabled, rotated, or deleted in the platforms that actually authenticate it.
- Tie legal, procurement, security, and IT into one exit flow Define who owns termination, who validates data deletion or return, and who signs off on residual access. Offboarding fails when the relationship ends in one team but the revocation work is scattered across several others.
- Use continuous discovery after termination Keep scanning for lingering exposure tied to former vendors, including externally reachable assets, archived environments, and forgotten integrations. The goal is to confirm that the vendor footprint really disappears after the contract closes.
Key takeaways
- Vendor offboarding fails when organisations confuse administrative closure with actual revocation of access.
- The article ties third-party exposure to real breach risk, including former vendor access that remained reachable after the relationship ended.
- Effective offboarding requires proof that every account, key, integration, and physical access path has been removed, not just recorded.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article is fundamentally about vendor identities that remain active after termination. |
| NHI-02 — Secret Leakage | Lingering API keys and tokens are central to the access paths described in the article. | |
| NHI-07 — Long-Lived Secrets | The article warns that stale keys and credentials can survive well beyond the contract term. | |
| Recommendation — Build offboarding into NHI lifecycle controls and verify every vendor identity is revoked at exit. Rotate and revoke exposed third-party secrets as part of every vendor exit. Replace persistent vendor secrets with short-lived credentials wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly covers lifecycle handling for authenticators and secrets used by vendors and integrations. |
| Recommendation — Apply IA-5 to enforce revocation and rotation of vendor authenticators at termination. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern centers on surviving credentials that can still be used to move through connected systems. |
| Recommendation — Map residual vendor credentials to credential access and lateral movement detections. | ||
Key terms
- Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
- Orphaned Access: Orphaned access is credentialed access that still works even though no clear business owner can justify or manage it. It usually appears after system changes, reorganisations, or integrations, and it is especially dangerous because it can remain active long after the original purpose has disappeared.
- Residual Vendor Exposure: Residual vendor exposure is the remaining attack surface a former vendor can still reach after offboarding begins or ends. It includes forgotten accounts, retained secrets, archived data, and lingering systems trust, all of which can persist if termination is not verified across every platform.
- Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners translate identity lifecycle controls into operational policy across human and non-human access.
Published by the NHIMG editorial team on September 2, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org