How do I remove a departing administrator’s server access safely?
Removing one login does not remove every route an administrator may have used. Offboarding should cover customer accounts, operating-system access, keys, tokens, active sessions and any shared credentials they knew. Preserve ownership of scheduled work and emergency access for the remaining authorised team.
Before you start
- An approved offboarding decision, access inventory and another verified administrator.
Instructions
1. Identify all access paths
List individual accounts, SSH authorised keys, VPN access, customer portals, remote consoles, deployment platforms and secrets-management roles. Include recovery access, API tokens and external integrations. Identify automated tasks or files owned by the departing person so responsibility can be transferred deliberately.
2. Revoke the confirmed scope
Use each platform’s supported account and credential controls. Invalidate relevant sessions and tokens where supported, and rotate shared secrets whose confidentiality is no longer assured. Removing a password or key may not terminate an already established session, so check that separately with the responsible administrator.
3. Verify continuity and denial
Confirm the former identity can no longer use the identified routes and that remaining administrators retain a tested access path. Check deployments, scheduled jobs and applications after ownership or secret changes. Record completion and review logs for activity after the authorised access end time.
Check the result
- Every inventoried access route is revoked or transferred as approved.
- Critical services and independent administrative access continue to work.
Troubleshooting
- A scheduled job stops after offboarding
- Check whether it used the person’s account or token. Move it to an appropriate dedicated service identity with only the permissions it needs.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.