Phishing-Resistant Auth

The Uncomfortable Truth About Your MFA

You turned on multi-factor authentication. You did the responsible
thing. And if that second factor is an SMS code, an authenticator-app
code, or a push notification you approve, it does not stop phishing.
It raises the bar, and modern attackers clear it every day.

This is not a hypothetical. Adversary-in-the-middle phishing kits now
sit between the user and the real site, proxy the login in real time,
and capture the authenticated session as it happens. The user types
their password into the fake page, the kit forwards it to the real
site, the real site asks for the MFA code, the fake page asks the user
for it, the user types it, and the kit forwards that too. Everything
the user can type, the user can be tricked into typing into the wrong
place. These kits are a commercial service now, rented for a couple of
hundred euro, no skill required.

So the honest state of things in 2026 is that most deployed MFA is
already bypassed, at scale, as a business. The question is not whether
your MFA can be phished. It is whether you are using the one kind that
cannot.

Why Every Typeable Factor Fails

The common thread across SMS, TOTP, and push is that they are all
shared secrets at the moment of use, and the user is the one moving
the secret.

An SMS code is a secret texted to you that you type in. A TOTP code
from your authenticator app is a secret your app computes that you
type in. A push approval is a yes-or-no you tap. In every case, the
thing that proves your identity is something you can be socially
engineered into handing to an attacker, because nothing about the code
or the tap knows which site actually asked for it. The code that logs
you into the real site works just as well when the attacker replays it
into the real site a second later. The factor has no idea it is being
relayed.

That is the flaw, and it is not fixable by making the codes longer or
the app fancier. Number-matching on push, TOTP over SMS, none of it
addresses the core problem: a human is in the loop copying a secret,
and a human can be fooled about where the secret is going. SMS adds
its own weaknesses on top, SIM swapping and network interception, but
even a perfectly delivered TOTP code fails the moment a real-time
proxy is in the middle. This is why CISA and NIST now say plainly that
none of these count as phishing-resistant.

The One Mechanism That Works: Origin Binding

There is exactly one property that actually stops phishing, and it is
worth understanding because everything else follows from it. It is
called origin binding.

A FIDO2 credential, the standard behind passkeys and hardware security
keys, is not a secret you type. It is a private key that lives on your
device and never leaves it. When you register with a site, your device
generates a unique key pair, sends the public key to the site, and
keeps the private key. To log in, the site sends a challenge, your
device signs it, and the site verifies the signature against the
public key it has. No secret is ever transmitted, so there is nothing
to phish in transit.

But the transmission part is not even the clever bit. The clever bit
is that the signature is bound to the origin, the actual domain
requesting it. Your browser records which site the credential was
registered to, and it will only use that credential for that exact
origin. When you land on the attacker's lookalike domain, the browser
looks at the origin, sees it does not match the one the credential
belongs to, and refuses to sign. Not because it detected the phish.
Because the credential for the real site simply does not exist for the
fake one. The authenticator stays silent, and there is nothing for the
user to hand over, because the user was never given a secret to move.

This is the whole game. The attacker can build a pixel-perfect replica
of the login page, and it does not matter, because the browser will
not release a signature to the wrong origin no matter how convincing
the page looks. The adversary-in-the-middle business model, which
defeats every typeable factor, collapses against a factor the user
cannot relay because the user never touches it.

Passkeys and Hardware Keys, Briefly

The same FIDO2 mechanism shows up in two forms, and the difference is
worth knowing.

A hardware security key is a physical device, USB, NFC, or Bluetooth,
that holds the private key in a chip it can never leave. This is the
strongest form: the key is a separate object an attacker would have to
physically possess, and the private key cannot be extracted even if
the computer is compromised. It is what you put on the accounts that
matter most, the admin accounts, the identity provider, the break-glass
paths.

A passkey is the same kind of FIDO2 credential, but stored in your
phone or laptop's secure element and, in the common case, synced across
your devices through Apple, Google, or Microsoft. Synced passkeys keep
the origin-binding property fully, the phishing resistance is enforced
by the protocol regardless of syncing, and they are dramatically more
usable than carrying a key, which is why billions are now in use. The
tradeoff is that their security now also depends on the security of the
cloud account they sync through, which becomes a recovery path an
attacker could target. For most people and most accounts, that tradeoff
is very much worth it. For the highest-value accounts, a hardware key
with no sync fabric is the tighter choice.

The practical shape most people should aim for: passkeys for the broad
set of accounts, hardware keys for the few that would be catastrophic
to lose, and two authenticators registered on anything important so
losing one device does not lock you out.

The Catch That Undoes Everything

Here is the part that ruins most deployments, and it is worth stating
bluntly. Adding a phishing-resistant factor does nothing if you leave
the phishable fallback switched on.

If an account accepts a passkey but also lets the user "sign in another
way" with a TOTP code, then an attacker simply steers the victim to the
fallback. The whole phishing-resistance is only as strong as the
weakest method the account still accepts. You did not remove the
vulnerability, you added a strong option next to the weak one and left
the weak one reachable. The attacker picks the weak one.

So the strategy is not "add passkeys." It is "add passkeys and then
remove the fallbacks." That second half is the hard part
operationally, because someone always has a reason the old method needs
to stay, and every reason is a door. Until the phishable methods are
actually gone, the account is still phishable. This is the single most
common way a passkey rollout fails to deliver the security it promised.

What I See, and What To Do

Phishing is how a large share of real breaches start. Not clever
zero-days, phishing, because it targets the human, and the human is
reachable. In engagements the pattern is consistent: an organization
has MFA everywhere, is proud of it, and is fully exposed to a
real-time proxy because every factor they deployed is one the user can
type. The MFA checkbox is ticked and the front door is open.

For your own accounts, the move is straightforward and worth doing this
week. Put passkeys on everything that offers them. Put a hardware key
on your email, your password manager, your identity provider, and any
admin account, because email is the account that resets all the others.
Register a second authenticator everywhere important. And where a
service lets you, turn off SMS and app-code fallback once the passkey
works, because the fallback is the hole.

The Point

Most MFA does not stop phishing, because most MFA is a secret the user
can be tricked into moving, and in 2026 tricking them is a paid
service. The only thing that actually stops it is a credential
cryptographically bound to the real origin, one the browser refuses to
use on a fake site, one the user cannot hand over because they were
never given it to hold. That is FIDO2, in the form of passkeys and
hardware keys.

Add the phishing-resistant factor, put hardware keys on the accounts
that matter most, and then do the part everyone skips: remove the
phishable fallback, because an attacker only needs the weakest method
you still accept. The password told them what you know. The passkey
proves where you are. Only one of those survives a convincing fake.