Offboarding exposed NHIs is the gap human IAM keeps missing

At a glance

What this is: This article argues that employee offboarding must extend to exposed NHIs, because human deprovisioning alone leaves service accounts and secrets behind.

Why it matters: IAM, PAM, and NHI teams need shared offboarding controls so a departing employee does not leave behind standing machine access that outlives human account removal.

👉 Read Oasis Security's guidance on managing NHIs exposed to offboarded employees

Context

Offboarding is not only a human identity problem. When employees move roles or leave, the entitlements they touched can include service accounts, API keys, and other secrets that remain valid after the person is gone. That creates a governance gap in mover-leaver processes, because deactivating the human account does not touch the non-human identities attached to systems and services.

The primary issue is exposure, not ownership. NHIs belong to workloads and applications, so they cannot be managed like employee accounts without risking outages or broken dependencies. For identity teams, the practical question is how to separate human lifecycle events from machine credential lifecycle events using NHI-aware discovery, rotation, and offboarding controls.

Key questions

Q: How should security teams handle NHIs exposed during employee offboarding?

A: Security teams should tie offboarding to NHI discovery, secret rotation, and dependency review, not just human account disablement. If a departing employee could see, create, or share a credential, the machine identity needs a separate lifecycle decision. That decision should preserve service continuity while removing unnecessary exposure and invalidating any reused secret.

Q: Why do mover-leaver processes miss so many non-human identities?

A: They are usually built around HR records and human access removal, while NHIs live in services, scripts, and shared automation. A person can leave without the organisation ever tracing which service accounts or secrets were exposed to that person. The result is valid machine access that survives the human exit.

Q: What breaks when human offboarding is used as the only control for NHIs?

A: The organisation keeps service credentials alive after the person who knew them is gone. That creates an exposure gap where access can continue, lateral movement can begin, and ownership becomes unclear. Human deprovisioning is necessary, but it does not retire machine identity risk by itself.

Q: Who is accountable for exposed NHI secrets after an employee leaves?

A: Accountability usually sits across IAM, security operations, and the application owner because each owns part of the lifecycle. HR can trigger the event, but it cannot revoke machine credentials on its own. The control owner must be able to prove that exposed secrets were identified, rotated, or retired.

Technical breakdown

Why human offboarding does not close NHI exposure

Human offboarding usually revokes SSO access, VPN access, and application roles tied to the employee record. Non-human identities sit outside that model because their lifecycle is tied to services, not people. If a departing employee knew, created, or shared a secret, the secret can remain valid even after the user object is disabled. That is why a clean HR exit can still leave an active machine credential in place. The architectural flaw is not weak HR execution. It is that IAM tooling often tracks human ownership but not secret exposure paths across workloads, scripts, and shared automation.

Practical implication: Map each leaver event to NHI discovery so exposed secrets are identified before the human account is fully closed.

Why reassignment is not the same as decommissioning

The article highlights a common mistake: treating an exposed NHI as if it can simply be reassigned to another person. Reassignment may be acceptable for owned application roles, but it is not a safe default for service accounts, keys, or credentials embedded in automation. Those identities often have latent permissions and hidden dependencies, so changing the human custodian does not remove the original exposure. Proper handling requires distinguishing between ownership transfer, privilege reduction, and full decommissioning. Without that distinction, teams can accidentally preserve excessive privilege under a new administrative wrapper.

Practical implication: Classify exposed NHIs into transfer, restrict, or retire paths before any ownership change is made.

How automated rotation reduces the post-exit exposure window

Rotation is the mechanism that turns discovered exposure into a shrinking risk window. If a secret was visible to a departing employee, changing it after offboarding cuts off reuse by anyone who captured or retained it. The article also points to real-time monitoring as a companion control, because rotation alone does not confirm whether the secret was already abused. In practice, this is a lifecycle control problem: discovery identifies what was exposed, rotation invalidates what can still be used, and monitoring checks for activity during the gap between exposure and remediation.

Practical implication: Trigger secret rotation immediately after exposure is confirmed, then validate that the old credential is no longer accepted anywhere.

Threat narrative

Attacker objective: The objective is to preserve or exploit valid machine access after human offboarding so cloud and internal resources remain reachable.

1. Entry occurs when a departing employee retains knowledge of or access to a service account, API key, or secret that was exposed during the employment relationship.
2. Credential abuse follows when that non-human identity remains valid after the human account is removed, allowing continued access from outside the organisation.
3. Impact occurs when the former employee or another actor uses the standing NHI to reach cloud resources and move laterally within critical systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human offboarding does not govern machine exposure. The leaver process was designed for employee accounts, devices, and human access revocation. That assumption fails when the departing person has seen or created NHIs that continue to authenticate independently of the employee record. The implication is that offboarding has to be treated as a cross-identity event, not a human-only workflow.

