has something changed with Register Security Info (security info page)

Question

We are looking for clarification regarding a change in Microsoft Entra Conditional Access behavior related to phishing-resistant MFA onboarding.

A few months ago, users targeted by a Conditional Access policy requiring Phishing-Resistant MFA authentication strength for applications could still access the Security Info Registration experience using password + traditional MFA (Microsoft Authenticator number matching). This allowed them to register a FIDO2 security key or Authenticator passkey, which was then used to satisfy the Phishing-Resistant MFA requirement.

Our environment also has separate Conditional Access policies targeting the Register Security Information user action with location and device restrictions.

Today, users who are subject to the Phishing-Resistant MFA requirement are being prompted to satisfy the Phishing-Resistant MFA authentication strength before they can register a passkey or security key on the Security Info page. This creates a circular dependency where users must already have a phishing-resistant method in order to enroll one.

Could Microsoft clarify:

1. What specific product change introduced this behavior?
2. Is this an intentional design change or a side effect of Conditional Access evaluation updates?
3. Is Temporary Access Pass (TAP) now the only supported onboarding method for users who do not yet have a phishing-resistant credential?
4. If an organization is not yet operationally ready to deploy TAP, what onboarding approach does Microsoft recommend for users being migrated from traditional MFA to phishing-resistant MFA?
5. Is there a supported Conditional Access configuration that allows initial passkey/FIDO2 enrollment while still enforcing phishing-resistant MFA for application access?

We are trying to understand the Microsoft-recommended migration path from traditional MFA to phishing-resistant MFA without creating an enrollment catch-22 for end users.

Answer 1

What is documented is this:

1. Conditional Access now applies more directly to registration flows than many organizations previously assumed. Users registering passkeys in Authenticator must satisfy any Conditional Access policy that targets Register security info, and if there are All resources policies with conditions, those conditions must also be met during registration. Microsoft also documents that if multiple Conditional Access policies target Register security information and each applies an authentication strength, the user must satisfy all of those authentication strengths.
2. This behavior is intentional in the product model. Microsoft documents that when a user isn’t registered for any method that satisfies the required authentication strength, the user is redirected to combined registration. But if the required authentication strength doesn’t include a method the user can register and use, Microsoft Entra ID blocks access. Microsoft also documents that some passwordless and phishing-resistant methods can’t be registered from Interrupt mode, which is the core reason the enrollment catch-22 can occur.
3. Temporary Access Pass is a supported onboarding method and is explicitly called out for this scenario. Microsoft states that administrators can provide TAP credentials so users can register from any device or location, and that TAP credentials satisfy Conditional Access requirements for multifactor authentication. For passkeys in Authenticator, Microsoft also documents a mobile policy pattern where users sign in to Authenticator with a TAP or another allowed method and then register the passkey directly in Authenticator, avoiding the loop.
4. A supported migration approach is to separate onboarding from enforcement. The documented pattern is:
   1. Use Conditional Access policies targeting Register security information carefully and test them in Report-only first.
   2. Ensure users can register the required method before enforcing an authentication strength that depends on it, because some passwordless/phishing-resistant methods can’t be registered during Interrupt mode.
   3. Use TAP for initial registration where needed.
   4. For passkey registration issues caused by recent MFA freshness requirements on My Sign-ins / security info management, Microsoft documents these mitigations:
      • At the tenant level, enforce Sign-in frequency: Every time for the Register security info user action, or enable passkeys for Windows Hello for Business users.
      • At the user level, ensure the user authenticates with a session no more than 10 minutes old, or with a combination of methods included in the enforced authentication strength.
5. There is a supported Conditional Access configuration pattern, but not one that bypasses the registration dependency if phishing-resistant auth is already strictly required for the same journey. Relevant documented constraints are:
   • Require multifactor authentication and Require authentication strength can’t be used together in the same Conditional Access policy.
   • Users can’t register passkeys in Authenticator if they’re included in an All resources policy for all devices with grant controls Require approved client app or Require app protection policy.
   • For mobile passkey registration, the grant control for the mobile policy must match the Conditional Access policy for Register security info.
6. About a specific product change: the context does not identify a single change announcement for the exact behavior described on the Security info page. The documented changes that are relevant are:
   • Starting August 25, 2025, users must complete MFA when managing credentials or accessing My Sign-ins if they haven’t done so within the last 10 minutes of the current session. Microsoft states this can conflict with authentication strengths for security info registration and can produce the “Let’s try something else...” error.
   • Starting July 6, 2026, Conditional Access policies targeting Register security information will also apply during Windows Hello for Business and macOS Platform SSO credential registration.

Based on the documented guidance, the Microsoft-supported path for migrating from traditional MFA to phishing-resistant MFA without creating an enrollment deadlock is:

1. Allow registration first.
2. Use TAP where users do not yet have a phishing-resistant method.
3. Keep Register security information policies aligned with the registration flow and test in Report-only.
4. Enforce phishing-resistant authentication strength for application access only after users have a registrable path to the required method.

---

References:

• Protect security info registration with Conditional Access policy
• Enable passkeys in Authenticator
• How Conditional Access authentication strengths work
• Combined security information registration for Microsoft Entra overview
• Conditional Access authentication strengths