Guide: configuring passkeys in Microsoft Entra ID

Before you start

This guide covers the full configuration of passkeys in Microsoft Entra ID, from an empty policy to verifying the rollout. Three concepts are worth settling first, because everything below assumes them.

Device-bound versus synced passkeys

A device-bound passkey creates the private key inside one physical device and never lets it leave: a FIDO2 security key, or Microsoft Authenticator on a phone. Lose the device and you lose the credential.

A synced passkey is encrypted on the device and synced to a cloud provider, so it is available on every machine where the user has signed in to that provider. That's what iCloud Keychain, Google Password Manager, Dashlane, 1Password and Bitwarden do.

The practical difference is one of guarantees: synced passkeys don't support attestation, so Entra ID can't verify which vendor they came from or whether they're hardware-backed. Microsoft treats them as phishing-resistant, but with the same security posture as any unattested authenticator. This drives all of step 6.

What an AAGUID is

The AAGUID (Authenticator Attestation GUID) is a 128-bit identifier that each vendor supplies during registration to declare the make and model of the authenticator. It is the only mechanism you have for saying "in this organisation, only these keys and these managers are acceptable".

With attestation on, the AAGUID is a verified claim. With attestation off, it is a value the authenticator asserts and nobody checks: a policy guide, not a security control. Microsoft says so explicitly, and it is the most common trap in the whole rollout.

What this guide doesn't cover

• Windows Hello for Business, configured separately even though it is also a phishing-resistant credential.
• Admin provisioning of security keys through Microsoft Graph, still in preview.
• Guest users: Entra ID doesn't support passkey registration for guests, internal or B2B, in the resource tenant. If your scenario is external collaboration, this route isn't available yet.

Step 1. Enable passkey profiles

Until 2025 the FIDO2 policy was a single global block: one attestation setting and one AAGUID list for the whole tenant. Passkey profiles replace that with per-group rules, which is what lets you treat administrators differently from everyone else.

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
2. Browse to Entra ID › Security › Authentication methods › Policies.
3. Select Passkey (FIDO2).
4. In the banner at the top of the blade, select the link to opt in to passkey profiles.

Two limits worth knowing before you design anything:

• Up to 10 profiles are supported, including the default one. The portal states this on the Configure tab itself; the documentation still says three, so trust what's on screen.
• The passkey policy has a 20 KB size limit. For reference: the base policy is 1.44 KB, a profile with no AAGUIDs about 0.4 KB, and a profile with ten AAGUIDs about 0.3 KB. Only tenants with very long AAGUID lists get near the ceiling.

Step 2. Configure the default profile

Stay in Passkey (FIDO2), on the Configure tab.

1. Set Allow self-service set up to Yes. If you leave it at No, users can't register a passkey from Security info even when the method is enabled. This setting is global: it doesn't live inside the profile.
2. Open the Default passkey profile. It can't be deleted or renamed: the name field is greyed out.
3. Under Passkey types, select the types you want to allow: Device-bound, Synced, or both.
4. Save.

Step 3. Create additional profiles

From the same Configure tab, select + Add passkey profile. Each profile involves four decisions.

The dialog itself carries a warning worth reading slowly: certain combinations of these settings can target passkeys that don't exist, and then users can neither register nor sign in. A Synced profile with attestation enforced is exactly that case. When a combination looks suspect, the portal flags the profile with a warning triangle in the list.

A profile design that works

This split covers most organisations with three profiles, and leaves plenty of room within the limit of ten:

The underlying logic: the higher the privilege, the narrower the list of acceptable authenticators. For accounts that administer the tenant, a synced passkey in a commercial manager isn't where you want the credential to live.

Step 4. Enable and target

A profile does nothing until you assign it to someone. Go to the Enable and target tab.

1. Check that Enable is On.
2. Select Add target and choose All users or Select targets for specific groups.
3. Select the profiles you want to apply to that target.
4. Save.

Step 5. Passkeys in Microsoft Authenticator

Authenticator stores device-bound passkeys, and it's the sensible default for staff with a corporate phone: no hardware to buy and no third-party manager to procure.