Identity ownership and credential validity are not the same thing. A person can leave the organisation while the secret they touched remains valid for days, weeks, or longer. This is a lifecycle failure mode, not a simple access review miss, and it creates a standing credential exposure window that human IAM controls do not naturally observe. Practitioners should stop assuming that account closure equals exposure closure.

Exposed NHI decommissioning is a governance problem, not a help desk task. The article shows that offboarding requires visibility into secrets, scripts, service accounts, and privileged dependencies. That is squarely in OWASP-NHI and NIST-CSF territory, because discovery, ownership, and remediation must be coordinated across identity, infrastructure, and security operations. The practitioner takeaway is to make NHI exposure a formal offboarding control, not an afterthought.

Secret rotation becomes a containment control only when exposure is known. Rotation by itself is not the point. Its value comes from shortening the period in which a departed employee or downstream actor can still use a credential they encountered during the employment lifecycle. The named concept here is standing credential exposure window, and it is what turns routine offboarding into a security event when unmanaged.

Lifecycle governance must separate service continuity from identity continuity. NHIs often cannot be deleted immediately because applications depend on them, but that operational constraint does not remove the need to track exposure, ownership, and revocation state. The field should treat continuity planning and credential governance as different layers of the same programme. Practitioners need controls that preserve services while eliminating human-access bleed-through.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• To go deeper, review NHI Lifecycle Management Guide for practical lifecycle controls that shorten exposure windows.

What this signals

Offboarding is becoming a boundary event between human identity governance and machine identity governance. As organisations formalise mover-leaver controls, the next failure mode is not whether the employee account is removed, but whether the secrets that employee touched are still valid, discoverable, and attributable after exit.

Standing credential exposure window: the period in which a secret remains usable after the person who saw it has left. That window is now the control target, because identity programmes that cannot measure it are effectively blind to post-exit machine access.

Teams should expect offboarding workflows to shift from ticket closure to evidence-driven remediation, with discovery, rotation, and verification becoming mandatory proof points. If the programme cannot demonstrate that exposed NHIs were identified and retired, the exit process remains incomplete.

For practitioners

• Inventory exposed NHIs at the point of offboarding Tie HR departure and mover events to an NHI discovery step that identifies service accounts, API keys, scripts, and shared secrets the employee could access or create.
• Separate ownership transfer from credential retirement Do not reassign a secret just because the employee left. Decide whether the identity can be safely transferred, restricted, or fully decommissioned based on system dependency and exposure.
• Rotate any secret with confirmed exposure If a departing employee had visibility into a credential, rotate it immediately and verify that the old value is rejected across all connected systems.
• Add offboarding checks to secret monitoring workflows Track whether exposed secrets are still active after the human account is disabled, then escalate any remaining valid access as a closure blocker for the leaver ticket.

Key takeaways

• Offboarding human accounts does not remove the machine credentials that employee could still know or reuse.
• The exposed-secret problem is measurable, and the risk persists long enough to create lateral-movement opportunity.
• The control that changes the outcome is not more HR process, but NHI discovery plus verified secret retirement or rotation.

Key terms

• Non-Human Identity: A non-human identity is a machine or workload credential used by software, services, automation, or integrations. It includes service accounts, API keys, tokens, and certificates. In governance terms, it needs lifecycle, ownership, and revocation controls even when no person directly logs in.
• Standing Credential Exposure Window: The period during which a credential remains usable after it has been exposed to a departing employee or another untrusted party. This matters because machine credentials can outlive human access changes, creating a post-exit attack window that human IAM controls do not automatically close.
• NHI Discovery: NHI discovery is the process of finding machine identities, secrets, and dependencies across applications, scripts, cloud services, and automation. The goal is not just inventory. It is to establish ownership, exposure, and lifecycle state so exposed credentials can be rotated or retired safely.
• Secret Rotation: Secret rotation replaces a credential with a new value and invalidates the old one. For NHIs, it is a containment control that reduces the usefulness of a leaked key or token, but it only works when the organisation can prove the old secret is no longer accepted anywhere.

Deepen your knowledge

NHI lifecycle management and exposed-secret remediation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your organisation is trying to extend mover-leaver controls beyond human accounts, this is a practical place to start.

This post draws on content published by Oasis Security: How to manage the NHIs exposed to an offboarded employee? Read the original.