Editorial explainer · official sources (NIST, CISA)medium
Phishing-resistant MFA: why not all second factors are equal
Multi-factor authentication is the most-cited defense against credential theft, but "MFA" is not a uniform category. SMS and push notifications remain vulnerable to phishing and MFA fatigue; only two implementations are considered phishing-resistant by official sources: FIDO2/WebAuthn (passkeys included) and smart-card-based PKI. An explainer on what NIST SP 800-63B and CISA guidance say, and how to adopt it.
An explainer, not the attack of the day
This piece doesn't cover a breach: it tries to answer the question almost every attack dossier leaves open — "so how do you defend against it?" — on one specific front, authentication. Because "turn on MFA" is right but incomplete: there is MFA and there is MFA, and the difference is exactly what decides whether phishing still works.
The problem: a second factor you can steal
The idea of multi-factor authentication is simple: add something else to the password, so stealing the password alone isn't enough. But many "something elses" are themselves capturable. A code over SMS or an OTP app is a number the user types: if a phishing site asks for it in real time and relays it to the real service, the attacker gets in. Push notifications ("approve this login?") add the MFA fatigue problem: bombard the victim with requests until, out of tiredness or distraction, they approve one.
The shared defect is that these factors are not bound to the site the user thinks they're connecting to. The right code, entered on the wrong page, works anyway. That's the crack social engineering keeps exploiting.
What makes a factor "phishing-resistant"
The official sources converge and are precise. CISA recognizes only two implementations as phishing-resistant: FIDO2/WebAuthn and smart-card-based PKI (PIV/CAC). NIST, in SP 800-63B, places hardware cryptographic authenticators at the highest assurance level (AAL3), which requires cryptographic proof of possession.
What do these technologies share? The factor is origin-bound: the cryptographic key responds only to the legitimate domain it was registered for. If the user lands on a lookalike domain, the browser simply doesn't present the right credential — not because the user was careful, but because the cryptography makes relaying impossible. The secret never transits, isn't typed, can't be intercepted in flight.
Passkeys, in practice
Passkeys are the most accessible embodiment of FIDO2: cryptographic keys managed by the device or a hardware authenticator, with no password to remember and no code to copy. For most companies they are today the most realistic way to bring phishing-resistant authentication to ordinary users, not just admins. A technical note from the guidelines: syncable passkeys (copied across devices via the cloud) offer great usability but aren't permitted at AAL3, which demands a non-exportable hardware key. Keep that distinction in mind when the context requires the highest assurance level.
How to adopt it without halting everything
Gradually, and with a priority order. High-privilege accounts first — admins, access to critical systems, anyone who can move money or data in bulk: that's where compromise does most damage, and where phishing-resistant MFA pays off most. Then extend to the rest, with passkeys as the default for general users. In parallel, reduce or remove weak factors — SMS and OTP — at least on sensitive logins, and disable the fallbacks that quietly reintroduce them (often the link that undoes everything else). The operational reference stays the official sources: NIST SP 800-63B for assurance levels, CISA's "Implementing Phishing-Resistant MFA" fact sheet for adoption. The principle beneath is one: a second factor that can be relayed isn't a barrier, it's a speed bump.
