Users are unable to self register the Passkey and phishing-resistant MFA

Question

How can I troubleshoot and ensure that Passkey and phishing-resistant MFA registration work for all my users? They all encountered a failure with the error detailed below.

Any assistance would be greatly appreciated.

Answer 1

Hey there! It looks like your users are hitting the generic “Passkey not registered” error during self-service setup—which usually means something in the FIDO2 / passkey policy or their client environment isn’t lining up. Here’s a quick playbook you can run through:

1. Verify policy configuration • In the Entra admin center under Authentication methods > Policies, make sure “Passkey (FIDO2)” is Enabled and “Allow self-service setup” is set to Yes. • If you’re using the Microsoft Authenticator passkey preview, ensure you’ve enabled that sub-option in the same FIDO2 policy, keep attestation turned Off (preview doesn’t yet support full attestation), and don’t enforce key restrictions unless you’ve explicitly added the Authenticator AAGUIDs.
2. Check Conditional Access (CA) / authentication strength scope • CA policies that require phishing-resistant MFA can inadvertently block passkey registration. Confirm you’re not targeting that CA at the registration endpoint—CA should guard sign-in, not the “Add security info” flow. • If you must enforce phishing-resistant auth for registration, test by temporarily disabling “Require attestation” or remove the CA requirement to see if registration succeeds.
3. Confirm user flow prerequisites • Users must complete an MFA challenge (or use a Temporary Access Pass) within the same browser session before adding a passkey. • Make sure they’re not in private/incognito mode, have a stable Internet connection, and (for cross-device flows) Bluetooth is on.
4. Validate client support • Devices must meet OS/browser requirements: Android 14+, iOS 17+ or Windows 10 1903+. • Browsers need WebAuthn support (Edge, Chrome, Safari latest).
5. Clean up orphaned or local-only passkeys • If a registration spun up a local passkey in Authenticator but never made it to the server, users should delete it from the Authenticator app and from My Security Info before retrying.
6. Gather logs & error codes • Have the user reproduce the error and capture the browser console or FIDO status. • Review Azure sign-in logs for any FIDO2-related error codes or conditional access insights.

Reference docs:

• Enable passkeys (FIDO2) for your organization: https://learn.microsoft.com/entra/identity/authentication/how-to-enable-passkey-fido2
• Register a passkey (FIDO2): https://learn.microsoft.com/entra/identity/authentication/how-to-register-passkey
• Enable passkeys in Authenticator: https://learn.microsoft.com/entra/identity/authentication/how-to-enable-authenticator-passkey
• Troubleshoot passkey sign-in issues: https://learn.microsoft.com/entra/identity/authentication/how-to-sign-in-passkey
• MFA registration troubleshooting: https://learn.microsoft.com/azure/active-directory/authentication/how-to-authentication-methods-manage

Answer 2

Use a structured approach that covers both client‑side issues and tenant configuration, focusing on known causes where passkeys are created locally but not registered in Microsoft Entra ID, and on Conditional Access loops that block registration.

1. Check for locally created but unregistered passkeys
   • The error pattern in the screenshots matches the scenario where the passkey is stored only on the device (or in Microsoft Authenticator) but not registered on the server.
   • For users registering via Microsoft Authenticator on Android or iOS:
     • Open Authenticator, select the affected account, go to Settings and choose Delete passkey (Android/iOS wording from the docs).
     • Then go to Security info / My Security info and delete the corresponding passkey entry if it exists.
     • Have the user repeat registration from scratch.
   • If users see an error that the passkey already exists when retrying, always delete the local passkey in Authenticator first, then retry registration.
2. Validate Conditional Access policies for passkey registration
   • If a Conditional Access policy requires phishing‑resistant authentication or “passkey in Authenticator” for All resources (formerly ‘All cloud apps’) and All devices, users can be forced into a loop where they must already have a passkey to add a passkey.
   • To avoid this:
     • Use application filters to move from All resources to a scoped list of apps, and explicitly tag Authenticator and other apps as needed.
     • Implement the documented two‑policy approach:
       • Desktop OS policy: targets desktop OS devices, requires Authentication strength – passkey in Authenticator.
       • Mobile OS policy: targets Android/iOS, allows TAP, passkey in Authenticator, or other specified methods so users can sign in and register a passkey without already having one.
     • Ensure any Conditional Access policy that targets Register security info is compatible with the methods users will use to register passkeys.
3. Check for “Require approved client app / app protection policy” loops
   • If there is a Conditional Access policy with:
     • Condition: All devices (Windows, Linux, macOS, Windows, Android)
     • Targeted resource: All resources (formerly ‘All cloud apps’)
     • Grant control: Require approved client app or Require app protection policy
   • Authenticator cannot satisfy these grant controls on Android or iOS, so passkey registration in Authenticator will fail.
   • Workarounds:
     • Use application filters to scope the policy to specific apps instead of All resources.
     • Or use MDM with Require device to be marked as compliant so that compliant, fully managed devices can satisfy the policy while still allowing Authenticator to work.
4. Address Windows 11 passkey privacy consent (for AVD/RDP scenarios)
   • On Windows 11 24H2 and later, if users declined the passkey privacy consent, passkey registration and use can fail in AVD/RDP sessions.
   • Have affected users:
     • Open Settings > Privacy & security > Passkey access.
     • Locate the relevant app or website and set it to Allow.
   • If this settings page is hidden by policy, configure Settings page visibility to restore access to Privacy & security > Passkey access.
5. Monitor and maintain passkey hygiene
   • Use Microsoft Entra audit logs and sign‑in logs to verify whether passkeys are being created and used successfully.
   • If a specific user’s passkey is problematic, delete it via the per‑user authentication methods UX or API, then have the user re‑register.
6. Roll out in stages
   • Use passkey profiles to scope a staged rollout of synced passkeys to selected user groups.
   • Prefer device‑bound passkeys for admins and highly privileged users, and synced passkeys for standard users, to reduce recovery and reissuance issues.

Following these steps removes the common causes where passkeys are created only locally, blocked by Conditional Access, or blocked by Windows privacy settings, and ensures users can complete phishing‑resistant MFA registration successfully.

---

References:

• Frequently asked questions about passkeys
• Considerations for Remote Desktop Connections in a phishing-resistant passwordless authentication deployment in Microsoft Entra ID
• Support passkeys in Authenticator in your Microsoft Entra ID tenant
• Set up a passkey in Microsoft Authenticator
• Register passkeys in Authenticator on Android or iOS devices