A secure employee offboarding checklist (close the access gaps)

When someone leaves your business, the security question isn't whether you'll remember to delete their email. It's whether you can revoke everything they could touch, every app, every shared login, every network path, every key, before the gap is exploited. For most growing companies the honest answer is "not entirely, and not quickly." Offboarding is one of the most predictable access-security gaps there is, and it's almost always a process problem rather than a tooling one. This checklist walks the steps in the order that actually closes the door.

Why offboarding is a top access-security gap

Provisioning gets attention because it's blocking: a new hire can't work until they have access, so someone makes it happen on day one. Deprovisioning has no such forcing function. Nothing breaks when a departed employee keeps a login, so it quietly persists. Months later, that dormant account is exactly what an attacker wants: valid credentials, no one watching, and no one who'll notice the login.

The risk is widest where access is scattered. If each application was granted separately, each one has to be revoked separately, and the list of "each one" is rarely written down completely. Contractors and seasonal staff make it worse, because their access often spans the same critical systems as full-time employees but with even looser tracking. The account that breaches you next quarter frequently belongs to someone who left last year.

The offboarding checklist, in the right order

Order matters here. The goal is to cut the broadest, fastest-acting access first, then work down to the long-tail cleanup. Doing it backwards leaves the front door open while you tidy the back rooms.

1. Disable the identity first

Before touching individual apps, disable the person's core identity account, the one they sign in through. If your access runs through centralized single sign-on, suspending that one identity immediately severs the path to every connected application behind it. This is the single highest-leverage action in the entire process, which is why it goes first. Suspend rather than delete at this stage so audit history and any files tied to the account stay intact.

2. Revoke active sessions and tokens

Disabling an account doesn't always end sessions that are already live. Force a sign-out everywhere and invalidate active session tokens, API keys, and any "remember this device" trust the person held. A still-valid session on an unmanaged laptop can outlive the account itself if you skip this.

3. Cut application access

Work through every app the person could reach. With centralized access management, most of this collapses into the identity suspension from step one. For anything outside that (standalone SaaS tools bought by a single team, legacy systems, anything provisioned ad hoc), revoke access explicitly. This is exactly where a complete, maintained inventory of who-has-what earns its keep.

4. Revoke network and remote access

Don't stop at applications. Remove the person from any secure private network access, VPN profiles, and remote-access entitlements. Network access is easy to forget because it's invisible day to day, but a lingering network path can be more dangerous than a single app login. It's a foothold, not just a door.

5. Rotate shared secrets

Any credential the person knew but didn't personally own is now compromised by definition. Rotate shared admin passwords, service-account credentials, Wi-Fi keys, and anything stored in a shared vault that they could read. Shared secrets are the quiet exception to identity-based revocation: suspending one account does nothing if five people knew the same root password.

6. Reclaim devices, keys, and hardware

Recover laptops, phones, hardware security keys, access badges, and any other physical token. For each device, confirm it's wiped or re-enrolled before reissue. A hardware key still in a former employee's drawer is a second factor an attacker would love to have.

7. Reassign ownership and data

Transfer ownership of files, mailboxes, shared documents, and any automations or integrations the person ran. This is partly continuity and partly security: orphaned resources with no owner tend to drift outside policy and become the thing nobody's watching.

8. Audit and verify

Finally, confirm the work. Pull the access and audit record for that identity and verify the revocations actually took effect rather than assuming they did. A good audit trail turns "I think we got everything" into "here's the evidence we did," which is also exactly what you'll want on hand if a question ever comes up later.

How centralized identity makes this one action

Most of the checklist above shrinks dramatically when access is governed centrally instead of app by app. When every application and network path sits behind a single identity, the hardest and most error-prone steps (find every place this person had access, then revoke each one) collapse into suspending one account. You go from a manual hunt across a dozen dashboards to a single, instantaneous, auditable action.

That's the real argument for centralizing access before you need to. Offboarding isn't a task you want to be improvising under time pressure on someone's last day. It should be a routine you can run in minutes and prove afterward. The steps that remain (rotating truly shared secrets, reclaiming physical devices) are the genuinely manual ones, and they're a short list when identity does the heavy lifting.

Where Clavkey fits

Clavkey is the platform that makes most of this one action. Staff and clients sign in once, and you manage every grant from a single console, so when someone leaves, suspending their identity revokes their applications and network access together, with the audit record to prove it. The few genuinely manual steps stay short. If your offboarding today is a checklist nobody's sure is complete, talk to us and we'll map what a single, governed revocation looks like for your team.