How Phishing-Resistant MFA works
Three-step view of how it operates in practice.
- Register. The user registers a hardware key or passkey with the identity provider. A cryptographic key pair is generated, the private key never leaves the device.
- Challenge. When the user signs in, the identity provider issues a challenge tied to the real website’s domain.
- Sign. The hardware key or passkey signs the challenge locally. A fake phishing site gets a cryptographically invalid response, the attacker can’t replay it.
Why Phishing-Resistant MFA matters
Attackers now rent phishing kits that sit between the victim and the real login page, capturing codes and approvals as they happen, which is why CISA urges organizations toward phishing-resistant methods, especially for administrators. For a smaller organization the pragmatic play is targeted: hardware keys or passkeys for the handful of accounts that control money and infrastructure buys most of the protection for a fraction of the effort.
Phishable vs phishing-resistant factors
- Codes and push approvals. One-time codes and tap-to-approve prompts still depend on human judgment, a convincing fake login page can relay the code or trigger the prompt in real time, and modern phishing kits do exactly that at scale.
- FIDO2 hardware keys. A physical key such as a YubiKey signs a challenge cryptographically bound to the genuine site's domain. Presented with an impostor page, it produces nothing an attacker can use, resistance is built into the protocol, not the user's vigilance.
- Device-bound passkeys. The same cryptography without a separate gadget: the credential lives in the laptop or phone's secure hardware and unlocks with a fingerprint or PIN. Same phishing resistance, easier rollout.
- Synced passkeys. Passkeys backed up through a cloud account so they follow the user across devices. Convenient for the workforce, with the trade-off that security now also rests on that cloud account — pick deliberately for admins.
Common Phishing-Resistant MFA mistakes
- Leaving phishable fallbacks alive. If a user has a hardware key but the account still accepts a texted code as backup, attackers simply request the weaker path, a downgrade attack. The rollout is finished only when the phishable methods are removed, not merely outranked.
- Not starting with admins and finance. Spreading upgrades evenly across all staff leaves the highest-value targets exposed the longest. Move administrators, executives, and anyone who can send money first; the rest of the organization can follow in waves.
- A phishable recovery path. Cryptographic sign-in means little if account recovery still runs through an email link or a persuadable help desk call. Recovery must be as strong as the front door — verified identity, a registered backup key, or an in-person step.