Passkeys in Entra ID Troubleshooting (2026)

Updated: July 28, 2026

Passkeys in Microsoft Entra ID are phishing-resistant, FIDO2-based credentials stored on a device (a phone, a hardware security key, or the OS platform authenticator) that let users sign in to work and school accounts without a password. If your users can't register or sign in with them, the fix almost always lives in one of three places: the Authentication methods policy, the Microsoft Authenticator version on their phone, or the AAGUID allowlist. I've spent most of 2026 rolling this out across a hybrid tenant, and this article is the runbook I wish I'd had on day one.

Passkeys in Entra ID work through Microsoft Authenticator (device-bound passkey), FIDO2 hardware security keys, and, as of the 2026 preview, synced platform passkeys on macOS and Windows.
Registration requires the Authentication methods policy to have Passkey (FIDO2) enabled with the correct AAGUID allowlist, plus a Temporary Access Pass if the user has no existing MFA method.
Microsoft Authenticator must be version 6.8.9 or later on Android and 6.9.2 or later on iOS to register a passkey. Older versions fail with a generic "Something went wrong" toast.
Cross-device sign-in uses Bluetooth Low Energy plus a QR code (the CTAP hybrid transport). Disabling BLE on the phone or the workstation is the single most common cause of a stuck sign-in screen.
Conditional Access policies that require a compliant device, or a hybrid Entra joined device, will block passkey enrollment from an unmanaged phone unless you carve out a security-info registration exclusion.
Passkeys satisfy Entra's Phishing-resistant MFA authentication strength, which lets you retire SMS and voice call fallbacks for privileged roles.

What are passkeys in Microsoft Entra ID?

A passkey in Microsoft Entra ID is a public-key credential that conforms to the FIDO2 / WebAuthn specification and is registered against a user's Entra account. In practice, that means the private half of the credential lives on a device (a phone running Microsoft Authenticator, a hardware security key, or, in the newer synced model, the operating system's platform authenticator) and Entra ID stores only the public half. Because the private key never leaves the device, there's nothing for an attacker to phish. The user proves possession of the device with a biometric or PIN gesture, and the device signs a challenge that Entra ID verifies.

Historically, the Entra ID stack called this method "FIDO2 security key," and the enrollment path was limited to physical USB or NFC keys from vendors on Microsoft's compatibility list. Since the 2025 general availability of device-bound passkeys in Microsoft Authenticator, most tenants have shifted to using the mobile app as the primary passkey vessel. In 2026, Microsoft is also rolling out preview support for synced platform passkeys via iCloud Keychain and Google Password Manager, which changes some of the recovery calculus but not the registration mechanics.

Here's the important distinction for helpdesk work: a passkey is a credential, not an authentication method type in the classic sense. When you enable Passkey (FIDO2) in the Authentication methods policy, you're enabling all three vessels above at once, and you steer which ones are actually usable through the AAGUID allowlist.

Prerequisites for a passkey rollout

Before you touch policy, verify each of the following. Skipping any of them produces the same symptom (registration failure), but the fixes are different, so it pays to check systematically.

Entra ID licensing. Passkey registration works on all Entra ID SKUs, including free. Conditional Access enforcement of passkey-only sign-in requires Entra ID P1 or higher.
Microsoft Authenticator version. Android must be on 6.8.9 or later, iOS on 6.9.2 or later. Older builds silently fail registration.
OS baseline for the phone. Android 14 or later, iOS 17 or later. Older OS versions can't expose the platform biometric to the Authenticator passkey provider.
Bluetooth Low Energy on the workstation. Cross-device sign-in uses the hybrid transport, which piggybacks on BLE for a proximity check. If BLE is disabled in Group Policy, or the laptop lacks a working Bluetooth radio, the QR sign-in flow times out at sixty seconds.
Temporary Access Pass availability. A brand-new user with no existing MFA method can't bootstrap a passkey without a TAP. Enable the TAP policy and scope it to your onboarding group.
Global Administrator or Authentication Policy Administrator role, so you can change the Authentication methods policy in the first place.

The official Microsoft Learn deployment guide lists a few additional edge cases (federated tenants, external identities, and B2B guests) that we cover further down.

How do I enable passkeys in Microsoft Entra ID?

The policy lives at Entra admin center → Protection → Authentication methods → Policies → Passkey (FIDO2). The steps below are the exact runbook I use for a controlled rollout.

