Phishing-Resistant MFA Guide

Most organisations have MFA, but most of their sign-ins still use methods an attacker can relay through a fake login page. Codes, push approvals and SMS all depend on the user spotting the fraud. Phishing-resistant MFA removes that dependency by binding the authenticator's output to the real site or to the protected channel. This guide is the programme view: what qualifies under NIST SP 800-63B-4, what OMB M-22-09 and CISA require, how to choose between FIDO2, passkeys, smart cards and platform authenticators, and how to move a workforce from "MFA registered" to "phishing-resistant MFA enforced" without leaving the old paths open. It is written for identity architects, IAM engineers and security leads who own the rollout.

Key takeaways

• Phishing resistance is a property of the protocol, not the user. NIST SP 800-63B-4 recognises two mechanisms, verifier name binding (WebAuthn/FIDO2) and channel binding (client-authenticated TLS, as used by PIV and CAC). Anything the user types or approves is not phishing-resistant.
• Registered is not enforced. If policy still accepts push, OTP or SMS, a phishing proxy simply asks for the weaker method. Coverage is measured by what the access policy requires, not by what users have enrolled.
• Start with administrators and the people who can reset others. CISA suggests help desk and IT administrators as the first group, and Microsoft's deployment guidance enforces admins on each platform before anyone else.
• The programme fails at registration and recovery. A first credential issued after a weak identity check, or a help desk reset over the phone, hands attackers a phishing-resistant credential of their own.
• Close the side doors too. Legacy protocols, device code flow, unreviewed exceptions and stolen session tokens all bypass the authenticator. They need their own controls and their own metrics.

What makes MFA phishing-resistant

NIST SP 800-63B-4 defines phishing resistance as the ability of the authentication protocol to prevent the disclosure of authentication secrets to an impostor verifier without relying on the vigilance of the claimant. It states plainly that passwords, look-up secrets, out-of-band authenticators and one-time passwords are not phishing-resistant, because a value the user enters manually is not bound to the session and an impostor can relay it. Cryptographic authenticators qualify only when they meet the requirements of section 3.2.5, through one of two mechanisms.

• Verifier name binding: the authenticator output is cryptographically bound to the verifier's authenticated identifier. For web sign-in that identifier is the DNS hostname, or a parent domain at least one level below the public suffix. WebAuthn is the example NIST gives: the browser supplies the origin, so a look-alike domain gets nothing usable. This is what people usually mean by origin binding.
• Channel binding: the protocol binds an identifier of the authenticated protected channel to the authenticator output, for example by signing both with the claimant's key, and the verifier checks that proof. Client-authenticated TLS is the example, and NIST notes that PIV and CAC cards provide phishing resistance this way. NIST describes channel binding as more secure than verifier name binding, because a relay fails even if the impostor holds a valid certificate.
• Authentication intent: section 3.2.8 requires an explicit response to each request (a touch, a PIN, a card reinsertion): SHOULD at AAL2, SHALL at AAL3.

Two assurance rules shape method choice. At AAL2, verifiers "SHALL offer at least one phishing-resistant authentication option", and federal agencies must require phishing-resistant authentication for staff, contractors and partners. At AAL3, the authenticator must have a non-exportable private key and provide phishing resistance, so syncable authenticators (synced passkeys) are not permitted at AAL3.

Methods compared

For method detail see the Hardware Security Keys Guide, the Passwordless and Passkeys Guide, the Smart Card and PIV/CAC Authentication Guide and the Windows Hello for Business Guide. Why the bottom three rows fail is covered in the AiTM Phishing Guide, the MFA Fatigue and Bypass Guide and the Authenticator Apps and OTP Guide.

Cross-device sign-in

When a user signs in on a laptop with a passkey held on a phone, the FIDO hybrid transport (CTAP 2.2) is used. NIST SP 800-63B-4 section 5.2.11 describes it: a QR code supports key establishment through a tunnel service, and a wireless technology such as Bluetooth LE requires physical proximity during association. The proximity check stops a remote attacker forwarding the QR code. Treat hybrid as an off-ramp for devices that cannot hold a local credential, not the daily path.

What the mandates require

CISA is candid that "The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication" and that PKI-based approaches require highly mature identity management. Where an application cannot support it yet, CISA says to escalate the risk to senior leadership and use interim controls such as number matching.

Choosing a method mix

