When should organisations prioritise NHI revocation over employee account closure?

What should be revoked first when an employee leaves?

Prioritise the machine identity that can still act after the person is gone. If a departing employee created cloud roles, API keys, tokens, service accounts, or agent credentials, those access paths can outlive the human account closure and keep working until they are explicitly revoked or rotated.

Revocation should be tied to what the identity can still reach, not just to who owned it. A closed directory account stops interactive login, but it does not automatically disable delegated automation, cached trust, or secrets already issued to systems and apps. Treat the employee exit as a full access-removal event, not an HR-only event.

Where non-human access is present, the safer assumption is that the blast radius remains until the underlying credential or role is removed, not until the human user record disappears. That is why NHI revocation should be planned as part of the same offboarding workflow rather than as a follow-up task.

Why account closure is not enough on its own

Human account closure and NHI revocation solve different problems. Account closure removes the person’s direct login path, but machine identities are often embedded in cloud IAM roles, application settings, build pipelines, SaaS grants, or automation platforms. Those relationships can continue to function independently of the person’s directory status.

This matters most when the departing employee had enough privilege to create long-lived access, delegate to a service principal, or seed an AI agent with tool access. In those cases, the active risk is not the employee’s username but the standing authority that remains in production systems, which is why service account governance and cloud workload identity controls are directly relevant to offboarding.

Good offboarding therefore asks a concrete question: what identities, secrets, or delegated grants did this employee create, approve, or inherit? If that inventory is incomplete, account closure can create a false sense of safety while the real access path stays live.

How to decide what gets revoked immediately

Use a blast-radius test. If the departing employee’s access can authenticate to a production system, trigger automation, or call an API without further human approval, it belongs in the immediate revocation set. If the access is merely administrative convenience with no persistent authority, closure may be sufficient only after confirming that no associated machine path remains.

Revocation priority should increase when you see long-lived secrets, shared credentials, unmanaged cloud roles, or cross-environment access. These patterns are common failure points because they survive personnel changes and are harder to trace back to a single owner. The same logic applies when an employee has created an AI agent that retains tool access, because the agent’s authority can outlast the user session that spawned it.

Where there is uncertainty, revoke first and re-establish least-privilege access later. That sequencing is usually safer than trying to prove that every downstream secret is harmless before shutting it down.

Risk and Threat Considerations

Leaving NHI credentials active after employee departure creates a persistence path for both insider misuse and external compromise. The human account may be closed cleanly, but any remaining keys, tokens, roles, or delegated grants can continue to authorize access, which means the control failure is often invisible until logs or alerts show unexpected use.

Failure mechanism: The organisation disables the directory account but fails to revoke the underlying machine identity, secret, or delegation chain, so the access path continues to operate with the same or greater privilege.

Impact: An attacker, a disgruntled ex-employee, or even an automated workflow can keep accessing systems, moving laterally, or extracting data long after the offboarding event appears complete.

Practitioner Guidance

What to prioritise: Revoke anything that can still authenticate or act on behalf of the departing employee, including cloud roles, API keys, refresh tokens, service accounts, and agent credentials. If the access path is reusable, treat it as higher priority than the human directory closure itself.

What to verify: Confirm that offboarding includes a search for owned or delegated non-human access across identity platforms, cloud consoles, CI/CD, SaaS integrations, and automation tools. The key verification point is whether any production path remains that does not depend on the employee’s interactive login.

Practitioner takeaway: The safe rule is simple: close the person, but also remove every machine path that person enabled, because the remaining secret or role is the part that can still be abused.

Related resources from NHI Mgmt Group

• When should organisations prioritise NHI posture management over other identity work?
• When should organisations prioritise NHI security over other identity work?
• When should organisations prioritise NHI monitoring over more access approvals?
• When should organisations prioritise NHI lifecycle governance over more access tooling?