How to use an authenticator app on two devices

You want the same six digits in two places — a second phone, a tablet beside the bed, the laptop you actually work on. The pages that come up for this question all give the same answer, and it is a correct answer: scan the same QR code on both devices while it is on screen.

It is also the answer to a question you are probably not asking. You set these accounts up months ago. The QR is gone, the setup screen is gone, and the thing you are looking at now is a security page with a button marked Edit — which, if you press it, will take every device you already have offline.

So here is the whole picture: why two devices can show identical codes at all, the one thing to check before you copy anything, the three routes that actually exist with what each costs, and the order of operations that keeps you out of your own account's recovery flow.

The short answer

• TOTP has no concept of a device. Two devices showing the same code are two copies of one secret, and the service cannot tell them apart.
• Before you duplicate anything, check whether the service lets you enrol a second authenticator as a separate entry. A few do. That is strictly better than a copy.
• Scanning the same QR on both devices works, and only during setup.
• Months later there are two routes: Google Authenticator's export QR if the entry lives there, or re-enrol and re-scan everywhere.
• Re-enrolment issues a new secret. Every device holding the old one goes dead the moment you confirm, including the phone in your pocket. Have the account's backup codes in front of you first.
• Google's own multi-device answer is sync, and sync means signing in to a Google Account.

Why two devices show the same six digits

When you turn on 2FA, the service generates a random secret and shows it to you as a QR code. The QR is only a transport: an otpauth:// link carrying that secret plus the issuer, your account name, and the algorithm, digit count and time period. Your app keeps the secret. The service keeps the same secret. After that, nothing is sent anywhere — both sides compute the code independently, which is why your app works with the network off.

RFC 6238, the TOTP standard, puts the arrangement in one requirement: "The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret" (RFC 6238 §3).

Read that again and notice what is missing. There is no device in it. A second phone holding the same secret is not a second registered device; it is the same credential being computed in a second place. Three consequences follow, and they explain most of the confusion around this question:

• There is no "add a device" button to find on the service's settings page, because the service has nothing to add. It knows one secret, not a roster.
• The sign-in log cannot tell you which phone typed the code. It records that a valid code arrived, and valid is all it can see.
• You cannot remove one device later. Nothing on the account's side distinguishes it from the other.

If you want the arithmetic behind the digits — how the clock turns into a code, and what breaks when it is wrong — TOTP vs HOTP covers it. The rest of this page is about the secret, not the code.

First, check whether the service will enrol a second device properly

A small number of services treat MFA as a list you can add to rather than a single setting you can edit. Where that exists, take it and skip every route below: two enrolments means two different secrets, each revocable on its own, and losing one device costs you one entry instead of a tour of every device you own.

AWS is the clearest documented example. "Your AWS account root user and IAM users can register up to eight MFA devices of any type", and "You only need one MFA device to sign in to the AWS Management Console or create a session through the AWS CLI as that user." The guardrail around it is the part worth copying as a mental model: "An IAM user must authenticate with an existing MFA device to enable or disable an additional MFA device" (AWS IAM).

The same page also names the per-device action a duplicated secret cannot offer: if an MFA device is lost or stolen, "it should be disassociated from the IAM principal with which it is associated."

How to tell which kind of service you are on, in under a minute. Open its two-factor settings and look at the authenticator entry. If it is a row in a list with an Add button beside it, you have real multi-device support. If it is a single setting offering Edit, Change or Set up again, you do not — and that button is the one to be careful with. Most consumer services are the second kind.

Route one: scan the same QR on both devices, at setup

This is what the pages ranking for this question tell you, and it works exactly as advertised. The answer on Microsoft's own Q&A puts it plainly: "set it up on one device and when the QR code is displayed, scan it on the second device as well. Verify that both apps generate the same code" (Microsoft Q&A). The GitHub community discussion on the same question lands in the same place.

Three details those threads skip:

• The window is the setup screen, not the account. Scan both devices before you confirm and leave. Most services will not show you that secret again; GitHub, for instance, offers the raw setup key only during configuration, "If you can't scan the QR code" (GitHub Docs).
• Verify before you confirm, not after. Both devices should be showing the same code at the same moment. Then type one of them.
• Saving the QR "for later" is a real decision, not a tip. Both threads suggest photographing or printing it so you can add devices in future. It works. It also creates a permanent plaintext copy of the secret wherever you put it — and if that is your camera roll, it is in whatever your camera roll syncs to, which is a decision worth making on purpose: is it safe to screenshot your 2FA QR code? unpacks what that picture actually contains. The question is identical to the one about a sheet of recovery codes, and so is the answer: where to store your 2FA backup codes.