1. On Configure, add a profile and name it something like Authenticator passkeys.
2. Decide whether to enforce attestation (there's an important caveat below).
3. Under Passkey types, select Device-bound.
4. Turn on AAGUID restrictions and set the behaviour to Allow.
5. Select + Add AAGUID and pick Microsoft Authenticator from the list, or enter the identifiers manually.

How the user registers it

There are two routes, and it's worth deciding which one you communicate so they don't get mixed up.

From the browser. In Security info, Add sign-in method and then Passkey in Microsoft Authenticator. The wizard restates the requirements — Android 14 or iOS 17 minimum, app up to date — and offers a link to add the account first if it isn't there yet.

From the app itself. Open the account in Authenticator and, under Other ways to sign in, tap Create a passkey. This is the mandatory route when you enforce attestation, because cross-device registration isn't available then.

When it finishes, the app confirms and names the passkey after the device, along the lines of Authenticator - iOS. That same screen carries a warning worth heeding: Authenticator has to be switched on as a system passkey provider. Without that, the passkey exists but the system never offers it at sign-in, and the user concludes registration failed.

Version requirements: Android 14 or later, iOS 17 or later. If a profile allowing both passkey types targets Authenticator, users also need Authenticator iOS 6.8.37 or Android 6.2507.4749 as a minimum.

Cross-device registration needs Bluetooth and an internet connection on both devices, plus access to cable.ua5v.com on Android or cable.auth.com and app-site-association.cdn-apple.com on iOS. Organisations that block Bluetooth can permit pairing exclusively with FIDO2 authenticators.

Step 6. Registering third-party managers such as Dashlane

This is the section that generates the most questions, because three layers have to line up: the Entra policy, the operating system or browser, and the manager's own app.

6.1. Configure the profile in Entra ID

Dashlane, 1Password and Bitwarden store synced passkeys. Two rules follow from that, with no exceptions:

• The profile must include Synced in the passkey types.
• Enforce attestation must be No. Synced passkeys don't support attestation: with it on, registration always fails, and the message the user sees doesn't explain why.

To allow one specific manager and only that one, turn on key restrictions, set the behaviour to Allow and add its AAGUID:

Password managers and platform providers are the easy case: each declares one AAGUID and it stays put. Physical security keys are considerably messier, and it pays to know that before building a list.

For physical keys there are three sensible ways to build the list, from most to least convenient:

1. The portal's own picker. Inside the profile, + Add AAGUID offers the providers Microsoft already knows about. Check there first.
2. Register one unit of each model you buy. Register it on a test account and read the identifier in Security info or on the user's authentication methods. Tedious, but exact, and it reflects your actual fleet rather than the global catalogue.
3. The FIDO Alliance metadata service. It publishes the full catalogue with the AAGUID and description of every certified authenticator. It's the source the other lists draw from, and the one to cite if anyone disputes an identifier.

One procurement tip: ask the vendor for the AAGUID list of the models they are selling you, in writing, before signing. They hand it over without fuss and it saves discovering it key by key.

The identifiers above come from the community AAGUID list and Microsoft's documentation, verified in August 2026. Vendors can add new ones over time, so they are worth rechecking whenever a new provider enters the organisation.

6.2. Enable the manager in the OS or browser

This is where most trials stall. Even with a correct Entra policy, the manager won't appear as an option when creating the passkey unless the operating system or browser has it registered as a passkey provider. This is a step the user takes on their machine, not one the administrator takes in the portal.

6.3. User registration

With the policy and the provider ready, the user does this:

1. Go to Security info.
2. Select Add sign-in method.
3. Choose Passkey, the option described as "Sign in with your face, fingerprint, PIN or security key".
4. Complete multifactor authentication. This is mandatory: MFA must have been completed within the past five minutes to register a passkey.
5. Microsoft shows Setting up your passkey… and hands over to the system. Dashlane then appears with its own window asking to create a new passkey for the account. Select Confirm there.
6. Return to the Microsoft wizard, select Next and give the passkey a recognisable name.

6.4. Confirm it registered correctly

The Security info page doubles as the check, and this is the part worth showing users so they can tell what they actually have:

• The entry reads Passkey (Synced) with the provider name underneath: Dashlane. If it said device-bound, you'd be looking at something else.
• Expanding the row with the arrow on the right reveals the passkey's AAGUID. That settles which provider stored it: if it starts with 531126d6, it's Dashlane.

That visible AAGUID is also the quickest way to obtain the identifier for any new provider: register a passkey on a test account, expand the row and copy the value.

6.5. What sign-in looks like

Worth knowing this screen, because it's the one that generates service desk questions. Microsoft shows its Face, fingerprint, PIN or security key dialog and, on top of it, Dashlane opens its own prompt with the account and a confirm button. The user confirms in Dashlane and the session continues.

Step 7. Temporary Access Pass for bootstrapping

There's a chicken-and-egg problem left: registering a passkey requires passing MFA, and a user without a strong method yet can't do that. The Temporary Access Pass (TAP) solves the bootstrap, and the recovery case when someone loses their phone.

1. Go to Entra ID › Authentication methods › Policies and select Temporary Access Pass.
2. Enable it and choose which users or groups it applies to.
3. Under Configure, adjust lifetime and format if needed.

To issue one: Entra ID › Users, the user, Authentication methods, Add authentication method, Temporary Access Pass. The code is shown once only, so copy it before closing the dialog.

Each user can hold only one active pass, and a new one replaces the old. In federated domains the pass takes precedence over federation: the user completes authentication in Entra ID and isn't redirected to their identity provider.

Step 8. Registration campaign

The registration campaign nudges users to register a passkey right after they complete MFA, so they don't have to go looking for where it's done. It needs no paid licence, but it does require MFA to be Microsoft Entra MFA.

1. Go to Entra ID › Authentication methods › Registration campaign and select Edit.
2. Under State, choose Enabled to control the settings yourself, or Microsoft managed to accept the recommended defaults.
3. Under Authentication method, select Passkey.
4. Set Days allowed to snooze (0 to 14) and Limited number of snoozes.
5. Include or exclude the relevant groups and save.

With Limited number of snoozes enabled, a user can postpone three times and registration is required on the fourth. Disabled, they can snooze indefinitely — which in practice means part of the workforce never will. The snooze count is tracked per user and survives campaign configuration changes.

A campaign can only target one method at a time: Authenticator or passkeys, never both in the same tenant.

Another detail that confuses testing: the nudge is evaluated per device-and-browser combination, not per account. A user with Windows Hello for Business isn't nudged on Windows, but is when signing in from a Mac with Chrome, because that credential doesn't apply on that platform. On Linux there's no nudge at all, because FIDO2 passkeys aren't available there.

Step 9. Requiring passkeys with Conditional Access

Enabling the method permits it; requiring it is a different job, and it's the part that needs Entra ID P1.

1. Go to Entra ID › Authentication methods › Authentication strengths as a Conditional Access Administrator.
2. Select New authentication strength and name it.
3. Tick Passkeys (FIDO2).
4. To restrict it to a specific model, go to Advanced options › Add AAGUID and enter the identifier.
5. Review and save, then reference that strength from the grant control of a Conditional Access policy.

Same caution with Require approved client app and Require app protection policy: Authenticator doesn't support those controls on iOS or Android, so affected users can't register passkeys. And in every case, users must also satisfy any policy targeting Register security information, or registration won't complete.

Step 10. Verify the rollout

Three checks, from broadest to narrowest.

Activity report

Entra ID › Authentication methods › Activity, with two tabs: Registration and Usage. The first tells you how many users are capable of passwordless authentication and which methods they have registered; the second, what's actually being used to sign in. It requires Entra ID P1 or P2 and a role with report-reading permissions.

Two limits: data lags by up to 36 hours, and disabled or soft-deleted users don't appear.

Per-user check

Entra ID › Users, the user, Authentication methods. Each registered passkey is listed with its details, including the AAGUID — which is how you confirm whether someone registered with the intended provider. To remove a credential, right-click the method and select Delete.

Sign-in test

With a test account in each profile: register an allowed passkey, register one the policy should reject, and sign in with the allowed one. If the second case doesn't fail, the policy isn't doing what you think it is.

Limitations and known issues

The order I recommend

For a production rollout, this sequence generates the fewest incidents:

This guide connects directly with the retirement of SMS and voice call in Entra ID: from 1 February 2027, anyone whose only MFA method is SMS or voice hits a blocking prompt to register a passkey. Everything above is what needs to be in place before that date.

If any step doesn't behave as described, write to me and I'll review it. Guides age better when they get corrected.

To connect these controls with identities, applications, data and exceptions, read the Microsoft 365 security assessment guide. It explains which evidence to review and how to prioritise improvements.