What the passkey profile migration does to your existing FIDO2 policy

The source is MC1221452, first published on 23 January and updated again this week. Worldwide, passkey profiles and synced passkeys roll out as GA from early to late March 2026. Tenants that haven't opted in by then are migrated to the profile model from early April to late May 2026 (GCC, GCC High and DoD follow later, with migration in June). Only tenants that already have the Passkey (FIDO2) method enabled are affected. The timeline itself is well covered elsewhere, so I'll stick to the mechanics.

The migration takes the tenant-wide FIDO2 settings you have today and turns them into a profile called Default passkey profile. Your existing include targets are assigned to that profile, your key restrictions (the AAGUID allow or block list) are copied into it, and the new passkey type setting is derived from one existing switch:

• Enforce attestation set to Yes becomes device-bound passkeys only.
• Enforce attestation set to No becomes device-bound and synced passkeys.

I expect that second line to surprise a lot of tenants. In the environments I look at, attestation is often off, for reasons that made sense at the time: a security key pilot that was set up quickly, or passkeys in Microsoft Authenticator that originally needed attestation switched off. Combine that with an include target of All users, which is common because the FIDO2 method only allows registration and doesn't force anything, and the result after migration is that every user can register a passkey in iCloud Keychain, Google Password Manager, 1Password or Bitwarden without anyone having changed a setting.

