Journey To Passwordless: Restrict FIDO2 key usage & conclusion

Blog series

  1. Passwordless: But why?
  2. Enable passwordless
  3. Temporary Access Pass
  4. FIDO2 Security keys
  5. Windows 10 device onboarding and Windows Hello for Business
  6. PowerShell administration without a password
  7. Microsoft Authenticator app
  8. Restrict FIDO2 key usage & conclusion

Advanced settings

In the last blogpost of the series it gets a bit more technical. Because for FIDO2 Security Keys as a login method, some additional settings can be configured in the Azure Portal.

  • Allow self-service set up
  • Enforce attestation
  • Enforce key restrictions - Restrict specific keys (Allow/Block)

Allow self-service set up

This setting must remain set to “Yes” as of 07/2021. If this setting is set to “No”, it is no longer possible for a user to add a FIDO2 security key. However, since it is also not possible to register a key for the user, “No” would effectively prevent the use of new keys.

Enforce attestation

If attestation is enforced, the FIDO2 key must identify itself to the Entra ID (Azure AD) (Relying Party) during initial registration.

In order for the FIDO2 key to support this at all, the manufacturer must submit a metadata statement with the supported features of the FIDO2 security key during certification, which is then distributed by the FIDO2 Alliance. For each key model, the vendor assigns an Authenticator Attestation Globally Unique ID which later identifies the exact model.

During the registration process, Entra ID (Azure AD) requests certain features of the key using a policy statement. If no supported security key is found, registration is not possible.

If the key supports all requirements, in this case attestation, the FIDO2 key sends additional information back to Entra ID (Azure AD). In addition to the AAGUID, this includes a signature that is created with the private key of the Attestation Certificate. This private key is written to the FIDO2 Security Key by the manufacturer during production and is not deleted even during a full reset of the key.

The Entra ID (Azure AD) can use this signature to verify that the FIDO2 key really matches the specified model, preventing a FIDO2 key from just pretending to support all requirements. For this purpose, Entra ID (Azure AD) uses the public keys stored in the metadata statement or checks whether the signature was signed by a certificate (trust chain) specified in the metadata statement.

Authenticator Attestation GUID (AAGUID)

The Authenticator Attestation Globally Unique ID is a unique identifier with a length of 128 bits. It is assigned by the manufacturer of the key, whereby it is sufficient for the manufacturer to define one AAGUID per model series. In the case of Yubikey, there are also some duplicates since the AAGUID does not refer to the interface of the key (e.g. USB-C or USB-A), but to the installed security chip.

The format corresponds to RFC4122 and is represented as five hexadecimal segments separated by a dash.

Example: 0076631b-d4a0-427f-5773-0ec71c9e0279

This GUID can be retrieved from various locations in Entra ID (Azure AD).

Security Info Portal

Each user can display the AAGUID in the Security Info area itself.


Azure AD Portal

As an administrator, you can also access the corresponding information in the authentication methods of the user, via View details.


Graph API

