What breaks when a former employee account is not fully revoked?

Why This Matters for Security Teams

When a former employee account is not fully revoked, the risk is not limited to a stale username in a directory. Active sessions, delegated access, API tokens, mail rules, cloud console roles, and SaaS entitlements can remain usable long after employment ends. That creates a direct path for misuse, whether the former user returns with bad intent or an attacker takes over the account through credential reuse or session theft. The control failure is lifecycle management, not just authentication.

This is especially dangerous in environments where access is distributed across identity providers, HR systems, cloud platforms, and business apps. Security teams often assume deprovisioning is complete once the primary account is disabled, but the real exposure usually sits in linked systems and standing authorizations. NIST SP 800-53 Rev 5 Security and Privacy Controls treats account management as an ongoing control activity, not a one-time event, because authority must be removed wherever it exists. In practice, many security teams discover the gap only after a mailbox rule, OAuth grant, or cloud privilege has already been abused, rather than through intentional offboarding validation.

How It Works in Practice

Effective offboarding has to remove authority across the full identity surface, not just deactivate the login. That means revoking identity provider access, expiring active sessions, removing group memberships, disabling delegated admin paths, rotating shared secrets that the employee knew, and invalidating tokens or application grants that survive password resets. Where the former employee used privileged access management, approvals and just-in-time paths also need review so the account cannot re-enter a privileged workflow after termination.

For cloud and SaaS environments, the most common missed items are OAuth refresh tokens, service desk approvals, password reset channels, SSH keys, and mailbox delegation. The OWASP Non-Human Identity Top 10 is relevant here because many human offboarding failures mirror NHI failures: credentials and tokens remain valid even when the person is gone. That is why good practice is to inventory every place the identity was authorized, then confirm removal rather than assume propagation. A concise checklist usually includes:

• Disable the primary account and terminate all live sessions.
• Remove roles, group memberships, and application entitlements.
• Revoke OAuth grants, API keys, certificates, and device trust.
• Transfer ownership of data, mailboxes, code repositories, and shared workspaces.
• Review privileged access logs for post-termination activity.

In mature environments, offboarding is tied to HR event triggers, automated deprovisioning, and validation reports so exceptions are visible quickly. These controls tend to break down when identity stores are fragmented across legacy systems and SaaS apps because revocation is not synchronised everywhere at once.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid revocation against legitimate business continuity, especially where the departing employee owns critical projects or shared services. Best practice is evolving on how much should be automated versus manually reviewed, but there is no universal standard for this yet.

Contractors, temporary staff, and joint-venture users create special cases because access may be intentionally limited but still widely distributed. Another edge case is privileged administrators who never used a single interactive account; they may have multiple break-glass paths, bastion access methods, or automation credentials that outlive the employee record. In regulated environments, revocation evidence should be retained so auditors can see when access ended and what was confirmed. For identity governance, the principle also aligns with least privilege and continuous control verification described in NIST SP 800-53 Rev 5 Security and Privacy Controls. When SaaS or cloud admins can create new tokens faster than offboarding can remove them, the control becomes a race condition instead of a safeguard.

Related resources from NHI Mgmt Group

• What breaks when a leaked NHI credential is rotated but not fully revoked?
• What breaks when a former employee still has access to shared cloud root credentials?
• Who is accountable when a former employee account or stolen token is used in a breach?
• What breaks when employee offboarding is handled as a simple account deletion?