Two-factor authentication is recommended universally, and the recommendation rarely distinguishes between methods that differ considerably in effectiveness.
Here they are, roughly from weakest to strongest.
SMS codes
The most widely deployed and the weakest.
Vulnerable to SIM swapping. An attacker persuades a mobile operator to transfer a number to a device they control, through social engineering or insider assistance. Codes then arrive at the attacker's device.
This is not theoretical — documented cases involve substantial losses, and it's a recognised attack pattern.
Vulnerable to interception. Weaknesses in mobile signalling protocols have been demonstrated to permit message interception.
Phishable. A fraudulent site can ask for the code and relay it in real time.
Security guidance from several national bodies has recommended against SMS for high-value accounts.
That said: SMS is substantially better than nothing, and for many accounts it's the only option offered. Use it where it's the only choice; prefer something else where alternatives exist.
Email codes
Similar weaknesses, plus an additional structural problem: if the email account is compromised, both factors are in the same place.
Particularly weak when protecting an account whose recovery is also via that email.
Authenticator apps
Time-based codes generated on your device from a shared secret.
Better because: no dependence on the mobile network, immune to SIM swapping, works offline.
Still phishable: a fraudulent site can request the code and use it immediately. This is the significant remaining weakness.
Backup considerations: if you lose the device without backups, you lose access. Some apps offer encrypted cloud backup, which is convenient and introduces a dependency. Recovery codes stored separately are the more robust approach.
Push notifications
An approval prompt sent to a registered device.
Better than codes because there's nothing to type, and therefore nothing to phish in the same way.
Vulnerable to fatigue attacks. An attacker with valid credentials triggers repeated prompts until the user approves one out of confusion or annoyance. This has been used in significant breaches.
Number matching — where the user must enter a number displayed on the login screen — substantially mitigates this and is worth enabling where offered.
Hardware security keys
Physical devices using public key cryptography, connected by USB, NFC or Bluetooth.
Phishing resistant by design. The cryptographic exchange is bound to the site's actual domain. A fraudulent site cannot obtain a usable response, because the key will not produce one for the wrong domain.
This is the property that makes them qualitatively different rather than incrementally better.
Organisations deploying them have reported effectively eliminating credential phishing.
Considerations: cost, the need for a backup key, and incomplete support across services.
Two keys, one carried and one stored securely, is the standard recommendation. A single key is a single point of failure.
Passkeys
The same underlying cryptographic approach, with the credential stored on a device and unlocked by biometric or PIN rather than requiring separate hardware.
Phishing resistant, for the same reason as hardware keys.
Considerably more convenient, which matters enormously for adoption. Security measures people don't use provide no security.
Synchronisation trade-off. Passkeys can sync across devices through a platform account, which is convenient and means the platform account becomes critical. Device-bound passkeys don't sync and don't have this property.
Adoption is expanding and support remains incomplete.
Practical recommendations
Prioritise your email account. It's the recovery route for everything else. If you protect one thing properly, protect this.
Use the strongest method each service offers. Many offer several and default to the weakest.
Remove weaker methods where possible. A strong method alongside SMS fallback is only as strong as the fallback, because an attacker will use the weaker route.
This is frequently overlooked and it undermines the whole exercise.
Store recovery codes properly. Printed and stored securely, or in a password manager separate from the accounts they protect.
Register a backup method. A second key, a second device. Losing access to your own accounts is a real risk and it's the main reason people avoid enabling this at all.
The account recovery weak point
Worth stating because it defeats everything above.
Account recovery processes exist for people who lose access, and they're frequently the weakest link. An attacker who can pass identity verification through a support process bypasses every authentication measure.
There's little an individual can do about this beyond choosing services with robust processes, and it's why the very strongest protections offered by some providers involve accepting that recovery becomes difficult or impossible.
That's a genuine trade-off between security and the risk of locking yourself out, and the right answer depends on what's being protected.
Shared and organisational accounts
An awkward case that the standard advice does not address.
Accounts used by several people — a business social media account, a shared service login — do not fit a model built around one person with one device.
What works: a password manager with shared vaults, where the second factor secret is stored in the shared entry so any authorised person can generate codes. Hardware keys work poorly here since they are physical objects in one place.
What does not work: registering one person's phone, which creates a dependency on that individual being available and a problem when they leave.
The departure case is the one organisations handle worst, and it is entirely predictable.