And of course, this info is also available in the Graph API.

    "@odata.type": "#microsoft.graph.fido2AuthenticationMethod",
    "id": "3f0S9SVSIKt4Ti9ZtgFjSHf7ahkNN3js0FTPe5dPD4o1",
    "displayName": "FEITIAN AllinPass FIDO2",
    "creationDateTime": "2021-05-13T14:19:39Z",
    "createdDateTime": "2021-05-13T14:19:39Z",
    "aaGuid": "12ded745-4bed-47d4-abaa-e713f51d6393",
    "model": "Feitian BioPass FIDO USB/NFC/BLE",
    "attestationCertificates": [
    "attestationLevel": "attested"

Well known AAGUIDs

The following AAGUIDs are currently known to me. I will expand this list if and when I find more AAGUIDs. Yubico also offers an overview on its own website.

Vendor Devicename FIDO2 AAGUID
FEITIAN FIDO Java card 2c0df832-92de-4be1-8412-88a8f074df4a
FEITIAN FIDO fingerprint card 8c97a730-3f7b-41a6-87d6-1e9b62bda6f0
FEITIAN MultiPass FIDO 310b2830-bd4a-4da5-832e-9a0dfc90abf2
FEITIAN iePass FIDO 6e22415d-7fdf-4ea4-8a0c-dd60c4249b9d
FEITIAN ePass FIDO 833b721a-ff5f-4d00-bb2e-bdda3ec01e29
FEITIAN ePass FIDO NFC ee041bce-25e5-4cdb-8f86-897fd6418464
FEITIAN BioPass K26/K27 77010bd7-212a-4fc9-b236-d2ca5e9d4084
FEITIAN BioPass K26/K27 Plus b6ede29c-3772-412c-8a78-539c1f4c62d2
FEITIAN BioPass K45 77010bd7-212a-4fc9-b236-d2ca5e9d4084
FEITIAN BioPass K45 plus b6ede29c-3772-412c-8a78-539c1f4c62d2
FEITIAN Allin Pass 12ded745-4bed-47d4-abaa-e713f51d6393
Yubico YubiKey 5 (USB-A, No NFC) cb69481e-8ff7-4039-93ec-0a2729a154a8
Yubico YubiKey 5 (USB-A, No NFC) ee882879-721c-4913-9775-3dfcce97072a
Yubico YubiKey 5 NFC fa2b99dc-9e39-4257-8f92-4a30d23c4118
Yubico YubiKey 5 NFC 2fc0579f-8113-47ea-b116-bb5a8db9202a
Yubico YubiKey 5 NFC FIPS c1f9a0bc-1dd2-404a-b27f-8e29047a43fd
Yubico YubiKey 5 Nano cb69481e-8ff7-4039-93ec-0a2729a154a8
Yubico YubiKey 5 Nano ee882879-721c-4913-9775-3dfcce97072a
Yubico YubiKey 5C cb69481e-8ff7-4039-93ec-0a2729a154a8
Yubico YubiKey 5C ee882879-721c-4913-9775-3dfcce97072a
Yubico YubiKey 5C Nano cb69481e-8ff7-4039-93ec-0a2729a154a8
Yubico YubiKey 5C Nano ee882879-721c-4913-9775-3dfcce97072a
Yubico YubiKey 5C NFC 2fc0579f-8113-47ea-b116-bb5a8db9202a
Yubico YubiKey 5C NFC FIPS c1f9a0bc-1dd2-404a-b27f-8e29047a43fd
Yubico YubiKey 5Ci c5ef55ff-ad9a-4b9f-b580-adebafe026d0
Yubico Security Key By Yubico f8a011f3-8c0a-4d15-8006-17111f9edc7d
Yubico Security Key By Yubico b92c3f9a-c014-4056-887f-140a2501163b
Yubico Security Key NFC (5.1) 6d44ba9b-f6ec-2e49-b930-0c8fe920cb73
Yubico Security Key NFC (5.2, 5.4) 149a2021-8ef6-4133-96b8-81f8d5b7f1f5
Yubico YubiKey Bio Series d8522d9f-575b-4866-88a9-ba99fa02f35b

Enforce key restrictions - Restrict specific keys

With this setting you can prevent the use of certain security keys. You have the choice whether you want to maintain a block or an allow list.

A block list makes sense, if it is known that certain FIDO2 keys should not be used, because they do not meet the desired security requirements.

By means of an Allow list, for example, the use of certain FIDO2 keys released by the company could be enforced.

During the setup, the user is not aware of these requirements. Only in the last step of the setup, after assigning a name, the key is rejected.

We detected that this particular key type has been blocked by your organization. Contact your administrator for more details and try registering a different type of key.


In the Entra ID (Azure AD) audit log this is displayed as status clientError and the reason User failed to register Fido.



The use cases of passwordless considered in this blog series show how extensively this topic is already supported in the Microsoft cosmos. Especially in environments where users work 100% with cloud services, there is really no reason not to go this route.

In addition to the many security advantages, the sign-in with FIDO Security Keys, especially if they can be unlocked with biometric features, offers a big plus in terms of user comfort. For users, this type of authentication has now become standard with modern smartphones and can finally be used in the workplace. While Windows Hello for Business has offered this for some time with its support for cameras and fingerprint sensors, the use of FIDO2 keys brings advantages in areas where a fixed workstation is not used and work is more likely to be done at a kiosk PC.

Certain limitations, such as the fact that it is not possible to provision a FIDO2 key for an end user, or that they are not yet supported on smartphones, slightly tarnish the positive overall impression. However, there is a good alternative with the Authenticator app.

In an environment that is strongly dominated by Windows 10 clients, the advantages for the user are already enormous. However, if you leave this context, you have to hope for Apple or Google and fall back on the sign-in methods available in ChromeOS and macOS. This is where the convenience for the end user is lessened, especially in the kiosk PC scenarios mentioned above.

What I haven’t examined at all in this series is working in a hybrid environment. Here, too, passwordless work is already possible today, but the planning and implementation effort is much greater. Depending on the usage scenario, it can quickly become necessary to set up a PKI environment or adapt the existing one. These are all no hindrances, but the “rapid” implementation of a PKI also entails major risks.

My excursion into the world without a password does not come to an end here, but the next posts will appear in a separate series and will not be ready in the next few weeks.