Microsoft Entra ID: Passkeys (FIDO2) – What to Configure and Why

Starting in March 2026, Microsoft is rolling out the Passkey profiles feature. This expands the configuration options for the Passkey (FIDO2) authentication method and is also a breaking change: existing settings are being migrated into the Default passkey profile, and a distinction is being introduced between passkey types (device-bound vs. synced).

In tenants where the Passkey (FIDO2) method is enabled and attestation is not enforced, synced passkeys will become enabled. And if you are also using the Microsoft-managed registration campaign, users may start seeing prompts to register passkeys after signing in to Microsoft 365, which often results in a certain amount of helpdesk noise. You can read more about this in the excellent article Microsoft Entra ID Will Auto-Enable Passkey Profiles in March 2026.

I do not want to dissect the change itself here. Instead, I would rather share our practical recommendations for configuring Passkey (FIDO2), which we use both internally and with our customers. If this helps you avoid surprises, then it has served its purpose 🙂

Passkey (FIDO2) configuration

Enforce Attestation

This is the mechanism by which the device storing the private key proves what it actually is — the device type, manufacturer, model, and sometimes even the certification level — and proves it cryptographically.

It ensures that:

• the Passkey / FIDO2 key being added is device-bound (only hardware devices and Microsoft Authenticator on iOS/Android are capable of performing attestation)
• during registration, the device proves itself cryptographically through attestation, which significantly reduces the ability to spoof its identity / AAGUID and pretend to be a different type of key

If attestation is not enforced:

• Users can use not only hardware FIDO2 keys, but also passkeys stored in virtually any application. For example, in any password manager, where we have no idea where the database is stored or how it is protected. We may not even know whether access requires strong authentication and a strong password, or whether the private key can be exported. In my view, this could lead to a situation where a passkey ends up being a less secure authentication method than a password combined with MFA via push notification.
• As a form of persistence, attackers can register a new FIDO2 / passkey credential for a user and lie about its AAGUID. For example, they can create a new passkey that they store only in a file on their side, which can be copied or shared with anyone and has no protection at all, but during registration in Entra ID they claim that it is a hardware FIDO2 key such as YubiKey 5 Series with NFC HW FIDO2 (2fc0579f-8113-47ea-b116-bb5a8db9202a). This is already a technique being used in practice, not just theory.

Restrict specific keys

This allows you to narrow down which types of FIDO2 keys and passkey stores users are allowed to use. In combination with Enforce Attestation, it works very well.

Without Enforce Attestation, however, it works only partially. It will successfully limit regular users, because they are not able to spoof a key’s AAGUID. An attacker, however, can spoof the AAGUID and impersonate any allowed key.

Device-bound vs. synced keys

We consider device-bound FIDO2 / passkeys to be a very secure authentication method. In Entra ID, this method is treated as both multifactor and phishing-resistant. In practice, this means that when FIDO2 / passkeys are used, Entra ID does not require any additional MFA step (such as SMS, OTP, or push notification). Likewise, for the detection of risky or suspicious sign-ins, it is a strong signal that the authentication is legitimate, which in my opinion also contributes to false-negative detections.

The problem, however, is that Entra ID will likely treat device-bound keys as being just as secure as synced ones. In reality, they are not equally secure. A synced key can be cloned or exported by design, and it does not necessarily test proof of presence or require multifactor authentication for access. FIDO2, on the other hand, requires a PIN or biometric verification together with proof of presence.

What configuration we recommend to our customers

• Enable the Passkey (FIDO2) authentication method for registration for all users. Even if you do not yet want to use it as the primary authentication method, users can start adopting it gradually.
• Allow hardware FIDO2 keys and device-bound passkeys stored in Microsoft Authenticator (iOS/Android).
• For privileged accounts, allow hardware FIDO2 keys only (this avoids the risk arising from compromise of the mobile phone operating system).
• As a less secure alternative, if you want to allow synced passkeys for regular users, combine this with an allowlist and permit only selected passkey providers / stores (AAGUIDs), such as iCloud Keychain or Google Password Manager — in other words, allow only those that we know make a reasonable effort to protect passkeys.

Below is a screenshot showing the configuration that allows hardware FIDO2 keys and device-bound passkeys stored in Microsoft Authenticator (iOS/Android) for all users in the tenant:

Conclusion

I will be glad if sharing our experience has been helpful to you. If you feel lost in Entra ID configuration, feel free to contact me. Our company specializes in the management and security of Entra ID (Microsoft 365), and we can help you with it.