Two-factor authentication adds a proof of possession to your password, and the methods differ mainly in whether a phishing page can capture that proof. SMS codes can be intercepted by SIM swapping and relayed by a fake login page; authenticator codes survive SIM swapping but not real-time relay; passkeys and hardware security keys, built on WebAuthn, are bound to the genuine site's domain and cannot be phished at all.
What a second factor is for
A password is something you know, and the problem with things you know is that they can be copied without your noticing: leaked in a breach, typed into a phishing page, reused somewhere weaker. A second factor adds something you have, so a copied password alone is no longer enough. The password security guide explains why credential stuffing is the dominant attack; a second factor of any kind ends it, because the attacker replaying a leaked password does not have your phone.
That is the easy win, and it is why the advice "turn on 2FA, any 2FA" is right for everyone. The ranking in this guide is about the next threat: an attacker targeting you specifically, who is willing to phish you in real time or take over your phone number. For those attacks the method matters enormously, and the differences are structural, not a matter of vendor quality.
SMS and voice codes
The site texts you a six-digit code and you type it in. It requires nothing but a phone, which is why it is universal, and it is the weakest option for two independent reasons.
SIM swapping. Your phone number is controlled by your carrier, and a carrier's support desk can move it to a new SIM. Attackers persuade or bribe the desk, or use leaked personal data to pass the identity check, and your number, with every code sent to it, arrives on their handset. Number-porting fraud achieves the same through a transfer to another carrier. The attacks are well documented in cryptocurrency thefts precisely because SMS codes guard the accounts. Some carriers now offer a port-out lock or account PIN; set it, but it is a mitigation, not a fix.
Real-time phishing. A fake login page that captures your password can also ask for the code and forward both to the real site within seconds. The code is valid for minutes, which is plenty. Nothing about SMS ties the code to the site you are looking at.
SMS also depends on the signalling network between carriers, and interception through it has been demonstrated against banking codes. NIST SP 800-63B classes SMS as a restricted authenticator for these reasons. Use it only where nothing else is offered, and make sure it is not the recovery method that can reset a stronger factor.
Authenticator apps: TOTP
An authenticator app implements TOTP, the time-based one-time password algorithm of RFC 6238, built on the HMAC counter scheme of RFC 4226. At setup the site shares a secret with your phone, usually by QR code; the app then computes a six-digit code from the secret and the current 30-second time step. Nothing crosses the phone network, so SIM swapping is irrelevant. The QR code encodes a URI like this:
otpauth://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Example&algorithm=SHA1&digits=6&period=30The secret is the whole security. Anyone who has it can generate your codes forever, which has two implications. Back it up deliberately, since a lost phone with no backup locks you out of every account, and be aware that a backup stored in a cloud account is only as safe as that account. And never scan a setup QR code presented by a page you did not navigate to yourself.
TOTP's weakness is the same relay attack that beats SMS. A proxy phishing kit sits between you and the real site, passes your password and your current code straight through, and captures the session cookie that comes back. The code was genuine; it was simply spent on the attacker's behalf. Open-source kits that do this are mature and widely used, which means TOTP should be understood as strong against remote, untargeted attacks and weak against a phishing page you actually fall for. The phishing guide is the companion to this one for that reason.
Push approval
Instead of a code, the site sends a notification to an app on your phone and you tap Approve. It is faster than typing and, because the phone must be enrolled, immune to SIM swapping. Its failure mode is human: push fatigue, where an attacker who has your password triggers login prompt after login prompt, sometimes at three in the morning, until you tap Approve to make them stop. Several high-profile corporate breaches began this way.
The fix is number matching: the login screen shows a two-digit number and the phone asks you to type it, so a prompt cannot be approved without seeing the screen that caused it. Most enterprise providers now default to it. Push with number matching is comparable to TOTP in strength and easier to use; push without it is worse than TOTP.
Hardware security keys and passkeys: WebAuthn
Everything above shares one flaw: the proof you provide is a number that can be typed into, or approved for, the wrong site. WebAuthn, the W3C standard implemented by browsers and operating systems on top of the FIDO Alliance's FIDO2 protocols, removes it. At registration the authenticator, which may be a USB or NFC security key or the secure hardware in your phone or laptop, creates a public-private key pair for that specific site and gives the site the public key. At login the site sends a challenge, and the authenticator signs it, but only after the browser has included the site's origin in the signed data and the authenticator has checked that the origin matches the one it registered for.
That origin binding is the entire point. A phishing page at login-example.com asks the authenticator to sign a challenge, the browser includes the true origin login-example.com, the authenticator has no credential for it, and nothing happens. There is no code to relay, and the user cannot be tricked into approving, because there is nothing to approve. This is what "phishing-resistant" means, and CISA and NIST use the term for exactly this category.
Hardware security keys hold the private key in a dedicated device. They are the strongest option because the key cannot be extracted or synced, and the best choice for high-value accounts and for the password manager that guards everything else. Buy two and register both, so a lost key is an inconvenience rather than a lockout.
Passkeys are the same WebAuthn credentials stored by the platform, in iCloud Keychain, Google Password Manager, Windows Hello or a third-party manager, and unlocked with the device's biometric or PIN. They are discoverable credentials, meaning the site can prompt for them without you typing a username, and most are synced across your devices through the platform's encrypted cloud. A passkey can replace the password entirely rather than supplement it, which is how the major platforms deploy them. The sync makes them recoverable, at the cost of making the cloud account the root of trust; protect that account with a hardware key.
Ranking the methods
| Method | Stops credential stuffing | Survives SIM swap | Survives real-time phishing | Recovery if device lost |
|---|---|---|---|---|
| SMS / voice code | Yes | No | No | Easy (new SIM) |
| Authenticator app (TOTP) | Yes | Yes | No | Needs backup of secrets |
| Push, no number matching | Yes | Yes | No, and fatigue attacks | Re-enrol |
| Push with number matching | Yes | Yes | Mostly | Re-enrol |
| Passkey (synced) | Yes | Yes | Yes | Via platform account |
| Hardware security key | Yes | Yes | Yes | Needs a registered spare |
Our position: use a passkey or hardware key wherever the site supports one, an authenticator app or number-matched push where it does not, and SMS only as a last resort, never as the recovery path for a stronger method. The gap between the top two rows and the rest is not incremental; it is the difference between a factor a phishing page can capture and one it cannot.
Setting it up in the right order
- Start with your email account, because password resets for everything else arrive there. Register a hardware key or passkey; add an authenticator app as backup; remove SMS if the provider allows it.
- Do the same for your password manager account, then for banking and any account holding payment details or cryptocurrency.
- Check that your passwords are not already breached; a second factor protects a compromised password, but the breach check tells you which ones to replace anyway.
- Register a second hardware key or a second device for every passkey, and store recovery codes offline.
- Set a carrier port-out PIN so that the SMS fallback you could not remove is at least harder to steal.
- When a login prompt or code request arrives that you did not initiate, treat it as an attack in progress: change the password, because the attacker evidently has it.
Finally, remember what a second factor does not cover. Once you are logged in, the session cookie is the credential, and malware or a proxy phishing kit that steals it needs no factor at all. Keep the browser updated, check links with the phishing URL checker before entering credentials, and see the privacy hub for the surrounding protections.
