Not all passkeys are created equal

After a public preview starting November 2025, Microsoft moved synced passkeys to general availability for work accounts in March and will enable passkey profiles automatically in all Microsoft 365 tenants by late May. It's a significant milestone for passwordless authentication — and a genuinely useful one for many organisations. But it also introduces a nuance that's easy to overlook: not all passkeys offer the same level of security, and treating them as interchangeable could leave gaps in your defences.

A quick primer: device-bound vs synced

At their core, all passkeys are built on the same FIDO2 standard. They're phishing-resistant, they eliminate shared secrets, and they're a meaningful step up from passwords and traditional MFA methods like SMS codes or push notifications. But how and where the private key is stored makes a real difference to your security posture.

Device-bound passkeys keep the private key locked to a specific piece of hardware — a FIDO2 security key, or a specific mobile device. The credential never leaves that device. If you lose the device, you lose the passkey. That's inconvenient, but it's also the point: there's a known, controllable perimeter around the credential.

Synced passkeys store the private key in a credential manager — Apple iCloud Keychain, Google Password Manager, 1Password, Bitwarden, and others — and synchronise it across every device signed into that account. Register a passkey on your work laptop, and it's available on your personal phone, your partner's iPad, or any other device where you're signed into that credential manager.

The convenience is obvious. The security implication is equally clear: your passkey is now only as secure as the least secure device it's synced to. If that personal phone has a weak PIN, a slow screen lock and a tendency to be left unlocked on café tables, the strength of the credential on your managed work laptop is somewhat academic!

Where synced passkeys make sense

None of this means synced passkeys are bad. For many roles and many organisations, they're a significant improvement on the status quo.

Consider staff who spend their day on their feet rather than at a desk. They might access a handful of company applications on a shared device or a personal phone. Their exposure to sensitive data may be limited. Asking them to carry a hardware security key or navigate the complexities of device-bound passkey registration is a friction that discourages adoption. Synced passkeys, registered once and available wherever they sign in, dramatically lower the barrier to phishing-resistant authentication. For this population, getting them off passwords and SMS codes and onto any form of passkey is a massive win.

Where synced passkeys probably don’t make sense

For more senior roles, or anyone with broad access to sensitive data — finance teams, IT administrators, executives with access to strategic documents — the calculus shifts. These are accounts where a compromise has outsized consequences, and where the organisation needs tighter control over where credentials live.

Device-bound passkeys—especially via Microsoft Authenticator—offer control that synced passkeys can’t. Because the credential is tied to a specific app on a specific device, you can enforce context-based policies: MAM (Mobile Application Management) policies can require strong passcodes and biometrics and up-to-date OS versions, while Conditional Access can add checks for device state, location, and risk. You’re not just authenticating the user—you’re validating the security posture of the device holding the credential.

With synced passkeys, that control evaporates. The credential could be sitting in a personal password manager on an unmanaged device, and there's nothing in the authentication flow that tells you otherwise.

Microsoft's flexible approach

One of the genuinely useful features of the new passkey profiles for Microsoft 365 work accounts is the granularity they offer. Administrators can create separate profiles for different user groups, each with its own configuration for passkey type (device-bound, synced, or both), attestation settings, and AAGUID restrictions. You might allow synced passkeys for your general workforce while requiring device-bound passkeys for privileged accounts — and enforce those policies at the group level rather than tenant-wide.

This means you don't have to make a binary choice. You can meet your workforce where they are, giving them the simplest path to phishing-resistant authentication, while maintaining tighter controls for the roles that need them. That kind of role-based, risk-proportionate policy is exactly how modern identity management should work.

The limitations of Google Workspace

Google Workspace offers a notably more constrained set of options by comparison. Administrators can allow users to skip passwords using passkeys, and they can restrict passkeys to hardware security keys only. That's essentially a binary choice: passkeys on any device, or passkeys only on physical security keys.

There's no equivalent to Microsoft 365's passkey profiles — no group-based configuration for different passkey types, limited AAGUID restrictions, no ability to allow synced passkeys for some users while requiring device-bound passkeys for others within the same tenant. If you want phishing-resistant authentication for your frontline staff without issuing hardware keys, you're allowing synced passkeys for everyone, including your administrators.

For organisations running Google Workspace, this limitation makes it harder to implement the kind of risk-proportionate passkey policy that Microsoft 365 now supports out of the box.

The attestation problem you need to know about

There's one more wrinkle that's worth understanding, because it catches out administrators who think they've locked things down tighter than they actually have.

When a passkey is registered, it can provide an attestation statement — a cryptographic proof of its make, model, and origin, verified against the FIDO Metadata Service. This is how Microsoft's platform can confirm that a passkey really is, say, a YubiKey 5 Series or a Microsoft Authenticator credential. Attestation is the mechanism that makes AAGUID restrictions meaningful as a security control.

Here's the problem: synced passkeys don't consistently support attestation. If you allow synced passkeys for Microsoft 365 work accounts, you must set attestation enforcement to "No." Microsoft's own documentation is explicit on this point — without attestation, Microsoft 365 cannot guarantee any attribute about a passkey, including whether it's synced or device-bound, or its specific make, model, or provider, even if you configure AAGUID restrictions.

That last part is critical and easy to miss. You can set up an AAGUID allow list that only permits, say, your corporate password manager. The policy will work as an organisational guide — it will steer well-meaning users toward the right tool. But it is not a security control. A determined or compromised actor can register a passkey with a spoofed AAGUID, claiming to be your approved credential manager while actually storing the key somewhere entirely different. Without attestation to verify the claim cryptographically, Microsoft 365 has no way to tell the difference.

Microsoft themselves advise administrators to treat AAGUID lists as a policy guide rather than a strict security control when attestation is disabled. That's sound advice, but it's buried in the documentation rather than surfaced prominently in the admin experience, and it's a subtlety that many organisations will miss.

Practical recommendations

If you're rolling out passkeys — or if Microsoft is about to roll them out for you — here are some starting points:

Audit your tenant now. If you had FIDO2 passkeys enabled without attestation enforcement, the automatic migration may have enabled synced passkeys by default. Check your passkey profiles ASAP.
Use passkey profiles to differentiate by role. Allow synced passkeys for lower risk staff. Require device-bound passkeys (with attestation enforced) for administrators, finance, and other high-privilege roles.
Don't rely on AAGUID restrictions as a security boundary for synced passkeys. They're useful as guardrails, not gates. Understand that without attestation, the stated AAGUID of a synced passkey is an unverified claim.
Wrap device-bound passkeys in conditional access and device compliance. The passkey is only part of the story. Combining it with device state checks, MAM policies, and risk-based conditional access gives you the layered assurance that sensitive roles need.
If you're on Google Workspace, understand your limitations. The binary choice between "any passkey" and "hardware security keys only" means you may need to supplement with other controls or accept a broader risk surface for some user groups.

Bottom line

Passkeys are a genuine step forward for authentication security, and synced passkeys in particular will help millions of users move away from passwords and weak MFA. That's worth celebrating. But the word "passkey" covers a spectrum of security properties, and not every passkey deployment is appropriate for every role.

The organisations that get the most value from this shift will be the ones that treat passkey policy the way they treat access policy more broadly — proportionate to risk, differentiated by role, and honest about the limitations of the controls they're relying on.

If you're navigating similar challenges, we can help—from cyber risk assessments to architecture advice, training, operating model design or trusted partner introductions. Reach out below.👇