What should teams do when a former employee may have left active NHI credentials behind?

Treat the situation as an identity offboarding issue, not just a personnel issue. Reconstruct which tokens, service accounts, and keys were created for that work, verify ownership, revoke anything unnecessary, and rotate any credential that must remain in service under a current owner.

What teams should do first when a former employee may have left active NHI credentials behind

Start by treating this as an identity offboarding problem with a live access-path risk, not as a simple HR cleanup. The key question is which non-human identities were created, who owns them now, and whether any of the credentials can still authenticate to production systems. That shifts the response from record-keeping to access containment and ownership restoration.

Reconstruct the full credential set tied to that work, including tokens, service accounts, API keys, certificates, and any delegated access or automation the person set up. If you can identify the current owner quickly, you can decide what to revoke immediately and what to preserve under a valid owner with a controlled rotation.

Ownership matters because orphaned access is what turns a leaver into a persistence problem. If a credential still works and nobody can explain why it exists, that credential should be treated as suspect until proven necessary. The practical test is whether the credential has a current business purpose, a current owner, and a current expiry or rotation path.

Which credentials should be revoked, rotated, or reassigned

Anything that is no longer needed should be revoked, and anything that must remain in service should be reassigned to a current owner before being rotated. In practice, the highest priority items are long-lived API keys, shared service accounts, certificates without clear expiry handling, and tokens that were issued for convenience rather than governance. The goal is to remove access without breaking the service that still depends on it.

Where a credential cannot be removed immediately, rotation is the safer bridge than indefinite retention. Rotation should be paired with validation, because old secrets sometimes survive in scripts, schedulers, build jobs, integration points, or configuration stores. If the old credential is still embedded in an active workflow, revocation must wait until the replacement is confirmed.

Service Account Security Guide is useful here because service accounts are often where leaver-created access lingers after the human relationship ends. For broader lifecycle cleanup, NHI Ownership and Accountability Guide helps teams assign a real owner before they decide whether a credential stays live.

How to prevent the same offboarding gap from happening again

The control objective is to make every non-human credential discoverable, attributable, and bounded by lifecycle rules before the employee exits. That means the joiner-mover-leaver process needs to include machine credentials, not just user accounts, and the handoff should record the system owner, rotation date, and dependency map for anything that remains active.

Teams should also standardise how credentials are issued so that they can be removed predictably later. Long-lived secrets, shared accounts, and undocumented keys create the biggest cleanup burden because nobody is sure what will break if they are revoked. If the organisation cannot explain why a credential exists, it is already a governance gap.

Ultimate Guide to NHIs gives the lifecycle and offboarding context, while API Key Management Guide is especially relevant when the leftover credential is an exposed or reusable key that needs rotation and revocation discipline. For teams that rely heavily on secrets, Guide to the Secret Sprawl Challenge reinforces why inventory and cleanup must happen together.

Risk and Threat Considerations

Active NHI credentials left behind by a former employee can become an unowned access path that persists long after the person leaves. That creates exposure not only from accidental use, but also from unauthorized reuse if the credential is discovered, copied, or never removed from systems the former employee touched.

Failure mechanism: The credential remains valid because offboarding covered the person but not the machine identity, so the access relationship survives in tokens, keys, or service accounts that were never inventoried or rotated.

Impact: An attacker or insider can use the stale credential for unauthorized access, lateral movement, data extraction, or service abuse, and the organisation may not notice until the dependency breaks or the access is already exploited.

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	Former-employee credentials left active are an offboarding failure for non-human identities.
	NHI-07 — Long-Lived Secrets	Left-behind tokens and keys often persist because they have no expiry or rotation discipline.
	NHI-05 — Overprivileged NHI	Leaver-created accounts often retain more access than the current service need requires.
Recommendation — Revoke orphaned non-human credentials and rotate any secret that must remain live. Replace long-lived credentials with short-lived, controlled secrets and enforce rotation. Reduce standing access to least privilege before reassigning any surviving credential.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	The issue requires revocation, rotation, and lifecycle control of authenticators and secrets.
	IA-9 — Service Identification and Authentication	Service accounts, API keys, and machine credentials are the authenticators at issue here.
	AC-2 — Account Management	The answer centers on discovering, assigning, disabling, and closing accounts and credentials.
Recommendation — Track, rotate, and revoke authenticators as part of offboarding and ownership transfer. Authenticate non-human services with controlled credentials and remove stale access promptly. Maintain account inventory, ownership, and timely disablement during offboarding.
ISO/IEC 27001:2022	A.5.15 — Access control	Access control governs who or what may retain access after employment ends.
	A.5.18 — Access rights	Access rights must be reviewed and withdrawn when the former employee no longer owns the service.
Recommendation — Apply access control rules to remove obsolete access and approve only current need. Review and revoke access rights that no longer have a valid business owner.

Practitioner Guidance

What to verify: Confirm which systems still trust the credential before you decide whether to revoke or rotate it. If you cannot map a token or key to a current owner, treat that as an escalation condition, not a documentation task.

Decision rule: If the credential can authenticate to production, prioritise containment and rotation before you investigate whether it has already been abused. If it is non-production but connected to deployment, scripting, or data movement, verify the blast radius before leaving it in place.

What good looks like: Every active non-human credential has a named owner, a known purpose, an expiry or rotation path, and a removal plan tied to offboarding. The best sign of control is that no one has to guess why the credential still exists.

Practitioner takeaway: The safe response is not “remove the former employee’s access”, it is “close every access path that person created or influenced, then re-establish only the ones with a current owner and a current need.”