Synced Passkeys generally available in March 2026

Stefan Dohnal •
Entra ID
Public Preview Entra ID Authentication methods

BannerImage

Table of contents

Synced Passkeys in Public Preview

Public Preview for Synced Passkeys in Entra ID will move to General Availability in March 2026. Where do Synced Passkeys offer tangible value?

With synced passkeys, Entra ID can use passkeys stored in native and third‑party passkey providers that already exist on users’ devices (for example Microsoft Authenticator, iCloud Keychain, Google Password Manager). The key trade‑off: synced passkeys cannot be used together with enforced FIDO2 attestation in Entra ID.

💡 Heads-up for March 2026
Starting in March 2026, Microsoft will auto-enable passkey profiles in Microsoft Entra ID, including support for synced passkeys and the new passkeyType property.
If you do not configure passkey profiles up front, your existing FIDO2 configuration will be migrated into a single default passkey profile and the passkeyType will be set based on your current attestation settings (device-bound only vs. device-bound and synced).
This makes it even more important to decide if and where you want to allow synced passkeys and where you require attestation-enforced, device-bound passkeys.

Exploring the added value

From a security configuration perspective, the most important limitation is simple: you cannot enforce attestation and allow synced passkeys at the same time in Entra ID. As soon as you turn on Enforce attestation in a passkey profile, the option to target synced passkeys disappears.

The underlying reason is that Entra ID cannot reliably verify attestation properties for synced passkeys issued by cloud‑backed credential managers. This means the service cannot strongly guarantee the authenticator’s make, model, or even the correctness of the reported AAGUID for synced passkeys. For device‑bound passkeys, attestation and AAGUID allow‑listing are a strong control to ensure only specific, certified models can be registered; for synced passkeys this control simply does not exist in a trustworthy way.

Synced passkeys are not “insecure by default” – but they shift part of the trust to the password manager or passkey provider that stores and syncs the credential. Microsoft explicitly highlights that synced passkeys solve many of the hard issuance, recovery, and reissuance problems of separate hardware authenticators.

Because of that, Microsoft recommends device‑bound passkeys for admins and highly privileged users, and synced passkeys for standard users without admin permissions. This aligns well with passkey profiles: you can keep strict attestation‑enforced, device‑bound passkeys for privileged accounts while allowing synced passkeys for the broader workforce.

Use Cases

Synced passkeys shine in scenarios where issuance and lifecycle of physical FIDO2 keys are hard or costly to manage. A few concrete examples:

  • Distributed workforce without hardware logistics
    Remote or globally distributed teams no longer need shipping, customs, or local stock of security keys. Users can rely on passkey providers already present on their devices while still gaining phishing‑resistant authentication.

  • Multi‑device users and BYOD
    Typical information workers use multiple devices (laptop, mobile, sometimes tablet) and often bring their own hardware. Synced passkeys remove the need to re‑register a passkey on each device – the credential roams with the user’s cloud account or password manager.

  • Initial rollout of phishing‑resistant MFA
    For organizations moving away from OTP and push approvals, synced passkeys can lower rollout friction, because users do not have to request a hardware token or perform per‑device registration.

  • Simplified recovery and device replacement
    If a device is lost or replaced, synced passkeys can be recovered together with the password manager account instead of requiring re‑issuance of a hardware key. This significantly reduces help desk effort compared to device‑bound only deployments.

  • Contractors and temporary staff
    For short‑term workforce or partners, it’s often not economical or practical to ship and reclaim physical keys. Synced passkeys give you phishing‑resistant auth with low operational overhead, provided you scope it to non‑privileged personas.

Practical example

In this scenario passkeys are enabled for “All users”. The default passkey profile enforces attestation and whitelists AAGUIDs of two FIPS-certified models with biometric unlock.

The other two profiles demonstrate configurations to distinguish passkey profiles for administrator, which my could allow any model with enforced attestation or specific models without attestation-enforcement like exampled above, and a profile for users. This profile in this example allows usage of synced passkeys.

  • Any user must only register attestation-enforced FIPS-certified or FIDO2 Level 3 certified passkey models
  • Privileged accounts may use FIDO2 Level 2 certified passkey models
  • Specific personas may use synced passkeys, FIDO2 Level 1 certified passkey models or Microsoft-Authenticator passkeys

Illustrated in a alternate way strictest per default and lowering requirements upon dedicated assignments:

  • Catch-all, strict-unless: FIDO2 Level 3 certified passkey models
  • Distinct-privileged, strict: FIDO2 Level 2 certified passkey models or higher certification level
  • Distinct-personas, less-strict: Synced Passkeys and/or FIDO2 Level 1 certified passkey models and/or Microsoft Authenticator passkeys (which certification levels depend on operating system used)

Code-based configuration

