Authenticator apps and SMS fall to the same attack

There's an informal hierarchy almost everyone accepts: SMS is bad, authenticator apps are safe. Swapping one for the other has become standard advice.

The swap does improve something. Just not the thing that matters — and the document that classifies authenticators is explicit about it.

The criterion that separates the factors

NIST, in the standard that defines identity assurance levels, defines phishing resistance as the protocol's ability to keep the secret from reaching an impostor verifier:

"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"

— NIST SP 800-63B, section 3.2.5

That last part is what organizes everything. The question isn't how much protection a factor provides. It's whether that protection depends on you noticing you're on the wrong site.

Under that criterion, the standard lists as not phishing-resistant: passwords, one-time codes, out-of-band authentication — and, explicitly, OTP. That covers SMS and it covers the authenticator app.

Both share the same structural weakness: they generate a code you read in one place and type into another. Anything capable of impersonating the real site gets that code handed over by you.

Where SMS genuinely is worse

The equivalence has limits, and it's worth being precise.

The standard treats SMS as a restricted authenticator — the only category classified that way. Restricted means it can still be used, but with conditions: whoever offers it must provide an alternative, and must weigh risk signals such as SIM swaps and number porting before sending the code.

In other words: SMS is worse, and it's worse for a specific reason — the phone line can be taken over. The authenticator app doesn't have that problem.

What it also doesn't have is phishing resistance.

The attack that doesn't care which of the two you use

In March 2026, Microsoft published an analysis of a phishing kit operating as a service. The numbers give a sense of scale:

"tens of millions of phishing messages reaching over 500,000 organizations each month worldwide"

The mechanics described are what matter here. The attack doesn't try to guess or intercept the code. It sits in the middle: the victim lands on a fake page, enters the password, receives the challenge, and the code itself is relayed to the real service in real time.

"The MFA codes were subsequently relayed through Tycoon2FA's proxy servers to the authenticating service"

From the victim's point of view, everything worked. Authentication succeeded. It succeeded for the attacker.

And there's a detail that changes the incident response: what gets stolen isn't just the credential, it's the session cookie generated by the successful authentication. A valid session doesn't ask for the password again. That's why "I changed my password afterwards" usually doesn't terminate the access — the door left open isn't the password.

Why protecting the phone line doesn't solve it

Much of the effort against authentication fraud, in Brazil and elsewhere, has focused on making line takeover harder: more verification to swap a SIM, waiting periods after account changes, identity checks on porting.

These are legitimate measures and they eliminate an entire class of fraud.

But the attack described above never touches your SIM. It doesn't need your line, your device, or for you to lose signal. It needs you to type the code into the wrong page.

Hardening SIM swaps protects against line takeover. It doesn't protect against phishing — and concluding that "SMS is safe now" trades a risk for a feeling.

What actually raises the bar

According to the same standard, phishing resistance appears in cryptographic authenticators, by two routes: binding the response to the communication channel, or binding it to the verifier identifier. The second is the one that matters to most organizations, and it's the mechanism behind WebAuthn — the foundation of passkeys and physical security keys.

The practical difference is easy to state. In these methods the secret never leaves the device, and the response is only generated for the legitimate domain. On an impostor page there's nothing to type incorrectly: the authenticator simply doesn't respond.

User vigilance stops being part of the defense. Which was exactly the criterion.

What to do with this

For anyone making authentication decisions in an organization, this is a matter of priority, not perfection:

Where there's sensitive data or money, the target is phishing-resistant. Passkeys or physical keys. It's the only category that changes the nature of the problem rather than just its difficulty.

Where that isn't feasible yet, an app beats SMS — because of line takeover, not because of phishing. It's still a code that can be handed to the wrong party.

Treat sessions as credentials. If the incident was phishing, changing the password isn't enough: sessions have to be revoked, and that's where response usually falls short.

The useful question isn't "do I use two factors?" It's: if I land on a convincing page, does my second factor save me on its own, or does it depend on me noticing?

---

Sources

NIST SP 800-63B — Digital Identity Guidelines, Authenticators section, National Institute of Standards and Technology.

Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale, Microsoft Security Blog, March 4, 2026.