I manage a small Microsoft 365 tenant with about 80 users, Business Premium, and 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 cross-registered YubiKey 5 NFC security keys. The keys will be stored in separate physical locations, while each account's long random password and FIDO2 PIN will be stored separately in a password manager. Authenticator was removed, and password expiration was disabled through Graph.
The passwordless FIDO2 sign-in works normally. However, when I enter the account password, Entra accepts it as single-factor authentication and then displays an identity-verification screen requiring a face, fingerprint, PIN, or security key. There is no Skip option. The sign-in log shows error 50125, indicating that the user must provide password-reset registration information. The only way to continue is to use the YubiKey.
That means the password is not a practical emergency fallback by itself. Is this expected for Global Administrator break-glass accounts using FIDO2, or is there a setting that would allow password-only recovery? Also, does this design seem reasonable, given the two keys, separate storage, separate password records, periodic testing, and Microsoft Support as the last-resort recovery path?
4 Answers
Many organizations keep more than two recovery keys or distribute additional copies among trusted administrators, but the right number depends on your physical-security and access-control model. Losing both keys could leave you dependent on Microsoft’s recovery process, and a promised 24–72 hour resolution should be treated as an estimate rather than a guaranteed escape hatch. Keep at least one ordinary administrative path available for normal operations, while reserving the break-glass accounts for genuine emergencies.
That behavior is generally expected, and password-only recovery is not a good fallback for an emergency Global Administrator account. If the account is being forced through SSPR registration, you may be able to exclude the break-glass accounts from the SSPR registration requirement or configure registration enforcement not to apply to them. That explains why Conditional Access appears as not applied. Even if the password path can be reopened, relying on password-only access undermines the purpose of the emergency account’s stronger controls.
The overall approach is reasonable: use two separately stored hardware keys, keep the credentials separate from the keys, and avoid personal email or phone dependencies. I would add formal ownership and handover procedures for the safes, especially if an employee can access one. Make sure the two accounts and their storage arrangements do not share exactly the same failure mode.
Also document what happens if a keyholder leaves, loses a safe combination, or is unavailable. Physical access and succession planning are just as important as the Entra configuration.
Add monitoring and regular testing. Alert on every sign-in, password change, authentication-method change, and unusual activity involving either emergency account. Test each key on a scheduled basis—monthly, quarterly, or at least every six to twelve months—and record the result so the process is not just theoretical.
A rotation where on-call administrators verify the keys and know where they are stored is useful. It confirms both that the hardware works and that people can actually retrieve it during an incident.
The important distinction is that the SSPR registration prompt may be configurable, but that does not make password-only access a sound recovery design. The security key should remain the intended authentication method.