From a Graph API perspective, synced passkeys are controlled via the same fido2AuthenticationMethodConfiguration object we used for passkey profiles in previous post. The main difference is the new passkeyTypes value that can include synced in addition to deviceBound.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration",
  "id": "Fido2",
  "state": "enabled",
  "defaultPasskeyProfile": "00000000-0000-0000-0000-000000000001",
  "passkeyProfiles": [
    {
      "id": "00000000-0000-0000-0000-000000000001",
      "name": "default-device-bound",
      "passkeyTypes": "deviceBound",
      "attestationEnforcement": "registrationOnly"
    },
    {
      "id": "7a3c8b1b-1234-4bcd-9abc-f00ba4babe01",
      "name": "allow-synced-passkeys",
      "passkeyTypes": "deviceBound,synced",
      "attestationEnforcement": "disabled"
    }
  ]
}

💡 Note When attestationEnforcement is enabled in a profile, you cannot target synced passkeys with that profile.

Practical example - as Code

To keep this post short you will find the payload from the above example within this section. Keep in mind to double- or even triple-check changes to avoid locking yourself out.

Click to expand: Example for "catch-all, strict-unless" FIDO2 passkey profiles incl. synced passkeys
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

{
  "@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration",
  "id": "Fido2",
  "state": "enabled",
  "isSelfServiceRegistrationAllowed": true,
  "isAttestationEnforced": true,
  "defaultPasskeyProfile": "00000000-0000-0000-0000-000000000001",
  "excludeTargets": [
    // optional
  ],
  "keyRestrictions": {
    "isEnforced": true,
    "enforcementType": "allow",
    "aaGuids": [
      "<fidoL3Certified1>",
      "<fidoL3Certified2>"
    ]
  },
  "includeTargets@odata.context": "https://graph.microsoft.com/beta/$metadata#policies/authenticationMethodsPolicy/authenticationMethodConfigurations('Fido2')/microsoft.graph.fido2AuthenticationMethodConfiguration/includeTargets",
  "includeTargets": [
    {
      "targetType": "group",
      "id": "all_users",
      "isRegistrationRequired": false,
      "allowedPasskeyProfiles": [
        "00000000-0000-0000-0000-000000000001"
      ]
    },
    {
      "targetType": "group",
      "id": "<groupdId1>",
      "isRegistrationRequired": false,
      "allowedPasskeyProfiles": [
        "29097f0f-7d25-4cd7-8bc9-9b794cace20b"
      ]
    },
    {
      "targetType": "group",
      "id": "<groupId2>",
      "isRegistrationRequired": false,
      "allowedPasskeyProfiles": [
        "f01dd57b-918c-4682-b678-e1a51b104e70"
      ]
    }
  ],
  "passkeyProfiles": [
    {
      "id": "00000000-0000-0000-0000-000000000001",
      "name": "Default passkey profile",
      "passkeyTypes": "deviceBound",
      "attestationEnforcement": "registrationOnly",
      "keyRestrictions": {
        "isEnforced": true,
        "enforcementType": "allow",
        "aaGuids": [
          "<fidoL3Certified1>",
          "<fidoL3Certified2>"
        ]
      }
    },
    {
      "id": "f01dd57b-918c-4682-b678-e1a51b104e70",
      "name": "fido2-adminPolicy",
      "passkeyTypes": "deviceBound",
      "attestationEnforcement": "disabled",
      "keyRestrictions": {
        "isEnforced": true,
        "enforcementType": "allow",
        "aaGuids": [
          "<fidoL2Certified1>",
          "<fidoL2Certified2>"
        ]
      }
    },
    {
      "id": "29097f0f-7d25-4cd7-8bc9-9b794cace20b",
      "name": "fido2-noAttestationAuthenticator-and-synced",
      "passkeyTypes": "deviceBound,synced", // allow device-bound *and* synced passkeys in this less-strict persona profile
      "attestationEnforcement": "disabled",  // attestation *must* be disabled when allowing synced passkeys
      "keyRestrictions": {
        "isEnforced": true,
        "enforcementType": "allow",
        "aaGuids": [
          "de1e552d-db1d-4423-a619-566b625cdc84",
          "90a3ccdf-635c-4729-a248-9b709135078f",
          "bada5566-a7aa-401f-bd96-45619a55120d", // 1Password synced passkey provider
          "d548826e-79b4-db40-a3d8-11116f7e8349"  // Bitwarden synced passkey provider
        ]
      }
    }
  ]
}

Wrapping up

  • Synced passkeys bring phishing-resistant authentication to users without the logistics of physical security keys and with better multi-device usability.
  • The trade-off is clear: no enforced attestation and weaker guarantees about authenticator properties, so synced passkeys should be scoped away from highly privileged accounts.
  • Combining passkey profiles with device-bound and synced passkeys lets you build a “strict by default, more flexible for non-privileged users” rollout strategy aligned to your personas.

References