Entra passkeys on Windows: profiles, AAGUIDs and rollout

What changed

MC1282568 announces general availability of Microsoft Entra passkeys on Windows. The mirror of the post lists these dates:

• Worldwide and GCC: late April 2026 as the rollout start, mid-June 2026 as the expected finish.
• GCC High and DoD: early October 2026 as the start, late October 2026 as the expected finish. These sovereign dates come only from the mirror page, so confirm them against the original post in your tenant’s Message Center.
• The mirror also shows the post as published 16 April 2026, last updated 20 July 2026, and expiring 30 November 2026.

Check where your tenant stands in its own Message Center and sign-in logs. Don’t infer it from these dates.

Per Learn, the feature registers FIDO2 passkeys in the local Windows Hello container. The device does not need to be Entra joined or registered. These passkeys are governed by Entra passkey (FIDO2) policies and passkey profiles.

The post also says:

• Each Windows device needs its own registration for each Entra account. The passkey is device-bound and not synced.
• Attestation is not currently supported for Entra passkeys on Windows but is planned for a future update.

Who is affected

The Message Center post says most organisations need no action. The scope it describes is tenants with passkeys enabled in the Authentication methods policy, where users sign in from Windows devices. That covers corporate, personal and shared PCs.

Learn lists these limits:

• Guest users, including B2B collaboration users, can’t register passkeys (FIDO2).
• If a user’s UPN changes, delete the old passkey and add a new one.
• Entra passkey on Windows does not support device sign-in.
• It does not replace Windows Hello for Business. Learn still recommends WHfB for corporate managed, Entra joined or registered devices.

The AAGUID question

This is the part to read twice. The two sources disagree.

• MC1282568 says passkey profiles that allow device-bound, non-attested passkeys let in-scope users register without extra admin configuration. To stop Windows registration or use, it says to add the Windows Hello AAGUIDs to the block list in the relevant profiles.
• Learn says these AAGUIDs must be explicitly allowed in a passkey profile to enable registration.

Microsoft’s own wording is inconsistent here. Neither source says which one applies to a profile with key restrictions off, or to the Default profile. Don’t treat either as settled. Test with a pilot user, and confirm in your tenant’s Message Center.

The three Windows Hello AAGUIDs listed by Learn:

Authenticator	AAGUID
Windows Hello Hardware	08987058-cadc-4b81-b6e1-30de50dcbe96
Windows Hello VBS Hardware	9ddd1817-af5a-4672-a2b9-3e3dd95000a9
Windows Hello Software	6028b017-b1d4-4c02-b4b3-afcdafc96bb2

Why it matters

• Key restrictions apply to sign-in as well as registration. Learn says that removing a previously allowed AAGUID stops users who registered with it from signing in with it.
• Profiles are a one-way door. Learn says passkey profiles are opt-in and, once you opt in, you can’t opt out. Opting in moves the global settings into a Default passkey profile. Up to three profiles, including Default, are supported.
• Exclusions are blunt. Learn says membership of an excluded group blocks passkey registration and sign-in entirely, and takes precedence over any included group.
• Overlap with Windows Hello for Business. Learn says registration fails if a WHfB credential exists for the same account and container. The Learn FAQ adds that the block might not apply once a user exceeds 50 total platform credentials. Learn does not say whether the block applies to personal or shared devices that aren’t joined.
• Licensing. Learn says passkeys (FIDO2) are available in all Entra ID editions, including Free, with no extra licence. Enforcing them through Conditional Access authentication strength needs Entra ID P1.

Runbook

1. Confirm prerequisites

   Learn lists these:

   • An account with at least Authentication Policy Administrator.
   • Passkey (FIDO2) enabled in the Authentication methods policy.
   • Windows 10 or 11, on a device that supports Windows Hello.
   • The global setting Allow self-service set up at Yes. At No, users can’t register a passkey in Security info. It is a global setting, not a per-profile one.

   The sources give no browser requirements and no Windows version detail beyond “Windows 10 or 11”. Confirm those on your pilot devices.

2. Record the current state

   In the Entra admin center, go to Entra ID > Authentication methods > Policies > Passkey (FIDO2). Note whether passkey profiles are enabled, which profiles exist (the limit is three including Default), who is targeted, and whether key restrictions are on. Take a screenshot for the change record.

3. Create a Windows profile

   Per Learn, go to Entra ID > Authentication methods > Policies > Passkey (FIDO2) > Configure > + Add profile, then:

   1. Set Passkey types to Device-bound.
   2. Select Target specific AAGUIDs and set Behavior to Allow.
   3. Select + Add AAGUID, choose Windows Hello, and Save.

   The profile can’t Enforce attestation. For a hardware-only (higher assurance) profile, Learn says to allow only the Hardware and VBS Hardware AAGUIDs. Software-only registrations are then blocked.

   Remember that adding profiles depends on opting in, and Learn says the opt-in can’t be reversed. Agree that internally first.

4. Scope the pilot

   Under Passkey (FIDO2) > Enable and target, make sure Enable is On. Choose Add target > Select targets and pick your pilot groups instead of All users. Select the Windows profile and Save.

   If a user is scoped to several profiles, Learn says they’re allowed when the passkey fully satisfies at least one of them.

