Hand Over Shared Accounts and Access Before You Leave Safely

TL;DR — Before you leave, transfer ownership in each service, move recovery email and phone to the new owner, rotate any shared password after the new owner confirms access, and remove your own sessions, API tokens, and MFA (multi-factor authentication) methods last. The most common failure is changing the password before the replacement person has accepted the invite or been added as an admin. Reading time: ~5 min

Goal

When you are done, the new owner or team can sign in to every shared account, receive password-reset and billing emails, use any required MFA, and you no longer have access through your user account, saved sessions, API tokens, or recovery methods.

Prerequisites

• A list of every shared account to hand over: email inboxes, domain/DNS, hosting, cloud, code repository, analytics, billing, social, and support tools
• Your login for each service
• The replacement person’s full name and work email address
• Access to the replacement person during the handover window so they can accept invites and test sign-in
• Your password manager, if the shared credentials are stored there
• Your authenticator app or hardware security key, if MFA is enabled
• A place to track completion, such as a spreadsheet or checklist
• If a service supports command line access: the CLI already installed and authenticated for that service; otherwise use the provider dashboard first

Steps

Step 1: Make a handover list

Create a table with one row per account. Use these columns exactly:

Service | URL | Current owner/admin | New owner email | Uses MFA? | Recovery email/phone | Billing owner | Status

What you should see when this succeeds: you have a complete list of every shared account you use for the client or team, not just the ones you remember first.

Step 2: Add the new owner as an admin before changing anything

In each provider’s dashboard, go to the users or members area and add the replacement person with the highest role needed.

Use the provider dashboard path, for example:

Provider dashboard → Settings or Admin → Users, Members, or Team → Invite user → enter new.owner@company.com → Role: Admin or Owner-equivalent → Send invite

If the service supports ownership transfer, use:

Provider dashboard → Settings or Admin → Ownership, Organization, or Account → Transfer ownership → new.owner@company.com → Confirm

What you should see when this succeeds: the new person appears as “Invited”, then “Active” after they accept.

⚠️ Do not change the password yet. If you rotate the password before the invite is accepted, you can lock everyone out of the account.

Step 3: Move recovery email, phone, and security contacts

For each shared account, replace your personal recovery details with a team-owned destination.

Use the provider dashboard path:

Provider dashboard → Account, Profile, or Security → Recovery email → change to accounts@yourcompany.com
Provider dashboard → Account, Profile, or Security → Recovery phone → change to the team phone number
Provider dashboard → Notifications or Billing → Billing contact email → change to finance@yourcompany.com

If the service has a separate security contact, set it to a shared mailbox such as:

security@yourcompany.com

What you should see when this succeeds: password-reset and billing messages go to the shared mailbox or team contact, not to your personal email or phone.

Step 4: Transfer shared credentials in the password manager

If the account still uses a shared username and password, move the credential into a shared vault (a shared password folder) and confirm the new owner can open it.

Use your password manager’s dashboard path, for example:

Password manager → Vaults or Collections → Shared-Team → Add item or Move item → select the account → Save
Password manager → Shared-Team → Manage access → add new.owner@company.com → Role: Can view or Can edit → Save

If you are not using a password manager, send the credential only through your approved internal method, then rotate it in the next step.

What you should see when this succeeds: the credential is stored in the team vault and the new owner confirms they can view it.

Step 5: Rotate the password after the new owner confirms access

Now change the password for any account that is still shared.

Use the provider dashboard path:

Provider dashboard → Account or Security → Change password
Current password: <current password>
New password: generate a new 20+ character password in your password manager
Confirm new password: <paste the same new password>
Save

If you need a copy-paste command to generate a password locally and you have OpenSSL installed:

openssl rand -base64 24

Save the new password only in the shared vault.

What you should see when this succeeds: the account accepts the new password, and the new owner can sign in with it.

Step 6: Replace MFA with the new owner’s method

For accounts protected by MFA, remove your device only after the new owner has added theirs.

