Departing employee access is risky because it combines legitimate knowledge with lingering access and unresolved trust. A worker may accidentally leave sensitive data on devices, or intentionally take customer data, trade secrets, or credentials to a new employer. If access is not removed promptly, the organisation may face data loss, legal liability, breach response costs, reputational damage, and regulatory penalties.
Why Offboarding Delays Become High-Risk
Departing employee access is dangerous because the access is still legitimate while trust has already changed. That gap creates a window where someone may retain access to email, cloud apps, file shares, source code, or admin consoles after their role has effectively ended. The longer that window stays open, the more likely it is to become a data-loss, privilege-abuse, or account-takeover problem.
Two factors make the risk especially sharp: the person already knows where valuable data lives, and the organisation may not have a clean inventory of every account, token, or shared credential they can still reach. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which is a useful signal of how often access removal lags behind personnel change.
What Actually Goes Wrong During Employee Departure
The failure mode is usually not one dramatic event. It is a chain of small misses: an account stays active, a device is not fully wiped, a session token survives, or a shared password is never rotated. Any one of those may be enough to keep access alive after the employment relationship has ended. If the employee is leaving on poor terms, the same gap can shift from accidental exposure to intentional misuse very quickly.
Departing staff also create special risk because their access often spans multiple systems and exceptions. They may have elevated permissions for support, finance, engineering, or operations, and those permissions are frequently inherited, shared, or poorly documented. That matters because an access path that looks harmless in isolation can still expose customer records, internal repositories, signing keys, or other sensitive material when it remains active after departure.
- Access revocation can miss accounts that were created outside central workflows.
- Shared or embedded credentials can survive the employee exit even when the main account is disabled.
- Long-lived sessions, synced devices, and cached tokens can extend access beyond the offboarding event.
- Privilege creep makes departure cleanup harder because the organisation may not know the full blast radius.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Discovery | Leaver risk is amplified by unknown active service and access accounts. |
| NHI-02 — Secrets and Credential Management | Departing users can retain tokens, keys, and other secrets after exit. | |
| NHI-04 — Lifecycle and Offboarding | The question is fundamentally about access removal at employee departure. | |
| Recommendation — Inventory all remaining access paths before and after offboarding to remove hidden credentials. Rotate or revoke any secrets the departing employee could still use. Trigger automated offboarding checks when employment status changes. | ||
| CIS Controls v8 | 5.1 — Establish and Maintain an Inventory of Accounts | You must know which accounts and shared access paths the leaver still owns. |
| 6.3 — Disable Dormant Accounts | Leaver accounts are high-value dormant access if not removed quickly. | |
| 6.4 — Restrict Admin Privileges | Departing staff often retain elevated permissions that widen blast radius. | |
| Recommendation — Maintain a complete account inventory so offboarding can remove every active path. Disable or remove accounts promptly when they are no longer needed. Revoke privileged access first and verify no inherited admin rights remain. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Offboarding depends on removing access and limiting post-employment reach. |
| PR.AA-05 — Least Privilege | Residual access is dangerous when permissions exceed the current role. | |
| DE.CM-08 — Monitoring for Unauthorized Access | Leaver accounts can be abused if lingering access is not detected quickly. | |
| Recommendation — Enforce identity and access lifecycle controls for every departure event. Reduce standing access before departure and keep permissions tightly scoped. Monitor for continued use of accounts and tokens after offboarding. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers and insiders both benefit from still-valid employee credentials. |
| Recommendation — Hunt for valid-account abuse when an employee leaves or access is not revoked. | ||
Practitioner Guidance
What to prioritise: Treat offboarding as an access-risk event, not just an HR process. The first question is whether the departing person can still authenticate anywhere, directly or indirectly, after their last working day.
What to verify: Confirm that revocation covers primary accounts, MFA methods, sessions, API keys, device trust, delegated access, and any shared credentials the person may have used. Validate removal in systems that do not automatically sync with HR records.
Common mistake: Disabling the main account and assuming the job is done. In practice, lingering tokens, local device copies, and unmanaged secrets often outlive the account closure itself.
Practitioner takeaway: The real control objective is not merely “disable leavers,” but to make sure no still-valid access path remains after trust has been withdrawn.
Related resources from NHI Mgmt Group
- Why do unintentional employee behaviors create so much security risk in modern environments?
- Why does M&A create so much security risk for identity, access, and compliance teams?
- Why does managing privileged access across heterogeneous systems create so much security risk?
- Why does weak employee security awareness create so much operational risk for identity and certificate management?
