Two-factor authentication is worth having in every form. But treating the three common forms as interchangeable produces a specific and expensive false confidence, because one class of attack passes straight through two of them.
Three methods, three different things that break
| Method | What it depends on | How it fails |
|---|---|---|
| SMS code | Your phone number | The number is moved to someone else through the carrier, or messages are read at device or network level |
| Authenticator app | A secret stored on your device | Device loss or compromise; the code is relayed through a phishing page in real time |
| Hardware security key | A physical device bound to the site's domain | Losing the key with no spare registered |
SMS is weakest because it rests on something you do not control. A phone number is administered by a carrier, and carrier processes exist to move a number to a new device. That path does not touch your password at all.
An authenticator app removes the carrier from the picture, which is a genuine step up. The secret lives on your device and the codes are generated locally.
A hardware key adds one property the other two lack: it knows which site it is talking to. That single property is what the next section is about.
The relay problem, and why it matters more than it sounds
"I have 2FA on, so a fake site can't get in" is wrong
Consider what happens on a convincing impostor page. You enter your password; it is forwarded to the real site immediately. The real site asks for a code; the impostor page asks you for a code. You read it off your authenticator app and type it in. It is forwarded within seconds, while still valid.
Nothing was broken. The code worked exactly as designed — it was simply used somewhere you did not intend. SMS and authenticator apps are both vulnerable to this, because neither knows which site is asking.
A hardware key does not have this weakness, because the response it produces is tied to the origin requesting it. Presented with a lookalike domain, it produces something the real site will not accept, not because it detected fraud, but because it is answering a different question. The public specification behind this behaviour is W3C WebAuthn, and the FIDO2 documentation covers the wider standard.
This is the practical conclusion: if you are relying on 2FA to protect you from ending up on a fake site, only the hardware option actually does that. The other two protect against a stolen password, which is a real and different threat.
Backup codes are a second key, not a formality
A backup code can replace the usual second verification step where a service supports it; it does not remove other sign-in requirements such as a password. Recovery options differ between services. Google's backup-code instructions describe single-use codes. Binance's authenticator setup guide shows a QR code and a setup key, without listing a batch of single-use recovery codes in that flow (checked in October 2026). A setup key can recreate the authenticator's codes; it is a reusable secret, not a single-use backup code, and needs the same careful storage.
So they deserve the same handling as a seed phrase: written on paper, stored separately from your devices, and never screenshotted, saved in notes, or messaged to yourself. The failure mode here mirrors the one in why a seed phrase must never be photographed — the leak happens through actions that feel like reasonable record-keeping.
Store them somewhere you will actually find them. Backup codes filed so carefully that you cannot locate them under pressure have the same effect as not having them.
The step people miss before changing phone
Test the new phone before wiping the old one
While the old phone still works, migrate each account and test an actual sign-in on the new device. Check the fallback separately: keep current backup codes where offered; otherwise, keep the setup key if one was provided and find the service's official recovery procedure. Only after the new sign-in works should you wipe the old phone.
Wiping the old phone before testing the new one can lock you out. If backup codes or another registered method still work, use those; otherwise, follow each affected service’s official recovery process.
Two related habits. Keep a short list of which accounts have two-factor enabled — write it down rather than relying on memory. And when a service offers to let you register a second method, take it; a tested backup can let you sign in if the main method becomes unavailable.
What to actually pick
Move off SMS where the option exists. Use an authenticator app as the baseline. Add a hardware key if you hold balances you would mind losing.
That ordering holds regardless of platform, though not every service supports all three — availability is whatever the platform's security settings currently show. If SMS is the only option offered, it is still much better than nothing; the point is not to refuse it, but to know what it does and does not cover.
One thing worth doing whichever method you choose: set it up before you deposit anything. The cost on an empty account is a few minutes, and the walkthrough with the rest of the account setup is in the sign-up guide. If you also want to constrain where funds can go, the trade-offs of a withdrawal whitelist are in is a withdrawal whitelist worth turning on.
Common questions
I turned on two-factor. Am I safe now?
It depends entirely on which one you turned on. Neither SMS nor an authenticator app stops a real-time phishing relay — the code you type into an impostor page is forwarded to the real site within seconds. Only a domain-bound hardware security key refuses to respond to the wrong site.
Why is SMS considered the weakest option?
Because it depends on your phone number, and a number can be moved to someone else through carrier processes. Message content can also be exposed at the device or network layer. Neither of those requires knowing your password.
How should backup codes be stored?
Where a service provides backup codes, write the valid codes on paper and store them separately, rather than in screenshots, notes or messages. They replace the usual second step, not every sign-in requirement. A setup key can generate codes repeatedly and is a different secret; keep it confidential too.
What should I do before changing phone?
Migrate each account while the old phone still works and test a sign-in on the new device before wiping it. Check current backup codes where offered; otherwise, keep the setup key if provided and find the official recovery procedure.
What happens if I lose my hardware key?
Register a second key as a spare if the service supports it. Save backup codes where offered; otherwise, confirm another sign-in method or the official recovery procedure. Losing your only key with no working fallback may leave you unable to access the account.