Phishing-Resistant MFA: Moving Beyond OTP to Passkeys

The uncomfortable truth about your current MFA

Multi-factor authentication was supposed to end credential theft. For a long list of organizations that already deployed it, the honest assessment is that it raised the bar without closing the door. The Verizon Data Breach Investigations Report continues to find that the large majority of breaches involve stolen or misused credentials, and attackers have simply industrialized the techniques for getting past a second factor.

The problem is not that MFA is useless — it stops password spraying and reused credentials cold. The problem is that the most widely deployed second factors were never designed to resist a determined, real-time adversary. Three attacks dominate what we see across client incident response engagements:

• Real-time relay (adversary-in-the-middle). Off-the-shelf phishing kits such as Evilginx and its many clones sit between the user and the real login page. They proxy every keystroke, capture the one-time code the moment it is entered, and — more importantly — steal the resulting session cookie. Once the token is replayed, the attacker is inside without ever needing the factor again. SMS codes, TOTP authenticator apps, and email codes all fall to this identically.
• MFA fatigue (push bombing). When the second factor is a simple "Approve" push, an attacker who already holds the password fires prompt after prompt at 2 a.m. until the user taps Approve to make their phone stop buzzing. This single technique was central to several headline breaches over the past few years.
• SIM swap. SMS-delivered codes assume the phone number belongs to the user. A social-engineered carrier port or an insider at a retail store moves the number to the attacker's device, and every SMS factor follows it.

The common thread is that these factors ask a human to relay a shared secret. Anything a user can read and retype, an attacker can capture or coerce.

What "phishing-resistant" actually means

The phrase is not marketing. It has a precise technical definition, and it comes down to one property: origin binding. A phishing-resistant credential refuses to authenticate to any site except the exact one it was registered with — and it makes that decision in silicon, not in the user's judgment.

Figure: with origin binding the private key never leaves the device and only unlocks for the true domain, so a relayed credential is worthless to the attacker.

FIDO2, built from the WebAuthn browser standard and the CTAP device protocol, is the mechanism behind both roaming hardware keys and passkeys. Instead of a shared secret, registration generates a public/private key pair. The private key stays sealed in the device's secure element or TPM and never crosses the wire. Authentication is a challenge-response: the site sends a random challenge, the authenticator signs it, and the browser includes the origin — the actual domain in the address bar — in what gets signed.

That last detail is the whole game. If a user lands on micros0ft-login.com behind a relay proxy, the browser presents that origin to the authenticator. The signature is computed for the wrong origin, the real server rejects it, and there is no code to steal and nothing to approve. The relay attack that defeats OTP and push simply produces an invalid assertion. There is also no shared secret sitting in a database to breach, and no push prompt to spam.

Two form factors deliver this:

• Hardware security keys (FIDO2 keys such as YubiKeys) are physical, roaming authenticators. The private key is device-bound and cannot be exported, which makes them the strongest option for the highest-value accounts.
• Passkeys are FIDO2 credentials created on a phone or laptop. Synced passkeys back up through a platform keychain so users are not locked out if a device breaks; device-bound passkeys never leave the hardware. Both are phishing-resistant; they differ in the recovery-versus-assurance tradeoff you are willing to accept.

A phased rollout that people will actually adopt

The mistake we correct most often is treating passkeys as a big-bang identity project. It is not. It is a prioritized migration, and the sequencing matters more than the technology. Enroll it under a coherent identity and access management program so enforcement is consistent rather than negotiated per application.

1. Start with the accounts an attacker wants most. Domain and cloud administrators, security staff, and break-glass accounts first. A compromised admin is a full breach, so this is where phishing-resistant MFA buys the most risk reduction for the least user disruption. Fold this into your privileged access management controls rather than running it as a separate silo.
2. Move to high-risk applications. Email, the identity provider itself, finance and payroll systems, code repositories, and remote access. These are the pivots attackers reach for once inside.
3. Register at least two authenticators per user. A hardware key plus a platform passkey, so a lost or dead device is an inconvenience rather than a lockout ticket.
4. Enforce with conditional access, not honor system. Registering passkeys is meaningless if the weaker factor still works alongside it. Build policies that require phishing-resistant authentication for privileged roles and sensitive apps, and weigh device posture, location, and risk signals. This is exactly the enforcement layer a zero trust implementation is built to deliver — verify every request explicitly instead of trusting a session because it once passed a prompt.
5. Only then turn off the weak factors for the population you have migrated. A phased cutover, role by role, avoids the flood of help-desk tickets that sinks rushed rollouts.

A realistic timeline for a mid-sized organization is a matter of months, not weeks, and the gating factor is almost never the technology — it is coverage of edge cases, legacy applications that only speak legacy protocols, and the recovery design below.

The fallback and recovery pitfalls that undo everything

Here is the failure mode we see again and again: an organization deploys passkeys beautifully, then leaves SMS or a one-time code as the "just in case" recovery option. An attacker does not attack your strongest factor. They attack the weakest path to the same account. If recovery falls back to a phishable method, you have bought phishing-resistant MFA and kept a phishable front door.

Design the recovery path with the same rigor as the primary path:

• No phishable fallback for privileged accounts. If a break-glass admin can recover with an SMS code, the account's real security is that SMS code.
• Prefer re-provisioning over downgrading. When a user loses a key, the recovery should be a verified re-enrollment of a new phishing-resistant authenticator — ideally identity-proofed in person or by a manager — not a temporary drop to a weaker factor.
• Treat account recovery as a privileged operation. Help-desk-driven MFA resets are a documented breach vector; an attacker calls, claims a lost phone, and talks their way to a reset. Require strong verification, and log and alert on every reset. Security awareness for the help desk matters as much as for end users here.
• Provision break-glass accounts deliberately. A small number of well-guarded, hardware-key-only emergency accounts, stored offline and monitored for any use, keeps a passkey rollout from becoming a single point of failure.
• Mind the unmanaged edges. Legacy applications that cannot speak modern authentication protocols, shared kiosks, and service accounts each need an explicit decision — front them with a modern access proxy, or accept and document the residual risk. Do not let them quietly reintroduce passwords.

Where to start

Phishing-resistant MFA is the single highest-leverage identity control available today, because it changes the economics: a phished credential and a captured session become worthless when the credential refuses to sign for the wrong origin. But the value is realized only when the rollout is sequenced by risk, the weak factors are actually retired, and the recovery path is not a soft underbelly.

If you want a clear-eyed assessment of where your MFA can still be relayed, fatigued, or SIM-swapped — and a phased plan to move admins and high-risk apps to passkeys without a help-desk fire drill — talk to intSignal's security team.