Use the provider dashboard path:

Provider dashboard → Security → Multi-factor authentication or 2-Step Verification → Add method → Authenticator app or Security key → complete setup with the new owner present
Provider dashboard → Security → Backup codes → Generate new codes → store in the shared vault
Provider dashboard → Security → Multi-factor authentication or 2-Step Verification → Remove your old phone, authenticator, or security key

What you should see when this succeeds: the account lists the new owner’s MFA method and no longer lists your device.

Step 7: Revoke your sessions, API tokens, and personal access

Remove the access paths that can survive after you stop using the account.

Use the provider dashboard path:

Provider dashboard → Security → Sessions or Devices → Sign out of other sessions
Provider dashboard → Security or Developer → API keys, Personal access tokens, or Access tokens → Revoke tokens that belong to you
Provider dashboard → Settings or Admin → Users, Members, or Team → your user → Remove or Downgrade role

If the service is a Git host and you used SSH keys, remove your key in the web UI:

Provider dashboard → Settings → SSH keys or Deploy keys → remove keys labeled with your name or laptop

What you should see when this succeeds: your old sessions disappear, your tokens show as revoked, and your user is removed or reduced to the agreed role.

Step 8: Hand over the record of what was changed

Send the new owner a simple handover note with the exact status of each service.

Use this template:

Subject: Shared account handover complete

Services handed over:
- <service name> — ownership/admin transferred to <email>
- Recovery email/phone updated to <shared mailbox/team number>
- Password rotated and stored in <shared vault name>
- MFA moved to <new owner/team method>
- My sessions/tokens removed

Outstanding items:
- <service name> — waiting for invite acceptance
- <service name> — billing contact update pending

What you should see when this succeeds: the new owner has one message listing what is done and what still needs action.

Verify it works

Do these checks for each service:

1. New owner sign-in test in a private window:

Open a private/incognito browser window → go to the service login page → sign in as the new owner or with the shared credential from the team vault

Expected result: login succeeds without asking for your email, phone, authenticator, or security key.

1. Password-reset destination test:

On the service login page → click Forgot password

Expected result: the masked recovery email or phone shown on screen is the shared/team destination, not your personal one.

1. Role and ownership check:

Provider dashboard → Settings or Admin → Users, Members, or Team

Expected result: the new owner is listed as Active with Admin/Owner-equivalent access, and your account is removed or downgraded.

1. Session and token check:

Provider dashboard → Security → Sessions or Devices
Provider dashboard → Security or Developer → API keys, Personal access tokens, or Access tokens

Expected result: no active sessions or tokens remain that belong to you.

Common pitfalls

Changing the password before the invite is accepted

Mistake: you rotate the shared password first.

Symptom: the replacement person cannot sign in, and password resets still go to you.

Fix: re-enter the account yourself, add/activate the new admin first, then rotate the password.

Leaving your email as the recovery address

Mistake: ownership is transferred, but recovery email or billing notifications still point to your inbox.

Symptom: password-reset, invoice, or security alerts continue arriving to you after you leave.

Fix: open Account/Security and Billing/Notifications and replace every personal email and phone with a shared team contact.

Removing your MFA before the new owner adds theirs

Mistake: you delete your authenticator app or security key too early.

Symptom: the account is left with no working second factor, or setup gets stuck during login.

Fix: add the new MFA method first, generate fresh backup codes, then remove your old method.

Forgetting API tokens and saved sessions

Mistake: you remove your user account but leave personal access tokens, SSH keys, or browser sessions active.

Symptom: scripts still run under your token, or your old laptop still opens the account.

Fix: revoke your tokens, remove your SSH keys, and use “Sign out of other sessions” before removing your user.

Storing the new password in chat instead of the team vault

Mistake: the rotated password is pasted into email or chat and later gets lost.

Symptom: nobody knows the current password, or multiple conflicting copies exist.

Fix: save the final password in one shared vault entry and delete temporary copies from chat drafts or notes.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.