Move Authenticator Codes to a New Phone Without Losing Access

Before you wipe, trade in or reset a phone, keep its authenticator available. Use the app’s supported transfer method, then re-register any account that did not move. Test a fresh sign-in with the new phone for each important account before retiring the old one.

An app backup is a useful start, but it does not prove that every website will accept the new setup. An authenticator may contain rolling codes, push approvals or passkeys, which have different transfer and recovery routes. If the sign-in method is a passkey, see our passkey recovery guide for that separate recovery process.

This guide focuses on time-based one-time passwords (TOTP): short codes generated by an authenticator app. It reflects sources available through 30 December 2025. Work and school accounts may have organisation-specific rules, so follow your IT team’s enrollment instructions for those.

Keep the old phone until the new one works

The safest time to move an authenticator is while you can still unlock the old phone and sign in to your accounts. Do not factory-reset it or sign out of your remaining sessions just because the new app opens.

Make a short list of the accounts that matter most: primary email, banking and payment services, your password manager, work or school, and anything you would struggle to recover. For each one, note whether sign-in uses a changing code, a push notification, a passkey, or a security key. These are different methods. Seeing an account name in a restored app does not prove that every way of signing in has moved.

TOTP codes are calculated from a shared secret and the current time, as described in RFC 6238 (May 2011). That secret is set up for a particular account. Keep any enrollment or transfer QR code private; do not save it in a shared photo folder or send it through chat or email.

Before starting, make sure you can unlock the new phone, access the account used by your authenticator app, and sign in to the services on your list. Check that each service has a recovery method you can reach without the old phone, such as a saved recovery code or another registered sign-in method. Keep recovery codes in a secure place separate from the phone. NIST’s July 2025 guidance says saved recovery codes are intended to be stored securely offline; its rules are written for digital identity providers, and individual websites may offer different options.

Choose a transfer route

Restore through the authenticator app

If your authenticator has a built-in transfer or sync feature, follow the app maker’s instructions for both phones and their operating systems. Check that the feature was enabled and that you are restoring from the right account. Do not assume a general phone backup includes every authenticator entry.

For example, Google announced on 24 April 2023 that Google Authenticator could sync one-time codes through a Google Account on iOS and Android. If that is the method you already use, sign in to the same Google Account in the new app and check that the expected accounts appear. Then test those accounts at their websites; a list of codes is not proof that every service still accepts them.

Re-register accounts that did not transfer

If an account is missing, or you are changing to an app without a supported import route, add the new authenticator through that service’s own security settings. Keep your current logged-in session open while you do this.

1. Open the service’s official website or app and go to its Security, Sign-in, or Two-step verification settings.
2. Choose the option to add an authenticator app on the new phone. If the site allows more than one method, add the new one before removing the old one.
3. Scan the setup QR code with the authenticator on the new phone. Enter a current code on the service’s page to confirm the enrollment.
4. Save any new recovery codes the service provides. A code used for recovery may no longer work afterwards, so follow the service’s instructions if it asks you to replace the set.
5. If the service does not let you keep both authenticators during setup, read its replacement steps carefully and confirm that you have a usable recovery method before proceeding. Some sites use different names and sequences for these controls.

If you are re-registering through the service, scan the new QR code it shows in that signed-in setup flow. A saved setup QR may recreate the old secret, but it does not run the service’s process for confirming or replacing the registered method.

Test a fresh sign-in for every account

Keep the original phone and your existing sessions available while you test. On another trusted device, or in a separate browser profile, start a new sign-in to each account and use the new phone’s method. Do not count an already-open session as a successful test.

For a rolling code, enter a newly generated code and confirm that the service accepts it. For a push-based login, trigger and approve a new prompt on the replacement phone. If a code is rejected, check that the phone’s date and time are set automatically, wait for the next code, and avoid repeated guesses. Use the service’s recovery process if you still cannot sign in.

NIST’s 2025 guidance recommends that providers let subscribers bind multiple authenticators and confirm a replacement works before invalidating the one it replaces. This is a useful order for a phone change: add, test, then retire. It is not a promise that every consumer service supports two phones at once, so follow each site’s own flow.

Retire the old authenticator only after testing

Once each important account passes a fresh sign-in, retire any separately registered old-device credential through that service’s security settings if it is no longer needed. Do not remove the working authenticator method simply because its label mentions the old phone. Check your recovery details, then reset the old phone using the phone maker’s instructions only when the replacement is confirmed.

Retrospective safety clarification (29 October 2026): copying or syncing a TOTP entry can put the same secret on both phones. Because TOTP derives codes from that secret and time, a device-list removal alone does not invalidate a copied secret. If the old phone is lost or the secret may be exposed, follow each service’s process to replace the TOTP secret and test the new enrollment. For a normal transfer, do not delete synced entries just to clear the old phone: Google warns that deleting a synced Authenticator code removes it from all synced devices. Follow the app and phone makers’ device-retirement instructions instead.

If the old phone is already missing, restore from an app backup you had enabled in advance if that route is supported. Otherwise try a recovery code or another sign-in method you previously registered, then follow the service’s official account-recovery process. NIST advises providers to treat a lost authenticator as potentially compromised and to invalidate it promptly after a loss is confirmed. Once you regain access, revoke the missing device’s separately registered credentials and replace any potentially exposed TOTP secret through the service’s security settings. Restoring a copied secret does not invalidate the old copy.

The move is complete when you can start a new sign-in without the old phone—not when the authenticator app merely looks familiar.