TAP requires step-up MFA when user already has a passkey registered — expected behavior

Question

Environment

• Microsoft 365 Business Premium (Entra ID P1)
• Cloud-only tenant
• Authentication methods enabled: FIDO2/Passkey only + TAP
• All other methods disabled (no Authenticator push, no TOTP, no SMS)

 

---

 

CA Policy configuration

 

CA001 — Protect Security Info Registration

• Target: User action — Register security information
• Grant: Custom authentication strength "Bootstrap and Recovery" (TAP one-time + TAP multi-use + Passkey/FIDO2 + WHfB/Platform credential)
• Status: On

 

CA002 — Require Phishing-Resistant Authentication

• Target: All cloud apps (excluding Azure Credential Configuration Endpoint and tested also excluding Microsoft App Access Panel)
• Grant: Built-in Phishing-resistant MFA
• Status: On

 

---

 

What was tested

 

Scenario 1 — User with no registered methods (only with Platform credential):

1. Admin issues TAP (multi-use, 4 hours)
2. User navigates to aka.ms/mysecurityinfo
3. User authenticates with TAP
4. Result:  Access granted — user can register passkey without any step-up, even in a flow authenticate directly to a resource (such as Microsoft Teams browser)

 

Scenario 2 — User with an existing (portable) passkey already registered (in MS Authenticator):

1. Admin issues TAP (multi-use, 4 hours)
2. User navigates to aka.ms/mysecurityinfo
3. User authenticates with TAP
4. Result:  Entra requests a second factor — specifically the existing passkey — before allowing access to My Security Info – Seams system enforces CA002

 

The TAP is accepted as a first factor, but the platform then requires the existing passkey as a second factor before proceeding.

 

---

 

Question

 

Is this behavior documented and expected? Specifically:

 

1. Is it by design that when a user already has a registered MFA-capable method (passkey), the platform enforces step-up authentication before allowing access to My Security Info — even when the user authenticates with a valid TAP?

 

2. If so, does the correct recovery procedure require the admin to first remove all existing authentication methods before issuing a TAP — so the user has no registered methods and the TAP is accepted without step-up?

 

3. Is there any way to allow TAP to bypass this step-up requirement for recovery scenarios, without removing existing methods first?

 

Any pointers to official documentation or confirmed behavior would be appreciated.

Answer 1

1. Yes. This is expected behavior when both policies are in scope.

The documentation states that when multiple Conditional Access policies apply to a sign-in, the user must satisfy all of the authentication strength requirements from those policies:

“In general, when multiple Conditional Access policies apply for a sign-in, the user must meet all conditions from all policies. In the same vein, when multiple Conditional Access authentication strength policies apply to the sign-in, the user must satisfy all of the authentication strength conditions.”

For security info registration specifically, authentication strengths that target Register security info are preferred over strengths that target All resources, but only in terms of which authentication strength policy is used for the MFA requirement. Other grant controls from other CA policies still apply:

“Authentication strengths that target the user action of Registering security info are preferred over other authentication strength policies that target All resources… All other grant controls … from other Conditional Access policies that are in scope for the sign-in apply as usual.”

In the example given in the documentation, a tenant:

1. Has a CA policy for All resources requiring a strong MFA strength and compliant device.
2. Has a CA policy for Register security info that allows TAP for bootstrap.

Result:

“Users on a compliant device can use a TAP to register any MFA method. They can then use the newly registered method to authenticate to other resources like Outlook.”

Your configuration is analogous:

• CA001 (Register security information) allows TAP as part of a custom “Bootstrap and Recovery” strength.
• CA002 (All cloud apps) requires the built-in Phishing-resistant MFA strength.

When the user already has a phishing-resistant method (passkey), CA002 is still in scope for the sign-in, so the user must satisfy that strength as well. TAP alone does not satisfy the Phishing-resistant MFA strength, so Entra prompts for the existing passkey as a step-up. This matches the documented “must satisfy all” behavior.

2. The documentation does not state that the correct recovery procedure must remove all existing methods first.

The documented pattern for bootstrap/recovery is:

“For new users or users without MFA, go through a process to issue users a TAP… Once users have a TAP, they're ready to bootstrap their first phishing-resistant credential.”

and

“As a result, users on a compliant device can use a TAP to register any MFA method. They can then use the newly registered method to authenticate to other resources like Outlook.”

The docs describe TAP as a way to bootstrap or recover when users don’t already have usable MFA. They do not prescribe removing existing methods as a required step. Instead, the example focuses on:

• Using TAP to allow registration of MFA methods (via the Register security info policy), while
• Using a separate policy for All resources that does not include TAP.

In your scenario, the step-up occurs because the All cloud apps policy is still active and requires a phishing-resistant method that TAP does not satisfy. Removing methods is one way to avoid that step-up, but it is not documented as the required or recommended procedure.

3. To allow TAP-based recovery without step-up, the documented approach is to scope the phishing-resistant policy so it does not block the TAP bootstrap flow, rather than to bypass it.

The documentation’s example shows how to allow TAP for registration while still enforcing strong MFA for normal sign-ins:

1. Create a custom strength (for example, Bootstrap and recovery) that includes TAP and any MFA methods.
2. Create a separate strength (for example, MFA for sign-in) that includes only the allowed MFA methods without TAP.
3. Apply the MFA for sign-in strength to All resources.
4. Apply the Bootstrap and recovery strength to the Register security information user action.

Key point:

“Authentication strengths that target the user action of Registering security info are preferred over other authentication strength policies that target All resources… All other grant controls … apply as usual.”

To avoid the step-up in recovery scenarios, configuration must ensure that the All cloud apps policy does not require an additional phishing-resistant strength that TAP cannot satisfy for that specific sign-in. Options (all configuration choices, not code changes) include, for example:

• Adjusting the scope of the phishing-resistant policy (e.g., excluding the Register security information user action or the relevant endpoints), and relying on the TAP-enabled Register security info policy for that flow, or
• Using a custom strength for All resources that includes TAP if the security posture allows it.

The documentation does not describe a mechanism for TAP to “override” or bypass another in-scope authentication strength. Instead, it clarifies that all applicable strengths must be satisfied and that the way to enable TAP-based recovery is through Conditional Access design (separate strengths and scopes) as shown in the example.

---

References:

• How Conditional Access authentication strengths work
• Configure Temporary Access Pass to register passwordless authentication methods
• Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID
• Passwordless for Students