Home / Guides / Phishing-resistant MFA
Phishing-resistant MFA: rolling it out without a mutiny
Not all MFA is equal — most of it can be phished. Here's what "phishing-resistant" really means, why passkeys and hardware keys are different, and how to roll it out to a whole company without the helpdesk revolt.
Most MFA — SMS codes, authenticator apps, push notifications — can be defeated by phishing or push-fatigue attacks. Phishing-resistant MFA (FIDO2/WebAuthn security keys and passkeys) can't, because the credential is cryptographically bound to the real website and never leaves the device. CISA recommends it as the gold standard. Roll it out in waves — admins and finance first — with backups enrolled, and the "mutiny" never happens.
"We have MFA" is one of the most comforting and least precise sentences in security. Some MFA stops the attacks companies actually face in 2026; some of it is theater that attackers routinely bypass. The distinction is phishing resistance, and it's worth understanding before your next incident teaches it to you. This is the practical guide, from a team that rolls out identity and access management for small companies. US CISA has been explicit that phishing-resistant MFA is the standard to aim for.
Why most MFA can still be phished
The common forms of MFA share a fatal property: they produce a shareable secret the user can be tricked into handing over. A fake login page harvests your password, then prompts for the SMS or app code, which you helpfully type — and the attacker relays both to the real site in real time. Modern phishing kits automate exactly this. Three weak links in particular: SMS codes (also defeated by SIM swaps), authenticator-app codes (phishable via relay), and push notifications (defeated by "push fatigue" — bombard someone with prompts until they tap Approve to make it stop). All three are real improvements over passwords alone. None of them stop a competent phishing attack, which is why the ground has shifted.
What "phishing-resistant" actually means
Phishing-resistant MFA removes the shareable secret. The two forms that qualify are built on the FIDO2/WebAuthn standard: hardware security keys (a physical device you tap or plug in) and passkeys (the same cryptography stored on your phone or laptop, protected by biometrics). The mechanism is the point: authentication uses public-key cryptography, and the private key never leaves your device — there's no code to read out, nothing to type into a fake page. Crucially, the credential is bound to the real website's domain. Land on a look-alike phishing site and the key simply refuses to respond, because the domain doesn't match. The user doesn't have to spot the fake; the cryptography does. That's the difference between MFA that depends on human vigilance and MFA that doesn't.
| Method | Phishing-resistant? | Beaten by | Use for |
|---|---|---|---|
| SMS code | No | Phishing relay, SIM swap | Last resort only |
| Authenticator app (TOTP) | No | Real-time phishing relay | Better than SMS; not for admins |
| Push notification | No | Push fatigue / MFA bombing | OK with number-matching; not for high-value |
| Security key (FIDO2) | Yes | — (domain-bound crypto) | Admins, finance, executives |
| Passkey (WebAuthn) | Yes | — (domain-bound crypto) | Everyone — the target state |
The rollout that doesn't cause a revolt
The reason phishing-resistant MFA has a reputation for friction is bad rollouts — flipping it on for everyone at once, with no backup keys and no runbook, generating a helpdesk pile-up and a lockout or two that poison the whole project. Done in waves, it's smooth. Here's the sequence we use:
Start where the risk is highest
Admins hold the keys to everything and are prime phishing targets. Enroll IT and all privileged accounts on hardware keys first — two keys each, a primary and a backup stored separately. This group is technical, tolerant of a new step, and the highest-value to protect. It's also your pilot: you'll learn your environment's quirks on the people best equipped to handle them.
Protect the money and the impersonation targets
Finance authorizes payments; executives get impersonated. Both are heavily targeted and worth the white-glove treatment — enroll them personally, explain the "why" (it ties directly to the fraud they've seen), and make sure each has a backup method. Small group, high payoff.
Passkeys for the population
For the broad workforce, passkeys on the phone or laptop they already carry are the low-friction path — no extra hardware to buy or lose, biometric unlock they already use. Communicate ahead, provide a one-page how-to, and enroll department by department so the helpdesk handles a trickle, not a flood.
Enroll a second factor before you need it
Every person gets a backup method enrolled at setup — a second key, or a passkey plus a key. And keep a documented, tightly-controlled "break-glass" recovery path for the day someone loses everything, so a lost phone is a minor inconvenience, not a locked-out executive at midnight.
Handling the objections you'll actually hear
"It's one more step." Passkeys with biometrics are often faster than typing a password plus a code — lead with that, and let Wave 1 report it. "What if I lose my key or phone?" That's what the enrolled backup and break-glass path are for; answer it before it's asked, in the how-to. "Our old systems don't support it." Common and real — cover those with the strongest method they do support and prioritize them for modernization; don't let the weakest system block protecting everything else. "It's expensive." Hardware keys are a modest one-time cost for the high-value group; passkeys are free for everyone else. Weighed against one account-takeover incident — or the insurance questionnaire that now asks about phishing-resistant methods for admins — the math is not close.
Where this sits in the bigger picture
Phishing-resistant MFA is the single control that most directly defeats the attack chain everything else on this blog keeps circling back to: the leaked or phished credential tried against your systems. It's the hero of our security checklist, the closer in our exchange security stack, and the specific thing that turns a valid stolen password into a dead end. If you do one security project this quarter and the basics of backups and patching are already handled, make it this. It's the highest ratio of attack-surface-removed to effort-spent that a small company can buy.
The systems that fight back (and what to do about them)
Every real rollout hits the same wall: something important doesn't support modern MFA. A legacy line-of-business application, an old VPN appliance, a vendor portal stuck in 2015. Don't let the weakest system dictate the whole project — that's how "we couldn't do MFA everywhere" becomes "we didn't do MFA anywhere." The playbook: inventory the holdouts explicitly; wrap what you can — put a modern identity layer (SSO/identity-aware proxy) in front of apps that can't do MFA natively, so the strong authentication happens at the gateway; compensate what you can't wrap — restrict those systems to trusted networks, monitor them harder, and shorten sessions; and put them on the modernization list with a date, because a system that can't do phishing-resistant auth in 2026 is telling you something about its future. The goal isn't perfection on day one; it's protecting the 90% that can move now while boxing in the 10% that can't, rather than holding the whole company hostage to the one stubborn app. That sequencing — strong where possible, compensated elsewhere, modernized on a clock — is the difference between an MFA project that ships and one that stalls in a meeting about the one system nobody wants to touch.
Frequently asked questions
Is an authenticator app good enough?
It's meaningfully better than SMS and fine as a baseline for lower-risk accounts, but it is not phishing-resistant — real-time phishing kits relay app codes just as easily as SMS. For admins, finance, and anything high-value, move to FIDO2 keys or passkeys. Think of app-based codes as the floor, not the destination.
What's the difference between a passkey and a security key?
Same underlying FIDO2/WebAuthn cryptography, different housing. A security key is a separate physical device (great for admins and shared/locked-down scenarios); a passkey lives on a device you already own — phone or laptop — unlocked by biometrics. Passkeys are the low-friction choice for the general workforce; hardware keys suit the highest-assurance roles.
Does phishing-resistant MFA really stop all phishing?
It defeats credential phishing specifically — the attacker can't capture and replay something that never leaves your device and won't respond to a look-alike domain. It doesn't stop every attack type (malware, social engineering into actions), so it's one critical layer, not the whole program. But for the dominant attack path, it's decisive.
How long does a company-wide rollout take?
For a small-to-mid company, typically a few weeks in waves — days for the admin pilot, then finance and executives, then the broad workforce department by department. The timeline is driven by communication and enrollment logistics, not technical difficulty; rushing it to a single day is what creates the "mutiny" you're trying to avoid.
Can we use passkeys and keep passwords too, or is it all-or-nothing?
You can phase it: add phishing-resistant methods alongside existing logins first, require them for high-value accounts, then progressively reduce reliance on passwords as coverage grows. Full passwordless is a destination, not a prerequisite — the security gain comes as soon as the strong factor is required for the accounts attackers target, long before you retire passwords entirely.
Do insurers or frameworks require this now?
Increasingly, yes — cyber insurance applications and security frameworks now single out phishing-resistant or strong MFA for privileged accounts, and CISA recommends it broadly. Beyond compliance, it's simply the control that most reduces the risk they're all worried about, which is why it keeps appearing on the forms.
Plan your MFA rollout Our IAM practice
Sources: CISA — Implementing Phishing-Resistant MFA · NIST SP 800-63B — Digital Identity Guidelines (Authentication). General guidance from our IAM engagements; specifics depend on your identity platform.