Deploy passkeys in Entra ID: Authenticator, Windows Hello and FIDO2 keys

To deploy passkeys in Microsoft Entra ID, opt in to passkey profiles on the Passkey (FIDO2) authentication method, create profiles per user group (device-bound with attestation for admins, synced or Authenticator passkeys for everyone else), and target them at groups. Then bootstrap users with their existing MFA or a Temporary Access Pass, add Windows Hello for Business as the local credential on PCs, drive registration with a passkey registration campaign, and finally enforce the built-in Phishing-resistant MFA authentication strength with Conditional Access, starting in report-only mode.

Who this is for and what you will have at the end

This guide is for identity administrators moving users from passwords, SMS codes and push approvals to phishing-resistant sign-in. It is especially relevant if you have users on SMS or voice MFA, which Microsoft retires in 2027 (see the SMS and voice MFA retirement guide).

At the end you will have:

• Passkey profiles that give admins and regular users different, appropriate rules.
• Passkeys in Microsoft Authenticator, FIDO2 security keys and synced passkeys enabled where they fit.
• A bootstrap path for new and existing users, including people with no MFA at all.
• Windows Hello for Business or Microsoft Entra passkey on Windows as the everyday local credential.
• A registration campaign and a staged Conditional Access enforcement plan.

Which passkey goes where

Microsoft separates credentials into portable ones, usable across devices, and local ones, tied to the device you sit at. Most users should have at least one portable credential and a local credential on each computer, and at least two methods in total so losing one device isn't a lockout.

Microsoft's persona recommendations:

Treat synced passkeys as phishing-resistant but with the same assurance as any other unattested authenticator.

Prerequisites

• Authentication Policy Administrator to configure methods, profiles and the registration campaign; Conditional Access Administrator for enforcement policies; Authentication Administrator to issue Temporary Access Passes to non-admins.
• No additional licence for passkeys. Conditional Access enforcement needs Microsoft Entra ID P1.
• Supported operating systems. Microsoft lists Windows 10 22H2 (for Windows Hello for Business), Windows 11 22H2, macOS 13, iOS 17 and Android 14 as minimums for native support; older devices need security keys.
• For Entra joined Windows devices, the best passkey experience is on Windows 10 1903 or later; hybrid joined devices need Windows 10 2004 or later.
• For cross-device registration with a phone, Bluetooth and internet on both devices, and network access to cable.ua5v.com (Android) and cable.auth.com, app-site-association.cdn-apple.com and app-site-association.networking.apple (iOS).
• If one profile allows both device-bound and synced passkeys and targets Microsoft Authenticator, users need Authenticator for iOS 6.8.37 or Android 6.2507.4749 or later.

Users must have completed MFA within the previous five minutes to register a passkey. Guest users can't register passkeys yet.

Step 1: Opt in to passkey profiles

Passkey profiles replace the single tenant-wide FIDO2 configuration with group-based rules.

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
2. Go to Entra ID > Security > Authentication methods > Policies and select Passkey (FIDO2).
3. Select the link in the banner to opt in to passkey profiles. This can't be undone. Your existing settings move into a Default passkey profile.
4. On Configure, set Allow self-service set up to Yes. This setting is global; with No, users can't register passkeys in Security info even when the method is enabled.
5. Open the Default passkey profile, choose the Passkey types to allow, and save.

You can have up to three profiles, including the default, and the whole Passkey (FIDO2) policy is limited to 20 KB.

Step 2: Design your profiles

Each profile has three controls: Enforce attestation, Passkey types (device-bound, synced or both) and key restrictions that allow or block specific authenticators by AAGUID. A practical three-profile design:

For the Authenticator profile, select + Add passkey profile, choose Device-bound, select Target specific AAGUIDs, set Behavior to Allow, then + Add AAGUID > Microsoft Authenticator. The Authenticator AAGUIDs are 90a3ccdf-635c-4729-a248-9b709135078f (iOS) and de1e552d-db1d-4423-a619-566b625cdc84 (Android).

