They should revoke the credential, rotate any dependent secrets, confirm the access path is gone, and document the retirement before the relationship is closed. If the organisation cannot prove removal, the account should be treated as still live.
What teams should do when a vendor or partner no longer needs NHI access
When vendor access is no longer justified, treat it as a standard offboarding action, not an administrative cleanup. Revoke the credential, invalidate any dependent secrets or tokens, verify the path is truly closed, and record the retirement decision. If you cannot prove removal, assume the access still exists and keep it in scope until it is confirmed gone.
Why offboarding must remove the whole access chain, not just one credential
For non-human access, one credential is often only one part of a larger trust chain. A partner may authenticate with an API key, a token, a certificate, a federated role, or a secret stored in a vault, and each of those can leave residual access if the others are not retired too. Offboarding has to address the identity, the secret, the authorisation path, and any integration that can still mint or refresh access.
That is why a vendor or partner exit should be handled as a lifecycle event with an explicit end state. The practical question is not whether the original account was disabled in one system, but whether any remaining path can still reach production data, call APIs, or impersonate the former relationship.
Teams that work through third-party access more systematically tend to catch the hidden dependencies earlier, especially where sponsorship, least privilege, and time-bounded access were weak from the start. Third-Party, B2B and Contractor Access Guide is useful when the vendor relationship spans multiple systems and business owners.
What proof of removal should look like in practice
The right standard is evidence, not intent. You should be able to show that the credential was revoked, any related secret was rotated or destroyed, the integration no longer authenticates, and the partner no longer has a route back in through delegated access, shared accounts, or stale tokens. If any dependency still points to the retired identity, the offboarding is incomplete.
In practice, this often means checking more than the obvious account record. Teams should confirm secret stores, CI/CD variables, OAuth grants, service principals, certificates, and application configuration have all been updated. A clean retirement is one where a fresh access attempt fails for the right reason and there is no fallback path left behind.
Identity governance is most effective when it closes the loop on removal, not just approval. Access Reviews and Certification Guide supports that discipline by tying review outcomes to actual deprovisioning and remediation.
Where the offboarding touches service or integration accounts, the underlying lifecycle problems are often the real failure mode. Service Account Security Guide is relevant because vendor access commonly survives in long-lived, poorly owned, or shared machine credentials.
Why stale vendor access becomes a security problem fast
Retired partner access becomes risky when it remains valid after the business relationship has ended. The main failure mode is blast-radius drift: a credential that was acceptable for a live integration becomes an orphaned trust path once ownership, monitoring, and contractual accountability have moved on. That is when dormant access turns into unauthorised access.
Failure mechanism: the organisation disables one account object but leaves behind a token, key, certificate, role assignment, or API grant that still authenticates or authorises the former partner.
Impact: an ex-vendor, attacker with stolen material, or an internal user who still knows the path can continue to reach systems, data, or administrative functions after the relationship has formally ended.
If the vendor integration is broad or privileged, that residual access can become a lateral movement path rather than a simple orphaned account issue. Offboarding is therefore a control over trust decay, not just a hygiene task.
Many teams find the strongest operational clue in their own account history: any integration that has not been exercised, reviewed, or owned recently should be treated as live until proven otherwise. The broader lifecycle and overprivilege risks are well captured in Top 10 NHI Issues, which is especially relevant when partner access was granted quickly and never revisited.
For background on how these compromises surface in the real world, The 52 NHI Breaches Report shows why leftover machine access and secret exposure are recurring attack paths rather than edge cases.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Vendor access retirement is the core offboarding problem for NHI credentials. |
| NHI-02 — Secret Leakage | Residual vendor access often persists through leaked or stored secrets after relationship end. | |
| NHI-07 — Long-Lived Secrets | Stale partner credentials and tokens are the common persistence condition behind incomplete offboarding. | |
| Recommendation — Revoke the NHI and retire every dependent secret, token, or certificate. Rotate or destroy exposed secrets that could still authenticate the former partner. Shorten credential lifetime and remove any long-lived material tied to departed vendors. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding requires revoking and rotating authenticators used by the retired partner. |
| AC-2 — Account Management | Account disablement and removal are central to proving partner access is retired. | |
| AC-6 — Least Privilege | Retirement is also a privilege-reduction event because residual access is still exposure. | |
| Recommendation — Invalidate authenticators and rotate dependent secrets when access ends. Disable or remove unused partner accounts and document the termination. Remove unnecessary entitlements and confirm no standing privilege remains. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Ending partner access requires timely removal and review of access rights. |
| A.8.5 — Secure authentication | Retired vendor access must no longer authenticate through any remaining credential or token path. | |
| Recommendation — Remove access rights promptly and retain evidence of revocation. Invalidate authentication material linked to the departed relationship. | ||
Practitioner Guidance
Decision rule: if the partner can still authenticate, still refresh a token, or still call the target system through any secondary path, the access is not retired yet. Treat the retirement as incomplete until the dependency chain has been tested, not merely changed on paper.
What to verify: confirm the exact secret or credential is gone, not just the account record; confirm dependent secrets were rotated; and confirm the integration owner can demonstrate a failed access attempt from the retired path. If the former partner could still succeed with cached material, the offboarding is not complete.
What good looks like: the business owner can show who approved the retirement, the technical owner can show what was revoked or rotated, and the security team can see that monitoring, inventory, and access records all agree that the relationship has ended.
Practitioner takeaway: the safest assumption is that access still exists until you can prove every path back in has been removed and no hidden dependency can recreate it.
Related resources from NHI Mgmt Group
- What should security teams do after a third-party partner leaves or no longer needs access?
- How should security teams handle third-party NHI access that outlives the vendor relationship?
- How should security teams structure third-party access when a partner product needs to read tenant data without seeing the data itself?
- How should teams respond when a protected account no longer needs elevated access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org