You are halfway through turning on two-factor authentication. The site shows a square, tells you to scan it with an authenticator app, and warns that you will not see this again. You scan, six digits appear on your phone, they change every thirty seconds, and the site accepts them. Somehow your phone agrees with a server on the other side of the world, without either of them talking to each other.
There is no ongoing conversation. There never was. Both sides computed the same answer from the same starting material, and that material is what you scanned.
What is actually in the square
The code holds a specially formatted URI. Not a web address you can visit, but a structured string that authenticator apps know how to parse. It carries:
- The secret. A random string generated by the service, unique to your account there. This is the whole game.
- A label. Usually the service name and your username, for the app's list.
- The issuer. Which service the entry belongs to.
- Parameters. The algorithm, how many digits, and how often the code rotates.
Your authenticator reads that string, stores the secret on the device, and adds a row to its list. That is the entire setup: a one-time data transfer, with the square as a convenient way to move a long random string onto a phone without typing it. The general idea of a code carrying structured text applies here exactly, and how codes encode data covers the mechanics.
Most setup pages also offer the same secret as a block of letters you can type by hand, which is what you use on a device without a camera.
How six digits appear on both sides
The server has the secret. Your phone now has the same secret. Both also have the current time.
The algorithm combines the secret with the current time interval, usually a thirty-second window, and runs it through a one-way function. Truncate the result and you get six digits. Same secret plus same window produces the same digits on any device holding both.
Nothing is transmitted. Your phone works offline because it has the ingredients and does the arithmetic locally. That is why the codes keep working on a plane.
Two consequences follow. Your phone's clock has to be roughly right, which is why an authenticator that suddenly rejects every code is usually suffering clock drift, fixed by enabling automatic time sync. And the codes rotate because a stolen six-digit number should be worthless within seconds.
Why you only see the code once
The secret is displayed at enrollment and then hidden. Services do this on purpose.
A secret retrievable at any time from your account settings would be a permanent target. Anyone who briefly reached your logged-in account could pull it and generate valid codes forever. Showing it exactly once closes that door.
The practical effect is that the moment you scan is the moment you commit. If your phone is lost or wiped afterward, you cannot go back and re-scan. You either recover through a backup mechanism or re-enroll from scratch, which requires being logged in, which is the thing you may have just lost.
Which brings us to the part most people skip.
Backup codes are the real safety net
Nearly every service offering two-factor authentication also hands you single-use recovery codes at enrollment. Long strings, usually eight or ten of them, on the same page you were rushing through.
These are the actual answer to a lost phone. Each works once in place of the six-digit code, and using one gets you back into the account so you can enroll a new device.
Save them somewhere that does not depend on the phone holding your authenticator. A password manager entry, a printed sheet in a drawer, an encrypted file on a computer. Not a screenshot on the phone in question, which is exactly what fails when that phone goes into a river.
If you cannot remember saving yours, most services let you regenerate a fresh set from the security section while you are still logged in. Doing that today, for your email account first, is a genuinely useful twenty minutes.
A screenshot of the setup code is a password
The square contains the secret. Anyone who has it can generate valid codes indefinitely, from any device, without your phone and without your knowledge. It does not expire, it does not rotate, and the account gives no signal that a second device is producing codes.
So a screenshot of a setup code is not a convenience copy. It is a second key, sitting in a photo library that probably syncs to the cloud and surfaces in the recent-photos strip whenever you attach an image to anything.
If you took one during setup and the account works, delete it, including from the recently-deleted folder and any cloud copy. And never send a setup code to anyone, for any stated reason. A support agent has no legitimate use for it. That request pattern is a relative of the tricks in recognizing malicious codes and our QR security overview.
If you need to inspect what a code contains without letting an app act on it, reading it without opening the link describes the safer approach.
Moving to a new phone
The secret lives in the app on the device, so changing phones means moving those secrets.
If your authenticator supports cloud sync or an account, installing it on the new phone and signing in usually brings entries across. Whether this is on by default, and what it covers, differs between apps and versions.
If it supports a device-to-device transfer, the old app typically shows an export code the new one reads. You need both phones working at once, so do this before wiping the old one.
If neither applies, re-enroll each account by hand: log in, turn two-factor off and on again, scan the fresh code. Slow, but reliable, and a good moment to save new backup codes.
Microsoft Authenticator, Google Authenticator, 1Password, Authy and others all read this same standard setup code, which is why one service's square works in whichever app you prefer. What each offers around backup and migration is its own decision and changes over time, so check the current documentation for the app you use.
One thing that surprises people: the old phone keeps generating valid codes. Wiping a phone tells the service nothing. The secret stays valid until you re-enroll or remove the method on the service side. When you retire a device, migrate properly or re-enroll, and do not assume a factory reset revoked anything.
If the device is already gone
In rough order:
- Use a backup code. This is what they are for.
- Try account recovery. Most services have an alternative path, often a verified email address or recovery phone. Expect a delay, because a fast path here would defeat the point.
- Check for a second enrolled method. A security key or a backup device may already be attached.
- Start with your email account. It is the recovery route for everything else, so restore access there first.
- Once you are back in, re-enroll and remove the old entry so the lost device's secret stops working.
Next step: open your email provider's security settings, generate a fresh set of backup codes, and store them somewhere that is not the phone running your authenticator.