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.
Expanded Definition
Vendor offboarding is the security and governance process for ending a third party’s operational access, not just closing the contract. It includes revoking credentials, removing API keys and service accounts, severing integrations, validating data return or deletion, and confirming that no hidden dependency continues to authenticate on behalf of the vendor.
In NHI practice, vendor offboarding sits at the intersection of lifecycle control, secrets hygiene, and third-party risk. It is closely related to the guidance in the NHI Lifecycle Management Guide and the broader lifecycle framing in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. There is no single standard that governs vendor offboarding by name yet, so usage in the industry is still evolving across procurement, IAM, and security operations teams.
The most common misapplication is treating offboarding as a procurement task, which occurs when contract termination is completed before credentials, integrations, and data paths are actually disabled.
Examples and Use Cases
Implementing vendor offboarding rigorously often introduces coordination overhead, requiring organisations to weigh rapid contract exit against the slower work of verifying every credential, workflow, and data exchange has been removed.
- A SaaS supplier is terminated, and the security team must disable SSO access, revoke OAuth grants, and remove webhook endpoints before the vendor can still write into production systems.
- A managed service provider loses scope, and its privileged service accounts must be rotated or deleted in the same change window to prevent orphaned access from surviving the relationship.
- A development tool is replaced, and embedded tokens in CI/CD pipelines and code repositories are discovered during offboarding, echoing the lifecycle failures discussed in Top 10 NHI Issues.
- A partner API integration is sunset, and the organization must confirm that no downstream jobs, automation agents, or scheduled tasks still authenticate with the vendor’s keys under NIST Cybersecurity Framework 2.0 governance expectations.
- A cloud marketplace app is removed, but its cached secrets remain in a secrets manager or configuration file, forcing a post-exit audit of all secret locations and rotations.
Why It Matters in NHI Security
Vendor offboarding matters because third-party access often outlives the business relationship. That residual access becomes a persistent NHI exposure when service accounts, API keys, certificates, or machine-to-machine trust links are left active. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which explains why offboarding gaps are so common in real environments.
This is also where NIST guidance on least privilege and access review becomes practical, because the end state of offboarding should be zero remaining standing access and verifiable removal of trust. The same principle aligns with NIST Cybersecurity Framework 2.0, which expects identity governance, asset visibility, and protective controls to work together rather than in isolation. In NHI terms, the hard part is not announcing exit, but proving that no credential, token, or automated workflow can still act for the vendor.
Organisations typically encounter the true risk only after a breach investigation or compliance audit reveals an ex-partner still had active access, at which point vendor offboarding becomes operationally unavoidable to address.
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-02 | Covers secret lifecycle weaknesses that commonly persist after vendor exit. |
| NIST CSF 2.0 | PR.AC-1 | Access is managed by policy, which includes removal when a vendor relationship ends. |
| NIST Zero Trust (SP 800-207) | N/A | Zero Trust requires continuous verification and no implicit trust after offboarding. |
Revoke vendor-issued secrets, rotate shared credentials, and verify no orphaned NHI remains active.
