← Back to home

Pillar guide

Phishing-resistant MFA for Microsoft 365: a 2026 implementation guide

Push notifications and SMS-based MFA are no longer enough. AiTM phishing proxies defeated both at industrial scale across 2022-2025, and the regulators have caught up. This is the deployment-shaped guide for Microsoft 365 / Entra admins operationalising the move — what counts as phishing-resistant, what doesn't, and how to ship the change without locking users out.

Last updated 30 April 2026 22-minute read

What counts as phishing-resistant MFA — and what doesn't

The term "phishing-resistant MFA" gets used loosely. The technical definition is narrow: an authentication method is phishing-resistant if the credential cannot be captured by an attacker who has positioned themselves between the user and the legitimate service via an adversary-in-the-middle (AiTM) phishing proxy. The credential must be cryptographically bound to the legitimate origin so a fake one can't successfully replay it.

In practice this collapses to a small set of credential types:

These are not phishing-resistant, regardless of whether the vendor markets them that way:

Microsoft has codified this distinction inside Conditional Access. The Authentication strengths feature ships a built-in "Phishing-resistant MFA" strength that explicitly excludes SMS, voice, OTP, and push — so a CA policy requiring it cannot be satisfied by the legacy methods. That's the most reliable single test of whether a credential counts: would Microsoft's authentication-strengths filter accept it?

Why push and SMS no longer pass — the AiTM problem

Until roughly 2022, push and SMS-based MFA were considered the modern baseline for SaaS sign-in. They added enough friction to trivial password-stuffing that most organisations got the security uplift they wanted. Then AiTM phishing kits matured — Evilginx, EvilProxy, Tycoon, Caffeine, Storm-1167 are the prominent kits — and the legacy MFA modes stopped working at scale.

The mechanic is straightforward. The user receives a phishing email, clicks through to what looks like the Microsoft sign-in page, types their password, completes the SMS / push / OTP step, and is logged in normally. What they didn't see: every keystroke and every authentication response was relayed through an attacker- controlled proxy. The proxy passed each request to the real Microsoft login, captured the resulting session cookie, and now has full session-level access — no password reset will revoke it, because it's not a password issue. The attacker bypassed MFA without ever defeating MFA cryptographically. They just rode along.

Microsoft's own Threat Intelligence team documented AiTM-driven sessions across 10,000+ organisations as of mid-2022, and the volume has grown substantially since. By 2024 it was the dominant initial-access technique in Microsoft 365 BEC (business email compromise) cases.

Passkeys (and the broader FIDO2 / WebAuthn family) close this gap by binding the credential to the legitimate origin during registration. When the user later authenticates, the browser checks that the relying-party origin matches the one in the credential. An AiTM proxy on a different domain — any different domain — fails that check. The user never even sees a sign-in prompt to be tricked by; the browser refuses to release the assertion. It's a structural defence, not a detection one.

That structural property is the only kind that scales. Detection-based defences (anomaly scoring, geo-velocity rules, suspicious-sign-in alerts) are useful as a second layer, but on their own they fail open more often than they fail closed. Phishing-resistant credentials fail closed by definition.

The regulatory pressure forcing the migration

The shift from "phishing-resistant is best practice" to "phishing-resistant is the baseline" is regulatory. A series of mandates over 2022-2026 have moved the floor for what's acceptable MFA. Most Microsoft 365 customers in scope of one or more of these are now actively planning the migration:

US Executive Order 14028 (2021) + OMB M-22-09

Federal agencies are required to deploy phishing-resistant MFA. The implementation memorandum (M-22-09) names FIDO2 / WebAuthn and PIV / smart-card authentication as the canonical mechanisms. Agency timelines run through 2025-2026 with most completing by end-FY-2025. Federal contractors and vendors with FedRAMP commitments are pulled along by extension.

CISA Zero Trust Maturity Model

Phishing-resistant MFA is the "Initial" tier of the Identity pillar — i.e. the minimum to count as having moved past traditional perimeter security. CISA publishes regular guidance reinforcing this; their Secure Our World materials specifically call out passkeys and hardware keys as the recommended forms.

EU NIS2 Directive (Article 21)

Applies to "essential" and "important" entities across 18 sectors (digital infrastructure, financial services, healthcare, public administration, energy, transport, drinking water, food, manufacturing, postal services, etc.). Article 21 requires "multi-factor authentication or continuous authentication solutions" — and national implementations + ENISA guidance interpret this as phishing-resistant in practice. The October 2024 transposition deadline has passed; enforcement is ramping through 2026 with material fines for non-compliance (up to 2% of global annual turnover for essential entities, 1.4% for important).

