Google Authenticator: safer setup, sync, and phone changes

01 · decision point

Create each entry from the service that owns the account

Google Authenticator does not independently activate 2FA for a service. The website or app you are protecting creates a TOTP secret in its own Security settings and usually shows it as a QR code. Confirm the registered domain and intentionally begin enrollment there. Scan the code with Google Authenticator, then enter the newly generated number back on the service. The service decides whether the code is accepted, what backup methods exist, and how a lost factor is recovered.

The setup QR code is a durable secret rather than a disposable picture. Anyone who captures it can generate the same sequence of codes. Do not scan a QR image delivered through an unexpected email, support chat, shared document, or social message. Do not save a screenshot as an informal backup. Use the service's recovery codes and the authenticator's documented transfer or sync features instead, and keep the original session open until a full sign-in test succeeds.

02 · decision point

Choose account sync or no-account mode deliberately

Google documents that Authenticator codes can sync with a Google Account, making entries available after signing in on another device. It also supports using the app without a Google Account. Sync can reduce lockout during phone loss, but it makes protection and recovery of the Google Account part of the authenticator threat model. No-account use keeps a different boundary but requires a careful device-transfer and backup plan.

Review the profile indicator in the app and know which mode is active before assuming codes are backed up. If sync is enabled, protect the Google Account with a passkey or security key when possible, maintain independent recovery details, and review signed-in devices. If no-account mode is selected, use the manual transfer process before retiring a device and preserve service-issued recovery codes. Neither choice excuses keeping the only recovery route on one phone.

03 · decision point

Transfer codes before wiping the old phone

Google's manual transfer workflow uses export and import QR codes between devices. Start it on trusted devices in a private place because the transfer images represent authenticator secrets for several accounts. Do not photograph, print, screen-share, or send those codes. After import, compare the account labels and test important services individually. A successful import into the app is not proof that every entry is current or that the corresponding service recovery path still works.

Keep the old phone until the new one completes a fresh sign-in for email, password manager, developer, social, and other high-impact accounts. If entries were synced, verify that the expected Google Account is signed in and that all relevant codes appear. Remove obsolete duplicates only after testing. When an old phone is lost rather than available for transfer, use another synced device, a service backup factor, or official recovery; no outside recovery company can recreate missing TOTP seeds.

04 · decision point

Troubleshoot rejected codes without taking risks

TOTP calculations depend on accurate time. Set the phone's date and time automatically, wait for a new code, and verify that the selected entry matches the exact service account. Duplicates can occur after a reset or import, and an older entry may keep displaying codes even though the service has replaced its secret. Use an existing trusted session to inspect registered methods rather than guessing which similar-looking entry is current.

Never test an authenticator by entering a code on a page reached through an unsolicited link. Close the page, navigate to the known service, and restart the sign-in. A six-digit value is short-lived but still powerful during its active window; an attacker can relay it immediately. If unexpected codes or prompts appear, change the service password, inspect sessions and recovery settings, and regenerate backup material that may have been exposed.

05 · decision point

Keep recovery independent of the protected account

For each important service, save the recovery codes it issues and register an additional factor when supported. Store the backup where it can be reached if the normal phone, Google Account, and primary mailbox are unavailable. A printed copy in a protected location or a separately recoverable encrypted store can provide useful independence. Avoid placing the only backup inside the account whose authenticator entry it is meant to recover.

Inventory entries during routine account reviews. Remove codes for closed accounts, rename ambiguous profiles, and confirm that device-lock and Authenticator privacy protections are enabled. For work accounts, follow the organization's policy because an administrator may own factor reset and offboarding. For personal accounts, document who can recover the Google Account and how another trusted device is reached. Recovery preparation is part of 2FA, not an optional task after setup.

Practical sequence

Use this checklist before changing the account

1. 01

   Begin authenticator enrollment on the service's verified domain.

2. 02

   Decide whether Google Account sync or no-account mode fits the recovery plan.

3. 03

   Save service-issued recovery codes outside the normal phone.

4. 04

   Use the private device-transfer flow before wiping an old device.

5. 05

   Test high-impact accounts individually on the replacement phone.

6. 06

   Reject emailed QR codes and requests for a current six-digit code.

Side-by-side comparison

Compare the relevant trade-offs

Continue on login.com

Related independent guidance

• Protect the Google Account behind synced codes
• Understand TOTP secrets, timing, and phishing
• Build an independent recovery-code plan