Phishing-Resistant MFA: Passkeys vs Push vs Hardware

TL;DR

• TOTP and SMS are not phishing-resistant. A real-time proxy (attacker-in-the-middle) relays the code to the real site before it expires, so a stolen 6-digit code is as good as a stolen password.
• Phishing-resistant MFA binds the credential to the legitimate origin. Passkeys/FIDO2 (WebAuthn) and origin-bound push approvals refuse to authenticate to a look-alike domain because the cryptographic challenge is scoped to the real one.
• Attestation is the dividing line. Without hardware attestation, “passwordless” still trusts a device that might be rooted, emulated, or cloned. Hardware-backed keys prove the credential lives in a secure element.
• Match the method to the risk tier. Number-matching push beats SMS; passkeys beat both; hardware-attested push or FIDO2 with device-bound keys is the bar for high-assurance (AAL3-class) access.

What is phishing-resistant MFA?

Phishing-resistant MFA is multi-factor authentication that cannot be defeated by tricking a user into entering a code on a fake site, because the authenticator cryptographically binds each login to the legitimate origin and refuses to respond to an attacker-controlled domain. NIST and CISA reserve the term for methods like FIDO2/WebAuthn and PKI — not SMS, TOTP, or basic push.

The distinction matters because “we have MFA” is no longer a meaningful security claim. The question regulators, auditors, and attackers all now ask is: which MFA, and does it survive a real-time phishing proxy? The US CISA guidance on phishing-resistant MFA is explicit that most deployed second factors are phishable, and NIST SP 800-63B ties the highest authenticator assurance level (AAL3) to verifier-impersonation resistance — which is the formal name for phishing resistance.

Why do TOTP and SMS fail phishing?

TOTP (the 6-digit code from an authenticator app) and SMS one-time passwords share a fatal flaw: the secret a user types is not bound to where they type it. A code that proves “I am the user” to the real bank also proves it to anyone who can replay it within the 30-second window. Modern phishing kits (Evilginx, Modlishka, and their successors) automate exactly this: they sit between the victim and the real site as a transparent reverse proxy.

The victim lands on bank-secure-login[.]com, enters their password, then their TOTP code. The proxy forwards both to the genuine bank.com in real time, completes the login, and harvests the resulting session cookie. The user never sees anything wrong. SMS is worse still — it adds SIM-swap and SS7 interception on top of the same relay weakness, which is why NIST has discouraged SMS as a restricted authenticator for years.

How to read this diagram: The top half shows a real-time attacker-in-the-middle (AITM) phishing flow against a code-based second factor. Because the TOTP or SMS code carries no information about which site requested it, the proxy simply relays everything to the real service and walks away with a live session cookie. The bottom half shows the same attack against an origin-bound credential: the WebAuthn/passkey ceremony embeds the relying-party origin into what the authenticator signs, so when the device sees a look-alike domain it produces no valid assertion at all. The lesson is that phishing resistance is not about code length or entropy — it is about whether the credential is cryptographically scoped to the legitimate origin. This is the single property that separates phishable MFA from phishing-resistant MFA.

What are the contenders?

There are three families worth comparing for any 2026 deployment.

Passkeys / FIDO2 (WebAuthn). A passkey is a discoverable FIDO2 credential — a public/private key pair where the private key never leaves the authenticator (a phone secure element, a platform TPM, or a roaming security key). The browser performs the W3C WebAuthn ceremony, which signs a challenge together with the relying-party ID and origin. Because the origin is part of the signed data, a passkey provisioned for bank.com is structurally unusable against bank-secure-login[.]com. The FIDO Alliance specifications underpin this model. Passkeys are the gold standard for phishing resistance and offer excellent UX (a fingerprint or face scan), but the syncable variety (synced via a platform cloud) trades some device-binding strength for recoverability.

Push with number matching. Tap-to-approve push notifications were widely deployed but suffered from “MFA fatigue” — attackers spam approvals until a tired user taps yes. Number matching closes that gap: the login screen displays a number the user must type into the prompt, so a blind approval cannot succeed. Properly implemented, push can also be origin-aware — the approval is tied to the specific session and the relying-party context, not just a yes/no. Number-matching push is a large UX and security upgrade over SMS, but its phishing resistance depends entirely on whether the approval is bound to the real origin and the device is trustworthy.

Hardware-attested device binding. This is the layer most comparisons miss. Whether you use a passkey or a push approval, the security collapses if the private key lives on a rooted, emulated, or malware-ridden device. Hardware attestation — via Android StrongBox, a TEE, or Apple’s Secure Enclave — lets the identity provider verify that the key was generated inside a certified secure element and that the device is not compromised, by validating a certificate chain back to the platform vendor root. The Android Key Attestation documentation describes how this chain proves key provenance.

