Are FIDO2-only break-glass accounts supposed to require a security key after password sign-in?

0
8
Asked By MellowOrbit42 On

We have a small Microsoft 365 tenant of about 80 users on Business Premium with Entra ID P1. After replacing Security Defaults with Conditional Access, I created two unlicensed Global Administrator emergency accounts. They are excluded from all Conditional Access policies, have no per-user MFA, and are not members of any other groups.

Both accounts now use YubiKey 5 NFC security keys. Two keys are registered to both accounts and will be stored in separate physical locations. The old Authenticator method was removed, and each account has a long random password with password expiration disabled through Graph.

The passwordless FIDO2 flow works normally: the key is inserted, the PIN is entered, and the key is touched. Entra may ask the user to register another authentication method, but that prompt can be skipped.

However, signing in with just the password behaves differently. The password is accepted and the sign-in log shows successful single-factor password authentication. Conditional Access policies are shown as not applied, but Entra then displays a verification screen offering only face, fingerprint, PIN, or security key. There is no option to skip it. The sign-in event reports error 50125 and says the user must provide password-reset information. The only way to continue is to use the YubiKey.

Is this expected for FIDO2-only emergency administrator accounts, or is there a tenant or SSPR setting that would permit password-only fallback? Also, is the overall design reasonable: two cross-registered keys in separate safes, passwords and PINs stored separately, regular testing, and Microsoft Support as the recovery path if both keys are lost? I intentionally avoided adding phone or email recovery methods because they would recreate the dependency I was trying to remove.

4 Answers

Answered By CedarFox88 On

The behavior is expected in practice: the password can satisfy the initial sign-in, but Entra is then requiring the account to complete its password-reset or authentication-method registration flow. That is separate from Conditional Access, which explains why the policies show as not applied. You may be able to exclude the emergency accounts from SSPR registration requirements or change the setting that forces users to register when signing in, but deliberately enabling password-only access for Global Administrators is generally a poor emergency design. A password-only fallback undermines the protection these accounts are meant to provide.

Answered By PixelSparrow19 On

Some organizations keep the break-glass accounts in scope for a phishing-resistant authentication policy instead of excluding them from every policy. Whichever approach you choose, the important properties are that the emergency accounts are monitored, rarely used, regularly tested, and protected by a method that remains available during an ordinary identity or device outage. Adding email, phone, or a personal authenticator may improve recoverability, but it also creates dependencies and attack paths that need to be weighed against the threat model.

Answered By NovaHarbor7 On

The physical-key design is reasonable, and several people use a similar model. Keep at least two keys in genuinely separate locations, test them on a schedule, and alert on every sign-in, password change, authentication-method change, or other activity involving either account. Consider testing access quarterly or at least every six to twelve months rather than waiting for an outage.

QuietMaple31 -

It is also worth having the two accounts differ in more than just their location. If both accounts depend on the same authentication method, tenant configuration, or operating procedure, one failure can affect both at once.

Answered By AmberKite56 On

The biggest risk is operational rather than technical. Document who controls each safe, how access is transferred when someone leaves, what happens if a keyholder is unavailable, and how the password manager and keys are recovered independently. Make sure no single person can quietly gain access to both accounts and that the recovery process does not depend on one employee or one building. Treat Microsoft Support recovery as a last resort, not as a guaranteed 24–72 hour escape hatch.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.