The trade. Cheapest route, nothing disrupted, available only in the minute the QR exists.

Route two: Google Authenticator's export QR, months after the fact

If the entry already lives in Google Authenticator, there is a route that never touches the service at all. Google documents it: on the old device, Menu > Transfer codes > Export codes; on the new one, Menu > Transfer codes > Import codes, then scan (Google Account Help).

That export screen works because the QR codes it draws carry the selected secrets themselves. The receiving app is not handed a reference to anything; it is handed the keys. KeyNesta reads those transfer QRs, which is what importing from Google Authenticator means in practice.

The trade, in three parts:

• It is a copy, not a sync. From the moment you import, you have two independent vaults that drift apart with every account you add to one of them.
• One picture holds the whole set. Screenshotting the export QR to scan it later puts every secret you selected into your photo library at once.
• It only moves entries out of Google Authenticator. Several apps read the format; most will not produce it.

Google's own multi-device answer is a different thing, and none of the pages ranking for this question mention it: sync. "With Google Authenticator, you can synchronize your verification codes across all your devices, simply by signing in to your Google Account", and "When you sign in to your Google Account within Google Authenticator on a new device, your codes are automatically synced to this device."

That is a genuine answer, with a price attached: an authenticator that now requires a Google account. Google's help page says the codes "remain encrypted in our systems and protected from any potential bad actors", which is a different claim from end-to-end encrypted. When the feature launched, researchers at Mysk reported: "We analyzed the network traffic when the app syncs the secrets, and it turns out the traffic is not end-to-end encrypted", adding that "Google can see the secrets, likely even while they're stored on their servers." Google's response at the time was that end-to-end encryption "is a powerful feature that provides extra protections, but at the cost of enabling users to get locked out of their own data without recovery... we plan to offer E2EE for Google Authenticator in the future" (MacRumors, April 2023). Google's documentation today still describes the sync as encrypted in its systems rather than end to end. If you want two devices for convenience, that is fine. If you want them for privacy, read that sentence twice.

Route three: re-enrol — and the button that kills every device you already have

This is the route for everybody whose QR is long gone, and it has a trap in it that none of the pages ranking today warn you about.

Pressing Edit, Change or Set up again does not re-display the secret you already have. It issues a new one. The instant the new enrolment is confirmed, every device still holding the old secret is producing numbers the service no longer accepts — including the phone that has worked fine for a year.

The GitHub discussion says it in a single line: "The moment you click that button, a new QR code will override the old one, and all of your configured Authenticators will be invalidated." The Microsoft thread arrives from the other direction: if you did not save the original QR, "you cannot recover it. What you can do, however, is disable 2FA and then turn it on again."

Do it in this order, and do not improvise:

1. Find the account's backup or recovery codes first and have them visible. If you cannot find them, regenerate the set before you touch anything else.
2. Stay signed in. Keep your current session open, ideally in a second browser, so a bad minute is not a lockout.
3. Start the new enrolment on the service's security page.
4. Scan the new QR with every device you want, while it is on screen. All of them, now. This is the only moment that secret is visible.
5. Check every device is showing the same code at the same time, then type one of them to confirm.
6. Only then delete the old entry from each app. GitHub's documentation is explicit about this ordering: "Changes to an existing 2FA method will only take effect after you have provided a valid code from the new method and clicked Save", and "Only replace the existing 2FA method on your device (e.g. the GitHub entry in your TOTP app) after your new method is saved to your GitHub account completely."

Step six matters more than it looks. The usual aftermath of a re-enrolment is two entries with the same name in the same app, one of them dead, and you copying from whichever one is on top — the first cause listed in 2FA code not working.

The trade. Works on any service, whenever you like. Costs you a short nervy window and a visit to every device you own.

What a duplicated secret actually costs you

None of the pages ranking for this question says this part out loud, so here it is without drama. A second device holding the same secret is a second copy of a long-term credential, and copies have properties.

