Sharing two-step verification across a team

When a shared account has two-step verification, signing in takes a code from an authenticator app or a text message on top of the username and password. That second step is built for one person, and a team has to work around it.

The code reaches one phone

Codes appear on the one phone where the app was set up, or arrive at the one number on file. So when that person is out, nobody else can sign in. What is two-step verification? explains how the codes work.

Sync and backup features don’t solve this. They help one person move to a new phone. Google Authenticator syncs codes only to devices signed in to the same Google Account. Microsoft’s support page on Authenticator backups says that for work or school accounts, “only the account name is backed up,” so you sign in again after restoring.

What happens when several people scan the setup QR code

One workaround is to have several people scan the QR code shown when the app is set up. The app and the service share a secret key, and each works out the code from that key and the current time (RFC 6238). Every phone that scans the code gets a copy of the key, so every phone shows the same codes.

Some services let one user register several apps. In Microsoft Entra ID, a user can have up to five authenticator apps or hardware code devices at a time. They still belong to one user, the shared account, and the service has no record of who holds each phone.

This workaround causes three problems.

• You can’t tell who signed in, because every phone shows the same code.
• The key multiplies. There is one copy per phone, plus any screenshot of the QR code.
• You can’t confirm the key is gone when someone leaves. Nothing shows whether it was deleted from their phone.

NIST SP 800-63B-4, the US federal guideline on sign-in methods, assumes each person has their own sign-in secrets. Its introduction says people are responsible for “not disclosing them to others.” The appendix on passkeys that sync between devices notes that guidelines have long cautioned against sharing sign-in methods between users. It also notes that some products now let people share keys with other users. One way it lists to limit that is managed devices that block synced keys from being shared.

Sharing a text message number

With text message codes, the code goes to one phone number. If that’s someone’s personal phone, the codes stop reaching the team when they leave or switch numbers. A company phone helps with departures, but the same gap appears whenever its holder is out.

NIST SP 800-63B-4 lists codes sent over the phone network as its only “restricted” sign-in method: allowed, but with extra conditions (sections 3.1.3.3 and 3.2.9). A service that uses it must also offer at least one sign-in method without those limits. NIST also says services that check the code should watch for risk signs such as a device swap, a SIM change or a ported number. None of this tells your team who holds the number or how others sign in without it. You decide that in advance.

Handling backup codes

Backup codes are one-time codes you enter when the app or phone isn’t available. Google lets you generate a set of 10 codes, each eight digits long. Each code works once, and creating a new set makes the old set stop working. Google tells you not to give the codes to anyone. NIST SP 800-63B-4 calls backup codes look-up secrets and likewise says each one must work only once (section 3.1.2.2).

For a shared account, backup codes are what you use when the phone holder is out. So keep them in one place, list who can open it, and log who used a code and when. Generate a new set when the people on the account change. Printing the codes for everyone is close to handing out the key itself.

What to cut off when someone leaves

What the person who left still holds depends on the method. Changing the password alone leaves them the authenticator key and any backup codes.

• Password: change it on the service.
• Authenticator app key, on phones and in QR code screenshots: set up two-step verification again, and only the people who stay scan the new code.
• Text message number: move it to a number the company controls.
• Backup codes: generate a new set, which cancels the old one.
• Passkeys and security keys (sign-in with a fingerprint, face or a small hardware key): delete the person’s key from the account’s list of sign-in methods.

NIST SP 800-63B-4 tells services to invalidate sign-in methods promptly when an account ends or the person is no longer eligible (section 4.5). Microsoft Entra ID gives admins a “Require re-register MFA” option. It deletes the user’s phone numbers, Authenticator apps and software code generators, turns off hardware code devices, and asks for a new method at next sign-in if needed. Both assume one person per account. The service doesn’t know the shared account lost a member, so your admin does each of these steps by hand.

Comparing the options

The table compares whether others can sign in during an absence, where the key ends up, and what a departure takes.

In every row, the service’s records show only the shared account’s name. The more people who can sign in during an absence, the more places the key lives. So whichever option you choose, keep a separate log of who used the account and when.