• Administrators and highly regulated users: device-bound FIDO2 security keys or smart cards, at least two per person. Microsoft's deployment guidance recommends FIDO2 keys here, with authenticator-app passkeys or CBA as alternatives; synced passkeys cannot meet AAL3.
• Knowledge workers on managed laptops: a platform authenticator (Windows Hello for Business, platform SSO on macOS) as the daily credential, plus a portable credential for new devices and recovery.
• Mobile-first and BYOD users: synced passkeys give the best adoption. Microsoft's guidance recommends synced passkeys for non-admin users. Accept that security then depends partly on the sync provider account.
• Shared devices and frontline staff: portable credentials. Microsoft states WHfB should only be used when each user signs into the PC as themselves, and supports up to 10 users per device; beyond that, use security keys.
• Existing PKI estate: keep smart cards where they work, especially for on-premises Windows logon, and use FIDO2 for cloud and SaaS. Running both is normal.

Small organisations should standardise on one identity provider, buy two security keys per administrator, enable passkeys for everyone and enforce them for the cloud email and admin portals first. Large organisations need persona groups, device readiness data by operating system, a funded key logistics process and an exceptions register, because the long tail of legacy applications decides the timeline.

How to implement: a phased rollout

1. Inventory sign-in paths. List every application and protocol users authenticate to, which ones go through your identity provider, and which use legacy authentication, RADIUS, LDAP or local accounts. Applications that cannot federate become exceptions with an owner and a date.
2. Check device readiness. Microsoft lists minimum versions for its methods (for example Windows 10 22H2 for WHfB, Windows 11 22H2 for passkeys, macOS 13, iOS 17, Android 14). Identify users whose devices fall short before enforcement, not after.
3. Create the enforcement policy in report-only mode first. Microsoft's example: all users excluding break-glass accounts, all resources, grant "Require authentication strength: Phishing-resistant MFA", state report-only, created "preferably before even beginning your enrollment campaigns".
4. Enforce for administrators. Issue two device-bound credentials to every privileged user, then switch a policy targeting directory roles and admin portals to On. CISA suggests help desk and IT administrators as the initial group.
5. Bootstrap everyone else in waves. Microsoft orders waves by persona and platform: admins on Windows and iOS, admins on macOS and Android, then other users on Windows and macOS, then iOS and Android. Pilot each wave with a small group and slow down if help desk ticket volume rises.
6. Enforce per wave and remove weaker methods. Move each group into the enforced policy, then disable SMS, voice, OTP and push for that group in the authentication methods policy. Keeping them registered "just in case" keeps the downgrade path open.
7. Close the side doors. Block legacy authentication and device code flow (next sections), then review exceptions monthly.

Rollback: keep each wave in its own group so a failure can be reversed by removing that group from the enforced policy, not by disabling the policy for everyone. Keep two cloud-only break-glass accounts protected by FIDO2 keys stored separately, and test them before every enforcement step.

Registration bootstrapping and recovery

A phishing-resistant credential is only as trustworthy as the event that issued it. If a new starter's first key is registered after a password and SMS code, an attacker who phishes those can register their own key. Microsoft's deployment guidance proposes identity verification (for example an identity verification provider with Microsoft Entra Verified ID), then a Temporary Access Pass (TAP) to register the first portable credential, which in turn bootstraps the local platform credential.

• Two credentials per user: NIST says CSPs should encourage at least two authenticators, and Microsoft recommends the same. Losing one key should mean using the second, not calling the help desk.
• Recovery at the same strength: resetting a phishing-resistant user with a phone call and an SMS code reduces the account to SMS strength. Require identity verification or manager-attested, in-person or video recovery before issuing a TAP. The MGM Resorts breach and the Storm-2949 Azure attack both began with a help desk reset. See the Account Recovery and Help Desk Security Guide.
• Revocation on loss: NIST requires a mechanism to invalidate an authenticator immediately on notification of loss or theft. Make "report a lost key" a self-service action from the second credential.

Enforcing with policy: a documented example

Identity providers express enforcement as a policy object listing acceptable methods. Microsoft Entra Conditional Access authentication strengths are a well-documented example.

