Forum Discussion
TAP requires step-up MFA when user already has a passkey registered — expected behavior?
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):
- Admin issues TAP (multi-use, 4 hours)
- User navigates to aka.ms/mysecurityinfo
- User authenticates with TAP
- Result: Access granted — user can register passkey without any step-up, even in a flow authenticating directly to a resource (such as Microsoft Teams in browser)
Scenario 2 — User with an existing portable passkey already registered (in MS Authenticator):
- Admin issues TAP (multi-use, 4 hours)
- User navigates to aka.ms/mysecurityinfo
- User authenticates with TAP
- Result: Entra requests a second factor — specifically the existing passkey — before allowing access to My Security Info. Seems the system enforces CA002 or a platform-level step-up requirement.
The TAP is accepted as a first factor, but the platform then requires the existing passkey as a second factor before proceeding.
Sign-in log analysis: The behavior does not appear in the Conditional Access tab of the sign-in logs as a CA policy failure — it appears to be enforced at the platform level, not by any configured CA policy.
Questions
- 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?
- 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?
- 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.
3 Replies
It seems to me like Passkey registration is currently broken. Like.. even with no restrictions in place, using mysignins.microsoft.com fails to complete passkey registration for me - at the final step.
Audit logs show a group sync query, then 'user failed to register security info'. There's no indication in sign-ins logs. But it's happening across multiple tenants.
That being said, Microsoft has recently also made a mess of the Registration campaigns - we had a random assortment of credentials try to force passkey setup during auth. This is set under Authentication Methods > Registration Campaigns. This could be why you're getting a passkey demand.I’ve already verified that Registration Campaigns are disabled.
I also have a Conditional Access policy targeting “Register security information”, with a custom Authentication Strength that allows:
- Windows Hello for Business/Platform credential
- FIDO2
- Temporary Access Pass (TAP)
However, based on the logs, this policy is not even being evaluated. Instead, it seems that the system always applies the main Conditional Access policy enforcing phishing-resistant authentication.
What’s even more concerning is the inconsistent behavior:
1. Passkey registration during sign-in
- When a user does not have any passkey registered, the sign-in flow forces passkey registration.
- When a user already has a passkey registered, they cannot register another one, even when using TAP.
This doesn’t make sense. In a scenario where a user has lost access to all their passkeys, TAP should allow registering new ones, even if others are already present.
2. ADE (Apple Device Enrollment) scenario on macOS
- If the user already has a passkey configured, I cannot proceed using only TAP — the system still requires passkey authentication.
- If the user has no passkey configured, I cannot proceed either — because the system forces passkey registration, which is not possible within the ADE flow.
I also have a Conditional Access policy targeting “Register devices”, so this should be properly scoped.
3. Additional testing performed
I performed an extreme test:
- Created a Conditional Access policy enforcing phishing-resistant authentication
- Explicitly excluded ALL cloud apps
The behavior remains unchanged.
Conclusion / Suspected issue
It appears that:
- The system is always enforcing passkey-based authentication, even when TAP is issued
- If the user has no passkey → they are forced to register one
- If the user already has a passkey → they cannot register additional ones
This behavior is inconsistent and breaks expected scenarios, particularly:
- Recovery scenarios using TAP
- macOS ADE setup flows
TAP works clean for users with no methods, but a user who already has a passkey gets asked to step up with that passkey before reaching My Security Info. Looks like platform behavior, not CA.
Yes, this is by design, and you are right that it is not coming from your Conditional Access policies. A Temporary Access Pass is meant as a bootstrap credential for someone who has nothing yet, or for getting back in. Once an account already holds a strong method like a passkey, Entra will not let a TAP quietly override or sit alongside it, so it asks the user to prove possession of the existing strong method before letting them into the security info portal to add or change methods. That step up is the platform protecting an account that is already in a good state, which is why it only appears in your second scenario.
So to your three questions:
It is expected behavior, not a misconfiguration.
For a genuine recovery where the user has lost access to the existing passkey, the supported pattern is for an admin to delete that method first, then issue the TAP. With the strong method gone, the account is back to the "nothing to step up against" state and the TAP flows through cleanly, exactly like your first scenario.
There is no supported switch to bypass the step up while the strong method still exists, and that is intentional. If there were, a TAP would become a way around an existing passkey, which would defeat the point of phishing resistant auth. So the recovery runbook is: confirm identity out of band, admin removes the lost method, issue TAP, user re registers.
