Offboarding employee passwords: a rotation checklist

Disabling a leaver’s account in your identity provider takes care of everything behind single sign-on. It does nothing about the passwords they know: shared logins, admin and break-glass accounts, API keys they created, the Wi-Fi and alarm codes, and the authenticator codes for shared accounts that live on their phone. Offboarding employee passwords properly means finding those and rotating them in order of how much damage each could do, starting with anything that controls other access.

This page is the order, the places to look, and a checklist to paste into your offboarding ticket. It assumes a password manager and an identity provider; if you have neither, the list of what to rotate is longer, but the order is the same.

Decide the timing first

• A friendly departure. Schedule the identity steps for the end of their last day, and rotate the high-value shared credentials straight afterwards. Ask them, before they go, which logins they know that aren’t in the password manager. It’s the quickest way to find the gaps.
• An unfriendly or sudden one. Agree the time with HR, and do the identity steps during or just before the conversation. Have the list of high-value credentials ready so the rotation starts within the hour.

Either way, this is not optional. Cyber Essentials requires that accounts are removed or disabled when no longer needed. ISO/IEC 27001:2022 Annex A covers it in controls 5.18 (access rights) and 6.5 (responsibilities after termination or change of employment), and SOC 2’s CC6.2 expects access to be removed when it’s no longer authorised.

Step 1: cut the identity and its sessions

Disabling an account doesn’t always end sessions that are already open. Do both.

In Entra ID, with Microsoft Graph PowerShell:

Update-MgUser -UserId leaver@example.com -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId leaver@example.com

In Google Workspace, suspend the user, then reset their sign-in cookies from the user’s security settings in the Admin console so existing sessions end.

Then, in the same sitting:

• Remove their MFA methods and app passwords, and revoke OAuth grants to third-party apps.
• Retire or wipe their devices through Intune, Jamf or your MDM.
• Remove them from the password manager. This stops them seeing future values. It doesn’t make them forget current ones, which is why Steps 2 and 3 exist.
• Remove them from tools outside SSO: GitHub organisations, cloud consoles, and your ShareShield organisation. Their ShareShield API keys stop working once they leave the organisation, and admins can see every member’s secrets (metadata only) and burn any that are still live.

Before you hand their mailbox to their manager, remember what’s in it. If people have been emailing them passwords, converting the mailbox to a shared one gives those passwords a new audience. Why not to send passwords over email explains why that history matters.

Step 2: find what they knew

This is the hard part. The aim is a list of every credential the leaver could have read, so you can rotate it.

• The password manager. 1Password Business and Bitwarden’s organisation plans have admin reports and event logs showing which vaults or collections a member could open, and in some cases which items they viewed. That’s your starting list.

• Apps outside single sign-on. Finance tools, social media, the domain registrar, supplier portals. If you don’t have an inventory, card statements and expense claims for software are a good way to build one.

• Cloud and code. Access keys, tokens and SSH keys they created:

  aws iam list-access-keys --user-name leaver
  aws iam update-access-key --user-name leaver \
    --access-key-id AKIA... --status Inactive
  # SSH key comments usually name their owner; check fingerprints if they don't
  grep -n "leaver" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys

  On GitHub, check deploy keys and the organisation’s personal access token list, and any service accounts or CI secrets they set up. Sharing API keys and .env files covers how to rotate keys without downtime.

• Message history. Search the channels, tickets and team mailboxes they had access to for “password”, “login” and “key”. Anything you find there was readable by them.

• ShareShield’s audit log. The audit log records the secrets and requests they created and who they were sent to; filter by member. Professional and Enterprise organisations can export it as CSV for the ticket.

• Physical and network secrets. Door and alarm codes, safe combinations, the office Wi-Fi password, the code for the bike store.

• Authenticator codes for shared accounts. If the shared social media account or the registrar uses a TOTP code from an app on their phone, the leaver still has it. This is the one most often missed.

Step 3: rotate in this order

At each step, also re-enrol MFA on any shared account where the leaver’s device held the second factor. A new password with the old authenticator seed still on their phone is half a rotation.

Where a service allows named accounts, replace the shared login now instead of rotating it. The next leaver then needs one account removed rather than a password changed for everyone.

Step 4: send the new values without making new copies

Update each item in the password manager directly; everyone with access gets the new value without anything being sent. For people outside it, such as a contractor or a client, send the new password as a one-time link, following how to send a password securely. Don’t post a list of new passwords in the team channel. That recreates the problem you’ve just spent an afternoon fixing.

Step 5: record what you did

Keep the offboarding ticket as the record: each credential, who rotated it, and when. Never the values themselves. That ticket is your evidence for ISO/IEC 27001, SOC 2 or Cyber Essentials, and it’s what you’ll want if anything happens after the person has left. Attach the export from your identity provider’s and password manager’s logs, and the ShareShield audit log export if you use it.

The checklist

Identity and sessions:

• Account disabled and sessions revoked in the identity provider
• MFA methods, app passwords and OAuth grants removed
• Devices retired or wiped
• Removed from the password manager, GitHub, cloud consoles and other tools outside SSO
• Mailbox reviewed before it’s shared or forwarded

Finding what they knew:

• Password manager access report reviewed
• Apps outside SSO listed
• Access keys, tokens, SSH keys and CI secrets they created listed and disabled
• Message history searched for credentials
• Physical and network codes listed
• Shared accounts with authenticator codes on their device listed

Rotation, in order:

• Registrar, DNS, cloud root, identity and password manager admins
• Banking, payments, payroll, social media
• Production secrets and API keys
• Shared operational logins
• Wi-Fi, door and alarm codes
• MFA re-enrolled on shared accounts

Record:

• Ticket lists each credential, who rotated it and when, with no values
• Log exports attached