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.
Why This Matters for Security Teams
When a vendor relationship ends, access removal is not just an IT housekeeping task. It is a control test of whether the organisation can prove offboarding happened, on time, across every system, secret, token, vault, and delegated service account. The business owner owns the decision to end the relationship, but technical teams own execution and evidence. That split matters because third-party access often spans IAM, PAM, SaaS admin consoles, CI/CD pipelines, and shared secrets. NHIMG research shows only 20% of organisations have formal processes for offboarding and revoking API keys, which is why this question keeps surfacing after the fact rather than during planned governance. See the broader lifecycle context in the Ultimate Guide to NHIs and the breach patterns in 52 NHI Breaches Analysis. OWASP also treats identity lifecycle failures as a core control gap in the OWASP Non-Human Identity Top 10. In practice, many security teams discover that “offboarded” means one portal was closed, while the vendor still has working access somewhere else.
How It Works in Practice
Accountability should be explicit in the offboarding workflow: the relationship owner approves termination, IAM or platform teams revoke identity bindings, PAM removes elevated access, and security validates that credentials no longer work. That validation step is critical. If no one is assigned to prove removal, the organisation is relying on assumptions, not control evidence. Current guidance suggests treating vendor offboarding as a revocation chain, not a single action, because third parties may hold multiple identities at once: human SSO accounts, API keys, service accounts, vault entries, and CI/CD tokens. The Ultimate Guide to NHIs — Key Challenges and Risks and the Reviewdog GitHub Action supply chain attack both show how quickly secrets spread beyond the original owner.
- Revoke the vendor’s primary identity, then verify group membership, app roles, and delegated admin rights.
- Rotate or invalidate every secret the vendor could have seen or stored, including tokens in code and automation.
- Check PAM sessions, SSH keys, API gateways, and vault policies for hidden persistence paths.
- Confirm removal with logs, ticket evidence, and an independent re-test of access.
OWASP guidance aligns with this layered revocation model, and Zero Trust thinking reinforces that no relationship should retain standing trust after termination. These controls tend to break down when vendors use shadow accounts, unmanaged secrets, or shared admin credentials because ownership and revocation paths are no longer traceable end to end.
Common Variations and Edge Cases
Tighter access control often increases operational overhead, requiring organisations to balance assurance against speed when a vendor exit is urgent. There is no universal standard for this yet, but best practice is evolving toward named ownership, time-bound access, and mandatory evidence of revocation. Temporary vendors, contractors, and embedded service providers may need a different offboarding path from strategic partners, especially when access is tied to a production support window or a regulated service. In those cases, the business owner still remains accountable for closure, while technical teams handle the mechanics and security signs off on residual risk.
This becomes more complex when access is indirect. A vendor may no longer have a login, yet still control an integration secret, a webhook, or a privileged automation job. That is why current NHI governance emphasizes secret rotation and post-termination validation, not just user disablement. The NHIMG data point that 91.6% of secrets remain valid five days after notification illustrates why delayed action is a real exposure window, not a theoretical one. For broader control framing, see the Ultimate Guide to NHIs and the identity failure patterns in The 52 NHI breaches Report. The practical rule is simple: if access cannot be independently proven removed, the vendor still has access.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Offboarding and revocation are core NHI lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access management apply to vendor termination. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires trust to end when the vendor relationship ends. |
Map vendor access to PR.AC-4 and remove entitlements before closing the relationship.
Related resources from NHI Mgmt Group
- Who is accountable for third-party access after a campaign or project ends?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when a user grants a risky third-party app access?
- How should security teams govern vendor access across the third-party lifecycle?
