# Phishing-resistant MFA: does it stop device code phishing?

> Phishing-resistant MFA (FIDO2/WebAuthn, PKI) blocks proxy phishing by binding to a site's origin — but it does not stop device code phishing. Here's why.

Phishing-resistant MFA is a class of multi-factor authentication — FIDO2/WebAuthn security keys and passkeys, and PKI smart cards — that cannot be relayed through a fake login page, because the credential is cryptographically bound to the real site's web address. It defeats the adversary-in-the-middle proxy phishing that steals one-time codes and push approvals. But it does **not** stop device code phishing, because in that attack the victim signs in on the *genuine* provider page — the phishing-resistant check passes exactly as designed, and the attacker simply collects the resulting tokens. Closing that gap needs a policy control, not a stronger authenticator.

## Quick takeaways

- Phishing-resistant MFA means **FIDO2/WebAuthn** (security keys, passkeys) or **PKI** (PIV/CAC smart cards) — the only two forms [CISA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) counts as phishing-resistant.
- It works by **origin binding**: the authenticator signs a challenge tied to the site's exact domain, so a proxy on a lookalike domain gets nothing usable.
- SMS codes, authenticator-app TOTP, and push approvals are **not** phishing-resistant — all can be relayed by an adversary-in-the-middle kit.
- Phishing-resistant MFA stops credential-relay (AiTM) phishing, but **not device code phishing**, because the victim authenticates on the real page and only *approves* an attacker-started session.
- The fix for device code phishing is a **Conditional Access policy** that blocks the device code flow, not a different authenticator.

## What is phishing-resistant MFA?

Phishing-resistant MFA is multi-factor authentication that an attacker cannot capture and replay by tricking the user into entering it on a fake page. The [US cybersecurity agency CISA names exactly two implementations](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) that clear the bar:

- **FIDO2/WebAuthn** — hardware security keys (like a YubiKey) and passkeys, built on an open standard from the FIDO Alliance and the W3C.
- **PKI-based authentication** — smart cards such as the PIV and CAC cards government agencies issue.

Everything else people call "MFA" falls short of *phishing-resistant*. A one-time code from SMS or an authenticator app, a push notification you approve, a magic link, a security question — each can be handed to an attacker, either by a user typing it into a convincing fake page or by an adversary-in-the-middle relaying it in real time. Those methods still beat a password alone, and number matching blunts push-fatigue attacks, but none of them are phishing-*resistant*. For how the tiers compare and where each belongs, see [which MFA types MSPs should deploy](/learning/mfatypesformsp).

## Why is FIDO2/WebAuthn phishing-resistant?

The defining property is **origin binding**. When you register a passkey or security key with a site, the authenticator generates a key pair that is scoped to that site's origin — its exact domain. At sign-in, the browser hands the authenticator a challenge along with the origin it is actually talking to, and the authenticator will only produce a signature if that origin matches the one the key was registered for.

That single check is what breaks proxy phishing. In an adversary-in-the-middle attack, the victim lands on `login.micros0ft-verify.com`, which silently relays every request to the real Microsoft page and passes responses back. With a TOTP code or a push approval, the relay works: the victim completes MFA on the real service *through* the proxy, and the attacker captures the resulting session cookie. A FIDO2 authenticator refuses to sign, because the origin it sees is the attacker's domain, not the real one. There is no code to phish and no approval to relay — the [authentication cannot be forwarded](/learning/why-do-phishing-emails-pass-spf-and-dkim) to a domain it was not registered against.

This is why passkeys are the recommended defense against credential theft, and why they also limit the blast radius when a [password is reused or leaked](/learning/how-do-password-managers-protect-accounts): there is no shared secret to steal in the first place.

## Does phishing-resistant MFA stop device code phishing?

No — and this is the gap most rollouts miss. Device code phishing abuses the OAuth 2.0 **device authorization grant** (RFC 8628), a legitimate flow built for input-constrained gadgets like smart TVs and conference-room devices that cannot show a full browser. The flow is simple: a device shows a short user code and a URL, and you approve it from your phone or laptop.

