What should teams do when a third-party NHI is no longer needed?

Revoke the credential, remove any linked permissions, and confirm that the identity cannot still reach build, support or deployment systems. If the offboarding step is skipped, the relationship may end on paper while the access path remains active in practice.

What changes when a third-party NHI is no longer needed?

Offboarding a third-party NHI is not just administrative cleanup. The identity, its credential and every permission tied to it should be removed together, then validated against the systems it could still reach. That includes build, support and deployment paths, because stale access often survives after the business relationship has ended.

Why revocation and permission cleanup have to happen together

A third-party NHI is usually created to let an external vendor, integration or automation perform a narrow function. When that function ends, the safe state is not simply “inactive,” it is no remaining ability to authenticate or authorize anything. Revoking only one layer, such as the secret but not the role, or the role but not the token chain, leaves a partial control gap.

The right mental model is that the identity lifecycle and the access lifecycle end at the same time. If the credential is still valid, the NHI can still authenticate. If permissions remain in place, a future token refresh, misplaced secret copy or dependent integration may still reopen access. Ultimate Guide to NHIs covers this lifecycle view in more depth, including why offboarding must remove both reach and authority.

For teams managing external integrations, the practical question is not whether the vendor says the work is complete, but whether any live path to production still exists. Service Account Security Guide is useful here because service-account style identities fail most often when inventory, ownership and permission review are treated as separate tasks instead of one shutdown process.

How to confirm the NHI is actually out of circulation

Offboarding is only complete when the identity cannot be used in practice, not just when a ticket is closed. Teams should verify that secrets have been revoked or rotated, linked roles and scopes have been removed, and any federation, app consent or trust relationship that could recreate access has been disabled.

Validation should be targeted at the systems the third party touched most often. Build systems, support tooling and deployment platforms are common residual-access points because they tend to have broad reach and are easy to overlook during vendor exit. The useful test is simple: if this identity tried to authenticate now, would every path fail?

NHI Authentication Guide is relevant because offboarding depends on understanding which authentication method was in use, whether it was secret-based, certificate-based or federated, and which dependency actually needs to be broken first. OWASP Non-Human Identity Top 10 also maps directly to the common failure pattern of long-lived access that is not fully removed.

What good offboarding looks like for third-party NHI access

Good offboarding is documented, owned and testable. The team should know who can approve removal, who confirms revocation, and who checks the downstream systems that might still trust the identity. That is especially important when the third party was granted access for support, incident response or deployment, because those privileges are often broader than the original use case suggests.

At scale, the hard part is discovery. Many organisations discover too late that the same third-party identity was reused across multiple apps, environments or automation paths. If you do not map those dependencies before shutdown, one credential may be removed while a second token, API key or delegated grant remains active elsewhere. Top 10 NHI Issues is a good navigation point for the recurring lifecycle failures that make this mistake common.

NHI Ownership and Accountability Guide is especially relevant when the offboarding target is a third party, because accountability often breaks at the handoff between the vendor owner, the internal system owner and the security team. The safest exit is the one where one named owner can prove the access is gone.

Risk and Threat Considerations

Leaving a no-longer-needed third-party NHI active creates silent residual exposure. The relationship may have ended contractually, but if a token, secret or delegated grant remains valid, an attacker, former vendor user or compromised integration can still reach sensitive systems long after the business has moved on.

Failure mechanism: The common failure is partial offboarding, where one artifact is revoked but another trusted path remains, such as an unrotated secret, a lingering role assignment or an uncancelled federated trust. That keeps the access path alive even when the identity is thought to be gone.

Impact: Residual third-party access can enable data access, deployment abuse, support-system misuse or lateral movement from a trusted integration into higher-value environments. The larger the vendor footprint, the more likely a missed dependency becomes an incident rather than a paperwork issue.

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 and CIS Controls v8 set 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	Third-party NHI offboarding is the core issue in this FAQ.
	NHI-07 — Long-Lived Secrets	Residual third-party access often persists through unrotated or unrevoked secrets.
	NHI-05 — Overprivileged NHI	Offboarding must remove permissions that would otherwise leave excess reach behind.
Recommendation — Revoke credentials and remove all linked access paths before closing the offboarding. Rotate or destroy any remaining secret that could still authenticate the NHI. Strip residual roles and scopes so the retired NHI cannot access production systems.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Revocation and lifecycle handling of authenticators is central to ending NHI access.
	AC-6 — Least Privilege	Removing linked permissions reflects least-privilege cleanup after the need ends.
	AC-2 — Account Management	Offboarding requires disabling or retiring the account or identity behind the access.
Recommendation — Invalidate or replace authenticators so the third party can no longer use them. Remove unneeded privileges immediately when the third-party function ends. Deprovision the account and confirm it is no longer active anywhere.
ISO/IEC 27001:2022	A.5.18 — Access rights	The question is fundamentally about withdrawing access when it is no longer required.
	A.5.16 — Identity management	The answer depends on retiring the identity and any trust relationships tied to it.
Recommendation — Review and revoke access rights promptly when third-party need ends. Manage the identity lifecycle so retired third-party identities cannot persist.
CIS Controls v8	CIS-5 — Account Management	Third-party NHI offboarding is an account and access management control problem.
Recommendation — Remove unused accounts and credentials and verify they no longer authenticate.

Practitioner Guidance

What to prioritise: Treat offboarding as an access-removal exercise first and an administrative closure second. Revoke the credential, remove the permissions, then prove the identity cannot still authenticate to any system it touched.

What to verify: Confirm there is no remaining path through support consoles, CI/CD, cloud roles, shared service credentials, SaaS app consent or delegated trust. If one of those paths still works, the offboarding is incomplete.

Practitioner takeaway: The deciding question is not whether the vendor relationship ended, but whether every live authentication and authorization path ended with it.