How do passkeys, push and hardware MFA compare?

The matrix below scores each method on the four properties that actually decide deployment: phishing resistance, device binding, user experience, and recoverability.

How to read this diagram: This is a decision flow that ranks each MFA family by the two questions that matter most. The first gate — is the credential origin-bound? — immediately separates phishable methods (SMS, TOTP) from everything else, regardless of how slick the UX is. The second gate — is it bound to a trusted device, and is that device’s integrity proven by hardware attestation? — is where the strongest options pull ahead. Notice that two methods can both be “phishing-resistant” yet land in very different security tiers: a number-matching push and a device-bound FIDO2 key both resist the relay attack, but only the attested path can reject a rooted or emulated device. The terminal nodes make the original point explicit: without attestation, even a passkey trusts a device whose integrity you never verified.

Why is attestation the dividing line?

Most “passwordless” marketing stops at “the private key never leaves the device.” That is necessary but not sufficient. The unanswered question is: what is the device? If an attacker can extract or clone the key on a rooted phone, run the authenticator in an emulator, or sideload a tampered build, then “the key never leaves the device” guarantees nothing — because the device itself is hostile.

Hardware attestation answers that question. When the authenticator generates its key inside a StrongBox, TEE, or Secure Enclave, the platform issues a signed attestation certificate proving the key’s provenance and the device’s boot state. The identity provider validates that chain and can reject rooted devices, emulators, and unlocked bootloaders before issuing any token. This is the difference between trusting a claim and verifying it. For a deeper treatment of how the attestation certificate chain is verified, see our companion piece on hardware attestation for authentication. Attestation is also where post-quantum signing and device trust converge over the next few years — the post-quantum authentication guide explains why your identity provider’s signing key is the first asset a future quantum adversary targets, which makes the integrity of the device holding your keys equally load-bearing.

This is precisely the design choice behind CAI-AUTH’s hardware-attested push approval: a tap-to-approve passwordless flow where the approving device must pass mandatory Android StrongBox/TEE attestation, so rooted and emulated devices are rejected outright rather than merely warned about. CAI Technology is not a government authority. The same posture — phishing-resistant by origin binding, hardware-bound by attestation, and tamper-evident in the audit log — is what makes the method auditable against EU regimes; see the DORA, NIS2 and PSD3 authentication checklist for how strong-auth and logging requirements map to these capabilities, and the Okta and Auth0 alternatives for EU companies comparison for how sovereignty and attestation factor into provider choice.

How should I choose for my risk tier?

Match the method to what you are protecting. For low-risk consumer accounts, syncable passkeys give phishing resistance with frictionless recovery and are a clear upgrade from SMS. For workforce and privileged access, prefer device-bound passkeys or number-matching push with enforced hardware attestation, because a rooted admin device is a far worse outcome than a slightly harder recovery story. For regulated workloads (finance, critical infrastructure, anything mapping to AAL3 or PSD3 strong customer authentication), require origin binding and attestation, log every approval to a tamper-evident trail, and have a clean recovery path — Shamir-style social recovery or attested re-enrollment — so that strong device binding does not become an availability risk. If you are weighing whether to run this stack yourself, the trade-offs of self-hosting your identity provider cover the operational and sovereignty side of the decision.

FAQ

What is phishing-resistant MFA?

Phishing-resistant MFA is authentication that cannot be relayed by a fake site, because the credential is cryptographically bound to the legitimate origin. Methods like FIDO2/WebAuthn passkeys and origin-bound push approvals qualify; SMS, TOTP, and basic push do not, because their codes can be replayed by an attacker-in-the-middle proxy in real time.

Are passkeys phishing-resistant?

Yes. Passkeys are FIDO2/WebAuthn credentials whose private key signs a challenge together with the relying-party origin, so a passkey provisioned for the real domain produces no valid assertion on a look-alike site. The phishing relay simply fails. Device-bound passkeys add stronger device binding than cloud-synced ones, at the cost of slightly harder recovery.

Is push notification MFA secure?

It depends on implementation. Basic tap-to-approve push is vulnerable to MFA-fatigue spam, and is only phishing-resistant if the approval is bound to the real origin. Number matching defeats blind approvals, and adding mandatory hardware attestation lets the provider reject rooted or emulated devices — which is what raises push to high-assurance, AAL3-class trust.

See a phishing-resistant, hardware-attested login in action: explore CAI-AUTH’s hardware-attested push approval — an EU-operated, self-hostable OIDC provider that rejects rooted and emulated devices by design. CAI Technology is not a government authority. (CAI TECHNOLOGY SRL, CUI 50512457.)