Phishing-resistant MFA in Microsoft 365: moving users to passkeys, FIDO2 and Windows Hello

Any MFA is far better than none. But attackers have adapted: phishing kits now sit between the user and the real Microsoft sign-in page, pass the password and the MFA response through in real time, and steal the session cookie that comes back. Codes, SMS and push approvals can all be relayed this way.

Phishing-resistant methods defeat that pattern because the credential is cryptographically tied to the genuine sign-in domain. A look-alike site can't obtain a response that works on the real one. Microsoft's passkeys (FIDO2) overview describes each method.

The phishing-resistant methods

Microsoft is steadily expanding passkey support, including which passkey providers are allowed. Check enable passkeys (FIDO2) in Microsoft Entra ID for the options available to your tenant today.

Step 1: Prepare the tenant

1. Use the Authentication methods policy. Enable Passkey (FIDO2) and, if you'll use them, certificate-based authentication, targeted to a pilot group at first. See manage authentication methods.

2. Decide on key restrictions. The passkey settings let you allow only specific authenticator models (by AAGUID) and enforce attestation. Restricting to the keys and apps you issue avoids surprises.

3. Enable Temporary Access Pass. A Temporary Access Pass is a time-limited passcode an admin issues so someone can register a new method without an existing one. It's essential for new starters and lost devices.

4. Protect registration. A Conditional Access policy on the Register security information action stops an attacker with a password from registering their own method.

5. Check prerequisites. Supported OS and browser versions, Windows Hello for Business configuration in Intune, and a stock of security keys if you're buying them.

Step 2: Roll out in waves

Wave 1: administrators

Admins first, because they're the highest-value targets and the easiest group to support. Register at least one phishing-resistant method per admin (two is better, for example Windows Hello plus a security key), then enforce with Conditional Access using the built-in Phishing-resistant MFA authentication strength for directory roles. Remember your emergency access accounts; see Entra ID privileged access.

Wave 2: high-risk groups

People who approve payments, handle payroll, hold executive mailboxes or manage customer data. Business email compromise targets these roles, so they benefit most.

Wave 3: everyone

Use a registration campaign to prompt users at sign-in, publish a short guide with screenshots from your own tenant, and staff the help desk for the first weeks. Enforce per group once registration numbers are high.

Step 3: Enforce with authentication strengths

Authentication strengths let a Conditional Access policy require specific methods rather than "any MFA":

• Admins: Phishing-resistant MFA, for all resources.
• Everyone else, during the transition: Multifactor authentication (any method), switching group by group to Phishing-resistant MFA as registration completes.
• Sensitive apps: an authentication context that requires phishing-resistant MFA, even for users not yet fully migrated.

Run each change in report-only mode first and look for users who would be blocked because they haven't registered a qualifying method.

Step 4: Retire the weakest methods

When most users have a stronger method, reduce reliance on SMS and voice. Remove them from the Authentication methods policy for groups that have migrated, and keep a documented exception path for the few people who genuinely can't use anything else. Enable system-preferred MFA so Entra ID prompts for the strongest method a user has registered.

Plan for recovery

• Lost phone or key: verify identity out of band (a manager, a video call, an ID check), issue a Temporary Access Pass, and have the user register a new method. Remove the lost method.
• Two methods per person where possible, so one loss isn't an outage.
• Help desk scripts that never reset MFA on a phone call alone. Social engineering of the help desk is a common way around strong MFA.

Measuring progress

Track the percentage of users, and separately of admins, with at least one phishing-resistant method registered, using Authentication methods › User registration details or the methods activity report. Report the admin number to leadership every month until it reaches 100%.

Common issues during rollout

• Shared PCs and kiosks: Windows Hello for Business is per user per device, so security keys often suit shared machines better.
• Unmanaged personal devices: passkeys in Microsoft Authenticator work without enrolling the phone in Intune.
• Legacy apps and protocols: anything using basic authentication can't use any MFA at all; block it first. See blocking legacy authentication.
• Guests: guest users authenticate with their home organization. Cross-tenant access settings can trust a partner's MFA claims.

Communicating the change

People accept a new sign-in method more easily when they understand why and know exactly what to do. A short message before each wave should cover:

• Why: phishing sites can now steal codes and approvals in real time; the new method can't be phished that way.
• What changes for them: for most people, signing in with a fingerprint, face or PIN instead of approving a notification.
• When: the date registration opens and the date it becomes required.
• How: a one-page guide with screenshots, and a drop-in session or help-desk slot.
• What to do if they lose a device: who to contact, and that the help desk will verify their identity before helping.

Common questions

Is number matching in Microsoft Authenticator enough?

Number matching makes accidental approvals much less likely, but a real-time phishing proxy can still relay the sign-in. It's a big improvement over simple approvals, not a phishing-resistant method.

Do we need to buy security keys for everyone?

Usually not. Windows Hello for Business and passkeys in Microsoft Authenticator cover most users without new hardware. Keys are most useful for admins, shared devices and people without a suitable phone.

Can guests be required to use phishing-resistant MFA?

Guests register methods in their home tenant. With cross-tenant access settings you can trust their organization's MFA, and authentication strengths can then require specific methods; check Microsoft's documentation on authentication strengths for external users.

A realistic timeline

For a small or mid-size tenant, admins can usually be moved within two weeks, high-risk groups within a month, and everyone else over one or two quarters, depending on device readiness and how much hands-on help people need. Publish the dates, track registration weekly, and don't enforce for a group until nearly everyone in it has registered.

How M365Assessments helps

M365Assessments reads MFA registration details, the Authentication methods policy and Conditional Access authentication strengths with read-only permissions. The report shows MFA coverage for users and admins and flags administrators without MFA, so you can track the rollout run by run. See what we assess.