EU DORA — Digital Operational Resilience Act

Applies to financial services across the EU. Effective January 2025. The technical standards reference NIS2 + ENISA frameworks and similarly drive toward phishing- resistant MFA for privileged access in financial-services environments.

PCI DSS 4.0

Effective March 2025, PCI DSS 4.0's MFA requirements (Requirement 8.4 + 8.5) cover all access into the cardholder data environment, including non-console administrative access. The standard doesn't mandate the word "phishing-resistant" verbatim but the supporting guidance and Q&A from the PCI SSC explicitly recommends FIDO2-based methods over OTP/push for any environment with elevated risk.

NIST SP 800-63B Rev 4 (under finalisation)

The revised digital-identity guidelines explicitly recommend phishing-resistant authenticators for AAL2 and AAL3 use cases, and tighten the criteria for what qualifies. Federal compliance frameworks that reference NIST 800-63 (FedRAMP, FISMA, StateRAMP) inherit the change. Many private-sector compliance frameworks reference NIST 800-63 by extension.

Cyber insurance underwriting

Less formal but more immediate for many organisations: cyber-insurance carriers (Beazley, Coalition, Chubb, AXA, Hiscox) tightened their MFA underwriting questions through 2024-2025. Many now ask explicitly whether phishing-resistant MFA is deployed across privileged accounts and for remote access. A "no" doesn't deny coverage but materially affects premium and sub-limits — to the point where the insurance saving from deploying often exceeds the deployment cost in year 1.

Net effect: most Microsoft 365 customers are now subject to at least one of the above. The deployment isn't optional any more — it's a question of when, not if.

What Microsoft 365 / Entra ships today

The good news: Microsoft has done the platform work. Phishing-resistant MFA on Microsoft 365 is a configuration exercise, not an integration project. Every paid Microsoft 365 plan (E3, E5, Business Premium) includes the necessary primitives. The relevant pieces:

Authentication methods policy

Entra admin centre → Protection → Authentication methods → Policies. This is where you turn each credential type on or off, scope it to groups, and configure attestation requirements. The phishing-resistant credentials available:

See the Entra ID passkey rollout guide for the policy detail.

Conditional Access authentication strengths

Entra admin centre → Protection → Conditional Access → Authentication strengths. Microsoft ships three built-in strengths:

The third one is what your sensitive-app Conditional Access policies should require. Set it as a grant control on policies targeting Microsoft admin centres, finance systems, source repositories, and any tenant scope your compliance framework designates as elevated.

Microsoft Authenticator passkey support

Microsoft Authenticator on iOS and Android can act as a phishing-resistant passkey provider. The user enrolls a passkey on the app and signs in with it on any site where the work account is registered. The Microsoft Authenticator passkey setup guide covers the per-device flow.

Hardware security keys

For privileged accounts (Global Admins, Privileged Role Admins, finance leadership, security operations) hardware keys are the safest option — they're attested, device-bound, and survive a compromised endpoint. YubiKey 5 series, Feitian K9, and Google Titan all work with Entra. Budget €40-€60 per key, two per privileged user (primary + backup).

Windows Hello for Business

For managed Windows endpoints joined to Entra (or Hybrid-joined). Windows Hello for Business is functionally equivalent to a platform passkey for phishing-resistance purposes — the credential is TPM-backed, origin-bound, and unphishable. The Windows Hello vs passkeys guide covers how it interoperates with the broader passkey rollout.

The 6-step deployment plan

With the credential primitives understood, the deployment is sequenced like any other identity infrastructure change. The mistake we see most often is teams skipping the report-only phase and hard-enforcing immediately, which locks out the unenrolled tail and forces a frantic rollback. The order matters.

Step 1 — pick the credential types

Decide which phishing-resistant methods your tenant accepts before you build the policy. The standard mix that works for most M365 customers:

Step 2 — enable in the Authentication methods policy

Entra admin centre → Protection → Authentication methods → Policies. Enable Passkey (FIDO2), Microsoft Authenticator (passkey), and FIDO2 security key. Scope to a pilot group (30-50 people) initially. Leave Enforce attestation off during pilot — broaden once the policy is stable.

