Phishing-Resistant MFA and the Passkey Shift
For a decade the security advice was 'turn on MFA', and it was good advice. It is now insufficient, because attackers adapted. One-time codes, push notifications and SMS all share a fatal property: the human can be tricked into handing the second factor to a machine-in-the-middle. The real frontier is not MFA versus no MFA — it is phishable MFA versus phishing-resistant MFA, and passkeys are how the second category is going mainstream.
To see the distinction, follow a modern phishing attack. The victim clicks a link to a convincing replica of their login page, sitting behind a reverse proxy the attacker controls. The victim types their password — relayed to the real site. The real site prompts for a code or a push; the victim provides it; the proxy relays that too. The attacker now holds a valid, authenticated session. Every factor was legitimate. The problem is that none of them were bound to where they were being entered.
Why origin binding changes everything
Phishing-resistant authentication — FIDO2/WebAuthn, the technology behind passkeys and hardware security keys — fixes exactly that seam. The authenticator signs a challenge that is cryptographically tied to the origin (the real domain) and never releases a reusable secret. Put the credential on a lookalike domain and the signature simply does not match; the login fails by design. There is no code for the human to leak, because the private key never leaves the authenticator and the browser refuses to use it for the wrong site. The machine-in-the-middle has nothing to relay.
Passkeys, plainly
A passkey is a FIDO credential made usable: a key pair where the private half is stored in a device's secure hardware and unlocked by a local biometric or PIN. Device-bound passkeys (and security keys) stay on one authenticator — highest assurance, best for privileged accounts. Synced passkeys roam across a user's devices through a platform keychain — lower friction, dramatically better than passwords, but now only as strong as the account that syncs them. That trade-off is the real decision, and it should be made deliberately per population, not by accident.
- Rank your factors honestly. SMS is the weakest and phishable and SIM-swappable; app OTP and push are phishable; number-matching push is better but still relayable; FIDO2/passkeys are phishing-resistant. Treat them as a hierarchy, not a checkbox.
- Require phishing-resistant factors for privileged and remote access first. Admins, finance and anyone reachable from the internet are where the AiTM kits aim.
- Kill the fallback. A passkey rollout with an 'or enter a code' escape hatch is still phishable — attackers simply steer victims to the weak path. Remove weak factors, don't just add strong ones.
- Bind step-up and re-auth to origin too. Sensitive actions should demand the phishing-resistant factor, not fall back to a push a proxy can relay.
- Plan recovery before rollout. Account recovery is the new soft target; if a lost passkey resets to an SMS code, you have reintroduced the weakness at the recovery door.
The migration is the hard part
Nobody flips an organisation to passkeys overnight. The realistic path is to introduce phishing-resistant factors, make them mandatory where risk is highest, and then — the step teams skip — retire the phishable fallbacks. Adding a strong factor while leaving SMS enabled buys you very little, because the attacker attacks the weakest enabled option. Progress is measured by what you have turned off, not what you have turned on.
- Check whether SMS or email one-time codes are still an accepted factor or recovery method for any privileged account. If so, that account's MFA is phishable regardless of what else is enabled.
- For one admin login flow, confirm whether a hardware key or passkey is required or merely offered alongside a push option. 'Offered' is not 'enforced'.
Smoke tests like this reveal the obvious gaps; proving least privilege actually holds across every role, tenant and forgotten service account is a standing exercise our assessment runs for you.
Phishing-resistant authentication only protects the accounts you have actually enrolled and the fallbacks you have actually closed. The forgotten legacy login with SMS still on is the one that gets phished — and you can't harden an authentication path you haven't discovered.