When you change phones, your 2FA codes do not come with you

Security · Two-factor · Published 15 October 2026

A six-digit code is not stored in your account. It is generated by a secret that was placed on one particular phone on the afternoon you scanned a QR code. That single fact explains almost every locked-out story I have read in a support forum, and it is fixable in about twenty minutes — on the day you still have both phones.

Four of the entries in the security group of our tools index are authenticators built around this mechanism, and their store listings disagree loudly about what happens when you replace the device. We pulled the listings for twelve authenticator and password apps from the US App Store on 15 October 2026 and read what each one promises. The differences are not marketing noise; they are two genuinely different architectures.

What the code actually is

Time-based one-time passwords work because two parties hold the same secret string and agree on the current time. When you enrolled, a QR code displayed that secret and your phone stored it. From then on the app computes codes locally; it does not ask a server for them. Vendor claim Salesforce’s own listing describes exactly this property: “The app also provides one-time verification codes for use while you’re offline or have low connectivity.”

Three consequences follow immediately, and they are the whole reason a phone change hurts:

• The secret lives where you put it. If it was installed on one device and never copied, wiping that device destroys it. No support desk can regenerate it, because the service never had a copy in a form it could hand back.
• Codes work without a network, and that is also why they cannot be fetched. The same offline property that makes an airport Wi-Fi login possible makes “just send me my codes” impossible.
• Enrolment and recovery are different systems. Resetting your password through an email link does not restore a TOTP secret. If the second factor is the only thing protecting the email account you use to reset the second factor, the loop closes on you.

Two architectures, and the listing tells you which one you bought

The first architecture keeps the secret on the device and gives you a manual bridge to the next one. The second keeps an encrypted copy tied to an account and syncs it to every device you authorise. Neither is abstractly “better”: one has a smaller attack surface, the other survives a dead phone. What matters is knowing which one you are relying on before the day it matters.

Here is how the apps themselves describe it, verbatim from their store listings.

Read the OTP Auth line twice, because it is the most honest sentence in the whole category: it states the default (no network) and the exception (iCloud sync stores an encrypted copy) in the same breath. That is the decision every sync-based app asks you to make, and most ask it implicitly during onboarding.

The work account is a third thing entirely

Two of the listings above are worth reading again with an employer in mind. Microsoft’s own text separates personal sign-in from an organisational one, and says you must register your device to your organization through the app. Duo’s text says the app “needs to be activated and linked to your account before it will work”. In practice that means the enrolment belongs to a policy your employer controls, not to you.

The consequences are practical and predictable:

• A work or school enrolment usually cannot be transferred by you alone. It is re-registered, sometimes by an administrator, sometimes through a self-service page that itself requires the old device to approve.
• Leaving an organisation can invalidate an enrolment you thought was yours. The codes stop being useful the day the account does.
• The worst sequence, and the most common one: new phone arrives, old phone is wiped or handed back the same day, and the work enrolment was on the old one. Now the recovery needs the device you no longer have.

Not verified here I have not tested a real device migration against any employer tenant, and organisational policies differ enough that no article can promise your IT team behaves the way a listing implies. What I can tell you is that if a listing uses the words “register”, “activate” or “linked to your account”, there is somebody else’s switch involved.

The order of operations that avoids the bad day

This is the whole point of the article. Do it in this order, and the failure mode above stops existing.

1. Unbox the new phone and keep the old one switched on. Not in a drawer. On the desk, unlocked, for the next few days.
2. Open the authenticator on the old phone and count your accounts. Write them down as you go. This list is the thing nobody has when they are locked out at an airport.
3. Use the app’s own transfer path first. Google Authenticator documents a QR-based account transfer; Microsoft Authenticator distinguishes a personal account you can restore from a work enrolment you generally cannot. If your app offers no transfer path, assume you are on manual re-enrolment for everything.
4. For anything you cannot export, re-enrol it properly. Log into the account on a desktop, turn two-factor off, then on again, and scan the fresh QR with the new phone. Do the important ones first: email, then banking, then anything that stores passwords.
5. Verify on the new phone before you let go of the old one. Sign in to at least three accounts and watch the code on the new device get accepted. “The list looks right” is not a test; a successful sign-in is.
6. Save the recovery codes somewhere that is not the phone. Printed, or in a password manager. These exist precisely for the case where step 3 fails.
7. Only now wipe the old device. And if a work phone: hand it back after step 5, not before.