Know the trade-offs before you save:

• Attestation lets Entra ID verify the make and model at registration. Without it, Entra ID can't guarantee anything about a passkey, including whether it is synced or device-bound. Synced passkeys don't support attestation, so an attested profile blocks them.
• Attestation and cross-device registration don't mix. Attested Authenticator passkeys must be registered directly in the Authenticator app.
• Attestation applies only at registration. Turning it on later doesn't block passkeys already registered without it.
• Key restrictions apply to sign-in too. Remove a previously allowed AAGUID and users who registered that authenticator can no longer sign in with it.

Step 3: Target profiles at groups

On Enable and target, make sure Enable is On, select Add target, pick the group (or All users) and assign the profile. When a user is in several profiles, a passkey is accepted if it fully satisfies at least one of them. A user in an excluded group is blocked from passkey registration and sign-in entirely, and exclusion wins over inclusion.

Consolidate targeting into a few groups. Registration can fail when a method or campaign targets many groups.

Step 4: Bootstrap users

Existing users with MFA can register directly. New users, and anyone without a usable method, need a Temporary Access Pass (TAP).

Enable and issue a Temporary Access Pass

Enable Temporary Access Pass under Authentication methods > Policies and target the groups that need it. The defaults:

Issue a pass from Users > the user > Authentication methods > Add authentication method > Temporary Access Pass, or with PowerShell:

$properties = @{}
$properties.isUsableOnce = $true
$propertiesJSON = $properties | ConvertTo-Json
 
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId adele@contoso.com -BodyParameter $propertiesJSON

Copy the pass when it's shown; you can't view it again. With a one-time pass, registration must finish within 10 minutes of sign-in. Privileged Authentication Administrators can issue passes to admins; Authentication Administrators only to non-admin members.

Register the first portable credential

• Security key or synced passkey: the user opens https://mysignins.microsoft.com/security-info, signs in with MFA or the TAP, selects Add sign-in method > Choose a method > Passkey > Next, and chooses where to save it. Use another device or More options shows security keys and phones.
• Authenticator passkey: the user adds their work or school account in Microsoft Authenticator, signs in with MFA or the TAP, and creates the passkey in the app. With attestation enforced, this in-app path is the only one that works.

Admins can also provision FIDO2 security keys on behalf of users through Microsoft Graph; that capability is in preview.

Step 5: Add Windows Hello for Business and local credentials

Once users have a portable credential, use it to set up a local one on each PC.

• Windows Hello for Business: Microsoft recommends the cloud Kerberos trust deployment model, which covers synced users on Entra joined and hybrid joined PCs. It supports up to 10 users per device and shouldn't be used on kiosks with a shared account. During Entra join, users can authenticate with a TAP and register Windows Hello in the same flow. On already-joined and hybrid joined devices, users must first sign in with another method, such as a password or security key, before using a TAP to set up Windows Hello.
• Microsoft Entra passkey on Windows: uses the Windows Hello gesture, works on devices that aren't Entra joined or registered, and supports several Entra accounts on one device, each with its own passkey. It doesn't sync across devices.
• Shared devices: use Entra passkey on Windows or a portable credential such as a security key.

Step 6: Drive registration with a campaign

Go to Entra ID > Authentication methods > Registration campaign, select Edit, and set State:

• Microsoft managed: Microsoft picks passkeys for passkey-enabled users, with one-day snooze and unlimited snoozes. Users are nudged only if they're in at least one eligible passkey profile.
• Enabled: you choose Passkey, set Days allowed to snooze (0 to 14) and Limited number of snoozes. With limited snoozes, users can skip three times and must then register.

