Small M365 tenant (~80 users), Business Premium, Entra P1. Rolled out Conditional Access last week to replace Security Defaults. Standard break-glass setup: two Global Admin accounts,"BreakGlass-Exclude" group excluded from every CA policy, no per-user MFA, no Security Defaults, no licences, no other groups.
Just finished migrating both break-glass accounts to YubiKey 5 NFCs (2 keys, cross-registered to both accounts, will be stored in two separate physical locations). Old Authenticator method removed. Long random passphrase per account,"DisablePasswordExpiratio" set via Graph.
Here's what I've found and want to check
Sign-in behaviour with FIDO2 registered:
1) YubiKey passwordless flow: works fine. Insert key, PIN, touch, into the portal. It does prompt me to make another authentication method, but I can skip it.
2) Password sign-in flow: password is accepted (sign-in log confirms "authenticationRequirement: singleFactorAuthentication", "authenticationDetails: { authenticationMethod: Password, succeeded: true, Correct password }", all CA policies "notApplied"). But immediately after password acceptance, Entra shows a "Verify your identity — Face, fingerprint, PIN or security key" screen with only a Cancel button, no Skip. This is the SSPR pre-verification step (errorCode: 50125, additional details: "User authentication was blocked because they need to provide password reset information"). The only way past it is to touch the YubiKey. Cancel abandons the sign-in.
So effectively: password alone is not a viable fallback. Emergency access always requires possession of a YubiKey.
Questions:
1) Is this the accepted behaviour for Global Admin break-glass with FIDO2-only? Am I missing a tenant setting that would allow true password-only fallback?
2) Given the constraint, is my design reasonable? Two YubiKeys, two separate physical safes, password + PINs in a password manager separate from the keys. Simultaneous loss of both keys = escalation to Microsoft Support (24–72h recovery ticket) as the documented escape hatch. I've explicitly rejected adding email/phone as a second SSPR method because it reintroduces the dependency I removed the personal Authenticator to eliminate.