Open the Passkey (FIDO2) policy and set Enable to Yes.
Under Target, start with a pilot group of maybe twenty users. Do not target All users on day one. You will not have time to answer the tickets.
Expand Configure. Set Allow self-service set up to Yes and Enforce attestation to Yes.
Set Enforce key restrictions to Yes, choose Allow, and populate the AAGUID list. The two AAGUIDs you almost certainly want are:
- 90a3ccdf-635c-4729-a248-9b709135078f (Microsoft Authenticator on iOS)
- de1e552d-db1d-4423-a619-566b625cdc84 (Microsoft Authenticator on Android)
Add the AAGUIDs of any FIDO2 hardware keys your organisation issues (YubiKey 5 Series, Feitian ePass, Token2, and so on). The FIDO Alliance metadata service is the authoritative source for these values.
Save the policy. Changes propagate in about ten minutes, though I've seen the first pilot user in a large tenant wait as long as thirty.

Once the policy is saved, users in the pilot group can register a passkey from My Sign-Ins → Security info → Add sign-in method → Passkey. On the workstation, this flow requires the user to already be signed in with an existing MFA method, or with a Temporary Access Pass if they have none. If you're combining this rollout with tightening MFA policies, our Microsoft 365 MFA troubleshooting guide is a useful companion.

Registering a passkey in Microsoft Authenticator

The end-user experience matters here, because most of the "it doesn't work" tickets come from users getting stuck between the workstation browser and the phone. Walk through the steps once yourself before you write the internal how-to.

User signs in to https://mysignins.microsoft.com on a laptop or desktop.
User picks Security info → Add sign-in method → Passkey → Microsoft Authenticator.
The workstation shows a QR code and starts a Bluetooth advertisement. Expected output: within about ten seconds, the phone's Authenticator app displays a "Set up passkey" notification.
User opens the notification, taps Continue, authenticates with their phone biometric, and confirms the account name.
The phone signs the challenge and the workstation flips to Passkey added. Expected output: the new passkey appears in the Security info list, and the AAGUID column matches one of the two Microsoft Authenticator AAGUIDs above.

If the flow stalls between step 3 and step 4, that's Bluetooth. If it stalls between step 4 and step 5, that's either the AAGUID allowlist or a Conditional Access policy blocking the browser session. Both are covered below.

Passkey registration errors and fixes

These are the four failure modes I see repeatedly. In every case, first collect the browser console log from the mysignins.microsoft.com tab. WebAuthn errors are logged with their raw NotAllowedError or SecurityError class, which tells you more than the UI toast does.

1. "Something went wrong" during registration

This is the generic bucket. Ninety percent of the time it's one of two things: Authenticator is out of date, or the AAGUID allowlist doesn't include the AAGUID of the vessel the user is registering with. Ask the user to open Authenticator, tap the menu, then Help, then Send feedback, which surfaces the app version at the top. Cross-check the phone OS version against the prerequisite matrix. Then run the diagnostic below against the tenant to confirm which AAGUIDs are actually allowed.

# Requires Microsoft.Graph.Identity.SignIns module
Connect-MgGraph -Scopes "Policy.Read.All"

$policy = Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2"

$policy.AdditionalProperties.keyRestrictions
# Expected output:
# aaGuids         : {90a3ccdf-635c-4729-a248-9b709135078f, de1e552d-db1d-4423-a619-566b625cdc84}
# enforcementType : allow
# isEnforced      : True

2. AAGUID not in allowlist

If the AAGUID returned in the console log isn't present in the policy output above, add it. If it is present but registration still fails, check that isEnforced is True. A common misconfiguration is switching the enforcement dropdown to Allow but leaving the enforcement toggle off, which quietly ignores the list.

3. "No compatible authenticator found"

This is the browser telling you the WebAuthn call couldn't enumerate any usable authenticator on this device or over the hybrid transport. On Windows, it usually means the platform authenticator (Windows Hello) is registered but not enabled for this operation, and Bluetooth is off. On macOS, it can also mean the browser is Safari and the user is trying to register a device-bound passkey. Safari currently prefers the iCloud Keychain synced passkey path, which won't register into the Entra ID FIDO2 method type unless synced passkeys are explicitly allowed in your policy. Ask the user to switch to Edge or Chrome for the registration.

4. Conditional Access blocks registration

If you have a Conditional Access policy targeting the User action → Register security information that requires a compliant device or hybrid Entra joined device, an unmanaged phone will fail with AADSTS53000. The fix isn't to weaken your policy. It's to bootstrap the registration on a managed workstation using a Temporary Access Pass, and then let the user use the passkey to sign in going forward.

