Offboarding That Actually Revokes Access

Ask most organisations how offboarding works and you get: HR notifies IT, IT disables the account, done. That handles the obvious path and leaves several that are not.

The access that survives a departure is rarely the main account. It is everything that does not authenticate through it.

What actually survives

Applications outside single sign-on. The marketing tool a department bought on a card, the design software with its own login, the vendor portal with shared credentials. If it does not authenticate through your identity provider, disabling the account changes nothing.

Shared credentials. The social media account, the domain registrar, the bank portal with one login the team uses. Disabling a person does not rotate a password they know. Every departure of anyone who knew a shared credential should trigger rotation — which is a strong argument for having as few as possible.

Personal devices. Mail and documents cached on a personal phone or laptop. Without app protection or device management offering selective wipe, that data stays. This is the most common gap in organisations that permit BYOD informally.

API tokens and service accounts. Tokens the person created, keys they generated, automations running under their name. These frequently outlive the account, and sometimes break when it is deleted — which is how you discover a production job was running as a departed employee.

Physical access. Badges, keys, alarm codes. Usually a different system and a different owner.

Mail forwarding and delegation. A forward set up to a personal address, or delegated access granted to someone who has also since left.

Third-party systems where they are the registered contact. The domain registrar, the certificate authority, the SaaS vendor whose account recovery goes to their email.

Recovery methods. Their phone number as the MFA fallback on a shared or administrative account. This one is easy to miss and completely undermines everything else.

Why the standard process misses these

Because it is organised around the account rather than around access, and because the authoritative list of what someone could reach does not exist anywhere.

The person who knows is usually the departing employee's manager, who is focused on handover, and the departing employee, who has no obligation to be thorough.

Building a process that works

Maintain an access inventory per role

Not per person — per role. What does someone in this role get access to? Built once, maintained as things change, and it becomes both the onboarding checklist and the offboarding checklist.

This is the single highest-value artefact in the process and the one most organisations do not have.

Separate the urgent from the thorough

Immediately — within the hour for an involuntary departure:

• disable the account, do not delete it
• revoke all active sessions and refresh tokens, which is distinct from disabling the account
• disable VPN and remote access
• revoke MFA registrations
• disable physical access
• rotate any shared credential they knew

Revoking sessions matters more than people realise: a disabled account with a live session can continue working until that session expires, which may be hours or days.

Within the week:

• transfer file ownership and mailbox access to the manager
• reassign or revoke API tokens and service accounts running under their identity
• remove from distribution lists, shared mailboxes and groups
• selective wipe of company data from personal devices
• update any external registration where they were the contact
• reclaim licences — which is also where the cost saving is
• collect hardware, and confirm what is on it

Within the month:

• confirm no mail forwarding or delegation remains
• review anything that broke, which reveals undocumented dependencies
• confirm licence reclamation actually happened

Do not delete the account too quickly

Deleting removes the audit trail, breaks anything running under that identity, and can orphan files. Disable, retain for a defined period that satisfies your obligations, then delete on a schedule.

Handle the involuntary case differently

For a termination, access revocation should complete before the conversation, not after. That requires HR and IT coordination that has to be agreed in advance, because there is no time to design it on the day.

The audit that finds what you have missed

Twice a year, independently of any departure:

• list every enabled account and reconcile against the current HR roster
• list accounts with no sign-in for 90 days
• list service accounts and name an owner for each — unowned ones are the problem
• list external sharing links and OAuth grants
• check who holds shared and administrative credentials
• check MFA recovery methods on privileged accounts for departed people's phone numbers

Expect to find things. Every organisation that runs this for the first time does, and that is the point of running it.

Why it is worth the effort

Former-employee access is a well-represented category in breach reports, and the cases are rarely malicious. They are usually a shared password still working, an application nobody tracked, or a personal device with cached mail.

Each is cheap to prevent and awkward to explain afterwards — particularly to a customer or regulator asking why someone who left eight months ago could still reach their data.