5. Bootstrap registration

   Learn says users must have completed MFA within the past five minutes before they can register a passkey. A user then goes to Security info, signs in with MFA, selects Add sign-in method > Passkey > Next, and chooses where to save the passkey.

   A Temporary Access Pass (TAP) can bootstrap passkeys. Learn says:

   • TAP must first be enabled in the Authentication methods policy, and the user must be in scope.
   • Authentication Administrators can create, delete and view a TAP for members, not themselves. Privileged Authentication Administrators can do so for admins and members.
   • Admin path: Entra ID > Users > the user > Authentication methods > Add authentication method > Temporary Access Pass. The value can’t be viewed again after you select OK.
   • Defaults: 1 hour minimum, 8 hours maximum, 1 hour default lifetime, one-time use False. The allowed range is 10 to 43,200 minutes.
   • Each user can have only one TAP. A new one overrides the existing one.
   • For a one-time TAP used to register a passwordless method such as a FIDO2 security key, registration must finish within 10 minutes of sign-in. Learn says this does not apply to a multiple-use TAP.

6. Test sign-in

   Learn describes the browser flow on Windows. Enter a username, or get auto-prompted if a passkey was used last time. Otherwise choose Other ways to sign in, then Face, fingerprint, PIN, or security key, and verify in the Windows Security dialog with Windows Hello. Sign-in options works without a username.

   Test on a device with an existing WHfB credential for the same account. Registration is expected to fail there, per Learn.

7. Decide whether to enforce with Conditional Access

   Authentication strength is a grant control (Require authentication strength). Creating a custom strength needs at least Conditional Access Administrator, at Entra ID > Authentication methods > Authentication strengths. Learn says:

   • You can’t combine Require multifactor authentication and Require authentication strength in the same policy.
   • Strength is evaluated after the initial authentication, so a user may still enter a password first. If they signed in another way, they must restart and choose the required method under Sign-in options.
   • The built-in Phishing-resistant MFA strength lists “Windows Hello for Business or platform credential”, FIDO2 security key and certificate-based authentication (multifactor). That page doesn’t name Entra passkeys on Windows separately.

   Microsoft’s published material doesn’t say how Conditional Access treats passkey creation or use on unmanaged Windows devices. Test with a pilot group before you attach a strength to anything that matters. For the wider policy set, see the Conditional Access baseline.

8. Decide your stop position

   If you need to prevent Windows passkeys, the Message Center post says to add the Windows Hello AAGUIDs to the block list in the relevant profiles. Given the conflict above, confirm in a pilot that this has the effect you expect. Don’t use an excluded group for this unless you intend to block all passkey registration and sign-in for those users.

9. Plan recovery

   Learn says an admin can delete a user’s passkey under the user’s Authentication methods in the Entra admin center. The permissions reference lists microsoft.directory/users/authenticationMethods/delete for Authentication Administrator (non-administrators and some roles only) and for Privileged Authentication Administrator (all users). That page doesn’t name passkeys explicitly, so test the deletion with your support roles before it goes in a helpdesk script.

   Learn confirms TAP as a recovery route when a user loses or forgets a strong method. No source states that it is the recommended route for Entra passkey on Windows device loss. Learn also advises users replacing a lost device to remove the old authentication methods.

For the wider picture on identity controls, see the Azure identity baseline.

Checks

• ✓

  Passkey (FIDO2) is enabled and targeted at pilot groups, not All users.

• ✓

  Allow self-service set up is Yes.

• ✓

  The Windows profile has Passkey types set to Device-bound, Windows Hello AAGUIDs allowed, and Enforce attestation off.

• ✓

  A pilot user can register a passkey in Security info on a Windows device and sign in with it.

• ✓

  A device with a Windows Hello for Business credential for the same account is tested, and the result is documented.

• ✓

  Your tenant's behaviour for the Default profile and the Windows Hello AAGUIDs is recorded, given the Message Center and Learn disagree.

• ✓

  Any Conditional Access authentication strength has been tested with a pilot group, including on unmanaged devices.

• ✓

  Helpdesk can issue a TAP and delete a passkey with their actual roles.

• ✓

  Sign-in logs reviewed for passkey registration and sign-in failures from the pilot group.

Rollback

• Stop use for a group: remove the group from the Windows profile target, or from the Passkey (FIDO2) targets. Learn says a profile can only be deleted once no targets are assigned to it.
• Stop sign-in with Windows Hello passkeys: Learn says removing a previously allowed AAGUID stops users who registered with it from signing in with it. Expect those users to need another method.
• Remove a single user’s passkey: delete it under the user’s Authentication methods.
• What can’t be undone: Learn says the passkey profiles opt-in can’t be reversed. Rolling back means removing targets and profiles, not leaving the profile model.

Common pitfalls

• Assuming one source is right. The Message Center post and Learn disagree on allow versus block for the Windows Hello AAGUIDs. Test in your tenant.
• Opting in to profiles casually. It can’t be reversed, and the global settings move into a Default profile.
• Enforcing attestation. The Windows profile can’t enforce it, and registration relies on that.
• Forgetting the MFA window. Users need MFA within the past five minutes before registering.
• Expecting one registration to cover everything. Each Windows device needs its own registration for each Entra account.
• Treating it as a WHfB replacement. Learn says it isn’t, and it doesn’t support device sign-in.
• Using exclusion groups as a gentle block. Exclusion blocks all passkey registration and sign-in for the user and wins over inclusion.
• Combining MFA and authentication strength grants. They can’t sit in the same Conditional Access policy.
• Overwriting a TAP. A new TAP replaces the old one, valid or not.
• Expecting guests to register. They can’t.