Offboarding Removes the Account but Not the Access

When someone leaves, their primary account gets disabled, but there’s no inventory or revocation of the other access acquired during their tenure: sessions, tokens, API or SSH keys, local accounts, third-party accounts, enrolled devices, shared secrets, VPN access, RMM, non-federated applications, and recovery mechanisms.

The process conflates identity with account. The account disappears from the directory; the access itself remains scattered across the environment.

Residual access is hard to attribute and even harder to search for after the fact. Some of it can function for months without producing an anomaly, especially when it relies on legitimate tools or shared accounts.

A former employee, a contractor, or anyone who managed to retrieve their secrets can come back in without ever reactivating the disabled account. During an incident, the organization believes it closed the front door while several windows remain open.

The risk is higher for technical roles, contractors, and anyone who administered multiple clients or platforms.

• Compare recent departures against the accounts and identities present in applications, VPN, firewalls, cloud platforms, code repositories, RMM, and security tools.
• Look for keys, tokens, and integrations created by the user or used from their devices.
• Check local, generic, and shared accounts whose secret the person knew.
• Review enrolled devices, authentication factors, app passwords, and recovery methods.
• Ask the manager and the technical lead what access actually existed; the central registry is rarely complete on its own.

• Maintain a register of assigned access, including non-federated secrets, keys, tokens, local accounts, and third-party platforms.
• Link each access to an individual identity wherever possible, and enforce expiration on temporary access.
• Trigger a revocation checklist tailored to the role, not a one-size-fits-all procedure.
• Rotate shared secrets known to the person and transfer ownership of automations, keys, and integrations.
• Revoke sessions, devices, and factors; recover or wipe managed equipment.
• Verify closure with technical evidence, not a “done” checkbox on the HR ticket.

• Build the complete list of historical access held by the person or the compromised identity.
• Revoke sessions, tokens, keys, certificates, devices, and secondary accounts; rotate shared secrets.
• Review activity on non-federated platforms and local accounts across the entire relevant period.
• Look for new accounts, rules, keys, or integrations created before the departure or the detection.
• Avoid immediately deleting accounts or artifacts needed for the investigation; disable, preserve, then remove following a documented sequence.

This sheet complements MFL-006: MFL-006 covers sessions that survive account disablement; MFL-026 covers all access that no longer depends on that account, or was never tied to it in the first place.