Sign-in failures fall into a different pattern from registration failures, because at sign-in time the credential already exists. The failure is either transport, freshness, or Conditional Access. Work through these in the order they appear; that's the order they occur in the sign-in pipeline.

User is prompted for a password after picking passkey. This is the classic federated-tenant footgun. If your tenant is federated to on-premises AD FS, the sign-in stack routes passkey users through the federated endpoint by default, which then asks for a password. The fix is to enable Staged Rollout for cloud authentication and add the passkey users to the pass-through authentication or password hash sync staged group. Once they're on cloud auth, the passkey prompt renders in the Entra ID login page directly.
"AADSTS500121: Authentication failed during strong authentication request." This means Conditional Access required an authentication strength the passkey didn't satisfy. Check the Sign-in log. If the AAGUID column shows the passkey came from Microsoft Authenticator and the required strength is Phishing-resistant MFA, verify that Microsoft Authenticator passkeys are included in the custom authentication strength. Until 2026, the built-in strength only counted FIDO2 hardware keys.
Sign-in stuck on "Waiting on your passkey." BLE proximity check timed out. Restart Bluetooth on both devices, make sure the phone screen is unlocked, and place the phone within a metre of the workstation. If the workstation is a desktop in a metal server room, the QR code path over the internet will complete the crypto, but the BLE proximity check will still block the sign-in. Microsoft added this deliberately as anti-phishing.
Guest user cannot use their passkey in your tenant. Cross-tenant access settings must allow the guest's home tenant to satisfy MFA on your behalf. This is the Trust settings → Trust multifactor authentication toggle in your Cross-tenant access policy for the partner tenant.

Cross-device passkey (QR code) troubleshooting

The cross-device sign-in flow (signing in on a workstation using a passkey stored on a phone) combines a QR code, a WebSocket relay, and a Bluetooth Low Energy proximity check. Any one of those failing looks identical to the user: a spinner that never resolves.

The QR code encodes a session identifier plus a public key that the phone will use to negotiate an encrypted channel to a WebSocket relay hosted by the browser vendor. Once the phone opens the QR (either by scanning with the camera or by tapping a system notification), it advertises over BLE. The workstation listens for that BLE advertisement, matches it to the session, and only then does the authentication succeed. This is the CTAP2 hybrid transport, documented in the CTAP 2.1 specification.

Diagnostic steps, in order:

Confirm both devices have Bluetooth on. On the workstation, run Get-PnpDevice -Class Bluetooth in PowerShell. Expected output is at least one device with Status OK.
Confirm the phone is on the same corporate Wi-Fi or has cellular data. The relay is HTTPS/443, so a captive portal or a proxy that intercepts TLS will break it.
Confirm outbound TCP 443 is open to *.cablepki.microsoft.com and caBLEv2.googleapis.com from both endpoints. Yes, both endpoints hit their respective vendor's relay. Microsoft's stack uses its own, and Chrome uses Google's.
Watch the Sign-in log in Entra admin center in real time. If you see no entry appear at all when the user scans the code, the failure is in the QR/relay phase. If you see an entry with error AADSTS16000, the phone completed the challenge but the workstation couldn't verify the proximity.

Escalation escape hatch: if a user must sign in now and cross-device is refusing, temporarily switch them to a Temporary Access Pass so they can complete the immediate task, and file a separate ticket to fix the transport later.

Passkeys vs FIDO2 security keys vs Windows Hello for Business

Users, and even some admins, conflate these three, so it's worth being precise. All three are FIDO2 credentials at the protocol level; they differ in vessel, portability, and management surface. If you support Windows-first fleets, our dedicated Windows Hello for Business troubleshooting guide covers the PIN and cloud Kerberos trust side in depth.

Feature	Passkey in Authenticator	FIDO2 security key	Windows Hello for Business
Vessel	Phone (device-bound)	USB / NFC hardware key	Windows PC TPM
Portable across devices	Yes, via cross-device sign-in	Yes, physically	No, per-device
Phishing-resistant MFA	Yes	Yes	Yes
Requires biometric	Yes (phone fingerprint or face)	Optional (PIN or fingerprint on key)	Yes (Windows Hello face, fingerprint, or PIN)
Recovery when lost	Re-register with TAP	Re-register with TAP or issue new key	Reset from lock screen with TAP
Typical cost per user	$0 (uses existing phone)	$25–$90 per key	$0 (built into Windows)
Works on shared kiosks	Yes, via QR sign-in	Yes	No

