I'm a solo IT administrator in a manufacturing environment and I'm trying to improve our Microsoft 365 and Entra security controls. I want to create a proper emergency access account protected by a physical FIDO2 USB security key, ideally without requiring Microsoft Authenticator or any other MFA method.
My attempts have led to two problems: either signing in with the key and PIN fails completely, or Entra requires the account to register both Microsoft Authenticator and the hardware key. The sign-in logs show that Conditional Access blocked token issuance and that the account could not satisfy the configured authentication strength because none of its available methods were allowed.
I was considering starting over with a fresh account that has no registered MFA methods, then using an enrollment process that permits only the approved hardware key. What combination of authentication method settings, authentication strength, Conditional Access exclusions, and enrollment steps should I use?
3 Answers
Enable FIDO2 security keys under Entra ID’s authentication methods. If you want to restrict enrollment to specific physical keys, enable key restrictions and allow-list the AAGUIDs for the exact models you use. Attestation can also help prevent software-based credentials from being accepted.
For Conditional Access, use a custom authentication strength containing only FIDO2 security keys. The built-in phishing-resistant MFA strength may also allow Windows Hello for Business or certificate-based authentication, so it is broader than USB-only FIDO2.
For initial enrollment, issue a Temporary Access Pass, use it to register the security key, and let the TAP expire afterward. Also issue two keys per person and keep the spare secured offline.
You may not actually need to block every other passkey type. A simpler design is to assign the approved FIDO2 keys as the MFA method, store the emergency credentials in a secure vault, and alert whenever the account’s authentication methods or recovery information changes.
If you do want USB-only authentication, check every applicable Conditional Access policy and exclude the emergency account where appropriate. Also inspect the authentication-method registration and usage details: a registered passkey marked as disabled by policy generally means another method policy or Conditional Access authentication strength is overriding the registration. Windows Hello for Business and Microsoft Authenticator may be included by a broader phishing-resistant or MFA requirement, which can explain why Entra asks for both methods.
I found that the custom authentication strength was allowing Windows Hello alongside the hardware key. Removing that alternative and reviewing the exclusions made the behavior much more predictable.
Those errors usually mean two separate policies are conflicting. A new account with no registered methods cannot satisfy a FIDO2-only authentication strength until it has a temporary bootstrap method, such as a Temporary Access Pass. A multi-use TAP gives enough time to sign in and complete key registration.
Also review the FIDO2 method policy itself. Key restrictions, attestation, and unsupported AAGUIDs can all cause the key registration or sign-in to fail without a very helpful error message.
Be careful with the emergency-account design, though. Microsoft’s usual guidance is to exclude at least one emergency access account from Conditional Access policies, including managed policies, and monitor and test it regularly. That account is intended to remain usable when normal authentication policies or identity services fail. If you want a FIDO2-enforced administrative account, use a separate account rather than making your only break-glass account dependent on the same controls you may need to bypass.
That distinction helped: one account can be a tightly controlled FIDO2 admin account, while the true emergency account stays excluded, with its credentials protected offline and its use heavily monitored.
That explains the enrollment problem. I was trying to make the account satisfy a phishing-resistant requirement before it had any phishing-resistant method registered.