• Custom strengths: up to 15 per tenant. Under Passkeys (FIDO2) advanced options you can restrict to specific authenticator models by AAGUID, and for CBA you can require specific issuers (by subject key identifier) and certificate policy OIDs, up to five of each. Use this to require attested hardware keys for admin portals.
• Evaluation timing: Conditional Access is evaluated after initial authentication, so a strength does not restrict the first factor. A user who signed in with a password is not prompted for WHfB and must restart the session.
• Grant controls: "Require multifactor authentication" and "Require authentication strength" cannot be combined in one policy. Replace the old MFA grant rather than stacking policies.
• Other identity providers: Okta's equivalent is an app sign-in policy requiring "a phishing-resistant possession factor", satisfied by passkeys (FIDO2 WebAuthn) or Okta FastPass. Okta documents that some WebView apps fail with "Access denied" under this rule and logs blocked relays as "Okta FastPass declined phishing attempt".

Policy design beyond authentication strength is covered in the Conditional Access Guide.

Gaps that bypass the authenticator

Microsoft's analysis, quoted in its legacy authentication guidance, found that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks used legacy authentication. Microsoft calls device code flow "a high-risk authentication method" and recommends "blocking device code flow wherever possible", with exceptions only for input-constrained devices such as conference room systems. Session theft after sign-in is the gap that survives a perfect rollout: the CitrixBleed 2023 exploitation used stolen session tokens to bypass MFA entirely. See the Token and Session Security Guide.

Where identity fits beyond the user

Service accounts, service principals and automation cannot use a passkey, so rollouts usually exclude them from the user policy. Microsoft notes that calls made by service principals are not blocked by Conditional Access policies scoped to users, and recommends replacing scripted user accounts with managed identities. Track every excluded account as a non-human identity with an owner and a credential plan, or the exclusion list becomes the easiest way in. See the NHI Authentication Guide.

Detection and measurement

Monitor these signals in the identity provider logs and stream them to the SIEM (Entra audit logs are retained for about 30 days by default):

• Method registration: new authenticator or security info registrations, especially within hours of a risky sign-in, a TAP issuance or a help desk ticket.
• Policy outcomes: report-only results where the phishing-resistant policy was "not satisfied", by user, operating system, client app and resource.
• Weak protocol use: sign-ins with legacy client apps or the device code authentication protocol outside allowlisted devices.
• Blocked relays: vendor events such as Okta's "Okta FastPass declined phishing attempt" are high-confidence indicators that a user reached a phishing page.

Framework mapping

Common failure patterns

• Calling OTP and push "strong MFA": the Twilio 0ktapus campaign harvested employee credentials through SMS lures. Cloudflare reported that three of its employees entered credentials in the same campaign, but the attacker "could not get past the hard key requirement" because every employee used a FIDO2 key.
• Leaving push on for high-risk users: the Uber breach turned a contractor's password and repeated push prompts into internal access.
• Enrolling keys without removing fallbacks: coverage dashboards show 90% registered while the policy still accepts SMS, so nothing has changed for an attacker.
• Weak recovery: help desk resets granted to a caller impersonating an employee, the route in the Co-op cyber attack.
• Remote access outside the identity provider: the Change Healthcare breach began at a remote access portal without MFA. Appliances, VPNs and RDP gateways must be federated or replaced.
• Permanent exceptions: rollout exclusions for executives, contractors or "the one legacy app" with no expiry date.

Practitioner checklist

• Define phishing-resistant using NIST SP 800-63B-4 section 3.2.5 and list which of your methods qualify.
• Create the phishing-resistant enforcement policy in report-only mode before the first enrolment campaign.
• Issue two device-bound credentials to every administrator and help desk operator, then enforce for them first.
• Bootstrap new users through identity verification and a one-time, short-lived TAP, never a password and SMS code.
• Roll out in persona and platform waves, each in its own group, with a documented rollback.
• Remove SMS, voice, OTP and push for each group as soon as it is enforced.
• Block legacy authentication and device code flow, with named, reviewed exceptions.
• Require recovery at equal strength and alert on method registrations after risky sign-ins.
• Report enforced coverage, weak method residue and exception age monthly.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• CISA: Implementing Phishing-Resistant MFA
• Microsoft Learn: Deploy a phishing-resistant passwordless authentication deployment
• Microsoft Learn: Conditional Access authentication strengths
• Microsoft Learn: Authentication flows in Conditional Access
• Okta: Phishing-resistant authentication
• Cloudflare: The mechanics of a sophisticated phishing scam and how we stopped it

Related NHI Mgmt Group resources: MFA Guide · Passwordless and Passkeys Guide · AiTM Phishing Guide · Conditional Access Guide · Workforce Identity Security Guide