The pragmatic recommendation I give my ticketing team: passkey in Authenticator for most knowledge workers, FIDO2 hardware key for privileged accounts and Break Glass, Windows Hello for Business for user-assigned laptops. All three can coexist on the same account, and Entra ID picks the strongest available credential at sign-in based on your Conditional Access authentication strength. For deeper policy design, our Entra ID Conditional Access guide walks through building custom strengths that gate access on the credential type.

Managing passkey policy with Graph and PowerShell

Everything in the Authentication methods policy is available via Microsoft Graph, which is how you should be managing this at scale. The GUI is fine for a first pilot; from your second tenant onward, put it in source control.

# Add Microsoft Authenticator AAGUIDs to the FIDO2 allowlist
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

$aaguids = @(
    "90a3ccdf-635c-4729-a248-9b709135078f",  # Authenticator iOS
    "de1e552d-db1d-4423-a619-566b625cdc84"   # Authenticator Android
)

$params = @{
    "@odata.type"         = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    state                 = "enabled"
    isAttestationEnforced = $true
    keyRestrictions       = @{
        isEnforced      = $true
        enforcementType = "allow"
        aaGuids         = $aaguids
    }
}

Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2" `
    -BodyParameter $params

# Expected output: no error. Verify with:
(Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2").AdditionalProperties.keyRestrictions

For a per-user audit (which of my users have registered a passkey?), the following Graph call returns every FIDO2 method across the tenant, which for our purposes includes device-bound passkeys.

# List all users with a registered passkey / FIDO2 method
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"

Get-MgUser -All -Property UserPrincipalName,Id | ForEach-Object {
    $methods = Get-MgUserAuthenticationFido2Method -UserId $_.Id -ErrorAction SilentlyContinue
    foreach ($m in $methods) {
        [PSCustomObject]@{
            UPN     = $_.UserPrincipalName
            AAGUID  = $m.AaGuid
            Model   = $m.Model
            Created = $m.CreatedDateTime
        }
    }
} | Export-Csv -Path .\passkey-inventory.csv -NoTypeInformation

# Expected output: passkey-inventory.csv in the working directory, one row per registered credential.

Wire this into a scheduled runbook and diff week over week. When the count drops for a user, the credential was deleted, usually because they reset the phone. That's your cue to send a TAP proactively, before they call the helpdesk mid-Monday morning.

Frequently Asked Questions

Do I need to disable password sign-in to use passkeys in Entra ID?

No. Enabling passkeys adds a stronger authentication option; it doesn't disable passwords. To actually force passkey use, you need a Conditional Access policy that requires the Phishing-resistant MFA authentication strength for the target apps or roles. Most tenants roll passkeys out alongside passwords for a quarter, then tighten policy once registration crosses 80%.

Why can't I register a passkey in Microsoft Authenticator?

Almost always one of three causes: Authenticator is older than 6.8.9 (Android) or 6.9.2 (iOS), the AAGUID for your platform isn't in the tenant's FIDO2 allowlist, or a Conditional Access policy is blocking security-info registration from an unmanaged phone. Check the Authenticator version first. It fixes roughly 70% of the tickets I see.

What is the difference between a passkey and a FIDO2 security key?

They use the same cryptographic protocol; the difference is where the private key lives. A FIDO2 security key is a physical USB or NFC device you carry. A passkey is the same credential implemented in software on a phone or platform authenticator. Passkeys can also be synced across a user's devices via a password manager, which FIDO2 hardware keys cannot.

Can I use passkeys and Windows Hello for Business on the same account?

Yes, and you should. Windows Hello for Business is device-bound to the laptop TPM and gives fast local sign-in; a passkey in Authenticator gives portability. Entra ID happily stores both credentials on one user, and at sign-in time it lets the user pick whichever is present. Layer authentication strength via Conditional Access to steer which one is used for which app.

How do I recover a user who lost the phone with their passkey?

Issue a Temporary Access Pass from the Entra admin center scoped to that individual user with a one-hour lifetime. The user signs in with the TAP, registers a new passkey on their replacement phone, and the old passkey is orphaned. Delete the orphan from Security info afterwards. If TAP isn't enabled in your tenant, an Authentication Administrator can also delete the old FIDO2 method and re-enrol via a supervised session.