What should teams do when employees leave but access still remains active?

Why Offboarding Must End Access, Not Just Employment

When someone leaves, the security problem is not the resignation date itself, it is any surviving path back into systems, data, or workflows. A clean offboarding process treats employment end, access end, and credential end as the same operational event, then verifies that the account state actually changed everywhere it mattered.

The practical reason is simple: modern access is rarely limited to one directory entry. A departing employee may still have active access through SaaS admin panels, shared tools, API tokens, password managers, VPN profiles, delegated roles, or application-specific permissions long after HR records show the person is gone.

What Has to Be Removed, Disabled, or Confirmed

The minimum outcome is not just password reset or a note in the ticket. Teams should revoke active logins, disable or delete the primary account where policy allows, and remove every linked entitlement that could still authenticate or authorize the former employee. That includes direct application access, group membership, SSO assignments, privileged roles, and any standing permissions inherited from teams or projects.

Verification matters because access often persists in places offboarding checklists miss. Shared admin consoles, SaaS tenant permissions, service portals, and locally cached credentials can outlive the employee record unless someone explicitly confirms the account state in each system. The goal is a complete access stop, not a best-effort request.

Where access is tied to a device, session, or token, the offboarding review should also confirm that the old trust path is no longer usable. A disabled directory account is not enough if a long-lived session, a synced app token, or a separately managed password still grants entry.

How Teams Prevent Leaver Gaps From Becoming Exposure Paths

The strongest approach is to make offboarding a control that is checked, not assumed. That means the offboarding workflow should produce evidence that the account was disabled or removed, the major connected applications were reviewed, and any elevated or unusual permissions were explicitly cleared before the case is closed.

For teams that rely on central identity systems, the most effective habit is to treat termination as a privilege-change event with a deadline, not an administrative follow-up. If the access path can still be used after the employment relationship ended, the control has failed regardless of whether the person has already left the building.

Offboarding also needs an exception path for urgent departures. If there is any indication of conflict, misuse, or timing risk, the response should prioritize immediate access removal first and documentation second. The system state matters more than the paperwork trail when the access window is still open.

Risk and Threat Considerations

Residual access creates a straightforward exposure: a former employee may still be able to view data, make changes, or authenticate as if they were still trusted. Even without malicious intent, forgotten access can lead to accidental actions, policy breaches, or retention of access that no longer has a business justification.

Failure mechanism: Offboarding breaks when identity records are updated in one place but application permissions, tokens, or privileged memberships remain active elsewhere. That leaves a stale access path that can be used after employment ends, and the gap often persists because different teams own different systems.

Impact: The result can be unauthorized data access, unauthorized changes, lingering administrative capability, or later account abuse if the old access is discovered by another party. In practice, the longer the gap remains open, the more likely it is to become a durable exposure rather than a brief oversight.

Practitioner Guidance

What to verify: Confirm not only that the main account is disabled, but that all connected application permissions, group memberships, and elevated roles were removed. If the employee used multiple SaaS tools, verify each one rather than assuming directory deprovisioning propagated everywhere.

Decision rule: If a leaving employee had privileged, financial, customer, or production access, treat the case as high priority and require explicit closure evidence before acceptance. If the access was broadly delegated or duplicated across tools, verify the downstream entitlements individually rather than relying on one identity-system status.

Practitioner takeaway: Offboarding is complete only when the person can no longer authenticate, inherit, or reuse access anywhere that matters, and the organisation has proof of that state.

Related resources from NHI Mgmt Group

• How should security teams secure AWS access when employees still rely on on-premises Active Directory accounts?
• How do security teams know if unmanaged access is still active?
• How should security teams handle offboarding when employees still have valid access to third-party SaaS tools after an IdP disablement?
• How should security teams handle leaked AWS keys that still have active admin access?