Google Authenticator Transfer to a New Phone Without Lockout

Replacing a handset locks people out of their own accounts when the authenticator codes never move across. Transferring Google Authenticator to a new phone is a deliberate step inside the app itself. Google documents two clean routes, the app’s own export and import QR codes and signing the app in to a Google Account so codes sync, plus one messy situation where the old handset is already wiped, sold or lost. All three are below, with Google’s published steps quoted as they appear, and a per-service fallback order for Gmail, GitHub and X. Help pages checked on 25 September 2026.

Google Authenticator transfer to new phone: pick your route first

Everything downstream depends on one fact about your current setup, so establish it before touching either device.

Codes synced to a Google Account

Newer versions of the app can hold your codes against your Google identity. Google’s Authenticator help page says you “can synchronize your verification codes across all your devices, simply by signing in to your Google Account”. This route needs version 6.0 or above on Android, or 4.0 or above on iPhone and iPad.

Codes stored only on the old phone

Used without signing in, the app keeps its secrets on that one device and nowhere else. Google’s wording for this case is that you “manually transfer your codes to another device”, because codes “will not be available on your other devices”. Nothing outside that handset knows them.

Check which one you have before wiping anything

Open Authenticator on the old phone and look at the top of the screen for an account avatar or a sign-in prompt. If the app is signed in, sync is available to you. If it offers to sign you in, sync is off. While the old phone still works you have two options: sign in there so the codes sync, which also covers you the next time a handset changes, or use the export and import QR codes below. Either one beats recovering services one at a time.

Transfer with the export and import QR codes

This route works whether or not sync is in play, and it is the one to use when the two handsets are in front of you.

Google Authenticator export accounts on the old phone

On the old device: tap Menu, then Transfer accounts, then Export accounts. Select the accounts you want to transfer, then tap Next. Google adds a detail that trips people up: “If you transfer more than one account, your old device may create more than one QR code.” Treat it as a short series of images, not one picture.

Import accounts on the new phone

On the new device: tap Menu, then Transfer accounts, then Import accounts, then scan the codes the old phone is showing. Work through every image before you put the old phone down.

Confirm every code works before resetting the old phone

Do not factory reset anything yet. Sign in to each service with a code from the new phone, one at a time. A tile that exists on screen is not proof the underlying secret came across correctly, and the old handset is your only second chance until every login is confirmed.

What to do with the old phone afterwards

An export copies the accounts across; it does not clear them off the handset you are retiring. Once every login is confirmed from the new phone, open Authenticator on the old one and read the list of what is still there. Delete the entries you no longer want on that device, sign out of any Google Account inside the app, then factory reset the handset before it is sold, traded in or handed to someone else. Google documents removing codes by removing the device from your Google Account only for codes that are synced, so on a device that was never signed in this is a manual pass you make yourself.

Google Authenticator cloud sync: what signing in backs up

Sync is the route worth setting up in advance, because it removes the need for both phones to be present at all.

Signing the app in to a Google Account

Inside Authenticator, sign in with the Google Account you want the codes held against. From then on the codes are tied to that account rather than to the handset, which is what makes a lost phone survivable.

Codes on a new device after you sign in

Google states it directly: “When you sign in to your Google Account within Google Authenticator on a new device, your codes are automatically synced to this device.” If you wanted to transfer Google Authenticator to a new phone without a QR code, this is the only route Google documents.

Removing an old device from your Google Account

Once the new phone is working, cut the old one loose. Google’s step here is specific: where codes are synced you can remove codes by removing the device from your Google Account. That is a different action from ending the sessions on it, and only the removal stops that handset holding synced codes.

Transfer Google Authenticator to new phone without old phone

This is the search that brings most people here, and the honest answer has two branches with very different amounts of work.

If your codes were synced

Install Authenticator on the new phone, sign in to the same Google Account, and wait for the tiles to populate. Then remove the old device from that account so nothing left on it keeps generating valid codes. If you are not sure where to look, our walkthrough of signing a lost phone out of your Google Account shows where the Your devices list sits under Security and sign-in.

If they weren’t: each service’s own recovery

Google does not soften this one. Where codes are not synced to your Google Account, it says you “need to visit every site that you have Google Authenticator set up on to remove the codes, and then relink your new device”. Every site means every site: each login gets recovered on its own terms, then set up fresh against the new phone.

