Initial Authenticator Registration Fails

The behavior matches known issues where Conditional Access and authentication-strength policies block or loop initial passkey/Authenticator registration when using the sign-in flow.

Key checks and workarounds for the tenant:

1. Check for an authentication strength loop
   • Look for a Conditional Access policy with:
     • Condition: All devices (Windows, Linux, macOS, Android, iOS)
     • Targeted resource: All resources (formerly “All cloud apps”)
     • Grant control: Authentication strength – Require passkey in Authenticator (or similar phishing-resistant requirement).
   • This configuration forces users to use a passkey in Authenticator to access all apps, including Authenticator itself, which breaks first-time registration and can cause timeouts.
   Workarounds from the documented pattern:
   • Change the policy target from All resources to specific applications using application filters, and explicitly tag Authenticator so it is not blocked during registration.
   • Alternatively, split policies by platform:
     • Desktop OS policy: require passkey in Authenticator.
     • Mobile OS policy: allow TAP, a phishing-resistant credential, or other allowed methods so users can sign in to Authenticator and register the passkey without looping.
   • Ensure that any Conditional Access policy targeting Register security info uses a grant control that users can actually satisfy before they have a passkey.
2. Check for “Require approved client app” / “Require app protection policy”
   • If there is a CA policy with:
     • Condition: All devices
     • Targeted resource: All resources
     • Grant control: Require approved client app or Require app protection policy
   • Authenticator does not support Intune app protection policies on Android or iOS for this scenario, so this will block registration and can manifest as a timeout.
   Workarounds:
   • Narrow the policy from All resources to specific apps using application filters and exclude Authenticator (and other registration endpoints) from that policy.
   • Or switch to using MDM with Require device to be marked as compliant instead of “Require approved client app” / “Require app protection policy”, since Authenticator can satisfy the compliant-device control when the device is fully managed.
3. Ensure Security info registration is reachable
   • For users who cannot complete registration via the in-app sign-in method, allow the alternate flow from Security info (mysignins.microsoft.com) and ensure:
     • Any CA policy targeting Register security info does not require a method the user does not yet have.
     • Users can satisfy that policy with TAP or another allowed method to bootstrap Authenticator/passkey registration.
4. Use Temporary Access Pass (TAP) as a bootstrap method
   • For affected users, issue a TAP and allow it in the mobile Conditional Access policy so they can:
     • Sign in to Authenticator using TAP or another allowed method.
     • Register a passkey in Authenticator without hitting the passkey-required loop.
5. If users are completely blocked from registration
   • Confirm they have at least one other enabled authentication method (SMS, voice, or other MFA) and that CA policies do not block those methods for Register security info.
   • If they do not, adjust CA temporarily or add TAP so they can complete initial setup.

Once these Conditional Access and authentication-strength configurations are adjusted (especially removing “Require passkey in Authenticator” and “Require approved client app / app protection policy” from All resources and from the registration flows), the sign-in-based Authenticator registration on handheld devices should stop timing out and work without needing the QR-code browser step.

References:

• Support passkeys in Authenticator in your Microsoft Entra ID tenant
• How to add your accounts to Microsoft Authenticator
• Register passkeys in Authenticator on Android or iOS devices