When offboarding is not enforced, the organisation can retain vendor access, data exposure, and contractual obligations long after the business need has ended. That creates hidden residual risk and makes audit evidence unreliable. The failure is usually not the contract itself, but the absence of a controlled exit process that actually closes access.
Why This Matters for Security Teams
Third-party offboarding is not just an HR or vendor-management task. It is the point where access, secrets, and contractual obligations must be cleanly retired so that the identity no longer exists in practice. When that step is missed, organisations keep residual access paths alive, often across service accounts, API keys, vault entries, and shared integrations. OWASP’s OWASP Non-Human Identity Top 10 treats lifecycle control as a core risk area because stale machine access is a common cause of exposure, not an edge case.
NHIMG research shows how often the problem persists after the business relationship ends: in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, only 20% of organisations report formal processes for offboarding and revoking API keys, while 91% of former employee tokens remain active after offboarding in Entro Security’s 2025 study. That combination means the security team may believe a vendor is closed out when the environment still accepts their credentials. In practice, many security teams encounter third-party overreach only after an incident review reveals that the exit process was never technically enforced.
How It Works in Practice
Enforced offboarding should remove the third party from every control plane where it could still authenticate, authorise, or retrieve data. That includes IAM groups, service accounts, vault leases, CI/CD variables, secrets managers, API gateway allowlists, and any brokered trust relationships. Current guidance suggests treating offboarding as a workflow with explicit completion evidence rather than as a notification email or contract clause. The NHI Lifecycle Management Guide and the Top 10 NHI Issues both emphasise that lifecycle failure is usually a process failure first, then a security failure.
Operationally, a controlled exit usually requires:
- revoking all active credentials and tokens, not just disabling the portal account;
- removing the vendor from RBAC roles, approval chains, and shared admin groups;
- rotating any shared secrets, certificates, or signing keys they could still use;
- verifying data return, deletion, and retention obligations before access closure is marked complete;
- capturing evidence for audit so the organisation can prove the exit happened.
This is where ZTA and ZSP thinking matters: no third party should retain standing access after the business need ends, and JIT access should expire automatically when the task is complete. The practical challenge is that many environments have hidden dependencies in scripts, pipelines, and nested vendor integrations. These controls tend to break down when the third party is embedded inside shared automation or unmanaged secrets sprawl because there is no single owner who can see every remaining access path.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance speed of vendor disengagement against assurance that every access path is closed. That tradeoff is especially visible in long-lived integrations, managed service providers, and subcontractor chains where the original vendor may not control all downstream identities. Best practice is evolving here, and there is no universal standard for how much evidence is enough, but the direction is clear: offboarding must end both authority and reach.
One common exception is a vendor that leaves behind a shared integration account used by multiple teams. In that case, offboarding cannot simply delete the account without a dependency review, so the safer pattern is to rotate credentials, split the workload identity, and rebind the remaining service to a new owner before termination. The same issue appears in incident response when a vendor is suspended temporarily rather than fully removed. In those situations, current guidance suggests using time-bound access, explicit reapproval, and documented rollback procedures rather than leaving dormant access in place.
For organisations aligning with OWASP Non-Human Identity Top 10, 52 NHI Breaches Analysis, and broader governance under The 52 NHI breaches Report, the rule is simple: if access is still technically valid, offboarding is not finished, regardless of what the contract says.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle and credential revocation are central to preventing stale third-party access. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege removal when a third party no longer needs access. |
| NIST AI RMF | Governance and accountability are needed where access decisions span many systems. |
Map vendor exit steps to access removal checks and require approval before entitlements remain active.
