Notifications
Clear all
Topic starter
06/06/2026 1:59 am
TL;DR: Employee offboarding often stops at human accounts while exposed service accounts, API keys, and secrets remain active, leaving lateral-movement paths open, according to Oasis Security. The real control gap is that human leaver processes are not enough when non-human identities outlive the employee who saw them.
NHIMG editorial — based on content published by Oasis Security: How to manage the NHIs exposed to an offboarded employee?
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step leaver and mover workflow for identifying NHIs tied to a departing employee
- Platform-specific discovery and correlation logic for linking human identities to exposed secrets
- Automatic safe secret rotation for secrets already managed in the platform
- Examples of how prioritisation and remediation tasks are grouped for offboarding teams
👉 Read Oasis Security's guidance on managing NHIs exposed to offboarded employees →
Offboarding exposed NHIs: where mover-leaver controls fail?
Explore further
06/06/2026 3:24 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Offboarding exposed NHIs is the gap human IAM keeps missing
