What’s the right way to revoke access when an employee or contractor leaves?

For credentials that genuinely must be shared, keep them in a password manager or dedicated secrets manager and rotate them during offboarding. Production secrets should come from the secret manager rather than copied .env files, chat messages, or laptops. Also audit repositories, chat history, CI systems, cloud key inventories, active sessions, and endpoint access so you can identify anything the departing person may have retained.

The biggest improvement is making the central identity provider the gateway to everything. Use SSO and MFA for cloud consoles, server access, databases, and internal tools, with permissions assigned through groups and roles. Cloud access should use temporary credentials obtained through role assumption rather than permanent access keys. Then offboarding starts by suspending the person’s identity-provider account, disabling their managed device, and revoking active sessions. Most downstream access disappears automatically.

A written offboarding checklist is essential. At minimum: suspend the central account immediately, revoke sessions and tokens, disable the company device, remove group memberships, invalidate SSH or VPN access, review cloud and database activity, rotate shared secrets, transfer ownership of important resources, and confirm that backups and automation no longer use personal credentials. How quickly this happens should match the risk—some departures require access to be cut off immediately, while others may allow a short transition period.

A bastion host or managed session service can make this much less painful. In one setup, engineers authenticated centrally and then used the bastion to reach servers or create database tunnels. Removing their identity-provider access cut off the network path immediately, even if a forgotten database account still existed. The remaining cleanup was still done, but it was no longer the only barrier.