Why there is no single reset for every service

The app never held anything on your behalf beyond a shared secret per account. Each service issued that secret and each service decides how you prove yourself without it, which is why the fallback order differs below and why no central button exists to reset them all.

Fallback order for Gmail, GitHub and X

Work top to bottom for each service. These are the methods each provider publishes; anything else is guesswork.

Gmail: backup codes, Google prompts and other second steps

Google’s backup codes page puts them under Security and sign-in, then 2-Step Verification, then Backup codes, in sets of ten. A used code becomes inactive, and creating a new set makes the old set inactive at once. The 2-Step Verification page lists the other second steps you may already hold: Google prompts, passkeys, security keys, an authenticator app, codes by text or voice call, and those backup codes. Any one of them gets you in without the retired phone.

GitHub: recovery codes, passkeys, security keys and account recovery

GitHub’s page on recovering your account lists a recovery code, a passkey, a security key, a fallback SMS number, or a one-time password sent to your verified email address combined with a recovery factor such as a verified device, an SSH key or a personal access token. It also sets the ceiling: “GitHub Support will not be able to restore access to accounts with two-factor authentication enabled if you lose your two-factor authentication credentials or lose access to your account recovery methods.” Where a request does go to review, GitHub says a member of Support will email you within three business days.

X: your backup code and security keys

X’s two-factor authentication help names three methods: text message, authentication app, or security key. It describes the backup code in the singular: one is generated for you when you turn two-factor authentication on in the iOS or Android app, and you can also generate a backup code on x.com while you are still signed in. Two limits catch people out. X says that if you try to log in with an inactive backup code, or use one out of order, you see an error message and need to generate a new backup code to log in. It also says a backup code works for signing in to X itself, not for a third-party application tied to your account. Without a working code or second step, X points you at its support forms, including one specifically for a problem with 2FA.

Google Authenticator didn’t transfer to new phone: common causes

If the new handset came up short, these are the practical checks to run, in this order. They are our own troubleshooting list rather than anything Google publishes as one.

Only some accounts were selected on export

The export screen is a picker, and unticked accounts stay where they are. If the old phone showed several QR codes and you scanned two of three, the missing logins are inside the one you skipped.

The app is signed in to a different Google Account

Sync only produces the codes held against the account you signed in with. On a handset that defaults to a personal address when the codes live under a work one, the app looks empty while nothing is actually lost.

The old phone was reset before codes were checked

This is the unrecoverable version of the mistake, and it is why the confirmation step above matters more than the transfer itself. Once the handset is wiped and the codes were never synced, you are on the per-service recovery path whether you like it or not.

Before the next phone change

Ten minutes of preparation now is worth more than any recovery article later.

Keep backup codes somewhere other than the phone

Download or print each service’s codes and keep them away from the device that generates codes. A password manager on a second device, or paper in a drawer, both beat a screenshot in the photo library of the phone you are about to replace.

Add a second verification method on each account

One method is a single point of failure. Add a passkey or a security key alongside the app so a lost handset is an inconvenience rather than a lockout. Use a mobile line you control for any number-based step. Google’s recovery phone page is explicit that a Google Voice number must not be your recovery phone, because that choice can lock you out of the account. A resold number is worse again, because its history belongs to someone else.

Accounts your team manages need the same care

Shared logins are where this goes wrong at scale, because nobody owns the second step. If the real problem is several people reaching one mailbox, Gmail’s delegate access hands out inbox rights without passing a password around, and Google Workspace puts mailboxes under the organization’s control instead of one employee’s, which is the sanctioned fix for a handover problem. Price that route first. Where a project genuinely needs its own separate consumer accounts for testing, QA or account-management work, PVAVRT lists Gmail account grades, GitHub account grades and X account grades. Whichever route you take, the rule is the same one this whole page rests on: set up each account’s own second step the day it arrives and keep those codes where the phone is not. A recovery route you did not set up yourself is not a recovery route, which is the same lesson as Yahoo recovery without a phone number teaches on the mail side.

If you need more accounts than you have

If you manage Gmail, GitHub or X logins for a team and need more accounts for a legitimate job, ask PVAVRT on Telegram @pvavrt which grade fits, and set up each account’s second step yourself on arrival. Buying accounts breaks the terms Gmail, GitHub and X each publish, and any of them can close an account at any time.