How to Hand Off Account Access Safely When Someone Leaves a Team
When an employee, contractor, administrator, or vendor leaves or changes roles, preserve necessary business continuity without leaving old access, shared credentials, API keys, or administrative paths behind.
Inventory → transfer ownership → remove access → rotate what must change → verify the result
This is an editorial framework, not an official industry standard. Start by identifying business applications, administrator consoles, cloud services, repositories, infrastructure, databases, shared mailboxes, password managers, API keys, SSH keys, MFA and recovery methods, service accounts, vendor systems, and file storage that apply to the person's role.
Transfer continuity before disabling access
Transfer ownership or responsibility for files, repositories, projects, billing accounts, domains, service ownership, shared mailboxes, and administrative roles before disabling an account where continuity requires it. For ongoing team administration, explore best practices for sharing business account access without sharing passwords: individual user accounts with role-specific permissions make revocation and accountability easier without eliminating risk.
Remove access and rotate based on risk
Once ownership is handled, remove access that is no longer appropriate from accounts, groups, VPN, cloud consoles, repositories, password managers, shared storage, administrator roles, and third-party services. Changing a password does not universally invalidate existing sessions, tokens, application passwords, or refresh tokens. Higher-priority rotation candidates include credentials the person knew, shared credentials, broad administrative access, credentials that cannot be confidently revoked, and credentials stored outside approved systems.
Technical and automation access
Review API keys, tokens, webhook secrets, SSH keys, server accounts, infrastructure roles, service accounts, CI/CD credentials, scheduled jobs, and integrations. Identify dependencies and responsible ownership before revoking or rotating. Issue new authorized SSH credentials; do not copy a former employee's private key. See API key sharing and SSH access.
MFA, recovery, and reset paths
Review authenticator enrollment, MFA devices, recovery codes, recovery email and phone numbers, hardware keys, shared mailboxes, administrative email, DNS, and reset destinations. Prefer provider-native delegation or recovery mechanisms. See our dedicated guide on transferring and storing 2FA recovery codes safely.
Verify the result
Confirm ownership transfers, disabled or revoked accounts, privileged access, and required service functionality. Ensure replacement owners can access critical services and document follow-up items. Logs may help review access or administrative changes where a service provides them, but their availability and completeness vary.
Where Paste & Purge fits
During an authorized transition, Paste & Purge may deliver a temporary text secret, such as transition recovery information or a decryption password, to a verified replacement when no better provider-native mechanism exists. It does not revoke accounts, rotate credentials, remove SSH keys, verify authorization, transfer ownership, manage IAM, invalidate sessions, or replace credential-management tools.
Offboarding checklist
- Inventory systems and roles
- Transfer business ownership
- Disable or revoke unnecessary identities
- Review privileged roles and shared passwords
- Review API keys, tokens, SSH, MFA, and recovery methods
- Review sessions, third-party integrations, and automation ownership
- Verify critical systems still function
- Record remaining follow-up