Keep SMS / voice / push enabled in parallel during rollout. They're the fallback path for users who haven't enrolled phishing-resistant credentials yet. Disable them only after step 6.

Step 3 — Conditional Access in REPORT-ONLY first

Build a Conditional Access policy targeting your pilot group + sensitive apps (Microsoft 365 admin portal, Azure portal, Microsoft Defender, Exchange admin, SharePoint admin, plus any of your business-critical SaaS that integrates via Entra). Grant control: Require authentication strength → Phishing-resistant MFA.

Critical: state → Report-only, NOT On. This logs what would happen without actually enforcing — letting you see which users would be blocked, from where, on which apps. Watch the report for 7-14 days. The Microsoft Learn report-only article explains the dashboards.

Step 4 — pilot

Run a 30-50-person pilot for 10-14 days. The pilot group is a deliberate cross-section of device families: Samsung, iPhone, Pixel, Mac, Windows, plus any Xiaomi / Huawei / OPPO / vivo / Honor users in your fleet. Most rollout failures we see come from teams piloting only with IT staff (uniform device set) and discovering Samsung Pass intercept and Mi Autofill device-only behaviour in production.

Document the device-specific quirks BEFORE broad rollout. The mixed-device fleet rollout guide documents the per-family runbook in detail. The best-practices pillar guide covers the comms cadence and helpdesk readiness layer.

Step 5 — broad rollout in waves

200-500 users per 2-3 week wave, grouped by department or geography. Helpdesk capacity is the binding constraint. Privileged accounts in the final wave with a stricter policy (attested-only credentials).

During waves, leave the Conditional Access policy in report-only — users still get prompted for phishing-resistant credentials when they have them, but unenrolled users can still complete sign-in via fallback methods. This is the "we're not forcing it yet, but we're showing what the future state looks like" phase.

Step 6 — enforce

