Handing over a shared account that uses 2FA

The person leaving runs the company Instagram, or the only login to a supplier’s portal is tied to their authenticator app. You need to hand over an account that uses two-factor authentication without locking yourselves out, and without the old holder keeping a working second factor.

The short answer: if the platform lets people have their own logins, use that and nothing needs handing over. If it doesn’t, do the handover live, and have the new holder set up two-factor authentication again on their own device or in your team’s password manager. That creates a new secret, so whatever the old holder still has stops working. Copying the existing secret across is the fallback for when you can’t do it live.

How authenticator codes work, briefly

An authenticator app’s six-digit codes (TOTP, defined in RFC 6238) are computed from a shared secret, usually called the seed, and the current time. The seed is what the QR code contains when you set up 2FA, as an otpauth:// URI with a base32 secret= parameter. Anyone with the seed can generate valid codes forever, on any device, until the seed is changed. That’s why the seed matters more than the phone it lives on.

Your options

Give people their own logins

Check this first, because it removes the problem rather than managing it. Meta’s business tools let you add people to a Page or ad account with their own Facebook or Instagram login. LinkedIn Pages have admin roles. Google Workspace and Microsoft 365 support delegated mailboxes. Many vendor portals let an administrator invite additional users, even if nobody ever asked. Where a service supports SSO with Entra ID or Google, use it, and leavers lose access when their directory account is disabled.

Keep the seed in a shared vault

When a single login is unavoidable, store the TOTP seed in the same password manager item as the password. 1Password and Bitwarden both generate codes from a stored seed (in Bitwarden this depends on your plan). Everyone with access to the item can sign in, nobody depends on one person’s phone, and the vault records who opened the item.

The trade-off: the seed is now as well protected as the vault, which makes the second factor less independent of the first. For most shared marketing and vendor accounts that’s an acceptable trade. For a cloud provider’s root account it isn’t; that belongs to one named person with a hardware key and a sealed recovery procedure.

A live handover, step by step

1. Check the recovery routes first. Look at the account’s recovery email address and phone number. If they point at the departing person’s mailbox or personal mobile, change them to a shared address or number the organisation controls before anything else. These are how the platform will reset the account, and how anyone else could.
2. Send the password by one-time link. One view, short expiry. If the account matters, add a passcode and read it out on the call rather than putting it in the same message. Our guide to one-time links and password managers covers where this fits.
3. Sign in together. The new holder signs in. The old holder reads out the current code from their authenticator, or approves the sign-in prompt.
4. Re-enrol two-factor authentication. In the account’s security settings, the new holder removes the existing authenticator and sets it up again, scanning the new QR code into their own app or saving the seed into the vault item. The old seed stops working at this point.
5. Generate new recovery codes. On most services, generating a new set invalidates the old one. Store the new codes somewhere other than the item holding the password, so one leak doesn’t give away both.
6. Change the password.
7. Close the side doors. Sign out other active sessions. Review connected apps, app passwords and API tokens, which often keep working after a password and 2FA change.
8. Clean up the old device. The old holder deletes the entry from their authenticator app. If the app syncs to the cloud (Google Authenticator signed into a Google account, Microsoft Authenticator with backup on), deleting the entry in the app should remove the synced copy as well. Uninstalling the app does not.
9. Write it down. Who holds the account now, when it was handed over, and where the recovery codes are.

When it can’t be done live

Sometimes the old holder is in another time zone, or is a former agency who will answer one email and no more. In that case, ask them for the seed as well as the password.

• Finding the seed. Most services show a “can’t scan the code?” option during setup that reveals the seed as text. If the old holder no longer has it, they can sign in and re-run 2FA setup to get a fresh one, which also retires whatever they had before.
• Getting it to you. Don’t ask for it by email. Send them a secret request for the password and a second one for the seed, so neither travels alongside the other in the same message, and both arrive in your account rather than an inbox.
• Then re-enrol. Once you’ve signed in with the transferred seed, carry out steps 4 to 7 above. Until you do, the old holder can still generate codes.

Pitfalls

• QR codes in photo libraries. A screenshot of a 2FA setup screen is the seed. Phones commonly sync screenshots to iCloud Photos or Google Photos. Ask anyone who took one to delete it from the library and from recently deleted items.
• SMS codes on a personal number. If the account sends codes by text to someone’s own mobile, the handover depends on them keeping that number. Move it to an authenticator app where the service allows it. NIST SP 800-63B treats SMS as a restricted authenticator for good reason: phone numbers can be ported or hijacked.
• Passkeys. A passkey on someone’s phone can’t be handed over. Add a passkey for the new holder, or save one into a shared vault in a password manager that supports it, then delete the old one from the account.
• Lockouts from new locations. Social platforms sometimes challenge or lock an account signed in from a new device or country. Do the handover while the old holder can still approve a prompt, not after their last day.
• Clock drift. TOTP codes change every 30 seconds by default and depend on the device’s clock. If a freshly set-up authenticator produces codes that are rejected, check the phone’s time is set automatically before assuming the seed is wrong.
• Recovery codes kept with the password. Anyone who finds both has bypassed the second factor. Keep them apart.

If this account changes hands because someone is leaving, it’s one item on a longer list. The audit trail guide covers recording what was handed over and when.