What is phishing-resistant MFA?

Phishing-resistant MFA is a form of multi-factor authentication in which the second factor is cryptographically bound to the service domain, so a credential captured on a cloned site cannot be replayed anywhere else. In practice this means passkeys and FIDO2/WebAuthn hardware keys: the signature produced is only valid for the origin that requested it, and it is that binding, not where the key is kept, that makes the difference. This is the distinction missing from the most common sentence in security meetings, "we turned MFA on, we are covered", which is a half truth. A code over SMS, a TOTP from an app, meaning a time-based code, or a push notification to approve all add an obstacle, but they remain secrets a person can hand to a fake site or approve out of fatigue. And session cookie theft sidesteps the discussion entirely: whoever steals the session after sign-in needs no factor at all, because they arrive already authenticated.

Why SMS, TOTP and push are not enough

The attack that beats all three is called adversary in the middle: the victim receives a link to a login page identical to the original, but behind it sits a proxy relaying credentials to the real service in real time. The user types password and code, the proxy forwards them, sign-in succeeds and the attacker pockets the session cookie. The code was valid, the second factor worked, and access is compromised anyway. Push notifications add an ergonomics problem: bombarding someone with requests at two in the morning eventually ends with a tap on "approve". SMS brings SIM swapping along, which takes no technical skill at all, only a forged document at a mobile operator's counter.

What actually makes a factor resistant

The mechanism is origin binding. The browser passes the key the exact address of the site requesting authentication, and the key signs only for that one: on a different domain, even one off by a single letter, it produces nothing useful. The standard describing the mechanism is W3C WebAuthn, while the NIST digital identity guidelines, now at SP 800-63B-4 of July 2025, prescribe no technology: they require a property, verifier impersonation resistance, at the highest authenticator assurance level, the one 800-63B calls AAL3. WebAuthn is one of the implementations that satisfy it, and the difference is not pedantry: it means you ask a supplier which property it guarantees, not which acronym it put on the price list. The operational consequence is that on this vector training no longer has to teach people to spot a fake page, because there is no secret left to hand over. It does not disappear entirely: what remains are the tricks that never pass through a login page, namely consent granted to a third-party application and requests to approve a sign-in code generated elsewhere, where the victim authenticates on the genuine site and gives up a session anyway.

One thing the marketing skips has to be said, though, because it concerns the commonest case. "The private key never leaves the device" holds for a hardware authenticator, the physical key you plug into a USB port, not for the synced passkeys of Apple and Google, which are the ones most people end up with without having chosen them. There the origin binding is identical, so phishing resistance stays intact; but custody of the key moves into the account's cloud keychain, and the security of that account becomes the security of every passkey it holds. That shifts the problem rather than removing it, and it is why a physical key beats a synced passkey for whoever administers the domain.

The case of a company on Microsoft 365 and VPN

A recurring scenario in Italian manufacturing: mail and files in the cloud, ERP access over VPN, push MFA enabled for everyone for two years. The first illicit access comes through a fake password renewal page sent to the purchasing office, and the stolen session is enough to read an email thread with a supplier and slip into a payment negotiation. The fix is not "more training": it is mandatory passkeys for anyone touching payments and finance, short sessions bound to a registered corporate device, and switching off the legacy mail protocols that bypass MFA by construction.

Why it matters for decision makers

A phishing-resistant factor closes the most exploited vector against human accounts, but it covers neither downstream session theft nor application identities, which have no finger to place on a key: those are governed as non-human identities. That is why MFA lives inside a Zero Trust design rather than in its place, and why the useful question to ask a supplier is not "is MFA on?" but "which groups have a phishing-resistant factor, and what happens to a session that has already been stolen?".