Offboarding

For SaaS, the perimeter is identity. On the last day you disable the account, revoke sessions and tokens, then remove keys. Order matters: a disabled account with a live refresh token is still in. Shared logins are the failure mode — you cannot revoke one person.

First principles

There is no office door. The still-valid session, the OAuth grant, the personal access token, the SSH key on a jump host, the cloud access key in a laptop folder — each one is a door. Offboarding is closing those doors on the last day, not the last payday, and not after the laptop comes back in the post.

A collected laptop with a still-valid cloud key in the home directory is still in.

Shared logins are the failure mode

If five people know the 'info@' mailbox password, you cannot offboard one of them. If the vendor portal is a single login on a sticky note, you cannot offboard anyone. Shared credentials turn every departure into a rotation you will skip. Unique identities are how offboarding is possible. That is not politeness. It is mechanics.

What an admin actually does

• Last day, not later: disable the directory account. That should cut IdP-federated SaaS in one stroke. Confirm the ones that do not federate.
• Revoke sessions, refresh tokens, API tokens, app passwords, and mail-forwarding rules. Check the inbox rules before you lock the mailbox.
• Remove SSH public keys, cloud access keys, VPN certs, and hardware keys. Recover the physical key.
• Rotate secrets the person could have copied: vault items they viewed, CI tokens, break-glass they knew. See Secrets.
• If you found a shared login during this process, split it now. Do not wait for the next departure.