Topic starter
02/09/2026 1:29 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by SecurityScorecard: “Vendor Offboarding: The Step TPRM Teams Forget”.
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.
Key questions
Q: What breaks when vendor offboarding is not verified?
A: Orphaned access survives.
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.
Q: How do security teams know whether offboarding is actually working?
A: Security teams should measure completion, not process start.
Practitioner guidance
- Map every vendor identity path Inventory accounts, API keys, tokens, service accounts, VPN access, badges, and integrations before termination begins.
- Require revocation evidence per system Do not accept a general confirmation that access was removed.
- 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.
Bottom line: Vendor offboarding fails when organisations confuse administrative closure with actual revocation of access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/09/2026 1:30 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Vendor offboarding gaps are leaving third-party access open
This post was modified 2 days ago by NHI Mgmt Group