Users are nudged after an interactive MFA sign-in, and only if they don't already have a suitable passkey for their current OS and browser. For example, a Windows Hello credential suppresses the nudge on Windows but not on a Mac. Linux users and guests aren't nudged, and neither are users signing in with SSO. A Conditional Access policy that blocks Register security information in the user's location also suppresses the nudge.

Step 7: Enforce phishing-resistant MFA

Create the measurement policy first, ideally before the campaign starts:

The sign-in logs then show who would have been blocked. Microsoft's Phishing-Resistant Passwordless Deployment (Preview) workbook, available if you send sign-in logs to Azure Monitor, turns that into per-platform lists of users ready for enforcement.

Enforce by user and device pair, using a group per platform:

A typical order is admins on Windows and iOS, then admins on macOS and Android, then everyone else. When every user is in a group, switch the report-only policy on and retire the per-platform policies. Keep emergency access accounts excluded; they should have their own FIDO2 keys.

To require a specific key model for a sensitive app, create a custom strength under Entra ID > Authentication methods > Authentication strengths > New authentication strength, select Passkeys (FIDO2), and add AAGUIDs under Advanced options.

For how this fits a wider access model, see the Zero Trust remote access architecture.

Verify

• Authentication methods > Activity > Registration: Users capable of passwordless authentication rises as users register FIDO2 passkeys, Windows Hello for Business or passwordless phone sign-in.
• The Usage tab shows sign-ins by method; phone and push methods should decline.
• In the sign-in logs, select a sign-in and open Authentication Details to see which method satisfied MFA.
• The report-only policy's results show how many sign-ins would still fail.

Troubleshooting

Users can't see Passkey in Security info. Allow self-service set up is No, the user isn't targeted by the Passkey (FIDO2) policy, or they're in an excluded group.

Synced passkey registration is rejected. The user's only profile enforces attestation or allows device-bound passkeys only. Add them to a profile that allows Synced.

Registration loops in Authenticator. A policy requiring phishing-resistant MFA for All resources applies to Authenticator too, so users need a passkey to register a passkey. Target specific apps with application filters, or split mobile and desktop policies and allow a TAP on mobile.

Authenticator can't register under app protection policies. Grant controls Require approved client app or Require app protection policy for all resources block Authenticator, which doesn't support them. Use Require device to be marked as compliant as an alternative, scope the policy to specific apps, or grant a time-limited exemption.

Android users can't find their passkey. Android uses passkeys only from the profile where they're stored. Users with Work and Personal profiles need a passkey in each.

Attested Authenticator registration fails intermittently. Attestation depends on Apple App Attest and Google Play Integrity; heavy load or outages there can fail registration. Retry later.

A user's UPN changed. Passkeys can't be updated for the new UPN. The user deletes the old passkey in Security info and registers a new one.

Temporary Access Pass sign in was blocked due to User Credential Policy. The user isn't in TAP scope, a one-time pass was already used, or a multi-use pass was issued while the policy requires one-time use.

Checklist

• Passkey profiles enabled; Allow self-service set up on.
• Separate profiles for admins (device-bound, attested) and general users (synced allowed).
• Authenticator AAGUIDs allowed where Authenticator passkeys are wanted.
• Temporary Access Pass enabled for onboarding and recovery.
• Windows Hello for Business (cloud Kerberos trust) or Entra passkey on Windows as local credentials.
• Registration campaign targeting passkeys for the rollout groups.
• Report-only Phishing-resistant MFA policy in place before enforcement.
• Per-platform enforcement groups and policies, with emergency access accounts excluded.
• Every user with at least two methods.

Passkeys are also the strongest item in a Microsoft 365 tenant security baseline.

References

• Enable passkeys (FIDO2) in Microsoft Entra ID
• Enable and support passkeys in Authenticator
• Plan a phishing-resistant passwordless authentication deployment
• Register a passkey with a FIDO2 security key
• Configure a Temporary Access Pass
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Authentication methods activity
• Manage authentication methods
• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• FAQ for Microsoft-provided SMS and voice retirement