Audit what you have today, not on the day you need it

Ten minutes, no new software. Most people discover their architecture during an outage, which is the worst possible moment to learn it.

• Open your authenticator and count the accounts. Do you know what every entry is? Orphaned enrolments are how people end up with a dead app holding a live secret.
• For the three most important accounts, check whether you have recovery codes stored outside the phone. If you cannot find them, regenerate them now while you can still sign in.
• Ask the transfer question explicitly: if this phone died tonight, what is my path? If the honest answer is “re-scan every QR”, that is a real answer — write down which accounts would fight you.
• Separate the personal from the organisational. Anything tied to an employer goes on a list you hand to your IT contact rather than to a support form.
• Check whether your email provider requires a second factor to reset a second factor. If it does, the printed recovery codes are not optional.

“I will just use SMS” is not the fix

When the transfer dance gets tedious, SMS codes look appealing: the number follows the SIM, so a new phone seems to solve itself. Two problems, and they are structural rather than incidental.

The first is that the number is not a secret held by your phone; it is a routing address controlled by a carrier account that a stranger can persuade, or a SIM that can be swapped. Anyone who takes over the phone number takes over the fallback. The second is that SMS only works where the network delivers it, which is exactly when you are abroad, in a basement, or on a plane — the reason every offline-generating app in the table above bothers to say so.

The pragmatic position is the one most security teams have landed on: keep the authenticator app as the second factor, keep recovery codes offline, and treat SMS as a worse path you hope never to use.

What the numbers look like today

Observed Pulled from the US App Store on 15 October 2026. Ratings counts are how many people submitted a rating, not a measure of security.

Two entries deserve a comment. Salesforce Authenticator and Duo Mobile are the apps most likely to be enrolled by an employer rather than chosen by you, which is why their rating counts look small next to Google’s — the audience is a workforce, not a market. Apple’s “first released” field describes the current store listing rather than the product’s history, which is why 1Password reads as 2022; treat that column as listing age only. And OTP Auth has not shipped an update since September 2023; on a mature, single-purpose app that can be fine, but it is the kind of thing worth knowing before you build a recovery plan on it.

What we did not verify

Discipline matters more in a security article than anywhere else on this site, so here is the boundary of what this piece is.

• No migration was performed for this article. Dlzer has no device lab. Every quoted capability comes from the vendor’s own store listing, which is a claim about the app, not our observation of it working.
• No support documentation was reachable from our network. Google’s help site is unreachable from where we work, so the transfer claim rests on Google’s own App Store text rather than on its help centre. Microsoft’s and Duo’s documentation pages did not load either. Where we could not check, we said so instead of paraphrasing from memory.
• Nothing here is a recommendation about your employer’s policy. Organisational enrolment behaves according to tenant settings we cannot see.
• There are no scores in this article. No “best authenticator 2026”, no star ratings, no comparison of cryptographic strength between apps that all implement the same standard.

What we are willing to assert is narrower and, I think, more useful: know which architecture your codes live in, and do the transfer while you still hold both phones. Everything else in this piece is detail in service of that one sentence.

Written by the Dlzer editorial desk. Not affiliated with, endorsed by or sponsored by Google, Microsoft, Duo, Salesforce, Twilio, LastPass, 1Password or Bitwarden; trademarks and app names identify the products discussed. Listing text quoted from the US App Store as published on 15 October 2026. Corrections: [email protected] with the app and the sentence — we edit and date the change, per our transparency page.