azureblog.co.uk
← cd ~/posts

Synced passkeys and passkey profiles are now GA in Entra ID

Entra ID now supports passkeys stored in password managers and phone platforms, and lets you set different passkey rules for different groups. Here's how to use both sensibly.

2 min read⚠ checked 18 Mar 2026Entra ID · Passkeys · What's new
Part 2 of 6 in Passwordless rollout
On this page
  1. Synced passkeys
  2. Passkey profiles
  3. A sensible starting design
  4. How Entra decides which rules apply
  5. Rolling it out
  6. Checklist

Two features reached general availability together, and they're designed to be used as a pair.

Device-bound passkey

security key, Authenticator, Windows Hello

  • The key never leaves that device
  • Attestation can confirm the exact model
  • Losing the device means registering again

Synced passkey

stored by a passkey provider

  • Available across the user's devices
  • Survives a lost or replaced phone
  • Less control over where the key lives
The trade-off between the two passkey types.

Synced passkeys

Until now, Entra passkeys were device-bound: tied to one security key or one phone's authenticator. Synced passkeys live in a passkey provider, such as the built-in platform provider on a phone or a third-party password manager, and are available across all of a user's devices.

The trade-off is simple. Synced passkeys are far easier for users: lose a phone, and the passkey is still there on the next device. Device-bound passkeys give you stronger guarantees about exactly where the key lives.

Passkey profiles

Passkey profiles let you define several sets of passkey rules in the authentication methods policy and target each at different groups. Each profile controls:

  • which passkey types are allowed (device-bound, synced, or both)
  • whether attestation is enforced
  • which authenticators are allowed or blocked

If you already had passkeys configured, those settings moved into a default profile automatically. Later updates raised the limit to 10 profiles per tenant and gave the passkey policy its own storage allowance.

A sensible starting design

ProfileWhoRules
AdminsPrivileged role holdersDevice-bound only, attestation enforced, approved security keys or Authenticator
StandardEveryone elseDevice-bound or synced, no attestation

This gets most users onto sign-in with very little friction, while keeping a tighter grip on the accounts attackers want most.

Pair it with Conditional Access: once users have passkeys, require the Phishing-resistant for admin portals and sensitive apps.

How Entra decides which rules apply

Each passkey profile is targeted at groups. When a user registers or uses a passkey, Entra applies the profile assigned to them. Keep the targeting simple: one restrictive profile for privileged users, one relaxed profile for everyone else, and a clear rule for who goes where. Profiles that overlap in unclear ways become hard to support.

Authentication methods policyPasskeys (FIDO2) enabled
Passkey profile: AdminsDevice-bound only, attestation enforced
Users in the admin groupCan register approved keys or Authenticator only
How profiles narrow down what's allowed.

Rolling it out

  1. Check what your existing passkey settings migrated into. Tenants that already had passkeys configured get a default profile with those settings.
  2. Create the admin profile first and test it with two or three admins, including registration on a new device.
  3. Widen the standard profile to allow synced passkeys, then run a registration campaign.
  4. Once most users have a passkey, require the phishing-resistant MFA authentication strength for sensitive apps.

Checklist

  • Decide which groups may use synced passkeys
  • Create an admin profile with device-bound keys and attestation
  • Test registration and sign-in on Windows, iOS and Android
  • Brief the service desk on lost-device recovery with a
  • Add authentication strengths once adoption is high

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.

Next in Passwordless rollout · part 3 of 6System-preferred authentication now picks the first factor too →