• You cannot revoke one. There is no per-device switch, because the account never knew about devices. Revoking the tablet means re-enrolling the account and re-scanning everywhere — route three again.
• The audit trail cannot help. A sign-in record proves a correct code arrived. It cannot say which copy computed it.
• Every copy stays live until you rotate. The screenshot of the QR, the printout in a drawer, the second phone you sold last year: each one still generates valid codes, and nothing on the account expires them.

NIST names this directly. Its authenticator threat table lists Duplication — "The subscriber's authenticator has been copied with or without their knowledge" — with examples including "Passwords stored in an electronic file are copied" and "Exportable cryptographic keys are obtained from a device or cloud-based sync fabric". The mitigation is blunt: "Use authenticators from which it is difficult to extract and duplicate long-term authentication secrets", and on moving keys around, "Transferring device-based authentication keys between devices increases the attack surface" (NIST SP 800-63B-4).

The other side is real too, and it is why people ask in the first place. A second device in a second place is the difference between an inconvenience and a lockout; lost phone recovery is this story told by someone who had no second anything. Two devices you physically control, in two places you control, is a sensible trade. Five copies you have lost track of is not — and the entire difference between those situations is bookkeeping.

One case deserves separating out, because one of the pages ranking for this question is really about it: two people sharing one account's codes. That is not a second device, it is a shared credential, and it removes any ability to tell who did what. If the service offers real multi-user access, use that instead. If it does not, at least make the choice knowingly.

Phone plus laptop, which is what most people actually mean

If the second device is the computer you work on rather than another phone, there is a third option that is not a copy at all: an authenticator that exists on both and keeps one vault between them. That turns the question from "how do I duplicate this secret" into "how do I sign in", which is a far smaller question — and it moves the thing you have to scrutinise to one place: what the server in the middle can read.

Two neighbours worth knowing about. Keeping TOTP codes in your password manager also solves this, at the cost of collapsing both factors into one vault — 2FA codes in a password manager is the argument in full. And if you landed here because Twilio retired the Authy desktop apps, an Authy desktop alternative covers what is left.

Where KeyNesta fits, and where it does not

KeyNesta is built for this question, and the honest framing is that it moves the problem rather than abolishing it.

• A second device is a sign-in, not a second scan. Your vault exists on your phone and in the web app. You sign in on the second device, unlock with your passphrase, and the entries are already there — no QR to hunt for, no re-enrolment, no visit to each service.
• Sync is zero-knowledge, and optional. Each entry, group and space is encrypted on the device before it leaves. The server holds ciphertext, object ids and version numbers, and no key that opens any of it. 2FA backup and sync is the full cycle, including the encrypted backup file if you would rather not have a server involved at all.
• Devices are a list you can revoke. You can see every device on the sync account and revoke any of them, and a revoked device stops working at its next request rather than at its next sign-in. That is the per-device control that duplicating a TOTP secret cannot give you. It applies to your vault, not to secrets some other app is holding.
• Two devices can edit the same entry safely. Neither edit is thrown away; the loser becomes a clearly marked "(conflict)" copy for you to resolve.

What it does not do, stated plainly because this page is about trade-offs:

• No passkeys, and it is not a security key. The features page names passkeys among what is not built, and an authenticator app is not a FIDO authenticator of any kind. For the one or two accounts where phishing resistance matters more than convenience, a hardware key is the right answer, and no authenticator app — ours included — substitutes for one.
• No automatic cloud backups. The encrypted backup file is a thing you make deliberately.
• Nobody can reset your passphrase. That is what makes zero-knowledge sync worth having, and it means a forgotten passphrase is not a support ticket.

The web app needs no sign-up, so the second-device part is something you can try before committing anything to it.

Takeaway

Two devices showing the same six digits is not a permission a service grants you. It is one secret existing in two places, and everything awkward about the question follows from that: no pairing step, no device list, no way to un-copy a copy.

So decide in this order. Check whether the service will enrol a second authenticator properly, because that answer is better than anything else on this page. If it will not and you are setting the account up right now, scan both devices before you leave the screen. If the QR is long gone, either export from Google Authenticator or re-enrol — with the recovery codes in front of you and every device in your hand before you press confirm. And if you are doing this often enough to be annoyed by it, the thing you actually want is not a second copy of each secret. It is one vault that both devices can open.