When you finish, your Microsoft Entra ID tenant will accept only the hardware key models you approve, only for the group you choose, and it will require one of those keys at sign-in for that group. One third-party guide puts the configuration at under an hour. The pilot that follows takes weeks.

Know one thing before you start. Turning on passkey profiles cannot be undone. Microsoft's FIDO2 documentation states that "after you opt in to enable passkey profiles, you can't opt out."

What you need

  • Authentication Policy Administrator or Global Administrator

    One of these roles is needed to change the Passkey (FIDO2) policy.

  • Conditional Access Administrator

    This role is needed for the enforcement steps.

  • A Microsoft Entra ID P1 license, or a P1 trial

    Registering keys works in every edition, including Free. Requiring keys through Conditional Access needs P1.

  • A pilot security group

    The federal ALTAuthN playbook suggests 25 to 50 users for a security key pilot.

  • The AAGUID of each key model you will allow

    An AAGUID is the identifier each key model reports to Entra ID. Your key vendor publishes these values.

  • A cloud-only break-glass account

    This is an emergency admin account that you exclude from every Conditional Access policy. Test that it can sign in before you enforce anything.

The brief for this page called for Microsoft's published list of eligible key vendors. We could not confirm that list's current contents from the sources behind this page, so it is not reproduced here. Get your AAGUIDs from your vendor and check them against Microsoft's documentation before you build an allow list.

The steps, in order

  • 1. Open the Passkey (FIDO2) authentication method policy and opt in to passkey profiles.

    If it worked, a profile named "Default passkey profile" appears. It holds your existing tenant-wide FIDO2 settings, which Entra ID moves into it automatically.

  • 2. Create a new passkey profile for the pilot.

    Microsoft's documentation allows up to three profiles, and the Default counts as one. Help Net Security [reported in June 2026](https://www.helpnetsecurity.com/2026/06/02/microsoft-entra-latest-security-updates/) that the limit rose to ten. Check what your tenant shows.

  • 3. Set Enforce attestation to Yes.

    With attestation on, Entra ID checks each key's make and model against trusted metadata when the user registers it. With it off, Entra ID cannot confirm anything about the key, including whether it is a physical key at all.

  • 4. Set the passkey type to device-bound.

    A device-bound key keeps its private key on the physical device. Synced passkeys are copied through cloud providers and do not support attestation, so leave them out of this profile.

  • 5. Add your key models' AAGUIDs as an Allow list.

    If it worked, the profile lists only the models you entered.

  • 6. Assign the profile to your pilot group.

    If it worked, the group appears on the profile's targeting.

  • 7. Confirm that self-service setup is allowed.

    [Yubico's Entra guide](https://docs.yubico.com/cloud-services/fidoprereg-microsoft/config-entra.html) warns that registration fails outright when this setting is off.

  • 8. Have one pilot user register a key.

    If it worked, the key appears in that user's authentication methods. The user must have completed MFA within the past five minutes.

  • 9. Create a custom authentication strength that allows Passkeys (FIDO2) and is limited to your AAGUIDs.

    An authentication strength is the Conditional Access rule that names which sign-in methods are acceptable. The built-in [phishing-resistant strength](/the-authentication-standards-cisa-calls-phishing-resistant/) also accepts Windows Hello and certificate-based authentication, which is why this step builds a custom one.

  • 10. Create a Conditional Access policy that requires that strength. Scope it to the pilot group, exclude the break-glass account, and set it to Report-only.

    If it worked, sign-in logs show what the policy would have done, without blocking anyone.

  • 11. Switch the policy to On once the logs come back clean.

    Microsoft's deployment guide recommends moving in waves: admins first, then everyone else, one platform group at a time.

  • 12. Add the next group to the profile and to the policy.

    Repeat until you cover the whole tenant.

Where this setup breaks

Check three things in this order. First, whether self-service setup is off. Second, whether the user's last MFA was more than five minutes ago. Third, whether their key model's AAGUID is missing from the profile's allow list.

Someone probably removed an AAGUID from an Allow list. Removing a model that was previously allowed blocks every user who registered that model. Put the AAGUID back, or issue those users new keys first.

No. An authentication strength is checked after the first sign-in step, so a user can still type a password. They cannot get past Conditional Access until they use the key.

The policy cannot use "Require multifactor authentication" and "Require authentication strength" together. Remove the first of the two.

Next: backups and lost keys

Your pilot group now signs in with approved keys only. Before you widen the rollout, decide what happens when someone loses a key. Microsoft recommends that every user register at least two methods. How many keys to buy per person, and how to handle backup and recovery, are the same questions whichever identity platform you run.

How many keys per user, and what happens when one is lost?

The pillar guide covers choosing a standard, setting a backup policy and budgeting for keys across the company.

Read the hardware key deployment guide