I'm trying to understand what a practical offboarding process looks like for a small team without a dedicated security person. When a developer or contractor leaves, there may be SSH keys in authorized_keys across multiple systems, shared database passwords, staging .env files in chat history, and cloud credentials on their laptop. Should everything they might have accessed be rotated, or is disabling their SSO, directory, and VPN account usually enough? Do you rely on a documented checklist, centralized access-management tools, or mostly tribal knowledge? We recently had a bad experience and want to establish a safer process without making every departure a huge manual project.
5 Answers
A good baseline is centralized identity, unique accounts, MFA, least privilege, short-lived or just-in-time administrative access, and a managed secrets vault. SSH certificate authentication tied to your identity system can eliminate permanent authorized_keys entries. Cloud-native identity roles and temporary credentials are also preferable to copying static keys onto laptops. You do not need to implement everything at once, but moving away from shared and manually distributed credentials should be the first priority.
For a small team, start with a written offboarding checklist and an asset/access inventory. Immediately disable the person’s identity provider, VPN, cloud access, password manager account, code-hosting access, and endpoint sessions. Then identify credentials they could have viewed or used—database passwords, API keys, SSH keys, service-account secrets, certificates, and staging files—and rotate those according to their risk. Shared passwords should be replaced with individual accounts and least-privilege permissions.
If the person may have accessed a sensitive shared secret, assume it is compromised and rotate it rather than trying to judge whether they copied it. Prioritize production credentials, privileged accounts, database passwords, cloud keys, signing keys, and anything that grants broad access. Keep the process consistent: disable access immediately, rotate secrets, verify the changes, record what was done, and conduct a later review to find gaps.
The goal should be for disabling one central identity to remove access everywhere. Use directory or SSO-backed authentication for servers, databases, VPN, cloud services, and administrative tools wherever possible. Avoid shared accounts and long-lived personal SSH keys; use centralized key management or short-lived certificates instead. At termination time, disable the identity, revoke active sessions and tokens, remove the user from groups, and disable any MFA or VPN credentials.
That approach works best when it is designed before accounts and keys are spread around. For existing environments, you may need an inventory and a cleanup project to find systems that are still using local or shared credentials.
Do not rely on simply disabling SSO if there are independent local accounts or credentials. Check local administrators, database users, SSH authorized_keys, cloud access keys, personal access tokens, CI/CD secrets, VPN profiles, privileged service accounts, and physical or unmanaged devices. Revoke sessions and tokens as well as the main account, and review audit logs afterward for anything unusual.
Documenting where secrets live is just as important as rotating them. Once you know which systems depend on each credential, automate the changes through a secrets manager or configuration-management tool instead of editing machines one by one.