I'm a one-person IT team in a manufacturing environment, and I'm trying to improve our Microsoft 365 and Entra ID security practices. One goal is to create a properly protected emergency access account that uses a physical FIDO2 USB security key, without requiring Microsoft Authenticator or other MFA methods.
I've tried several Conditional Access and authentication-method configurations, but I keep running into one of two problems: either signing in with the key's PIN and tap fails completely, or Entra requires the account to register Microsoft Authenticator in addition to 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 permitted methods qualified.
Ideally, I'd like to start with a fresh account and have an enrollment process where it registers only an approved hardware key. What combination of FIDO2 settings, authentication strengths, Conditional Access exclusions, and enrollment steps should I use?
3 Answers
You may not need to prohibit every other passkey type if the real problem is that another policy is forcing Microsoft Authenticator alongside the hardware key. First identify which Conditional Access policy is requiring that extra registration, then exclude the emergency account where appropriate.
If you do want USB-only authentication, use a custom authentication strength with the approved FIDO2 AAGUIDs and avoid adding Windows Hello as an alternative. In the authentication-method settings, also check whether the registered passkey is shown as disabled by policy; that usually means the method policy, authentication strength, or an overlapping Conditional Access rule does not permit that credential.
Those two errors usually point to separate issues. A new account with no registered methods cannot complete FIDO2 enrollment by itself, so use a Temporary Access Pass for the first sign-in and key registration. A multi-use TAP gives you more flexibility than a short one-time pass.
Also review every Conditional Access policy affecting the account. An emergency access account is commonly excluded from the normal Conditional Access policies, including policies that require a different authentication strength. Put the account in a clearly named emergency-access group, document the exception, and test the account regularly so the recovery path is known to work.
Check the FIDO2 policy too: restrictions or attestation can reject a key even when the Conditional Access configuration looks correct.
I’m going to rebuild the policy from scratch and review all inherited and Microsoft-managed policies. The authentication-strength message was misleading until I realized another policy could still be requiring a method the account was never meant to use.
For the FIDO2 method, enable security keys and turn on key restrictions so you can allow-list the AAGUIDs for the exact hardware models you issue. Enforce attestation as well if you want to ensure that only approved physical keys are used.
For Conditional Access, create a custom authentication strength containing only FIDO2 security keys. The built-in phishing-resistant strength can also accept Windows Hello for Business and certificate-based authentication, so it is broader than USB-only.
For initial enrollment, issue the account a Temporary Access Pass, use it to register the security key, and then let the TAP expire. Keep two keys available for each critical account or administrator, with the spare stored securely.
That enrollment sequence makes sense. The TAP avoids the chicken-and-egg problem where a new account needs a phishing-resistant method before it can register one.
That distinction is helpful. I may have been solving the wrong problem by restricting passkeys more than necessary. I’ll trace which policy is forcing Authenticator and verify that the registered key’s AAGUID is allowed.