Close the Seat, Session, Token, and Recovery Path When Someone Leaves

The Signal

An employee leaves on Friday. Their email account is disabled, the laptop is returned, and the offboarding ticket is closed. On Monday, a browser session still opens the support desk. A personal recovery address can still reset a vendor login. An API token created for a spreadsheet continues to pull customer data.

The account was closed in one system. Access was not closed across the business.

NIST’s Account Management control, AC-2, includes disabling accounts when they are no longer associated with a user and managing the lifecycle of system accounts. That is the useful operating standard here: offboarding is complete when every access path has a recorded final state, not when the email seat disappears.

Why this matters now

Most teams do not use one identity path. The company directory may control the CRM and file storage through single sign-on, while finance software has a direct login, a scheduling tool uses a personal recovery number, and an integration runs under a token the departing person created months ago.

Those paths behave differently. Removing a directory user may block a new sign-in without revoking an existing session. Resetting a password may leave an API token active. Deleting a seat can strand dashboards, automations, domains, or billing ownership under an account nobody else controls.

This is not only a security problem. It is an operating continuity problem. The former team member may have been the only owner of a form, ad account connection, password vault collection, recurring report, or vendor portal. If the company deletes first and traces later, it can lose the history and ownership needed to keep the work running.

The mistake to avoid

Do not reduce offboarding to “disable email and remove licenses.” That checklist covers visible seats. It does not prove sessions ended, tokens stopped, recovery methods changed, or business objects moved to a current owner.

Do not blindly rotate every credential either. A token may support a valid production workflow. Rotating it without naming the dependent process can break customer intake, reporting, billing, or fulfillment. The correct move is to identify the token, name its owner and dependency, replace it through the approved custody path, verify the workflow, and then revoke the old value.

The other bad fix is deleting the person’s account before transferring ownership. Preserve the audit history, files, dashboards, workflows, and approvals the business still needs. Close access without erasing the operating record.

Trace every access path

Start with the person, then inspect six objects for each system: seat, session, token, recovery method, owned assets, and data copies.

The seat tells you whether the user record is active. Sessions tell you whether already authenticated browsers or devices can continue. Tokens cover API keys, personal access tokens, app passwords, webhook secrets, and command-line credentials. Recovery methods include personal email addresses, phone numbers, backup codes, and security keys. Owned assets include domains, forms, dashboards, automations, repositories, campaigns, and billing profiles. Data copies include approved exports and local sync folders that need a retention or deletion decision.

Put the result on one line per system. Record the previous identity, the action taken, the replacement owner, the verifier, the timestamp, and the evidence link. “Removed” is not evidence by itself. A directory event, provider audit record, session-revocation result, token rotation receipt, or ownership readback shows what actually changed.

What stays protected

Keep production integrations, customer records, financial history, legal retention, and audit logs intact while you close the access paths. Offboarding does not authorize deleting shared business data or changing a live workflow without an owner and a test.

Keep personnel details restricted too. The operating receipt needs identity, system, access class, action, owner, timestamp, and evidence. It does not need the reason for departure in every tool or an open spreadsheet.

Separate custody from execution. The person reviewing the roster does not need to expose or copy secret values. Record the credential reference, rotate it through the approved custodian, verify the dependent system, and preserve only the non-secret receipt.

The first move

Pull the last five employee or contractor departures and the ten systems that hold the most sensitive data or control the most important workflows. For each departure, verify all six objects: seat, session, token, recovery method, owned assets, and data copies.

Mark the first missing receipt. If the seat is gone but session revocation was never checked, that is the gap. If a token exists but nobody can name its dependent workflow, that is the gap. If the account owns a dashboard with no successor, transfer ownership before deletion.

The move this week

Create one offboarding receipt with nine fields: person, final working time, system, access class, action, replacement owner, verifier, completed time, and evidence link. Add a separate dependency field for tokens and automations so rotation cannot happen without a readback test.

Run the receipt on one recent departure. Do not redesign the identity stack yet. Close the missing paths, transfer the owned objects, and verify that required workflows still run. Then make the receipt part of every departure ticket.

The objective is simple: no one should be considered offboarded while a seat, session, token, recovery path, or ownerless business object still says otherwise.