Windows Hello for Business (WHfB) is a brilliant primary credential - but it lives on one device. When a user needs to sign in on a shared machine, recover from a lost laptop, or authenticate somewhere Hello is not provisioned, a FIDO2 security key is the portable phishing-resistant companion. The catch: if you enable FIDO2 without restrictions, a user can register any random key from a drawer. This post covers deploying FIDO2 alongside WHfB and - the part that actually matters for security - locking registration to the specific key models you trust, by their AAGUID.
The problem: "passwordless" is only as strong as the weakest key you allow
FIDO2 keys are phishing-resistant by design, so it is tempting to switch them on and move on. But not all keys are equal: some enforce a PIN or biometric second factor, some are certified to a hardware standard, and some cheap keys are neither. If your Authentication methods policy allows any FIDO2 key, a user can self-register a consumer key with no second factor and you have a phishing-resistant-in-name credential guarding real access. Control over which keys can register is the whole security story.
Why it happens: attestation and the AAGUID
Two concepts make key control possible. Attestation is the key proving, at registration, what make and model it is - Microsoft Entra ID verifies that claim against trusted metadata. The AAGUID (Authenticator Attestation GUID) is a 128-bit identifier the FIDO2 spec requires every vendor to embed, identical across identical models and distinct between models. Together they let you say "only YubiKey model X and our issued keys may register" and have Entra enforce it.
How to verify
Confirm three things. First, a user in the target group can register an allowed key from the Security info page, and a disallowed key is refused. Second, the registered key's AAGUID (visible in the user's authentication method details) matches your allow-list. Third, accessing the Conditional-Access-protected resource actually demands the FIDO2 key. If registration of an approved key fails, check that the user completed multifactor authentication within the last five minutes - that is a hard prerequisite for registering a passkey.
The fix, part 1: enable passkey profiles
Modern Entra uses passkey profiles - group-based rules rather than one tenant-wide switch, so you can require attestation for admins while being more permissive for frontline staff. As an Authentication Policy Administrator:
- Sign in to entra.microsoft.com as at least an Authentication Policy Administrator.
- Go to Entra ID › Security › Authentication methods › Policies › select Passkey (FIDO2).
- Select the banner link to opt in to passkey profiles (your existing global settings transfer to a Default passkey profile).
- On the Configure tab, set Allow self-service set up to Yes so users can register via the Security info page.
- Select the Default passkey profile › choose the passkey types to allow › Save.
The fix, part 2: restrict which keys can register
In a passkey profile, two controls do the heavy lifting:
| Control | Setting | Effect |
|---|---|---|
| Attestation | Enforce attestation = Yes | At registration, Entra verifies the key's make/model against trusted metadata. Without it, Entra cannot guarantee anything about the key - including whether it is synced or device-bound |
| Key restrictions | Enforce key restrictions = Yes, Behavior = Allow/Block, + AAGUID list | Only the listed key models may register (Allow), or the listed models are refused (Block) |
To create a dedicated profile with these controls:
- Back on the Configure tab, select + Add passkey profile.
- Set Enforce attestation to Yes.
- Set Enforce key restrictions to Yes › choose Behavior (Allow or Block) › add the AAGUID(s) for the key model(s).
- Select Save, then under Enable and Target, add the target group(s) this profile applies to.
In the passkey profile those two controls look like this:
To find a key's AAGUID: work with the vendor, consult Microsoft's list of attestation-eligible keys, or - if the key is already registered - read it from the user's authentication method details in the admin center.
The fix, part 3: require the key for sensitive access
Enabling registration does not force anyone to use it. To require a phishing-resistant FIDO2 sign-in for sensitive resources, use a Conditional Access authentication strength - either the built-in phishing-resistant strength, or a custom one that even pins a specific AAGUID:
Proof it worked
Success is a user registering exactly the key model you sanctioned, an unsanctioned key being turned away at registration, and the sensitive app prompting for the FIDO2 key on next access. Your allow-list is short and matches the hardware you actually issued - not "any FIDO2 key on earth."
References
- How to enable passkeys (FIDO2) in Microsoft Entra ID (passkey profiles, AAGUID)
- FIDO2 security keys eligible for attestation with Microsoft Entra ID
- Conditional Access authentication strengths
- Passwordless security key sign-in to on-premises resources
Script for this post is in Daily-Tasks.