Someone's last day is on the calendar. The risk here usually isn't sabotage — it's the login nobody remembered, still valid long after the goodbye message. Taking access back works better as an ordered procedure than as a checklist you tick off in whatever order you happen to read it. Each pass changes what an ex-colleague can still reach, and the passes get slower and more disruptive as you go.
The short version
Work in three passes, in this order:
- The identity layer. Suspend the directory account and end active sessions. One action that covers many apps.
- The accounts that were never behind it. Vendor portals, trials, the domain registrar, anything signed up for directly with a work email address.
- The shared credentials. A secret with no per-person identity can't be revoked for one person, so it has to be rotated.
Cheap and broad first, slow and disruptive last. The sequence also matters in a smaller way: pass 1 leaves you the mailbox you will need to do pass 2. If your team has no identity provider yet, pass 1 shrinks to the email account and the real work is passes 2 and 3.
| Pass | What it does | What they can still reach after it |
|---|---|---|
| Identity layer | Blocks login across linked apps | Apps outside it; shared logins |
| Standalone accounts | Removes or transfers each login | Shared logins and keys |
| Shared secrets | Rotates what can't be revoked | Copies taken before you started |
Before you start
Two things decide whether this is merely tedious or genuinely difficult.
An inventory. A list of the places your team has accounts, ideally written when nobody is leaving. Without it, pass 2 becomes archaeology through a mailbox and a card statement.
A handover. Someone has to inherit what the leaver owned — the billing contact, the workspace they created, the automation running under their name. If nobody does, the pressure to keep the account alive "just until we work out what it does" wins, and you end up with a live login belonging to a person who no longer works there.
Agree the cutoff time with whoever is running the departure. Revoking before the conversation has happened causes its own problems; revoking days afterwards is the gap this whole procedure exists to close.
Pass 1 — the identity layer
The identity layer is your single sign-on (SSO) setup: one account, held in a directory such as Google Workspace, Microsoft Entra, or Okta, that grants access to a set of connected apps. Suspending that one account is the widest single move you have, which is why it goes first.
Suspend, don't delete. Deleting the account can also delete the mailbox, and the mailbox is the reset path for the standalone accounts you haven't found yet. It is also, in some setups, the owner record for files and calendars. Suspend now; delete or archive after passes 2 and 3.
End the sessions, not just the login. Suspending the account blocks new sign-ins. An app the person is already signed in to may keep working on a session token it was issued earlier — a credential the app has already handed out — until that token expires. If your provider offers "sign out of all sessions" or a token revocation control, use it, and check the apps that matter separately.
Revoke what was issued under their identity. OAuth grants (the "sign in with Google" connections that let a third-party app act on their account), app passwords, and personal API tokens are separate from the login itself. They are listed in the account's security settings, and they outlive a password change.
Check how deeply your apps are connected. If an app is connected for provisioning as well as login — the SCIM standard, System for Cross-domain Identity Management, is the usual mechanism — suspension propagates and the seat is deactivated in the app too. If it is connected for login only, the account may still exist inside the app; blocked from signing in through SSO, but present, and reachable again if the app also allows a local password. Worth checking on the apps holding customer or financial data.
Then move the mailbox. Set a forward or delegate access to whoever picked up the work, so replies and — importantly — password reset emails land somewhere a colleague sees.
After this pass, the person is out of everything behind SSO. They are not out of anything else.
Pass 2 — the accounts that were never behind it
These accumulate quietly. Someone needed a tool on a Tuesday, signed up with their work email, expensed it, and it never got connected to the directory. Common homes: vendor and supplier portals, the domain registrar and DNS host, the payment processor, analytics, the app stores, CI and hosting dashboards, social accounts, and the trial that turned into a real subscription.
To find them, use what pass 1 preserved:
- The mailbox. Search for signup and receipt language — welcome, confirm your email, your invoice, password reset. This is the reason you suspended rather than deleted.
- The card statement. Recurring charges name tools nobody remembers buying.
- The password manager. Compare the shared vault against what they kept in their personal one. Entries only they held are the ones at risk.
- The OAuth grant list from pass 1. It doubles as an inventory of apps they connected.
For each account, the order within the account matters too. Transfer ownership first, then remove the seat. An orphaned workspace whose only owner is gone is a harder problem than one the leaver can still log into. Change the account's contact and billing email off their address while you still can, because that address is the recovery path. Then remove them.
Where the account offers no ownership transfer, you may be left rotating its password and treating it as a shared credential — which is pass 3.
Pass 3 — the shared credentials
A shared credential is one with no per-person identity attached: a login several people use, an API key, a deploy key, an SSH key sitting in authorized_keys, a database password in a config file, a service account, the Wi-Fi passphrase. Suspending a person does nothing to any of them. The only remedy is rotation — replacing the secret and distributing the new value.
This pass is last because it is the one that breaks things. Rotating a key in a config file means a deployment. Rotating a shared login means telling everyone who uses it. Do it anyway, and rank the work by what the credential reaches, not by how easy it is to rotate: production data, money movement, and customer records before the shared account on a scheduling tool.
Two things make the next departure easier:
- Write down where each secret lives as you rotate it — which config file, which CI variable, which vault entry. The cost of rotation is mostly the search, not the change.
- Treat each rotation as evidence. A credential that had to be rotated because one person left is a credential that would be better issued per person: individual seats instead of a shared login, per-user or per-service API keys instead of one master key. That converts a future pass 3 into a future pass 1.
What survives all three passes
Revocation stops future access. It does not reach what has already left, and it does not close the side doors.
Copies. An export downloaded to a personal laptop, a synced folder, a spreadsheet emailed home, screenshots. No password change reaches these. They are handled by the agreement the person signed and by device policy — a conversation, not a control panel.
Recovery paths. These outlast passwords, and they are easy to miss. A personal phone number set as an account recovery contact, a personal email as backup address, a hardware security key registered to an account, their name on the registrar's admin contact. Where you can see the recovery settings on an account you control, update them in the same visit as the password.
Shares from personal accounts. If work lived in a folder on their personal cloud storage, removing their work account changes nothing. The share has to be moved or ended at the source.
Physical and network access. Badges, door codes, a VPN profile installed on a personal device. Outside the scope of a password manager, and worth one line on the same list.
Who should skip this
If you are two or three people, everything runs inside one workspace, and there are no shared logins, this is more procedure than you need. Suspend the account, remove the shares, transfer what they owned, and you're finished. The ordering earns its keep once accounts exist outside your identity layer — which tends to be the moment someone buys a tool that doesn't support SSO on the plan you're on.
If you have no identity provider at all, don't try to run pass 1. Your version is passes 2 and 3, done by hand, and it is slow enough that it is the clearest argument you will get for putting an identity layer in place before the next departure.
The next action
Open your password manager and start the list you'll need for pass 2: the accounts that are not behind your identity provider, and who owns each one. Building it while nobody is leaving is the difference between a suspension and a search.