Every employee who leaves takes two things with them: everything they remember, and everything you forgot. The first category includes shared passwords they typed for years. The second includes the contractor account nobody deprovisioned, the API key in a script they wrote, and the social media login saved in their personal browser profile. Offboarding is the process of making both categories harmless - And it's one of the most commonly botched routines in business security.
The stakes aren't hypothetical. The 2021 Colonial Pipeline shutdown began with a single dormant VPN account - No MFA, password later found in a breach dump - Belonging to an account that was no longer in active use. Surveys of IT professionals routinely find that a large share of ex-employees retain access to at least one former employer's systems weeks or months after departure, and that some admit to actually using it. Most of these aren't malicious masterminds; they're people whose Netflix-style muscle memory still logs into the old Dropbox. But an ex-employee's credentials in a phishing dump work just as well for a stranger as for the ex-employee - The account doesn't know the difference.
Why offboarding leaks happen
Three structural problems make this hard. Access accretes silently. Over a tenure, a person accumulates logins the way a desk accumulates cables: granted for one project, never revoked, invisible in any central list. Knowledge can't be revoked. Disabling someone's personal account does nothing about the shared warehouse-system password they've known since 2022 - You can't unring that bell, only change the tune. Ownership is split. HR knows when someone leaves, IT knows how to disable accounts, and individual team leads know which obscure tools their team actually uses. Any gap between the three becomes a leak.
The fix is not heroics on departure day; it's structure before it. Companies that offboard cleanly share three habits: an access inventory maintained as things are granted (not reconstructed at exit), single sign-on wherever possible, and a shared password manager for whatever can't go behind SSO.
The offboarding playbook, in order
Timing matters as much as completeness. For voluntary departures on good terms, execute at close of business on the last day; for terminations or any departure with friction, access removal happens during the exit conversation, not after it.
- Disable the identity provider account first. If you run SSO through Google Workspace, Microsoft Entra, or Okta, suspending that one account instantly severs email plus every connected app - The single biggest lever in the whole process, and a core reason single sign-on is a security upgrade, not just a convenience. Suspend rather than delete for 30–90 days so you can transfer files, set mail forwarding, and preserve anything under legal hold.
- Kill live sessions and tokens. Disabling an account often doesn't end sessions already open. Force sign-out everywhere, revoke OAuth grants and app passwords, expire refresh tokens, and revoke API keys, SSH keys, and personal access tokens the person created - These frequently outlive the account that made them.
- Reclaim or wipe devices. Collect laptops and badges; remote-wipe corporate data from personal phones via MDM. Remember that a personal browser signed into a work profile may sync work passwords to a home computer - Which is why company policy on browser-stored credentials matters long before anyone resigns.
- Rotate every shared secret the person ever knew. This is the step organizations skip. Team logins for social media and vendor portals, admin passwords, door codes, the office network - Regenerate each with real randomness (a WiFi password generator makes the network rotation painless, and a proper password generator covers the rest) and distribute the new values through your password manager, never by email or group chat.
- Transfer, don't orphan. Reassign ownership of documents, domains, ad accounts, and any service registered to the person's address. Orphaned accounts with an ex-employee's email as the recovery address are time bombs.
- Hunt the shadow IT. Ask the manager and teammates: what tools did this person use that IT never provisioned? Free-tier SaaS signed up with a work email is the classic escape hatch.
- Log and verify. Someone owns the checklist; someone else spot-checks it within a week. Then watch authentication logs for attempts against the disabled accounts - Failed logins from a departed employee's old credentials are a signal worth having.
Rule of thumb: you can revoke an account in one click, but you can only replace a password someone knows. Anything a departing employee could type from memory must be different by the time they reach the parking lot.
Shared credentials: the hard part, structurally solved
Shared logins are where offboarding meets password management, because rotation is only feasible if you know what's shared and can redistribute new values instantly. That means:
- An inventory that exists before it's needed. Every shared credential lives in a team password manager with access grouped by role. When someone leaves, the manager itself tells you exactly which secrets they could see - That list is your rotation to-do.
- Rotation as routine, not crisis. If shared passwords rotate on a schedule anyway, departure-day rotation is just an early cycle. A standing password audit keeps the inventory honest between departures.
- Fewer shared secrets overall. Individual named accounts (even paid seats) beat shared logins wherever the vendor allows, because named accounts are revocable. Reserve true credential-sharing for services that offer nothing better.
Formalizing all of this - Who may share what, where credentials live, how fast rotation must happen - Belongs in your written policy; our NIST-aligned password policy guide covers the rest of that document.
What a stale account costs
| Leftover access | Typical risk | Counter |
|---|---|---|
| Dormant VPN / remote-access account | Direct network entry (Colonial Pipeline pattern) | Disable at IdP; MFA everywhere; quarterly account review |
| Known shared passwords | Silent login to team tools, social accounts | Same-day rotation from manager inventory |
| API keys and personal access tokens | Automation-level access that survives account disable | Token revocation step in checklist; key ownership registry |
| Ex-employee as recovery email | Account takeover via password reset | Ownership transfer step; domain-controlled recovery addresses |
| Work passwords synced to personal browser | Credentials on uncontrolled home devices | SSO-first; managed browser profiles; no-browser-storage policy |
| Shadow-IT SaaS accounts | Data in tools IT can't see or revoke | Exit interviews with the team; SSO discovery / expense-report reviews |
Two attack patterns give these leftovers teeth. Old corporate credentials appear constantly in breach dumps and infostealer logs, where criminals replay them at scale - The economics described in our guide to credential stuffing apply doubly to accounts nobody is watching. And unmonitored dormant accounts give an intruder something precious: time. IBM's Cost of a Data Breach research has repeatedly found breaches involving stolen or compromised credentials among the slowest to identify and contain, with lifecycles approaching a year - Dormant accounts are exactly where that dwell time hides.
Make the next departure boring
The measure of good offboarding is that it's dull: a checklist executed in an hour, because the structure - SSO, a maintained vault, named accounts, scheduled rotation - Did the real work months earlier. If your last departure involved anyone asking "wait, does she still have access to…?", treat that as the finding. Run the inventory now, while it's nobody's last day.
FAQ
How fast should access be revoked when someone leaves?
Same day, always - And during the exit conversation itself for terminations or contentious departures. The window between "employee told" and "access removed" is when angry-impulse incidents happen, and the window after a quiet departure is when forgotten accounts begin their long dormancy. Nothing about revocation gets easier by waiting.
Do we really have to change shared passwords every time anyone leaves?
Every shared credential the person could access - Yes. You cannot revoke what someone remembers; rotation is the only remedy. The practical fix is reducing the pain: keep shared secrets in a team password manager so the "what did they know" list generates itself, and prefer individual named accounts so the list stays short.
What about the employee's own saved and personal passwords?
Corporate credentials in a company-managed vault or browser profile are reclaimed with the account. The real gap is work passwords saved into personal browser profiles or personal manager vaults over the years - You can't reach those, which is another argument for rotating anything sensitive they touched and for policies that keep work credentials in managed tools from day one.
Does SSO make offboarding automatic?
It makes the biggest slice automatic: one suspension cuts email and every SSO-connected app. But SSO never covers everything - Shared logins for tools without SSO support, API keys, infrastructure accounts, and shadow IT all live outside it. Think of SSO as reducing the checklist from fifty items to fifteen, not to one.
Is logging into a former employer's account actually illegal?
In many jurisdictions, yes - In the US it can fall under the Computer Fraud and Abuse Act as access without authorization, and employees have been prosecuted for post-departure logins and sabotage. Policy should say so plainly at offboarding. But deterrence is the weaker defense: the stronger one is making the login fail.