Phishing-resistant MFA, on the wire
Most "MFA" is replayable. A modern reverse-proxy phishing kit (Evilginx, EvilProxy, Tycoon 2FA) is just a pipe — it takes whatever your user types, including the OTP and the session cookie, and hands it to the attacker. FIDO2 / WebAuthn is the one factor it cannot forward.
The four MFA archetypes, ranked
| Factor | Phishable? | Why |
|---|---|---|
| SMS / voice OTP | Yes, trivially | SIM swap, SS7, plain interception. NIST has been deprecating this since 2016. |
| TOTP (Google Authenticator, Authy) | Yes — replayed in real time | The 6 digits are valid for 30 seconds. The proxy types them into the real site faster than the user does. |
| Push notifications | Yes — push fatigue / number matching helps but doesn't solve | If the user approves the push, the attacker is in. Number- matching reduces but doesn't eliminate. |
| FIDO2 / WebAuthn passkey | No | The signed assertion is bound to the origin the browser is actually talking to. The phishing site has the wrong origin, so the signature is invalid for the real site. Period. |
What makes WebAuthn unphishable
Three properties, in order of importance:
- Origin binding. The authenticator signs over the origin the browser sees (
login.example.com), not what the user thinks they're on. A reverse-proxy atlogin-examp1e.comwill produce a signature for that domain, which the real server rejects. - No shared secret. The server stores only the public key. There is nothing to steal from the database, nothing to exfiltrate from a memory dump, nothing to forward.
- User presence + verification. The signature is only produced after a local gesture (Touch ID, Face ID, PIN, button press). The credential is non-exportable from the secure enclave on single-device passkeys, and end-to-end encrypted for synced passkeys.
What "passwordless" actually means
Three deployment patterns, ordered by maturity:
- Passkey + password fallback
- Cheapest way to add phishing-resistance, but the password remains as a phishable backdoor. Most consumer rollouts (Apple, Google) started here.
- Passwordless primary, recovery via secondary device
- The password is removed from the account. Recovery is another passkey on a backup device, an admin-recovery flow, or attested re-enrollment from a trusted endpoint.
- Phishing-resistant only, no exceptions
- AAL3 / OMB M-22-09 territory. No SMS recovery, no helpdesk reset without identity-proofing. The bar U.S. federal agencies have to meet by mandate, and what mature enterprises are heading toward.
Where it goes wrong in the wild
- Soft fallback. "If passkey fails, send an OTP" — the attacker just triggers the fallback. Defeats the point. Don't.
- Helpdesk bypass. Caller IDs themselves, says they lost their device, helpdesk re-enrolls a passkey on the attacker's device. This was the MGM and Caesars pattern in 2023.
- Account-takeover via session token theft post-auth. A passkey stops phishing but doesn't stop infostealer malware that lifts an already-issued session cookie. Token-binding (or token- binding's modern cousin, DPoP) is the answer.
- Mixed RP IDs. Registering a passkey for
example.comand trying to use it onapp.example.comwithout a proper RP ID hierarchy breaks. Plan the relying-party-ID tree before rollout.
What you can do today
- Walk through the passkey demo. It's the same WebAuthn ceremony enterprise IdPs run.
- Read about agent identity — the same primitives, applied to AI agents instead of humans.
- For your own org: enable passkeys on the IdP, gate sensitive admin roles to passkey-only (no fallback), and add token-binding / DPoP on the highest-risk APIs.