Phishing-resistant MFA is multi-factor authentication (MFA) designed so that a fake login page can’t capture and reuse the sign-in. Instead of a code the user types or a prompt they approve, the user’s device uses a cryptographic key tied to the real website or a verified connection, so a look-alike site gets nothing it can replay. In practice this means FIDO2 security keys and passkeys, and certificate-based smart cards. Common methods such as text-message codes, authenticator app codes and push approvals are MFA, but not phishing-resistant.
At a glance
- Phishing-resistant methods are generally FIDO2/WebAuthn (security keys and passkeys) and PKI-based smart cards or certificates.
- They work by binding the credential to the genuine site or channel, so a fake site gets no code or approval it can reuse.
- SMS, voice, one-time code apps and push prompts, including push with number matching, can be phished.
- It closes the most common way attackers get past MFA, but not session theft, app consent abuse or weak recovery.
- Often required first for administrators and high-risk users, and increasingly asked about by insurers and in US government guidance.
What problem it solves
MFA blocks a large share of password attacks, which is why insurers and auditors push for it. But attackers adapted. Adversary-in-the-middle phishing kits put a proxy between the user and the real login page: the user types their password and MFA code into the fake page, the kit passes both to the real service in real time and keeps the resulting session. Push-based MFA is abused through repeated prompts (MFA fatigue) until a tired user taps approve, or by simply asking the user over the phone to accept.
Phishing-resistant MFA removes what these attacks depend on. There is no code to type into the wrong page, and the cryptographic response is tied to the real domain, so a proxy relaying it to the real site should fail.
How it works
FIDO2 and WebAuthn. When a user registers a security key or passkey with a service, the device creates a key pair specific to that service’s domain. The service keeps the public key. At sign-in, the service sends a challenge; the browser includes the domain it is actually connected to, and the device signs only for the matching credential after the user unlocks it with a PIN or biometric. A look-alike domain gets no valid response.
Certificate-based authentication. Smart cards and device certificates use public key infrastructure (PKI). The private key stays on the card or in the device’s secure hardware and proves possession during a protected exchange with the genuine service. This is common in government and regulated industries.
Policy enforcement. Your identity provider (IdP) is where you register these methods and require them, for example for administrators, finance staff or access to sensitive apps, while blocking weaker fallbacks for those users.
Recovery and fallback. The protection holds only if attackers can’t fall back to a weaker method. Organizations restrict which methods may be used, register backup keys and require strong identity checks when a user needs to re-enroll.
When it matters for buyers
- At cyber insurance renewal. Some applications ask specifically about phishing-resistant MFA for admins, email and remote access; requirements differ between insurers.
- When protecting administrators and executives. These accounts are the most targeted and the most damaging if taken over.
- When public-sector or regulated customers set requirements. US government guidance and some contracts call for phishing-resistant methods; check the specific requirement that applies to you.
- When choosing an identity provider or tier. Support for FIDO2, passkeys and certificate-based sign-in, and the ability to enforce them by group, varies.
- When budgeting. Hardware security keys carry a per-user cost and need spares; passkeys on managed devices may reduce that cost.
Questions to ask vendors
- Which of your MFA methods are phishing-resistant, and can we require only those for selected users and apps?
- Do you support both device-bound security keys and synced passkeys, and can we restrict which are allowed?
- Can we block weaker fallback methods for users enrolled in phishing-resistant MFA?
- How do new users and replaced devices get enrolled securely?
- Which of our applications, VPN or remote access tools can use these methods directly?
- What protections exist against stolen session tokens after a successful sign-in?
How it differs from standard MFA
Standard MFA requires two or more factors, but some factors can be relayed: a typed code or approved push can be captured by a fake site and replayed in real time. Phishing-resistant MFA uses factors that are cryptographically tied to the genuine service, so a relay fails. All phishing-resistant MFA is MFA; much MFA in use today is not phishing-resistant. It is also related to passwordless authentication: passkeys and smart cards are both, but some passwordless methods, such as emailed links, are neither multi-factor nor phishing-resistant. For controls around administrator accounts where this matters most, see our privileged access management overview.