It's still extremely common for B2C applications, and even some B2B applications, to call SMS-based codes "two-factor authentication." Regulators have started pushing back. The security community has been pushing back for a decade. The applications we test, however, keep using it.
Here's why we recommend against it, consistently, on every engagement.
SIM swapping is industrial
Taking over someone's phone number — convincing their carrier to issue a new SIM card pointing to the attacker's device — is not a sophisticated attack anymore. The market for SIM swaps is mature, prices are documented, and the carrier-side controls have improved without catching up to the attacker workflow.
Once the attacker has the phone number, every SMS-delivered code goes to them. Banking, email, social media, anything else SMS-protected — all owned. The original user notices when their phone stops getting signal, by which point the breach is complete.
This is the dominant attack against high-value SMS-protected accounts. It is not an edge case.
SS7 is broken
The carrier signaling network that routes SMS — SS7 — was designed in an era of trusted carrier-to-carrier relationships. It has no authentication. Anyone with access to it (legitimately or otherwise) can redirect messages, including authentication codes, to a device of their choosing.
Access to SS7 is no longer the exclusive domain of nation-states. There's a market for it, and the prices are well below the value of any meaningful account.
Phishing kits include SMS
Modern phishing kits — the ready-to-use toolkits sold on criminal forums — relay SMS codes in real time. The victim enters their password on the phishing site, gets the genuine SMS code on their phone, enters it on the phishing site, and the kit relays it to the legitimate service. The attacker is now logged in.
This is why phishing-resistant authentication (WebAuthn, hardware tokens) matters: the second factor never leaves the device, so the phishing site cannot proxy it.
What we recommend instead
The hierarchy we present to clients, in increasing order of strength:
- SMS: Better than nothing for low-value consumer accounts. Not appropriate for anything that handles money, health data, or business assets.
- Email-delivered codes: Strictly worse than SMS in our view, unless the email account itself is well-protected. Adds nothing to attacks that come through the email vector.
- TOTP apps (Google Authenticator, Authy): A real improvement. Phishing-vulnerable but immune to SIM swaps and SS7.
- Push-based MFA (Duo, Okta Verify): Better than TOTP for usability. Still phishing-vulnerable through MFA fatigue attacks.
- WebAuthn / FIDO2 / hardware keys: Phishing-resistant. The recommended baseline for any account with material value.
- Passkeys: WebAuthn with a better UX. Where you can support them, you should.
If you can offer only one option, offer TOTP at minimum. If you can offer two, offer TOTP and passkeys. SMS belongs in the recovery path, if at all — and even there, it should be paired with a delay window long enough for the user to notice if something has gone wrong.
The migration argument
The pushback we hear is always operational: "our users don't have authenticator apps," "SMS is what they expect," "the support burden of changing this is too high." All true. None of those concerns will be on the call after the first SIM-swap incident, when the question is "why were we using SMS in 2024?"
If you're starting fresh, default to WebAuthn. If you're migrating, offer both, set a deprecation date for SMS, and use the migration window to educate users. The companies that have done this successfully have not regretted it.