Key restrictions soften this, but only in one direction. If you run an allow list with your security key models, synced providers are not on it and stay out (with a caveat about AAGUIDs that I'll come back to). If you run a block list, for example to keep Authenticator passkeys out while you pilot them, synced providers are not on that list either, so they get through.

Both types are phishing resistant, and for most users a synced passkey is a big step up. The difference is where the private key lives. A device-bound passkey stays on the security key or in Authenticator. A synced passkey is encrypted and stored with the passkey provider and becomes usable on every device signed in to that provider account, which for many users is a personal Apple or Google account you don't manage and can't inventory.

The bigger difference for policy is attestation. Synced passkeys don't support attestation, and the passkey profile documentation is explicit about the consequence: with Enforce attestation set to No, Entra ID can't guarantee any attribute of a passkey, including whether it's synced or device-bound, or its make, model or provider, even when you target specific AAGUIDs. Without attestation, the AAGUID and the synced or device-bound classification are whatever the authenticator reports about itself. Microsoft's own advice is to treat AAGUID lists as a policy guide in that case and not as a security control.

The same applies to Conditional Access. The built-in phishing-resistant MFA authentication strength treats Passkeys (FIDO2) as one method, so a synced passkey satisfies it in the same way a FIDO2 security key does. A custom authentication strength can filter on AAGUID, but Microsoft doesn't document how that filter is evaluated at sign-in, and as far as I can tell it can only work with the AAGUID Entra recorded at registration, which for an unattested passkey is self-reported. If your admin policies rely on "phishing-resistant MFA" and your admins are in scope of a profile that allows synced passkeys, the strongest credential on an admin account can end up in a personal consumer cloud account.

One asymmetry matters if you plan to tighten things later. Attestation is only checked at registration: passkeys registered without attestation keep working if you enforce it afterwards. The passkey type is enforced at sign-in: if you remove Synced from a profile, users in that profile can no longer sign in with a synced passkey they already registered. So if you allow synced passkeys for a few weeks and then pull them back, expect help desk calls from everyone who registered one in that period.

A user can be in scope of more than one profile, and registration or sign-in succeeds if the passkey fully satisfies at least one of them. There is no precedence order. Excluding a user from the FIDO2 method blocks passkeys entirely, so exclusion can't be used per profile. The documentation also lists a maximum of three profiles including the Default one, which can't be deleted, and a 20 KB size limit on the policy.

So a stricter admin profile does nothing if your admins are also members of All users and All users points at a Default profile that allows synced passkeys. The design that works with these rules is to make the Default profile the strict one (device-bound, attestation enforced, optionally an allow list) and add a second profile that allows synced passkeys, targeted at a group that doesn't contain admin accounts. That leaves one slot, for example for an Authenticator pilot.

MC1221452 also changes the registration campaign for tenants where the campaign is in the Microsoft managed state, Passkey (FIDO2) is enabled, passkey profiles allow both device-bound and synced passkeys, attestation isn't enforced and there are no AAGUID restrictions. Microsoft managed is what Graph calls default, and it's the state of every tenant that never touched the campaign. For those tenants:

• The targeted method changes from Microsoft Authenticator to passkeys (FIDO2).
• Days allowed to snooze goes from 3 to 1 and is no longer configurable.
• Limited number of snoozes goes from Enabled to Disabled, also no longer configurable.
• Targeting widens from users who do MFA by SMS or voice to all MFA-capable users.

So every MFA-capable user in scope gets a passkey prompt after MFA, once a day, and can skip it indefinitely. If you want the campaign but on your own terms, note that the registration campaign API currently only accepts microsoftAuthenticator as the targeted method in the Enabled state. Your options today are Microsoft managed (passkeys, Microsoft's settings), Enabled (Authenticator, your settings) or Disabled.

Passkey profiles are in the Graph beta endpoint for now. Before migration, the fields that predict the outcome are isAttestationEnforced, keyRestrictions and includeTargets; after opt-in or migration you'll also see passkeyProfiles, each with passkeyTypes (for example deviceBound,synced) and attestationEnforcement (disabled or registrationOnly). Note that the property is plural in Graph, while the Message Center post calls it passkeyType.

To see what your admins have already registered, the per-user fido2Methods endpoint returns aaGuid, attestationLevel and, in beta, passkeyType:

• Which groups get synced passkeys, and whether any admin or other privileged account is a member of a group that ends up in a profile allowing them.
• Whether attestation matters for you. If you need to know make and model (certified keys, regulatory requirements, AAGUID filtering you actually rely on), enforce it in the strict profile and accept that existing unattested registrations stay.
• What the registration campaign should do: let Microsoft managed nudge everyone towards passkeys, keep it on Authenticator under Enabled, or disable it until your help desk and end-user guidance are ready.
• Whether you opt in yourself. The documentation still describes an opt-out, but I would treat the opt-in as one-way.

Run the two queries above this week and write down isAttestationEnforced, the key restriction mode, the include targets and the campaign state; if that reads "false, none, all_users, default", opt in to passkey profiles yourself before April and set the Default profile to the configuration you want for your admins.

Update April 2026: On 15 April Microsoft updated MC1221452: automatic migration for worldwide tenants now runs from early May to late June 2026, and the registration campaign change moves with it. The campaign change now only applies to tenants with at least one user enabled for both synced and device-bound passkeys, and only those users without profile restrictions (attestation or AAGUID) are nudged. See the version history of MC1221452.

Update July 2026: On 13 July Microsoft announced in MC1426371 that passkeys become the default from 1 September 2026: users enabled for SMS or voice are automatically enabled for passkeys, in a profile that allows all passkey types, and the registration campaign is set to Microsoft managed targeting passkeys. Microsoft-provided SMS and voice are being retired in the same announcement. The profile design above now matters for a much larger group.

• MC1221452: passkey profiles and synced passkeys, including version history
• MC1426371: passkeys by default and retirement of Microsoft-provided SMS and voice
• How to enable passkeys (FIDO2) in Microsoft Entra ID: passkey profiles
• Synced passkeys in Microsoft Entra ID
• Passkeys (FIDO2) authentication method in Microsoft Entra ID
• Custom authentication strengths: advanced options for FIDO2 security keys
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Microsoft Graph: fido2AuthenticationMethodConfiguration resource type (beta)
• Microsoft Graph: fido2AuthenticationMethod resource type (beta)
• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication