
Can You Share a Google Authenticator QR Code?
Yes, and it works: the QR code is the secret. Here is exactly what the image contains, what the second phone can do, and what the provider records.
Yes, and it works exactly as you would expect it to: anyone who scans that QR code gets an authenticator entry producing the same codes as yours, at the same moment, indefinitely. Nothing about it is single-use, and nothing on the provider’s side notices. Whether that is a good idea is a separate question that deserves its own treatment; this article is about what actually happens.
It works because the QR code is not a link to your account or a one-time invitation. It is a picture of the credential itself, which is why the sharing cannot be undone once the image has been seen. What a team should do with a shared Google Authenticator account is covered in how to share Google Authenticator codes with a team.
What is actually inside the image
A setup QR code encodes a short piece of text: an otpauth:// URI. The scanner
reads the characters, the app parses them, and that is the whole enrolment. It
carries:
- The secret, as a base32 string, in plain text. Not encrypted, not signed, and the only input that matters.
- The label and issuer: the account name and service name you see in the app’s list. Cosmetic, and changing them changes nothing about the codes.
- The period, usually thirty seconds, which is how long each code lasts.
- The number of digits, usually six.
- The algorithm, usually SHA-1 for TOTP.
The last three vary at providers that want eight digits or a sixty-second window, and the QR code carries them so the app does not have to guess. Everything an authenticator needs is in that string, which is the same as saying that a screenshot of the QR code is the credential. How the secret becomes six digits is covered in the complete guide to TOTP for teams.
Two phones, the same six digits
Two people who scan the same QR code will see the same code, changing at the same time, and they will keep matching for as long as the enrolment survives.
That is not a synchronisation feature. A TOTP code is computed from the secret and the current time rounded down to the period, with no network request involved: the app never asks the provider what the code is. Give two devices the same secret and roughly correct clocks and they cannot produce different answers.
The matching codes make the duplicate feel like a shared account with two authorised devices, when what exists is two independent copies of one credential with no relationship between them. A badly drifting clock is the only way either device can fall out of step.
What the account records: nothing
This is the part people find hardest to believe. When a second person scans the QR code:
- No request reaches the provider.
- No device appears in the account’s security settings.
- No email is sent.
- Nothing distinguishes the second app from the first, in either direction.
Enrolment stores one secret against the account: not a device, not a list of devices, not a count. The provider has no way to learn how many apps hold the secret, so there is no per-device revocation to reach for later. The only thing that invalidates a copy is invalidating the secret itself, by turning 2FA off on the account and enrolling again, which cuts off every holder at once including you. That reset is described step by step in how TOTP secrets work and why you shouldn’t share them.
It also explains why auditing the account tells you nothing. The security page of a service where four people scanned the setup screen looks exactly like the page of a service where one person did.
Why the QR code is usually shown only once
Most providers display the enrolment QR code during setup and never again. Once you have confirmed a code the page is gone, and asking support to show it again does not work. That is deliberate: the secret is written into the account at enrolment, and there is no reason for the service to display it twice.
Some providers go further. The secret on screen is a candidate that only becomes the account’s real secret when you enter a valid code from it, so if you abandon or reload the page you get a different one, and the QR code photographed a minute earlier now produces codes the account rejects. If a saved QR image gives codes that are refused, that is usually the explanation.
When you no longer have it
Do not organise anything around recovering the original image. Re-enrol instead:
- Get the account’s recovery codes in hand, generating a fresh set if the provider will not show the existing ones.
- Turn 2FA off in the provider’s security settings.
- Turn it back on, and point the new enrolment at wherever the secret should live from now on.
- Confirm a code works before you close the tab, then store the new recovery codes somewhere other than the account they recover.
It takes minutes, and it retires whatever copies of the old secret are out there, which is often the real reason to do it.
Scanning a QR code someone else has already scanned
Nothing special happens. The image is not consumed, the first enrolment is not disturbed, and no one is told. You get a working entry, and so does the next person, with no upper limit. Scanning it twice on one phone gives two entries with the same name, both producing the same digits.
There is no conflict to resolve because there is no shared state. A password reset link exists once and can be spent; a QR code is a photograph of a string.
What Google Authenticator does and does not do here
Google Authenticator has no sharing feature, and the two features people mistake for one do something else:
- Sync copies your accounts to your own devices through your Google Account. It is about your phone and your tablet, not about colleagues. Using it for a team means several people signing in to one Google Account.
- Transfer exists so you can move your entries when you replace a phone. Pointed at someone else’s device, it copies secrets, with the same result as handing over the QR code.
The app also cannot tell you what you have. An entry someone else set up on your phone looks identical to one you created, because both are a secret with a label: no owner, no expiry, no warning. The Microsoft app behaves differently in one respect, because push approvals cannot be duplicated this way, which is covered in how to share Microsoft Authenticator codes with a team.
Deleting the image afterwards changes nothing
Once a QR code has been scanned, the copy is made. Deleting the screenshot, unsending the message or asking a colleague to remove the picture from their photo library does not reach into an app that already holds the secret.
The image also outlives the moment it was needed for: a camera roll that syncs to a cloud backup, an attachment in a chat history new joiners can scroll to, a copy in the ticket where someone asked for access. Treat any QR code that has been sent anywhere as permanently out, and if that matters for the account, the remedy is the re-enrolment above.
What to do when several people need codes
First, check whether the platform can give each person their own login. Where it can, there is no QR code to share at all, because everyone enrols their own second factor. Which accounts genuinely have one login is the subject of shared account 2FA: how should teams handle it?.
For the accounts that really do, stop distributing the secret and distribute the codes instead: one place holds the secret, and access to the codes it produces is a list you edit rather than a copy you cannot recall. The mechanics are in how to share TOTP codes without sharing the secret, and the comparison of approaches, dedicated phone and shared password manager entry included, is in best ways to manage 2FA for shared accounts.
Where Share Auth fits
Share Auth is the one place that holds the secret. Each account’s secret is entered once and encrypted at rest, and invited members see the current code with its countdown rather than the string behind it, so there is nothing for them to scan into an app of their own. Permissions are set per member and per account, every code view is written to an access log, and removing a member removes their access everywhere at once. Scripts that need to sign in can request codes through the API instead of a person reading them out.
The free plan covers three secrets and three members with no card, which is enough to move one shared account off the QR code and see whether the workflow suits your team.
Frequently asked questions
Yes. The QR code is not a single-use invitation, it is an image containing the secret. Everyone who scans it enrols a fully working copy of the account's second factor in their own app.
Yes, provided both clocks are roughly correct. The code is computed from the secret and the current time, with no call to the provider, so identical inputs give identical output.
No. Enrolment stores one secret against the account, not a list of devices. There is no second-device event, no entry in the account's security page, and therefore nothing to revoke device by device.
Do not go looking for the old one. Fetch the account's recovery codes, turn 2FA off, then turn it back on and point the fresh enrolment at wherever the secret should live from now on.
No. The copy was made when the image was scanned. Deleting the picture, the message or the enrolment tab afterwards has no effect on the apps that already hold the secret.
Read next · Authenticator apps
How to Share Google Authenticator Codes With a TeamGuide
Google Authenticator has no sharing feature and no notion of a team. The three options that actually work, and how to move an account off one phone.
Is It Safe to Share a 2FA QR Code?
No, and the useful part is why: who ends up seeing a shared QR code, what they can do with it, and how to judge whether an exposure warrants a reset.
How to Share Microsoft Authenticator Codes With a Team
Microsoft Authenticator does two different jobs: a push approval cannot be shared at all, a six-digit code can, without handing out the secret.