Beyond passwords: phishing-resistant MFA

Multi-factor authentication is not one thing. The gap between a one-time code texted to a phone and a hardware-backed passkey is the difference between slowing an attacker down and stopping them entirely. This is the distinction between phishable and phishing-resistant MFA.

Why most MFA is still phishable

The problem with codes and push prompts is that the second factor is a shared secret the human can hand over. If a user can read a code and type it into a page, they can be tricked into typing it into an attacker's page.

• SMS / TOTP codes — an attacker-in-the-middle (AiTM) proxy such as Evilginx presents a pixel-perfect login clone, relays the credentials and the OTP in real time, and captures the resulting session cookie. The valid code buys nothing.
• Push notifications — vulnerable to MFA fatigue / prompt bombing: repeated approvals until a tired user taps "Approve."
• SIM swapping — moves the victim's number to an attacker's SIM, defeating SMS entirely.

Number matching and geo-context on push help, but they are mitigations on a fundamentally phishable design.

What makes MFA phishing-resistant

Phishing-resistant MFA removes the human from the trust decision. Two properties matter:

• Origin binding — the credential is cryptographically tied to the exact web origin it was registered for. A look-alike or proxy domain simply does not match, so authentication silently fails.
• No shared secret in transit — authentication uses a challenge-response with a private key that never leaves the device.

The standards that deliver this:

• FIDO2 / WebAuthn — the browser and platform standard for public-key authentication.
• Passkeys — FIDO2 credentials, either device-bound (hardware security key, e.g. YubiKey) or synced (backed up across a vendor ecosystem like Apple, Google, or a password manager).
• PIV / smart cards (x.509) — the long-standing enterprise/government approach.

Why AiTM proxies fail against it

User → phish.example (attacker proxy) → real.example

WebAuthn assertion is signed over the origin the browser sees:
  clientDataJSON.origin = "https://phish.example"
The credential was registered for "https://real.example"
→ origin mismatch → the authenticator/RP rejects the assertion

There is no code for the user to relay and no cookie the proxy can harvest, because the login never succeeds against the wrong origin. The browser enforces this — not the human.

Rolling it out without breaking things

Prioritise by risk. Start with admins, finance, executives, and anyone with access to crown-jewel systems. These are the accounts AiTM kits target first.

Plan for account recovery. Recovery is the new soft underbelly — if a lost key falls back to SMS or a help-desk call, you have reintroduced the phishable path. Require two registered authenticators per user (e.g. a security key plus a platform passkey) and harden help-desk identity verification.

Handle mixed estates. Synced passkeys ease deployment on personal and mobile devices; device-bound keys suit high-assurance and shared/kiosk scenarios. Many orgs run both.

Sequence the migration:

1. Enable FIDO2/passkeys alongside existing MFA.
2. Register a second factor and drive enrollment campaigns.
3. Move privileged roles to phishing-resistant required.
4. Remove SMS and voice as factors.
5. Expand the phishing-resistant requirement org-wide via conditional access.

Aim for phishing-resistant as required, not merely available. As long as a phishable fallback exists, attackers will steer users toward it — a technique known as MFA downgrade.

How GottaPhish helps

Phishable MFA — OTP and push — gives a false sense of safety while leaving a real gap that attackers actively exploit; simply owning the technology does not close it. GottaPhish and its expert support team help you make the business case and execute the rollout: our AiTM-style simulations demonstrate, safely and measurably, how OTP and push MFA fall to a real proxy, giving leadership the evidence to fund phishing-resistant MFA. From there our experts guide your FIDO2/passkey deployment hands-on — prioritising high-risk roles, planning dual-authenticator enrollment and recovery, and reporting on adoption alongside your click and report metrics — and help you interpret the results so you can prove the phishable gap is actually closing.