What should teams do first when a user leaves and access must be revoked?

What should happen first in a leaver revocation?

The first move is to stop active access immediately, then work outward through the rest of the user’s access paths. That means shutting down current logins, then disabling the channels and credentials that can recreate access, before turning to shared ownership, group membership, and formal deprovisioning checks. The order matters because delayed revocation leaves a window for continued use.

In practice, the initial step is an access freeze, not a paperwork task. If the account can still reach systems through SSO, VPN, mail, privileged sessions, tokens, or reset paths, the user still has a live route back in even if the HR record already shows termination. That is why leaver handling is a security control, not just an admin workflow.

Why the revocation sequence matters

Revocation has to be sequenced around blast radius. Active sessions and reusable credentials create different exposure paths, so a complete shutdown is stronger than simply changing one password or disabling one directory account. A complete response also has to consider whether the user held access through delegated roles, shared accounts, or service-linked permissions that do not disappear with the primary login.

The cleanest way to think about the process is to remove the highest-trust, most immediately usable access first, then remove the lesser but persistent paths. That usually includes session invalidation, token and certificate revocation, mail and VPN shutdown, and then entitlement cleanup. If you only remove the visible account object, you can leave live sessions or alternative authentication material in place.

For a structured leaver process, the Employee Offboarding Security Guide gives a practical sequence for HR-triggered revocation, session shutdown, and follow-up checks. For teams building the broader access governance model behind that sequence, IAM and IGA Basics explains how provisioning, entitlements, and access governance fit together during joiner, mover, and leaver events.

Which access paths must be removed, not just disabled

Teams should treat the primary account as only one part of the leaver footprint. Live sessions, SSO assertions, VPN access, mailbox access, privileged shells, API tokens, certificates, and password reset paths can all keep access alive after the account itself looks closed. Shared accounts and group memberships also matter because they can preserve indirect access even after the named user account is disabled.

The operational question is whether the person can still authenticate, authorise, or recover access by another route. If the answer is yes, the revocation is incomplete. That is why good offboarding also includes ownership transfer for shared resources, removal from groups and roles, and confirmation that recovery options no longer point back to the departing user.

For cloud and platform identities, the same principle applies to the credentials and roles behind the account. The Cloud Workload Identity Guide is useful where the leaver touched service principals, roles, or temporary credentials, and the Access Control Policy Template shows how to encode leaver handling, least privilege, and review cadence into policy rather than relying on memory.

Risk and Threat Considerations

A delayed or partial leaver action can leave a still-valid path into production systems, messaging, or administrative consoles. The most common risk is not a dramatic new compromise, but continued legitimate use after employment ends, followed by missed visibility because the access looked disabled in only one place.

Failure mechanism: Residual sessions, cached tokens, certificate-backed access, or inherited group entitlements can survive the first disable action, allowing the former user or another party holding those credentials to keep operating until the remaining paths are revoked.

Impact: The organisation can lose control over data, approvals, operational changes, and privileged actions, while audit evidence falsely suggests that access was removed when some routes were still active.

Practitioner Guidance

What to prioritise: Make session and credential shutdown the first operational action, then verify that the user cannot re-enter through SSO, VPN, mail, or recovery paths. Treat shared-account ownership transfer and group removal as part of the same revocation event, not as a later cleanup task.

What to verify: Confirm the revocation against a human trigger such as HR termination or manager notice, then check that no active sessions, reset channels, or privileged memberships remain. If the user had administrative or elevated access, require explicit closure evidence before closing the case.

Practitioner takeaway: The right first step is to cut off every live access path, not just disable the visible account, because leaver risk is defined by what still works after the first obvious switch is flipped.

Related resources from NHI Mgmt Group

• Who is accountable when an application keeps access after a user leaves the directory?
• Who is accountable when cloud access is not revoked after someone leaves?
• Who is accountable when social media access is not revoked after a contractor or employee leaves?
• What happens when a delegated AI agent is started by a user whose session ends or whose access is revoked?