Is two-factor authentication by text message good enough?

Two-factor is not one thing, and the difference has a name

Start with the property that separates the options, because once you have it the rest of this is arithmetic.

NIST defines it precisely. In its guidelines, "phishing resistance is the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier (i.e., an attacker fraudulently posing as the verifier) without relying on the vigilance of the claimant."

Unpack the last clause, because it is the whole thing. An impostor verifier is a fake login page. The vigilance of the claimant is you noticing that the page is fake.

A method is phishing resistant when it protects you even if you do not notice. That is a property of the protocol, not a property of how careful your team is on a bad Friday afternoon.

So the question stops being how secure is a text message and becomes something checkable: if somebody who is being fooled hands over everything the screen asks for, does the attacker get in?

For a code you can read, the answer is yes. That is not a flaw in text messages specifically. It is true of any code a person can retype.

Anything you can type into a box can be typed into the wrong box

This is the part that surprises people who moved from text codes to an authenticator app and assumed the problem was solved.

The app on your phone is doing something well defined. The standard behind it describes "A time-based variant of the OTP algorithm" that "provides short-lived OTP values, which are desirable for enhanced security."

Short-lived is a real improvement. A code that expires in seconds is useless to somebody who finds it written down next week.

But look at what the method requires: "The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret."

A shared secret, and a code derived from it that you read off a screen and type in. If a convincing fake login page asks for that code while it is still valid, the attacker can pass it straight to the real site. The code is short-lived, not single-destination.

So an authenticator app fixes interception and reuse. It does not fix being fooled. Both text codes and app codes sit on the same side of the line NIST drew, which is why upgrading from one to the other is a smaller improvement than it feels like.

That is the honest ranking. Codes beat no second factor by a wide margin. The gap between kinds of code is narrow.

Text messages carry a caution the others do not

Now the specific thing about the phone network, stated at the strength the source states it and no stronger.

NIST does rule some things out flatly. On email it is unambiguous: "Email SHALL NOT be used for out-of-band authentication".

It does not say that about text messages. What it says is different and more interesting. Sites checking your identity "SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret."

PSTN is the ordinary phone network. Read that list again, because it is a list of the ways a phone number gets stolen rather than intercepted. Somebody persuades a mobile operator to move your number to their device, and the codes follow the number.

That is the actual risk, and it explains why the advice is aimed at the site rather than at you. You cannot detect a SIM swap from your end. You find out when your phone stops working.

NIST also keeps the question open, which is worth knowing before you invest in anything: it "may adjust the restricted status of out-of-band authentication using the PSTN based on the evolution of the threat landscape and the technical operation of the PSTN".

Restricted is a status with consequences, and the sentence says it can move. So a method that is acceptable today is one the standards body has explicitly reserved the right to downgrade, which is an argument for not building your whole recovery story on it.

None of this says switch it off. It says a text code is the option with a caveat attached and a review pending.

The version that does not depend on you being careful

Here is the thing on the other side of the phishing resistance line, and it is probably already available on the accounts that matter to you.

MDN describes it plainly: the Web Authentication API "enables strong authentication with public key cryptography, enabling passwordless authentication and secure multi-factor authentication (MFA) without SMS texts". And it names the word you will actually see in the settings screen: "On the web, passkeys are implemented using the Web Authentication API."

Why it resists phishing is one sentence, and it is the most useful sentence here: "An attacker who creates a fake login website can't login as the user because the signature changes with the origin of the website."

Nothing about that depends on you spotting the fake. The browser checks which site is asking, and a lookalike address is a different site, so the credential simply does not work there. There is no code to read out, which means there is no code to be tricked into reading out.

That is the same property NIST defined at the top of this page, arriving from the other direction.

What to check, in order

Five checks, and every one of them is free.

• Do not turn off text message codes while you decide. The gap between a text code and no second factor is enormous, and the gap between a text code and a passkey is much smaller.
• Look at which accounts control everything else: your domain registrar, your hosting, your email, and the profiles your listings depend on. Those deserve the strongest method available before anything else does, because whoever holds them can reset the rest.
• Check whether those accounts offer a passkey or a security key, and turn it on where they do. On many services this is now a setting rather than a purchase.
• Check your recovery options with the same eye. An account with a passkey and a text message recovery path can still be taken by taking the phone number, and recovery is the part people configure once and never revisit.
• Make sure more than one person can get in. The strongest authentication in the world becomes a problem when the only person who can pass it leaves or is unreachable.

One thing worth separating out. Who is listed on an account and who legally owns it is a different question from how people prove who they are, and it is worth settling in writing rather than in a settings screen.

Getting the accounts behind a website onto sensible authentication, and making sure recovery does not quietly undo it, is part of what we do when we look after a site.

Sources

• NIST Special Publication 800-63B revision 4, Digital Identity Guidelines: Authentication and Authenticator Management (NIST)
• RFC 6238, TOTP: Time-Based One-Time Password Algorithm (RFC Editor, Informational)
• Web Authentication API (MDN Web Docs)

Last reviewed 2026-09-12.