# Passkeys and Phishing-Resistant MFA in Microsoft 365: Windows Hello for Business, FIDO2 Keys, Authenticator Passkeys and a Rollout Order for 20–500 Seats

> Windows Hello for Business, FIDO2 keys and Authenticator passkeys, the Conditional Access strength that enforces them, and a 20–500-seat rollout order.

Canonical: https://o365hq.com/blog/passkeys-phishing-resistant-mfa-microsoft-365-rollout-order
Provider: IT Partner LLC — US Microsoft partner since 2006. Book: https://o365hq.com/book

Published: 2026-09-14 · IT Partner

Most Microsoft 365 tenants we see already require MFA. Fewer require an MFA that a phishing kit cannot relay. Microsoft Entra ID treats Windows Hello for Business, FIDO2 security keys and Authenticator passkeys as one family of phishing-resistant credentials that Conditional Access can require by name. Here is how the pieces fit, and the order we roll them out in a 20–500-seat organization.

## Why an approved MFA prompt is no longer the finish line

A push notification or a text code proves the user holds a phone, not that the user is on the real Microsoft sign-in page. An attacker-in-the-middle site relays the password and the prompt and receives the session token; we walked through that path in [Why MFA Is Not Enough Anymore](/blog/why-mfa-is-not-enough-microsoft-365-attack-paths).

Phishing-resistant methods close it because, in Microsoft's definition, they require an interaction between the authentication method and the sign-in surface. A passkey is a key pair registered to one site; the private key never leaves the device and will not sign a challenge from a look-alike domain, so the credential cannot be reused, replayed or shared.

Two consequences shape the rollout: the credential is tied to hardware, so device readiness matters as much as policy, and users need a way to obtain their first credential without a password, which is what the Temporary Access Pass is for.

## The credentials Microsoft counts as phishing-resistant

Microsoft Entra ID's built-in Phishing-resistant MFA strength accepts Windows Hello for Business or a platform credential, a FIDO2 security key (which is what a passkey is underneath), and multifactor certificate-based authentication. In practice a small or mid-size organization works with four options.

- **Windows Hello for Business** is the local credential on a company PC: a PIN or biometric unlocks a key protected by the TPM, and biometric data stays on the device. Microsoft recommends Cloud Kerberos Trust for hybrid tenants, notes a limit of 10 users per device, and advises against it on shared kiosks.
- **FIDO2 security keys** are portable hardware, USB or NFC, unlocked by a PIN or biometric on every sign-in; a key can sign the user in to Windows as well as the browser. Microsoft recommends keys as the portable credential for admins and highly regulated users.
- **Passkeys in Microsoft Authenticator** are device-bound passkeys on the user's phone (Android 14 or iOS 17 or later). Signing in to a PC from the phone uses Bluetooth plus internet on both devices, and attestation can be enforced so only the genuine Authenticator app can register one.
- **Synced passkeys** in Apple, Google or third-party password managers are generally available in Microsoft Entra ID, and Microsoft recommends them as the portable credential for non-admin users.

Smart cards are also phishing-resistant, but Microsoft's guide says to use certificate-based authentication only if necessary, because it is harder to configure than passkeys. Passkeys themselves need no license in any Microsoft Entra ID edition; enforcing them through Conditional Access is what needs Entra ID P1.

## Authentication strengths: how Conditional Access enforces the method

An authentication strength is a Conditional Access grant control that lists which method combinations satisfy the policy. Microsoft ships three built-in strengths: Multifactor authentication (password plus push, code or token), Passwordless MFA (adds Authenticator phone sign-in) and Phishing-resistant MFA (only the combinations above). Microsoft's template list includes Require phishing-resistant multifactor authentication for administrators; our [Conditional Access policies every business should have](/blog/conditional-access-policies-every-business-should-have) shows where it sits.

Four details from Microsoft's documentation decide whether the policy works in production:

- Conditional Access needs Microsoft Entra ID P1, included in [Microsoft 365 Business Premium](/subscriptions/microsoft-365-business-premium) and the E3 and E5 suites; Business Basic and Standard seats need [Microsoft Entra ID P1](/subscriptions/microsoft-entra-id-p1) added.
- The policy is evaluated after the first authentication: a user can still type a password but must then present a phishing-resistant method before the session is granted.
- Require multifactor authentication and Require authentication strength cannot be combined in one policy, because the built-in Multifactor strength is the same thing as the MFA grant.
- A strength and a sign-in frequency can be satisfied at different times: a passkey sign-in yesterday plus a Windows Hello unlock today meets both, which is documented behavior worth explaining to an auditor.

Every new policy starts in report-only mode with emergency access accounts excluded (and, in hybrid tenants, the Directory Synchronization Accounts role). Our [Microsoft Entra ID Conditional Access Policy Implementation](/services/microsoft-entra-id-conditional-access-policy-implementation) service builds the set in that order; the [Conditional Access Policy Review and Break-Glass Validation](/services/conditional-access-policy-review-break-glass-validation) checks tenants that already have policies.

## A rollout order for a 20–500-seat organization

Microsoft's deployment guide is written for enterprises, but its structure scales down: personas, devices, a portable credential, a local credential, then enforcement per user-and-device pair. The sequence we use:

1. **Check device readiness.** Microsoft's minimums are Windows 10 22H2 for Windows Hello for Business (Windows 11 22H2 for passkeys), macOS 13, iOS 17 and Android 14; older devices can still use a FIDO2 key. On Intune-managed PCs the Windows Hello for Business policy is a profile, which is the scope of our [Password-less Authentication](/services/passwordless-authentication-windows-hello-intune) service.
2. **Turn on the methods.** Under Authentication methods, enable passkey profiles, one per persona: device-bound with attestation enforced for admins, device-bound or synced for everyone else. Enable the Temporary Access Pass policy; Microsoft's defaults are a one-hour lifetime and an eight-hour maximum, and a one-time pass must be used within 10 minutes of sign-in.
3. **Admins first.** Group every account with a directory role. Each admin registers a FIDO2 key, then Windows Hello for Business on their PC. Apply the Phishing-resistant strength to the group in report-only mode, then enforce; Microsoft's suggested order is Windows and iOS first, then macOS and Android.
4. **Information workers in waves.** Issue a Temporary Access Pass, have each user register a passkey in Authenticator (or a synced passkey, if the profile allows it), and let Windows Hello for Business enroll at next sign-in on managed PCs. Waves of 25 to 50 users keep help-desk load visible; Microsoft recommends watching ticket volume per wave.
5. **Enforce by platform group.** Microsoft's pattern is one policy per platform (Windows, macOS, iOS, Android and other), each targeting a group of users whose devices on that platform are ready and granting the Phishing-resistant MFA strength. Users join a group as their device pair is confirmed; at the end every user is in one.
6. **Frontline and shared devices.** Users with no permanent PC stay on portable credentials: FIDO2 keys registered on their behalf through the Graph API, or synced passkeys.

After enforcement, keep Entra ID Protection risk policies in place and consider token protection; attackers who cannot phish a credential move on to stealing tokens.

## What breaks in practice, and what to tell users

- **Platform gaps.** Microsoft's compatibility matrix: NFC and Bluetooth keys are not supported on macOS, Bluetooth keys are not supported on iOS or Android, new security-key registration does not work in iOS or macOS browsers, and Firefox on Android cannot sign in with a passkey. Register keys on a Windows PC.
- **Lost phone or key.** Recovery is a Temporary Access Pass issued after identity verification, not a password reset. Write that procedure before enforcement, and give every user two credentials where possible.
- **Biometric objections.** Windows Hello stores biometric templates only on the device, and Microsoft states they cannot be converted back into raw biometric data. Say so in the user communication.
- **Legacy authentication.** A strength does nothing for a protocol that never reaches Conditional Access. Block legacy authentication in the same project.

## Frequently asked questions

### Do we need Intune for Windows Hello for Business?