An attacker turns that into a trap. They start a device code request themselves, receive a real user code and the genuine verification URL from the provider, and send both to the victim — often disguised as an IT prompt, sometimes delivered by [QR-code phishing](/learning/what-is-quishing-qr-code-phishing). The victim opens the *authentic* provider page, enters the code, and signs in. Here is the crucial part: **the sign-in is real**, so a passkey or security key works perfectly and the phishing-resistant check passes. Once the victim consents, the provider issues access and refresh tokens — to the attacker, who has been polling the token endpoint the whole time. In some cases they register a device to capture a long-lived Primary Refresh Token and stay in for [months](/learning/device-code-flow-exploitation).

Origin binding provides no protection here because the attacker never proxied the login. The victim was on the correct domain with the correct credential; they just approved a session someone else initiated. Phishing-resistant MFA is answering "is this the right user on the right site?" — and the honest answer is yes. The abuse lives one layer up, in the flow itself. The same blind spot applies to consent phishing, where a user grants a malicious OAuth app permissions with a fully valid, phishing-resistant login.

## How do you defend against device code phishing?

Because a stronger authenticator does not close this route, the defense is a policy control that stops the flow from being available at all:

- **Block the device code flow with Conditional Access.** In Microsoft Entra, an [authentication-flows Conditional Access policy can block the device code flow](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows) outright. Microsoft's guidance is to block it wherever possible and grant narrow, account-based exceptions only for the shared-device resource accounts that genuinely need it.
- **Scope exceptions tightly.** If some conference-room or IoT devices require device code sign-in, allow it only for those specific service accounts and, where possible, only from managed devices — not as a tenant-wide default.
- **Alert on device code sign-ins.** Treat interactive device code authentications by ordinary user accounts as suspicious. A finance or admin user completing a device code flow is a strong signal worth investigating.
- **Train for the specific lure.** The tell is being asked to enter a code you did not request into a real Microsoft or Google page. Teach users that a legitimate service never sends *them* a device code to approve on someone else's behalf. This is the same "authenticated does not mean safe" gap behind [ghost phishing and other DMARC-evading techniques](/learning/what-is-ghost-phishing).

## Frequently asked questions

### Are passkeys and security keys the same thing?

Both are FIDO2/WebAuthn credentials, so both are phishing-resistant. A security key is a physical device you carry (like a YubiKey); a passkey is a FIDO credential synced or stored on a phone or laptop. The origin-binding protection is identical — the difference is portability and recovery, not resistance.

### Is Microsoft Authenticator with number matching phishing-resistant?

No. Number matching stops push-fatigue attacks, where a user blindly approves a flood of prompts, but the approval can still be relayed by an adversary-in-the-middle proxy. CISA classifies app-based push, even with number matching, as MFA that is *not* phishing-resistant.

### If phishing-resistant MFA can be bypassed, is it still worth deploying?

Yes. It eliminates the most common and scalable attack — adversary-in-the-middle credential and session theft — which no other authenticator type fully stops. Device code and consent phishing are narrower, require a policy control you can apply centrally, and are far easier to detect. Phishing-resistant MFA plus a device-code block covers both.

### Does phishing-resistant MFA protect against a compromised session token?

No. Once a valid token or session cookie exists, MFA has already happened. Token theft (including the device code case) is handled by shortening token lifetimes, binding tokens to devices, and revoking sessions on suspicious activity — not by the authenticator.

## Where Palisade fits

Palisade does not manage your MFA, but it closes the email side of the same impersonation problem: it deploys SPF, DKIM, and DMARC, moves your domains to enforcement, and reads the aggregate reports so attackers cannot forge your exact domain to deliver the lures — the fake IT prompts and code requests — that start attacks like these. Pair phishing-resistant MFA and a device-code Conditional Access block with a locked-down sending domain, and check where your domain stands today with the [Email Security Score](/tools/email-security-score).

## Related reading

- [Which MFA types should MSPs use to protect clients?](/learning/mfatypesformsp)
- [How can attackers exploit OAuth device code login?](/learning/device-code-flow-exploitation)
- [What is ghost phishing and can DMARC stop it?](/learning/what-is-ghost-phishing)