Once the userRegistrationDetails report shows 95%+ enrolment in scope:

  1. Send a 7-day enforcement warning to the unenrolled tail.
  2. Confirm break-glass / emergency-access accounts are excluded from all CA policies (Microsoft's recommended pattern: two break-glass accounts, both with stored offline credentials).
  3. Run report-only one final time. Check that no legitimate sign-in would be blocked.
  4. Flip the CA policy state from Report-only to On. Phishing-resistant MFA is now enforced for the scope.
  5. Over the following 4-8 weeks, expand scope: more apps, more user groups, eventually a tenant-wide baseline policy that requires phishing-resistant for everyone.
  6. Months 3-6 post-rollout: start removing password-based authentication from the methods policy entirely. Goal state: passwords retained only on break-glass accounts.

Five mistakes that derail phishing-resistant MFA rollouts

1. Hard-enforcing before broad enrolment

The single most common rollout-killer. Team gets to 75% enrolment, leadership wants to "lock it in", Conditional Access flips to On, the unenrolled 25% can't sign in to enrol, helpdesk explodes, policy gets rolled back, momentum dies. Wait until 95%+ before enforcing. Always.

2. Treating Microsoft Authenticator as the only acceptable credential

Authenticator is one valid phishing-resistant credential, but iCloud Keychain and Google Password Manager passkeys are equally phishing-resistant by the same FIDO2 origin-binding. Requiring Authenticator-only adds friction (download + sign in + cross-device handshake) that drops enrolment rates. Restrict Authenticator-attested-only to privileged scopes; accept any FIDO2 passkey for general staff.

3. Skipping report-only mode

Conditional Access policies are blunt. Going straight from "policy doesn't exist" to "policy enforced" denies the team any chance to spot issues before they bite users. The report-only phase exists to catch edge cases (legacy auth from a CRM integration, service accounts, scoped users in odd locations). Always run it for 7-14 days minimum.

4. Forgetting non-browser auth flows

Phishing-resistant CA policies cover browser-based sign-in. They don't automatically cover legacy Outlook profiles, IMAP/POP, ActiveSync, PowerShell with username +password, automation scripts, or Microsoft Graph clients using device-code flow. Audit your tenant for legacy auth (the sign-in logs will show you) and either upgrade those clients to modern auth or carve out an explicit exception. Enforce phishing-resistant for everything else.

5. No break-glass accounts

Phishing-resistant enforcement breaks emergency access by design. If your only admin account is locked behind the policy and the policy or the credential or Microsoft itself has a bad day, you're locked out of your own tenant. Stand up two break-glass accounts, both excluded from every CA policy, both with credentials physically stored offline (vault, safe, two different locations). Test break-glass sign-in BEFORE you enforce, not during the outage.

See your branded phishing-resistant rollout walkthrough

Type your work domain on the home page — within seconds you'll see what your employees would land on, branded with your real logo and accent colour, with device-specific flows for every phone and laptop family in your fleet.

Try the branded demo → Talk to us

Frequently asked questions

What is phishing-resistant MFA?

Phishing-resistant MFA is a class of authentication methods designed so the credential cannot be captured by an adversary-in-the-middle (AiTM) phishing proxy. The credential is cryptographically bound to the legitimate origin and is never typed, copied, or screenshotted in a way an attacker can replay. The canonical phishing-resistant credentials are FIDO2 / WebAuthn passkeys (whether platform-bound, synced, or hardware-key-backed) and Windows Hello for Business. SMS, voice call, push notification, and OTP code are NOT phishing-resistant.

Are passkeys the same as phishing-resistant MFA?

Yes — passkeys ARE phishing-resistant MFA. The passkey standard (FIDO2 / WebAuthn) is the underlying technology behind phishing-resistant authentication strength on Microsoft Entra. When Microsoft, CISA, or NIS2 use the term "phishing-resistant MFA", passkeys (and the equivalent hardware-key + Windows Hello for Business credentials) are exactly what they mean.

Does NIS2 require phishing-resistant MFA?

Yes, effectively. NIS2 Article 21 requires "multi-factor authentication or continuous authentication solutions" for entities in scope (essential and important entities across 18 sectors in the EU). National implementations and ENISA guidance interpret this as phishing-resistant MFA in practice — push and SMS-based MFA are increasingly excluded as they're considered defeated by current attack techniques. Verify with your jurisdiction's NIS2 transposition law for the exact wording.

Does Microsoft Entra support phishing-resistant MFA out of the box?

Yes. Microsoft Entra has a built-in "Phishing-resistant MFA" authentication strength option in Conditional Access. It's available on every paid Microsoft 365 plan that includes Entra (E3, E5, Business Premium, F1/F3 with Conditional Access add-on). The included credential types are FIDO2 passkeys, Microsoft Authenticator passkeys, FIDO2 security keys, Windows Hello for Business, and certificate-based authentication.

How long does it take to deploy phishing-resistant MFA across a 1,000-person company?

Realistic timeline is 8-12 weeks: 2 weeks policy + pilot, 6-8 weeks of waves, 1-2 weeks at the end to flip Conditional Access from report-only to enforced. Orgs that promise "two weeks" typically slip to four months because they skip the pilot and discover device-specific issues in production.

What's the difference between phishing-resistant MFA and "passwordless"?

Adjacent but not identical. Phishing-resistant means the credential resists AiTM proxies (a security property). Passwordless means the user doesn't type a password (a UX property). Most phishing-resistant credentials are passwordless (passkeys, Windows Hello, hardware keys), but you could in theory have a passwordless flow that ISN'T phishing-resistant (e.g. a magic-link via SMS). In practice the Microsoft 365 ecosystem treats the two as the same target state — every phishing-resistant credential it ships is also passwordless.

Can SMS or push MFA satisfy phishing-resistant requirements?

No. Both SMS and push notification MFA were defeated at scale by AiTM phishing proxies (Evilginx, EvilProxy, Tycoon, Caffeine, Storm-1167) throughout 2022-2025. CISA, NIST SP 800-63B, NSA, and Microsoft all explicitly classify them as NOT phishing-resistant. The Microsoft Entra "phishing-resistant authentication strength" filter intentionally excludes SMS and push so a Conditional Access policy requiring it cannot be satisfied by the legacy methods.

Do we need to buy hardware security keys for everyone?

No. Most users are well-served by software passkeys (Microsoft Authenticator, iCloud Keychain, Google Password Manager) which are phishing-resistant by the same FIDO2 / WebAuthn primitives. Hardware keys (YubiKey, Feitian) are typically reserved for: privileged accounts (Global Admin, Privileged Role Admin), regulated roles where attestation is mandatory, and users on devices that don't support platform passkeys (older Windows, Huawei post-2019).

Last updated 30 April 2026. Microsoft Entra's authentication-strengths feature and Authentication methods policy are stable across versions; the regulatory landscape (NIS2 transposition + DORA + revised NIST 800-63) continues to evolve through 2026. Verify the specific compliance citations against your jurisdiction's current text before quoting them in board-level materials.