The most expensive security incident I've watched a startup go through started with an offboarded engineer's GitHub personal access token. The engineer had left amicably eighteen months earlier. HR had revoked their email. IT had collected the laptop. Nobody had revoked the GitHub PAT they'd generated for a CI workflow on a public repo. When that PAT eventually leaked through a misconfigured GitHub Action log, the attacker had production push access to a repository that contained AWS credentials.

Offboarding is the failure mode no one wants to plan for and everyone gets bitten by. This article is the secure offboarding checklist I wish I'd had — the specific accounts, tokens, and credentials to revoke, in the right order, with notes on what's commonly missed.

Why offboarding is harder than onboarding

Onboarding is event-driven: HR triggers it, IT executes a known checklist, the employee gets access. The state transition is "no access → access," and any miss means the employee can't do their job, which gets caught immediately.

Offboarding is the inverse — and the failure mode is silent. If you forget to revoke an SSH key, the employee can still use it. They probably won't. But "probably" is the wrong word in security. Six months later, a malicious actor (or just a careless ex-employee with a stolen laptop) has access you forgot to remove, and you have no way to detect it until something visible breaks.

The fix is a comprehensive checklist, run as a single deliberate action, with a verifiable audit at the end.

Day -1: Before the offboarding day

If the offboarding is planned (resignation, end of contract):

Identify the leaver's full credential surface. Pull a list of every system they have access to. This is harder than it sounds — see the section below on inventory.
Audit shared credentials they may have accessed. Any password manager item shared to a group they were in? Mark it for rotation.
Plan the credential handover. Which of their personal tokens (CI tokens, deploy keys, service account keys) need to be regenerated under a successor's name?
Schedule the access cutoff time. Usually end of their last working day.

If the offboarding is unplanned (termination, security incident):

Cut access first, audit after. Speed matters more than completeness in the first hour.
Lock all SSO sessions immediately. Don't wait for the laptop return.

The complete offboarding checklist

Run through this in order. Each item should have an owner and a verification step.

Identity and SSO

[ ] Disable Google Workspace / Microsoft 365 account
[ ] Revoke all OAuth grants tied to that identity
[ ] Revoke any active sessions (forced logout)
[ ] Disable Okta / OneLogin / SSO provider account
[ ] Remove from all SSO-protected applications

Source control

[ ] Remove from GitHub / GitLab / Bitbucket organization
[ ] Revoke all personal access tokens they created
[ ] Audit organization webhooks they may have created
[ ] Check for and revoke any deploy keys associated with their repos
[ ] Audit any GitHub Apps they installed under organization scope

Cloud providers

[ ] Disable IAM user (AWS / GCP / Azure)
[ ] Revoke all access keys associated with the user
[ ] Audit any service accounts they created — transfer ownership or delete
[ ] Check for any console session credentials that need to be invalidated
[ ] Rotate any KMS keys they had access to if they could have exfiltrated key material

Databases

[ ] Drop database users named after them (per the per-person-credential pattern)
[ ] If they used a shared credential, rotate it
[ ] Audit RDS / Cloud SQL master passwords if they had access
[ ] Revoke any temporary credentials issued by Vault or similar

CI/CD

[ ] Revoke their CircleCI / GitHub Actions / Buildkite tokens
[ ] Audit any pipeline secrets they may have set
[ ] Check for self-hosted runners they registered
[ ] Rotate deploy keys for production deployments

SaaS tools

[ ] Slack: deactivate (don't delete — preserves audit trail)
[ ] Notion / Confluence: revoke access, transfer page ownership
[ ] Linear / Jira: deactivate, reassign tickets
[ ] Figma: remove from team
[ ] Datadog / Sentry / monitoring: revoke API tokens, deactivate user
[ ] Stripe / billing systems: revoke API keys they created
[ ] Customer support tools (Intercom, Zendesk): deactivate

Servers and SSH

[ ] Remove their SSH public key from authorized_keys on every server
[ ] If you use a centralized config (Ansible, Chef), remove from the role
[ ] Audit any bastion access logs for unusual recent activity
[ ] Revoke any SSH certificates issued to them
[ ] If they had root on any server, audit ~/.ssh/authorized_keys for keys they may have added

Hardware

[ ] Collect laptop, phone, hardware security keys (YubiKeys)
[ ] Wipe and reimage the laptop
[ ] Disable any registered MFA devices
[ ] Revoke device certificates (if you use device-based auth)

Customer-facing

[ ] Review any vendor relationships they managed
[ ] Update emergency contacts and on-call rotations
[ ] Notify customers if they were the named technical contact
[ ] Update support tool routing if they were a support agent

The documentation step that everyone skips

[ ] Write a one-page "what they owned" document for the team
[ ] Hand over any in-progress credentials and access via a secure channel

The credential handover problem

Here's the part most checklists ignore. The leaver had credentials they shared with no one — a personal CI token, a shared but un-documented API key for a third-party service, the password to the coffee shop wifi the team uses for offsites. Before they walk out, those credentials need to transfer to a successor.

This is where ad-hoc credential sharing fails. The leaver opens Slack, DMs the new owner, pastes the credentials, and now you have one more long-lived chat-message credential exposure.

The right pattern: leaver opens a secure share tool, encrypts each credential as a separate self-destructing share with a 24-hour expiry, sends links to the successor. Successor opens each, copies into the team password manager, the links die.

The leaver gets a clear "I've handed over everything" moment. The successor gets a clean import. No persistent chat-history exposure.

Verification after offboarding

The day after the cutoff, run a verification pass:

Try to log in as them through SSO (should fail).
SSH from one of your servers using their old key (should fail — Permission denied (publickey)).
Check the audit log of every system they had access to for any activity by them after the cutoff. If you see activity, you missed a credential.
Run a pg_user audit and verify their DB users are dropped.
Run aws iam list-access-keys --user-name them and verify nothing is active.
Spot-check three random servers' authorized_keys.

The goal: if a determined ex-employee tried to access something at 3 AM the next day, they should fail at every door.

Where SnapSend fits in

The credential handover step is what SnapSend is built for. The leaver creates one Credential Card per credential they need to transfer, sets a 24-hour expiry, sends links to the successor. Each link is end-to-end encrypted, self-destructs on first read, and leaves no copy in Slack or email.

The Secure Receive flow is also useful here — the successor can generate request links for "send me the staging API key" and the leaver fills them in. The successor's browser is the only place that can decrypt, which means even if the leaver is going somewhere they shouldn't, the credentials don't end up in their archive of the offboarding chat.

Make offboarding boring

A boring offboarding is a successful offboarding. The leaver gets to leave with no lingering questions. The team gets to move on without a slow-burn liability. The cost is a comprehensive checklist and the discipline to run it every single time.

Try SnapSend free at snapsend.site — no account needed.