Synced Passkeys Are Now in Your Microsoft Tenant. Here's How to Set Policy Before Your Users Do.

In our previous article we explained the concept that separates the two families of passkeys: key custody. Synced passkeys replicate through consumer cloud accounts. Device-bound passkeys live in hardware and cannot be copied out. This spring, that distinction became a practical matter for every organization with passkeys enabled in Microsoft Entra ID. This article covers what changed, what the standards require, and how to build a policy that fits your risk.

What changed in your tenant this spring

In early March 2026, Microsoft began rolling out passkey profiles in Entra ID, a new group-based way of managing FIDO2 authentication. From April onward, tenants with Passkeys (FIDO2) enabled that had not opted in were migrated automatically.

The migration added a passkeyType property that separates device-bound passkeys from synced ones, and mapped every migrated tenant's old FIDO2 settings onto it with a single rule. Tenants that enforced attestation were set to allow device-bound passkeys only. Tenants that did not enforce attestation now allow both types.

The second case is the one to pay attention to. A setting many administrators configured years ago, or never consciously configured at all, now decides whether corporate credentials can replicate into employees' personal iCloud and Google accounts. If your registration campaign is Microsoft-managed, it may already be prompting users to enroll whichever passkey types your inherited profile allows.

The new architecture does bring a real improvement. Profiles allow different rules for different groups, for example attested hardware keys for admins and more permissive settings for frontline staff, instead of one tenant-wide policy. But the migration defaults were chosen for the average tenant, and your risk profile is probably not average. The rest of this article is about choosing your settings deliberately.

Attestation: the only way to know what holds your keys

During a normal login, synced and device-bound passkeys behave identically. The difference appears at registration, and it comes down to attestation.

A device-bound authenticator can present an attestation statement when it registers: cryptographic proof, chained back to the manufacturer, of exactly what hardware generated the credential. The relying party validates that chain against the FIDO Alliance Metadata Service and knows with certainty that this is a genuine security key of model X, certified to level Y, holding a private key that cannot be exported.

Synced passkeys cannot offer this. A sync service cannot guarantee anything about every device a key may eventually end up on, so consumer passkey providers attest nothing. This is why Entra's behavior is binary: if a profile enforces attestation, synced passkeys are automatically excluded from it.

There is a further consequence here that many deployments miss. Every authenticator reports an AAGUID, a 128-bit make-and-model identifier, and organizations commonly build allowlists on it ("YubiKey 5 series only"). The AAGUID, however, is self-reported. Without attestation enforcement, an attacker who reaches a registration flow can enroll a credential that falsely claims to be approved hardware, gaining durable access that looks compliant in every report. An AAGUID allowlist without attestation labels your inventory. It does not secure it.

What the standards require

This assurance gap is written into the standards, not just vendor opinion.

NIST's finalized SP 800-63-4 Digital Identity Guidelines (2025) recognize both passkey families, but set a ceiling. Synced passkeys can satisfy AAL2, the assurance level appropriate for general workforce access. AAL3, the level expected for privileged and high-impact access, requires a phishing-resistant authenticator with a non-exportable private key. A synced passkey is exportable by definition, because replication is its entire purpose. Only hardware-backed, device-bound credentials qualify.

European organizations should apply the same logic to NIS2's strong-authentication expectations and DORA's requirements for financial entities. Regulators are moving from asking whether you deploy MFA to asking what assurance you can demonstrate about it. A policy that enforces attested, device-bound authenticators for privileged access is something you can demonstrate. Passkeys on unknown devices in personal cloud accounts is not.

How attackers get around passkeys

The cryptography of FIDO2 has held, so attack research in 2025 and 2026 moved to the seams around it. The findings should shape your configuration.

In August 2025, Proofpoint demonstrated a downgrade attack against FIDO authentication in Entra ID. A standard adversary-in-the-middle kit (Evilginx) ran a custom phishlet that spoofed a browser without FIDO support, Safari on Windows. Because the login flow believed the user could not use a passkey, it offered a fallback instead: an SMS code or push approval, both phishable, both captured by the proxy. The passkey itself was never attacked. The attacker simply steered the user onto a weaker method.

Months earlier, the PoisonSeed campaign abused the cross-device QR-code sign-in flow at scale, luring victims into scanning attacker-supplied QR codes and approving fresh authentications. Both Microsoft and Okta published hardening guidance in response.

The lesson is simple: your authentication is only as strong as the weakest method a user can be pushed into. Passkeys with SMS fallback enabled are not phishing-resistant for the user who is being phished right now. The same applies to account recovery. If your helpdesk re-enrolls credentials after one convincing phone call, that is a downgrade path too, just one that runs through a person instead of a login page.

Building a deliberate policy

1. Audit what the migration did. Check which profile your tenant landed in, whether attestation is enforced, which passkey types users have registered since April, and what your registration campaign is now promoting.

2. Tier your users. For privileged and high-impact access (admins, finance approvers, production access, anyone NIS2 or DORA would call critical), require attested, device-bound passkeys on certified hardware keys. Enforcing attestation makes your AAGUID allowlist verifiable and excludes synced credentials automatically. For the general workforce, make the call consciously: synced passkeys are still phishing-resistant and far better than what they replace, but the custody trade-off should be accepted knowingly. Keep in mind that modern attacks often target finance, HR, and procurement before admins. Many organizations will conclude that hardware keys are cheap compared to the gap.

3. Close the side doors. Remove SMS and voice fallbacks entirely. Restrict or monitor cross-device QR flows. Enforce passkey sign-in for sensitive resources through Conditional Access authentication strengths, so a downgrade attempt has nowhere to land.

4. Hold recovery to the same standard as registration. Whatever process enrolls a credential, recovery must be no weaker. Otherwise recovery becomes the easiest way in, and your recovery process, not your login policy, defines your real level of assurance.

The bottom line

The question is no longer whether to adopt passkeys. The question is key custody: does the private key live in certified hardware you control and can cryptographically prove, or in a consumer cloud account you cannot see? For most users and most logins, synced passkeys are a clear step forward. For the accounts that can move money, change infrastructure, or appear in a regulator's incident report, the answer has not changed. The key belongs in hardware, the hardware should prove itself at registration, and there should be no weaker path around it.

Spear Innovations helps European organizations deploy phishing-resistant, hardware-backed authentication that meets NIS2, DORA, and AAL3-grade requirements, including tiered passkey policy design for Microsoft Entra ID. Talk to us.