How to Share Google Authenticator Codes With a Team

Google Authenticator has no sharing feature, and it is not an oversight: the app is built for one person and their own devices. So there are three ways a team gets codes from an account enrolled in it, and only one of them scales.

You can read the code out to whoever needs it. You can copy the secret onto everyone’s phone, which is permanent and uncountable. Or you can move the account’s secret into something built for several people and keep Google Authenticator for your own logins. This article is mostly about the third, because the first does not survive a holiday and the second does not survive an offboarding.

What Google Authenticator is built for

The app holds secrets on a device and computes codes from them. It can synchronise those accounts to your other devices through your Google Account, and it offers a way to transfer accounts when you replace a phone.

What it has no concept of, because it was never meant to:

• People other than you. There are no members, no roles, no invitations.
• Access that can be withdrawn. Nothing registers which devices hold a secret, so nothing can un-register one.
• A record of use. No log of which code was read, by whom, when.
• Scope. An account is either in the app or not; there is no way to grant one account without the others.

None of that is a criticism. For your own email, bank and cloud logins it is the correct tool, and this article is not suggesting you uninstall it.

The three things people mean by “sharing Google Authenticator”

Reading the code out

Someone with the app reads six digits to a colleague on a call or in a message.

This shares the short-lived thing and nothing else, which makes it the safest of the three. Its limits are practical: both people have to be available at the same moment, nothing records who signed in, and one person becomes the way in for everyone else. Fine as an occasional favour, expensive as a workflow.

Letting everyone scan the same setup QR code

At enrolment, the QR code is shown to the whole team so each person adds the account to their own app. Availability is solved instantly.

What has actually happened is that the account’s second factor has been duplicated onto an unknown number of devices, plus their backups and any authenticator sync those people have enabled. There is no list of holders, and the only way to invalidate the copies is to turn 2FA off on the account and set it up again for everyone.

Using the transfer feature to put the accounts on a colleague’s phone

The export or transfer flow exists so you can move your own accounts to your own new phone. Pointed at a colleague’s device, it does exactly what the shared QR code does, which is to copy secrets, with a few more steps and a stronger impression of being an approved procedure.

The effect is identical, and it is worth being blunt about it: any method that makes a second app generate the codes independently has handed over the credential itself. There is no version of that which is revocable.

Why sharing a Google Account is not the answer

Because sync exists, the tempting shortcut is one Google Account for the team with Authenticator on it, credentials in the team vault.

This trades one shared account for a worse one. That Google Account becomes a single point of failure holding every second factor you own, it has its own 2FA to solve, and several people signing in to it from different places is exactly the pattern consumer account protection reacts to, at the moment you need a code most. It also drags in everything else attached to the account.

If a shared login is unavoidable, the goal is to have fewer of them and to keep each one narrow. Concentrating all your second factors inside one consumer account is the opposite move.

What to do instead, in order

1. Check whether the platform can give each person their own access. Cloud consoles, ad platforms, payment providers and business managers often can. Then each person enrols their own second factor in their own Google Authenticator and there is nothing to share. This is the only option that removes the problem rather than managing it.

2. For accounts that genuinely have one login, move the secret to one place the team can reach. Not one phone: one place, with per-person access to the codes it produces and a record of who read them. The comparison of the available approaches is in best ways to manage 2FA for shared accounts, and how to decide which accounts belong in which bucket is in shared account 2FA: how should teams handle it?.

3. Keep Google Authenticator for personal logins. Every person’s own accounts stay exactly where they are.

Moving a shared account off one person’s phone

The instinct is to export the secret out of the app and import it somewhere else. Do not organise the migration around that. Re-enrolling at the provider is cleaner, reversible, and it invalidates whatever copies already exist, which is usually the real reason to do the work.

1. Pick a quiet moment. For the fifteen minutes this takes, the account’s second factor is in flux.
2. Get the recovery codes in hand first. If the provider will not show them again, generate a fresh set before you touch anything.
3. Turn 2FA off on the account, in the provider’s security settings. Every existing copy of the old secret stops working here, including the one on the phone that used to hold it.
4. Turn it back on, and enrol the new destination: enter the secret once into the shared vault, or scan the QR code with it.
5. Confirm a code works from the new home before closing the tab.
6. Grant access to the people who need codes, per person.
7. Store the new recovery codes somewhere outside the account they recover.
8. Remove the account from the phone that used to hold it, and from any other app you know duplicated it.

Step 8 is housekeeping, not security: the copies died at step 3. What matters is that the entry stops sitting there looking authoritative while producing codes for a secret that no longer exists.

Do this for one low-stakes account first. The procedure is short but the first run always finds something specific to your provider.

What changes for the person who had the app

Their phone stops being infrastructure. They keep Google Authenticator for their own logins, they stop getting messaged for codes on holiday, and their departure stops being an event that requires resetting 2FA on eleven accounts.

That last point is the one to make when someone objects that the current setup works fine. It works fine until the person holding it is unreachable, or gone, and both of those are events you can prepare for now rather than discover later.

Where Share Auth fits

Share Auth is step 2. Each shared account’s secret is entered once and encrypted at rest, invited members see the current code and its countdown rather than the secret, permissions are set per member and per account, and every view is written to an access log. Removing a member removes their access everywhere at once, with nothing to reconfigure for the people who stay.

That arrangement is laid out end to end on the shared authenticator app page.

It has nothing to say about your personal logins, which belong in the authenticator app on your own phone, Google Authenticator included.