Passkey (Entra) Not working on Lockscreen but works on Web API

Question

Hi

We have built a custom FIDO2 passkey to be used with EntraID.

The passkey works with Windows Hello (Personal Account), Microsoft Web Auth but on Windows Pro Lockscreen, the security key fails with the following reason "You cannot sign in with this account. Try a different account". We are not sure what the error is (If any).

Could you help us point direction or give pointers on how to debug the same.

vlcsnap-2025-08-12-16h49m45s889.png

vlcsnap-2025-11-17-12h15m06s629.png

vlcsnap-2025-11-17-12h15m01s107.png

Thanks

Chandra

Answer 1

Hi chandra,

The failure is specific to your custom FIDO2 key's AAGUID not being recognized by Windows as a trusted authenticator for primary authentication, even though it passes web registration. The Yubikey works because its AAGUID is pre-trusted by Entra ID.

Check the AAGUID of your custom key in the Entra ID Authentication Methods activity logs. Filter for sign-in attempts with cFIDO; if the AAGUID is listed as "noncompliant" or lacks a "fido2SecurityKey" attestation type, Windows logon will reject it. You must add the custom AAGUID to the tenant's trusted FIDO2 security key list via Entra ID > Protection > Authentication methods > Policies > FIDO2 Security Key > Configure. If the AAGUID is not whitelisted, device logon fails.

Ensure the key is registered under the user's security info as a "FIDO2 security key" and not a "passkey." Passkeys bound to Microsoft accounts are invalid for Entra join. Use PowerShell with the MSOnline module to verify the registration type: Get-MsolUser -UserPrincipalName <user> | Select-Object -ExpandProperty StrongAuthenticationMethods should show "FIDO2SecurityKey" for both keys.

If the AAGUID is trusted and registration correct, the issue may be in the key's firmware or attestation certificate. Windows requires valid FIDO2 certification for lock screen use. Test cFIDO on another Entra-joined device to isolate the fault.

I hope you are clear with the information, and it's really appreciated of you to accept the answer to help build the community by sharing your experience with the issue. Thanks!

Vivian

Answer 2

Good morning chandra,

Regarding your issue, here is a fairly comprehensive explanation, and I hope you'd spend some time reading it.

My analysis shows that the rejection is not coming from the key. Wins is refusing the account before the FIDO2 ceremony even matters. The lock screen only accepts sign-in methods that are already registered in Entra ID as valid Primary Authentication for that specific user and for that specific device join state. The notice "You cannot sign in with this account" means the account is not eligible for FIDO2 login at the OS level.

You need to confirm the account is Entra ID-joined and not a personal Microsoft account. A custom FIDO2 authenticator will pass WebAuthn tests, but Windows uses the Azure AD Primary Refresh Token flow. If you don't have a valid PRT bound to the device, Windows blocks FIDO2 at the lock screen.

Also, validate that the tenant has FIDO2 security key authentication enabled at the tenant level and allowed for the user. If the policy is enabled only for browser sign-in or Conditional Access MFA, Windows treats the authenticator as unsupported for primary sign-in even though it works through web flows.

Ensure the AAGUID of your custom key is trusted by Entra ID. If the AAGUID is unknown, registration will appear to succeed, but Windows logon will deny it because the platform cannot map it to a supported authenticator model. Use the Entra ID Authentication Methods activity logs to verify that the AAGUID is recognized; unknown AAGUIDs show up as “noncompliant” even though browsers accept them.

Finally, check that the key is registered as a FIDO2 credential under the user’s Entra ID profile, not as a passkey synced to a Microsoft Account. Windows Hello on the login screen will not use MSA-bound passkeys for domain or Entra sign-in.

Once the PRT state, tenant FIDO2 enablement, and AAGUID recognition align, the lock-screen prompt accepts the key and the error disappears.

I hope you are clear with the information. Should you have any more questions, feel free to leave a message. It's really appreciated of you to accept the answer to help build the community by sharing your experience with the issue. Thanks!

Answer 3

Good morning,

Have you found the answer useful? If everything is okay, don't forget to share your experience with the issue by accepting the answer. Should you need more information, free free to leave a message. Happy to help! :)

Vivian

Answer 4

Hi @vivian Phan

Thank you for the above note.

In addition to our custom FIDO2 key (lets call cFIDO), we also have a Yubikey(lets call yFIDO) as a standard check. Surprisingly yFIDO works on the lockscreen but cFIDO alone fails. So we are not entirely sure it is OS itself and not cFIDO but yes, we will start looking at it too.

Notes from above:

1. (PRT) Azure AD Primary Refresh Token
2. (Conditional Access Policy) Validate that the tenant has FIDO2 security key authentication enabled at the tenant level and allowed for the user
3. (AAGUID) Ensure the AAGUID of your custom key is trusted by Entra ID
4. check that the key is registered as a FIDO2 credential under the user’s Entra ID profile

Here are our comments

1. PRT need to recheck
2. yFIDO works, so we know this is set correctly
3. AAGUID is set correctly as at the time of registration it accepts the passkey
4. we register here https://mysignins.microsoft.com/security-info . same for yFIDO which works

Tentatively we have accepted your answer as requested.

Thanks

Chandra