Ownership should sit with the business and security stakeholders who approved the relationship, but the workflow must enforce revocation through IAM and contract controls. If access remains after the vendor relationship changes, accountability has failed. The right test is whether offboarding removes both the business approval and the technical entitlement.
Why This Matters for Security Teams
vendor offboarding is not just an administrative closeout. It is a control point where business approval, contract terms, and technical entitlement have to collapse together. When access remains active, the organisation has effectively created a standing non-human identity with no clear operational owner. That is a lifecycle failure, not a paperwork issue. Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both treat lifecycle control and entitlement cleanup as core security requirements, because forgotten access is one of the fastest ways third parties become an internal exposure path.
This is especially important for vendors because their access often spans SaaS consoles, APIs, shared vaults, and support tooling. A contract can end while a token, service account, or delegated role remains live. In mature programs, business ownership answers who requested the relationship, security ownership answers how revocation is enforced, and IAM ownership answers whether the access actually disappeared. In practice, many security teams encounter stale vendor access only after an audit, incident, or renewal dispute has already exposed the gap.
How It Works in Practice
The cleanest model is shared accountability with hard technical gates. The business owner confirms the relationship is over, procurement or legal confirms the vendor is out of scope, and security or IAM executes the revocation workflow. That workflow should cover all active entitlements: SSO assignments, API keys, OAuth grants, service accounts, vault entries, SSH material, and any delegated admin roles. NHI Lifecycle Management Guide and 52 NHI Breaches Analysis both emphasise that lifecycle control fails when revocation is partial or manually tracked.
Practitioners should tie offboarding to a checklist that cannot be marked complete until technical evidence exists. That usually means:
- removing the vendor from RBAC groups and PAM/JIT approval paths
- revoking secrets, tokens, and certificates at source, not just disabling a UI account
- confirming no active integrations remain in CI/CD, ticketing, or shared vaults
- logging the revocation event with owner, timestamp, and system-of-record evidence
Where possible, use workflow automation and policy-as-code so revocation is triggered by contract status, ticket closure, or procurement events rather than waiting for a human reminder. This aligns with the intent of zero trust and with the account lifecycle guidance in OWASP and NIST-aligned identity practice. These controls tend to break down in environments with shared vendor accounts, unmanaged integrations, or no reliable source of truth for where the vendor’s credentials were copied.
Common Variations and Edge Cases
Tighter offboarding often increases coordination overhead, requiring organisations to balance speed against completeness. That tradeoff becomes visible when vendors support multiple business units, when the same provider is reused across contracts, or when an integration is embedded in production code. Current guidance suggests the owner of the relationship should not be the same as the person performing the revocation, but there is no universal standard for exactly how that split should map across procurement, security, and application teams. The important part is that the revocation authority is explicit and auditable.
For high-risk vendors, the contract should require immediate return or destruction of credentials and should define evidence of deletion as part of offboarding acceptance. For lower-risk SaaS tools, the same principle still applies, but the controls may be lighter if the platform supports automated deprovisioning and centralised logging. Organisations should also watch for “ghost access” in environments where shared secrets were handed to the vendor months earlier and never inventoried; Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both point to visibility gaps as a recurring failure mode.
When access is still active, ownership should be treated as a shared control failure, but the final technical responsibility belongs to the system that can revoke it. OWASP Non-Human Identity Top 10 frames this well: if entitlement removal is not enforced at the identity layer, offboarding is only a declaration.
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-01 | Vendor offboarding is an NHI lifecycle and entitlement cleanup problem. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and removed when business need ends. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification and prompt revocation of third-party access. |
Treat vendor offboarding as a zero-trust event and revoke access immediately at trust termination.