No. It can be configured through Intune or Group Policy. Intune makes it a profile on every enrolled PC, which is why our Password-less Authentication service assumes it; [Trusted Device and Phishing-Resistant Access](/services/trusted-device-and-phishing-resistant-access) covers tenants without Intune.

### Is a passkey in Microsoft Authenticator as strong as a hardware key?

Both are FIDO2 credentials and satisfy the Phishing-resistant MFA strength. Microsoft recommends hardware keys with attestation for admins and highly regulated users, and Authenticator or synced passkeys for everyone else.

### Do passkeys cost extra?

No; they are available in every Microsoft Entra ID edition. Conditional Access, which enforces them, needs Entra ID P1, and hardware keys are bought from any vendor on Microsoft's attestation-eligible list.

### Can users still type their password after we enforce phishing-resistant MFA?

They can type it, but it grants nothing until a passkey or Windows Hello for Business is presented; removing the password from the account is a separate step.

### What about guests and external users?

Strengths apply to external users too, but the methods your tenant accepts depend on where MFA is completed; Microsoft documents this separately. Keep guests in their own policy on the Multifactor strength.

## Sources

- Microsoft Learn: Conditional Access authentication strengths; Require multifactor authentication for all users; Conditional Access templates
- Microsoft Learn: How to enable passkeys (FIDO2) in Microsoft Entra ID; Enable passkeys in Authenticator; Passkey (FIDO2) authentication matrix; Microsoft Entra ID attestation for passkey (FIDO2) vendors
- Microsoft Learn: Get started with, Plan, and Considerations for specific personas in a phishing-resistant passwordless authentication deployment in Microsoft Entra ID
- Microsoft Learn: Configure Temporary Access Pass to register passwordless authentication methods
- IT Partner: Trusted Device and Phishing-Resistant Access service page

The Windows-side Windows Hello for Business documentation was not consulted.

| Credential | Portable or local | Meets Phishing-resistant MFA strength? | Microsoft's recommended persona | License to register |
|---|---|---|---|---|
| Windows Hello for Business | Local, per PC | Yes | Local credential for admins and information workers | None; Entra ID P1 to enforce |
| FIDO2 security key | Portable | Yes | Admins and highly regulated users; frontline | None; hardware purchase |
| Passkey in Microsoft Authenticator | Portable, device-bound | Yes | Alternative for any persona | None |
| Synced passkey (Apple, Google or third-party manager) | Portable | Yes | Information and frontline workers | None |
| Authenticator push, SMS or voice | Not applicable | No; Multifactor strength only | None | None |

## Key takeaways

- Phishing-resistant means the credential is bound to the sign-in surface: Windows Hello for Business, FIDO2 keys, Authenticator passkeys, synced passkeys and multifactor certificates qualify; push and SMS do not.
- Passkeys need no extra license in any Entra ID edition; enforcing them needs Entra ID P1 (included in Business Premium, E3 and E5) through a Conditional Access authentication strength.
- Roll out by persona and device pair: admins with hardware keys first, information workers with Authenticator or synced passkeys plus Windows Hello for Business, frontline users on portable credentials.
- Bootstrap with a Temporary Access Pass, not a password, and write the lost-credential procedure before enforcement.
- Start every policy in report-only with break-glass accounts excluded, and block legacy authentication in the same project.

---

On Intune-managed Windows PCs, our [Password-less Authentication](/services/passwordless-authentication-windows-hello-intune) service configures Windows Hello for Business through Intune profiles at a fixed price, and the [Microsoft Entra ID Conditional Access Policy Implementation](/services/microsoft-entra-id-conditional-access-policy-implementation) service builds the authentication-strength policies, report-only first, with break-glass accounts validated. Seats on Business Basic or Business Standard need [Microsoft Entra ID P1](/subscriptions/microsoft-entra-id-p1) for Conditional Access, sold at Microsoft's list price. Without Intune, [Trusted Device and Phishing-Resistant Access](/services/trusted-device-and-phishing-resistant-access) covers the same ground with a device filter.