They remain risky because NHIs are tied to systems and processes, not to the employee who handled them. If those credentials are still valid, a former employee or another actor can use them to access resources, bypass normal human offboarding, and potentially move laterally.
Why exposed non-human identities stay dangerous after someone leaves
The risk does not leave with the employee because the identity does not belong to the employee in the first place. It usually belongs to an application, service, workload, or integration, so any still-valid key, token, certificate, or secret can keep working after offboarding. That means the real control question is whether the NHI itself was discovered, owned, rotated, and revoked.
What makes the exposure persist after offboarding?
Human offboarding removes a person’s access path, but it does not automatically stop machine-to-machine access. If the credential was embedded in code, stored in a pipeline, shared across teams, or issued with a long expiry, the access can survive role change, termination, or account disablement. Joiner-Mover-Leaver (JML) Guide is useful here because the failure is usually a lifecycle gap, not a login problem.
The persistence problem gets worse when the NHI has broad permissions or is reused across environments. In practice, that means the leaving employee may no longer be the main issue, but the credential they handled can still authenticate, authorize, or delegate access long after their departure. If the secret was never tied to a clear owner, offboarding may remove the user while leaving the machine path intact. NHI Ownership and Accountability Guide maps to this exact gap.
Which controls actually reduce the risk?
The most effective controls are the ones that treat the NHI as a governed asset: inventory it, assign an owner, set a rotation or expiry policy, and revoke anything that no longer has a valid business purpose. Human offboarding should trigger a separate review for service accounts, API keys, OAuth grants, certificates, and automation tokens that the employee could have created, stored, or used. The question is not whether the person has left, but whether the credential still has live reach.
That is why service-account-specific governance matters. Many exposures come from accounts that are intentionally non-interactive, yet are left with standing privileges, shared usage, or passwords that never expire. Service Account Security Guide is directly relevant because it covers the controls that stop a departed employee’s access path from becoming an orphaned identity.
Ultimate Guide to NHIs, Key Challenges and Risks also supports the practical control view: the common failure modes are visibility gaps, secret sprawl, and overprivilege. When those exist, offboarding becomes incomplete by design because there is no reliable way to prove what needs to be removed.
Risk and Threat Considerations
Exposed NHIs are especially risky after an employee leaves because the credential often outlives the human trust relationship that originally justified it. An attacker, a contractor, or even the former employee can reuse that still-valid access to reach systems directly, bypass normal offboarding controls, and move laterally if the identity has broad permissions.
Failure mechanism: The machine credential remains valid, was not rotated or revoked, and may be embedded in an application, CI/CD pipeline, vault, or shared integration where offboarding never touches it.
Impact: Unauthorized persistence, hidden access paths, and delayed detection are common outcomes, and the blast radius can be large when the NHI has access to production data, cloud resources, or administrative APIs.
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 and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers rotation, revocation, and expiry of credentials that survive employee offboarding. |
| AC-2 — Account Management | Applies because orphaned non-human accounts must be disabled or removed after departure. | |
| AC-6 — Least Privilege | Relevant because lingering NHIs often retain excessive access after the human owner departs. | |
| Recommendation — Enforce IA-5 to rotate and revoke machine credentials when ownership changes or staff leave. Use AC-2 to inventory, review, and disable non-human accounts that are no longer needed. Apply AC-6 to reduce standing privileges on service accounts, tokens, and integrations. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The question is fundamentally about non-human identities left active after people depart. |
| NHI-05 — Overprivileged NHI | Lingering machine identities remain dangerous when their permissions exceed the business need. | |
| NHI-07 — Long-Lived Secrets | Post-exit risk is amplified when secrets remain valid long after the original employee leaves. | |
| Recommendation — Map leaver workflows to NHI offboarding so related credentials are revoked without delay. Reduce standing access on NHIs and recertify permissions when staff or roles change. Replace long-lived secrets with rotated, expiring credentials and retire unused ones. | ||
Practitioner Guidance
What to prioritise: Treat every departure as a trigger for a separate NHI sweep, not just a human account disablement. The first pass should identify service accounts, tokens, keys, and certificates linked to the leaver’s projects, repos, pipelines, and admin tools.
What to verify: Confirm that each credential has an owner, a current purpose, and a rotation or expiry mechanism. If you cannot show who owns it or why it still exists, treat it as an exception requiring immediate review.
Common mistake: Teams often believe offboarding is complete once HR and IAM workflows close the user account. That leaves the machine-side access intact, which is exactly where the post-departure risk sits.
Practitioner takeaway: The right test is not “has the employee left?” but “can any credential they handled still authenticate, authorize, or delegate access anywhere important?”
Related resources from NHI Mgmt Group
- How should organisations offboard non-human identities when an employee leaves without breaking critical workflows?
- How should organisations govern non-human identities alongside employee access?
- Why do exposed credentials create more risk for non-human identities?
- How should organisations reduce risk from exposed non-human identities and secrets?