Since passkeys became a mainstream option in Entra ID, the conversation around passwordless authentication has shifted a lot. The interesting part starts once you go past basic enablement and manage authentication strengths and key types by group. Passkey profiles in Entra ID are now broadly available after months of preview, and they let organisations apply different FIDO2 and Authenticator passkey settings to different user groups. In my projects, this has been the missing piece. It lets you enforce higher standards for admins, support only specific security keys, or introduce attestation requirements without making life harder for everyone else.

Passkey profiles replace one global policy with targeted settings

Before passkey profiles, FIDO2 and Authenticator passkey settings in Entra ID applied globally, and all you could do was configure basic exclusions. Now you can create several profiles with different configurations and assign each one to specific users, groups or administrative units. In practice that makes a real difference. You might allow only certain hardware keys (filtered by AAGUID) and require attestation for admins, while standard users register passkeys in Microsoft Authenticator because it's easier for them. You no longer have to apply the same rules to everyone, so the controls can match the actual risk and audience.

In the Entra admin center, go to Entra ID → Authentication methods → Policies. There you can set up separate FIDO2 and Authenticator passkey profiles, assign the target group, configure AAGUID allow lists and attestation requirements, and even set a maximum number of passkeys per user. A typical setup might look like this:

flowchart TD
    AdminProfile["Admin profile"] --> AAGUIDfilter["AAGUID filter: Only hardware key"]
    AdminProfile --> Attestation["Attestation: Required"]
    AdminProfile --> GroupAdmins["Assignment: Admin group"]
    UserProfile["Standard user profile"] --> AuthPasskey["Authenticator passkey allowed"]
    UserProfile --> AAGUIDopen["AAGUID: No restriction"]
    UserProfile --> GroupUsers["Assignment: User group"]

Figure: Separate passkey profiles for admins and standard users in Entra ID.

AAGUID filters and attestation decide which keys get through

The mistake I run into most often during passkey rollouts is an AAGUID allow or deny list that is either too broad or too narrow. If your organisation has tighter governance requirements, I'd strongly recommend allowing only models you have tested and approved. Your own registration data is the best source for AAGUIDs. Set up test accounts, register each supported key, and pull the AAGUIDs from the device details in the Entra admin center or with PowerShell/Graph. Authenticator passkeys have their own AAGUIDs depending on the platform (iOS, Android). The Microsoft docs on FIDO2 AAGUIDs and Authenticator passkeys have the details.

When attestation is enforced, every key has to provide verifiable proof of origin at registration. For admin profiles this is essential, because it keeps homebrew FIDO2 devices out. Not every key supports attestation, though, so check your key inventory before you switch it on. Otherwise your support team will be dealing with a wave of failed registrations.

Practical tip: If a user can't register a passkey, check their group membership, the profile assignment, and whether the key's AAGUID is on your allow list. Starting strict and loosening controls only where needed carries much less risk than doing it the other way round.

Admins still stick to device-bound hardware keys

Now that Microsoft Authenticator supports synced passkeys, it's tempting to let everyone use them, admins included. Most security teams I work with still limit admin accounts to device-bound (non-synced) hardware keys. Their reasoning is straightforward. Synced passkeys are convenient, but if the phone is compromised they could be misused across multiple devices. Hardware keys never leave the device, which keeps the risk lower for admins. In the passkey profile you can enforce this by allowing only non-synced (device-bound) keys for specific groups.

The settings live in the Entra admin center

You'll find everything under Entra ID → Authentication methods → Policies in the Entra admin center. AAGUIDs can be collected from the device details page or with PowerShell. For example (this requires Global Admin and the Microsoft Graph PowerShell module):

Get-MgUserAuthenticationFido2Method -UserId <UserId>

The cmdlet returns the AAGUIDs of all keys a given user has registered, which is exactly what you need to build your allow list. Attestation is a simple toggle, and you can assign profiles to users, groups or administrative units. In larger environments I recommend starting profiles in report-only mode and watching the impact before the actual rollout.

Passkey profiles are becoming the norm, but governance decides the outcome

I keep seeing the same pattern. Passkey profiles in Entra ID are changing how MFA policies are built, but the result depends much more on governance and discipline than on the technology. The direction is towards more granular, risk-based controls, particularly for admin accounts. My advice is to require attestation and hardware keys for admins, keep your AAGUID allow lists carefully maintained, and test before you enforce any new restriction. The Microsoft documentation covers all options currently available, and the Message Center is where new features and changes show up first.

If you want to dig into reporting and what authentication method migrations look like in a real tenant, have a look at my article Authentication methods report: Real tenant security insights.