Employee Offboarding Security: Closing Every Door on the Day They Leave
7 min readAccounts & Access
Ask a founder how many former employees still have access to something, and the honest answer is usually "I'd have to check". Then they check, and the answer is not zero.
This is not a discipline problem. It is a structural one: access is granted continuously by many people over years, and revoked — if at all — once, in a hurry, by someone with a lot on their mind on the person's last day.
Here is the checklist that fixes it, in the order the clock actually runs.
The gap: accounts outlive employment
Three things make offboarding leaky at small companies specifically.
Nobody has the full list. Tools get adopted by whoever needed them. Marketing signed up for a scheduling tool, a developer added a monitoring service, someone's personal card pays for a design subscription. There is no central inventory, so there is nothing to work down.
SSO covers less than you think. Even with Google Workspace or Microsoft 365 as your identity provider, "sign in with Google" is not the same as being managed by Google. Many tools let someone create a local password in addition to social login — and that local password survives the Google account being suspended. Suspending the identity provider account is necessary and not sufficient.
The relationship is friendly. Most departures are amicable, which makes the security steps feel like an accusation. So they get softened, delayed, or skipped. Do them anyway, and do them for everyone identically — a process applied uniformly is not personal, and that is exactly why it should be written down before you need it.
Worth being clear about the real risk. The rare case is a departing employee doing damage deliberately. The common case is an account that stays live, unmonitored, protected by a password that later appears in an unrelated breach, and gets used by someone with no connection to your former colleague at all. You are not defending against the person who left. You are defending against the account they left behind.
The offboarding checklist
Hour one: identity and email
Start the moment the departure is effective — for a resignation, the agreed time; for an involuntary exit, before the conversation ends, not after.
- Suspend the identity provider account. Suspend, do not delete. Deletion can destroy data you are legally required to retain and can break shared file ownership. Google Workspace and Microsoft 365 both keep a suspended account's data intact.
- Revoke all active sessions. This is the step that gets missed, and it is the one that matters most. Suspending an account does not always terminate sessions already running on a laptop or phone — a live session can continue working for hours or longer. Both major platforms have an explicit "sign out all sessions" action. Use it.
- Reset the password anyway. Belt and braces, in case reactivation happens later.
- Check for mailbox forwarding rules before you change anything else. If a rule is forwarding mail to a personal address, you want to know it existed. Then remove it.
- Handle their email properly. Delegate the mailbox to their manager, or convert it to a shared mailbox. Do not set up an auto-forward to a colleague's personal inbox, and do not re-use the address for a new hire for at least a few months — password reset emails for old accounts are still arriving at it.
- Remove them from group aliases — sales@, support@, the all-staff list.
Day one: the accounts SSO doesn't cover
- Work the SaaS inventory. If you do not have one, this is the moment to build it — the fastest sources are your card and bank statements for the last twelve months, plus the "connected apps" or "third-party access" page in your Google Workspace or Microsoft 365 admin console. That page is often revealing on its own.
- Revoke third-party app access granted through their account via OAuth. A connected app can hold a token that keeps working after the account is suspended.
- Remove them from tools that keep local passwords — the ones where "sign in with Google" was optional. This is the category that leaks. Check each tool's user list directly rather than assuming SSO handled it.
- Rotate credentials they knew. Any shared login they had, any API key or service credential they created or had access to, any server or database password. If they had production access, treat every secret they could read as needing rotation. This is tedious and it is the difference between a suspended account and actually revoked access.
- Remove them from code repositories, cloud consoles and CI/CD — including personal access tokens, deploy keys and SSH keys they registered.
- Transfer ownership of anything they own before you go further: documents, calendars, automations, domains, cloud resources, the analytics property, the ad account. Ownership orphaned to a suspended account becomes a genuine problem later.
Week one: devices, data and money
- Collect company devices, and check them before wiping — sometimes the only copy of something important is on a laptop.
- Handle personal devices with company data. If they used their own phone for email, remove the company account remotely. Most device management, including the basic tier built into Google Workspace and Microsoft 365, supports removing just the company account rather than wiping the personal phone. Know which one you are triggering before you click.
- Revoke building access, alarm codes and physical keys. If a shared door code was known to them, change it.
- Remove payment authority. Company cards cancelled, banking and payment-processor access removed, expense tools deactivated, and their approval rights reassigned rather than left vacant.
- Remove them from the customer-facing surfaces — support desk, shared inboxes, social accounts, anywhere they could still send a message that appears to come from your company.
- Tell the people who need to know. Key customers and suppliers should hear from you who their new contact is. This is courtesy, and it is also fraud prevention: a supplier who has been told will be more suspicious of a later message from a personal address claiming to be your former employee.
Get the 31-point security checklist
The checklist, then one email a week on what changed and what a company your size should do about it.
Weekly. Unsubscribe in one click. See the checklist first.
The two hard cases
Shared accounts
Every small company has at least one login that "everyone uses". When someone leaves, that password is out, and rotating it means interrupting everyone else.
Short term: rotate it anyway, from the password manager, and tell the team it changed. Longer term: eliminate the category. Most tools now offer per-user seats or a shared-mailbox model that removes the need for a shared password entirely. Where a genuine shared credential is unavoidable — an old system with a single admin login — keep it in the password manager, record exactly who has access, and rotate it on every departure without exception.
The realistic upgrade path is one shared account per quarter. That is slow, and it is much better than the annual "we should really fix that".
The founder or admin who left
The highest-risk departure is the technical co-founder, the first employee, or the outsourced IT person who set everything up. They are the one who owns the domain registrar, the root cloud account, the backup system and the credentials nobody else has ever seen.
Handle this deliberately and early, ideally while the relationship is still good:
- Change ownership of the domain registrar first, then the cloud root account, then the identity provider's super-admin.
- Verify the recovery email and recovery phone number on every critical account — an old personal address left as the recovery contact is a permanent back door, and it survives every password change you make.
- Rotate the root and break-glass credentials, and store the new ones somewhere at least two current people can reach.
- Check where the backups live and who can delete them.
Do this even when — especially when — you are certain there is no ill intent. You are not protecting yourself from them; you are protecting yourself from anyone who compromises their personal email in three years' time.
Make it repeatable
Two documents, both short.
A one-page checklist, kept where whoever runs departures will find it, with a named owner and a completion date per line. The unchecked box is the point: it makes the gap visible instead of remembered.
A living SaaS inventory — tool, what it holds, who administers it, how access is granted and removed. A spreadsheet is fine. Update it when a tool is adopted, not at audit time.
Then two habits that make the whole thing cheaper:
Grant less in the first place. Most access does not need to be permanent or company-wide. Administrator rights belong to the two or three people who genuinely need them. The less you grant, the less there is to chase.
Review quarterly, not only on departure. Fifteen minutes with the user list of your five most important systems. You are looking for three things: people who left, people whose role changed, and accounts nobody recognises. This review is also, conveniently, evidence for the access-management questions on every security questionnaire and cyber insurance application you will ever fill in.
The offboarding checklist is the visible part. The quarterly review is what makes it accurate.