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

Hi @Neha Chandna

Good news: this isn't a random regression. It's how the registration-scoped authentication strength is designed to work, and it's an easy trap to fall into once you're running Phishing-Resistant MFA on your app-access policies.

What's actually happening

Conditional Access evaluates the Register Security Info interrupt wizard a little differently than normal sign-in. Authentication strengths scoped to the Register security information user action take precedence over anything scoped to All resources. So if your registration policy (the one with location/device restrictions you mentioned) is also set to Phishing-Resistant MFA, that's the policy governing the wizard, and it's requiring the exact credential the user is there to create. That's the loop.

Separately, Microsoft tightened session freshness for this flow: since August 25, 2025, managing security info at My Sign-ins requires a session no older than 10 minutes, and adding or modifying a passkey specifically requires 5 minutes. So even a well-scoped policy can trip this if the user's session has gone stale. Worth ruling out before you assume it's purely the policy.

The fix: split registration from enforcement

Jan Bakker has the cleanest writeup of this pattern I've seen, and it maps directly onto your setup. Short version: don't let one policy cover both jobs. Run two (really three, with app coverage):

1. Bootstrap & Recovery policy, scoped to Register security information, using a custom authentication strength that allows Password + Authenticator push or TAP. This is what lets a user with no phishing-resistant method reach the wizard at all.
2. Enforcement policies, scoped to All resources, requiring Phishing-Resistant MFA. Split these by platform (desktop vs. mobile), since the enrollment flow behaves differently on each.
3. Exclude the Azure Credential Configuration Endpoint Service app from your mobile enforcement policy. If a user is upgrading from an existing MFA method to a passkey inside the Authenticator app, that upgrade flow breaks out of the Register security info action and talks to this endpoint directly, so your mobile policy will block it unless it's excluded.

TAP isn't your only option here, contrary to what you might read elsewhere. Password + an existing MFA method works fine as a bootstrap credential too, as long as your Bootstrap & Recovery policy's authentication strength permits it. Use TAP for new hires and true greenfield users; let everyone else upgrade with what they've already got.

One more thing worth adding to your rollout, separate from the CA fix: a registration campaign (Entra ID > Authentication methods > Registration campaign) is Microsoft's supported way to nudge already-enrolled users toward passkeys without waiting for enforcement. It runs after MFA succeeds, so it won't help your locked-out population, but it's the right lever once the Bootstrap policy is in place and you want the rest of your users moving over voluntarily. One thing to check if you go that route: if you restrict passkeys to specific hardware AAGUIDs, use the Enabled state rather than Microsoft managed, since Microsoft-managed eligibility only recognizes a short list of named providers (iCloud Keychain, Google Password Manager, Authenticator, Entra passkey on Windows) and will silently skip anyone outside that list.

Test all of this in Report-only first, and don't touch the enforcement policies until you've confirmed the Bootstrap policy actually gets users through the wizard.

References:

• Control security information registration with Conditional Access
• How Microsoft Entra authentication strength works in a Conditional Access policy
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Jan Bakker, You shall not pass(key)! (updated)
• Jan Bakker, Security Info Registration. Entra ID's rabbit hole.

Happy to go deeper on the AAGUID exclusion policy or the mobile-app-upgrade exclusion if useful.

Answer 2

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