The Enterprise Passkey Migration Decision Framework: When Device-Bound vs. Synced Passkeys Actually Matter

Only 13% of enterprises have deployed passkeys at scale. Yet 93% are somewhere in the pipeline, according to a June 2026 FIDO Alliance and HID study of 500 IT and security decision-makers across the US, Canada, UK, France, and Germany. That is an 80-point gap between "started" and "actually running in production."

I have reviewed enough of these rollouts, first scaling authentication at LoginRadius past a billion users, now building GrackerAI, to know where that gap usually comes from. It is rarely budget. It is rarely executive buy-in. It is a decision nobody made explicitly. Some users get a device-bound passkey, tied to one piece of hardware that never releases it. Others get a synced passkey, encrypted and copied across a user's devices by Apple, Google, Microsoft, or a password manager.

Both are phishing-resistant. Both meet the WebAuthn standard (the W3C protocol that lets a browser talk to a hardware or platform authenticator). Neither is "more secure" in the abstract. They are secure against different things, and the enterprises stuck at pilot scale are almost always the ones that picked one type and tried to force it onto every employee.

This is a framework for making that call by user population, device context, and compliance obligation, not by defaulting to whichever passkey type IT happened to evaluate first.

What actually separates device-bound from synced

Device-bound passkeys generate a private key inside a hardware boundary: a security key like a YubiKey or Titan Key, or a platform authenticator's secure enclave (Touch ID tied to one Mac, the TPM behind Windows Hello on one PC). The key is created and used inside that hardware. It never touches the operating system, never gets exported, and never syncs anywhere. Lose the hardware and you lose the credential. That is the tradeoff, not a defect.

Synced passkeys generate a private key that gets encrypted and distributed across a user's devices through iCloud Keychain, Google Password Manager, Microsoft account sync, or an enterprise password manager like 1Password or Bitwarden. Enroll once, and the credential shows up on every device signed into that account. The cloud provider's account security becomes part of your trust chain, whether you planned for that or not.

NIST finalized SP 800-63-4 in July 2025, and it settles a question enterprises kept asking their auditors. Syncable passkeys now explicitly satisfy AAL2 (multi-factor authentication). Device-bound passkeys are required for AAL3, the highest assurance level; syncable credentials are explicitly disallowed there because the private key, even encrypted, is technically exportable. That one distinction decides more enterprise passkey architectures than any UX debate does.

At LoginRadius we ran both at once: YubiKeys for anyone with administrative access, synced passkeys through an enterprise password manager for everyone else. That was not indecision. It was matching the credential to what each population actually put at risk.

The decision framework: map users, not policy

A single company-wide passkey policy fails because your workforce is not a single risk profile. Four factors decide the right passkey type for a given population: how much damage their compromise causes, what device they authenticate from, what compliance framework governs their access, and what the choice costs to run for three years.

Factor 1: user risk profile

Start here, before touching device policy or vendor tooling. Map user categories to the passkey type that matches what a compromised account actually exposes.

Keep admin credentials separate from daily-use ones for the same person. A VP of Engineering uses a synced passkey for email and Slack, then switches to a hardware key for the production console. Zero trust architectures call this a privileged access workstation pattern. It limits what one compromised credential can reach.

Factor 2: device context

The device someone authenticates from can override the risk-profile answer entirely.

Shared workstations are the number one adoption blocker enterprises report, cited by 31% of organizations in FIDO Alliance's 2025 enterprise passkey survey. The reason is mechanical, not a policy failure. A platform authenticator like Windows Hello enrolls the first person's face or fingerprint to that machine. The second nurse, the second retail associate, the second warehouse worker on the next shift cannot authenticate with their own face on someone else's enrollment. Retail, healthcare, and manufacturing floors need hardware security keys here, full stop. The user carries the key, taps it at whichever terminal they are on, and removes it when the shift ends.

BYOD environments flip the constraint. You cannot mandate that contractors buy a YubiKey for their personal laptop, and most legal teams will not let you try. Synced passkeys paired with device attestation, checking that the device is encrypted, screen-locked, and patched before it authenticates, get you most of the security benefit without owning the hardware.

Corporate-managed devices are where you have real choice, and the risk-profile table above should drive the decision rather than device constraints.

Factor 3: compliance obligations

Some frameworks make the decision for you before risk analysis even starts.

The practical read: if any part of your user base touches FedRAMP High or AAL3-governed systems, that population goes on device-bound passkeys, no further debate needed. Everyone else gets a documented risk assessment, and synced is usually defensible.

Factor 4: what it actually costs

Hardware keys run $20 to $60 per user before shipping, training, and three years of help desk tickets for lost or replaced keys. Synced passkeys are close to free to provision, since they ride on hardware employees already own, but they shift cost into cloud-account security and recovery process design instead of procurement.

Run the math on 1,000 users over three years. Device-bound everywhere lands around $108 per user (hardware, shipping, training, and ongoing support). Synced everywhere lands around $20 per user. Neither number is the one that matters. The hybrid approach, device-bound for the 10% to 20% of users the risk-profile table flags as high or critical, synced for the rest, comes out around $29 per user blended. It is the only version of that math that reflects how a real enterprise is actually exposed.

Three ways the wrong call shows up later

Platform authenticators on shared devices

A retail chain enables Windows Hello on point-of-sale terminals shared across three shifts. The first employee each shift can log in with a face scan. Everyone after them cannot, because the device enrolled one face. IT falls back to shared passwords, the exact outcome the passkey project was supposed to prevent. The fix has to be decided before rollout, not discovered during it: shared devices get hardware keys, never platform authenticators.

Admin and daily-use on the same credential

An engineer enrolls one synced passkey and uses it for email, Slack, and the production database console. It is convenient right up until their personal Apple ID or Google account gets targeted, at which point the blast radius includes production. Separating the credential by risk tier, synced for daily tools, device-bound for anything with production or admin scope, is the fix. It has to be a policy decision, not something left to individual judgment.

Compliance mismatch found at audit, not at design

A startup rolls out synced passkeys company-wide through Okta without specifying which sync providers are approved. Engineers enroll through personal iCloud accounts and personal password managers. A SOC 2 auditor flags it: the company has no visibility into where its authentication credentials actually live. The fix is cheap if it happens before deployment (name the approved sync providers, require device attestation, document it in the security policy) and expensive if it happens after (a failed audit finding and a re-enrollment project).

Recovery is a decision, not an afterthought

Device-bound and synced passkeys fail differently when a device is lost, and the recovery path has to be designed before the credential type is chosen, not after the first executive gets locked out at an airport. Device-bound needs a second hardware key sealed somewhere secure, plus a documented break-glass process. Synced needs the underlying cloud account to carry its own strong MFA, since account recovery there is credential recovery. I cover the full recovery architecture, enrollment UX, and rollout sequencing separately in Passkeys at Scale. This piece is about which credential to hand someone in the first place.

Frequently asked questions

Do I need both device-bound and synced passkeys, or can I standardize on one?

Most enterprises need both. FIDO Alliance and HID's enterprise survey found 82% of organizations implementing or considering device-bound passkeys specifically, almost always alongside synced passkeys for the general workforce, not instead of them. Standardizing on synced alone fails any AAL3 or FedRAMP High requirement. Standardizing on device-bound alone means procurement, shipping, and help desk overhead for users whose risk profile does not justify it.

Does NIST actually allow synced passkeys for enterprise authentication?

Yes, at AAL2. NIST SP 800-63-4, finalized in July 2025, explicitly recognizes syncable passkeys as meeting AAL2 multi-factor authentication requirements. They are disallowed at AAL3, which requires a non-exportable, hardware-bound private key.

Can synced passkeys work on shared workstations?

Not through a platform authenticator like Windows Hello or Touch ID. Those bind to the first enrolled biometric on that device. A shared workstation needs a hardware security key that each user carries and taps, regardless of whether the rest of the deployment is synced.

Where should a security team start this decision?

Map users to a risk tier before evaluating a single vendor. The tooling decision gets easy once you know how many of your 1,000 employees sit in the 10% to 20% band that needs device-bound, and how many sit in the 80% to 90% band that does not.

Start with the map

The organizations stuck at 13% deployment are not failing at passkeys. They are trying to answer one authentication question with one authentication answer, for a workforce that was never uniform to begin with. Map risk first, layer in device context and compliance, and the device-bound-versus-synced choice mostly makes itself.

I wrote about killing passwords for good a few years into building LoginRadius, back when passkeys were still a hard sell: why I would tell you to kill yours. The tooling caught up faster than expected. The decision framework for using it well took enterprises longer to figure out, which is what this piece is for.

For the mechanics of biometric and platform authenticators specifically, CIAM Compass has a deeper reference on biometric authentication. And if a 36% enrollment rate sounds high, it should: I broke down why most deployments never get past single digits in Passkeys Have a 93% Login Success Rate. Only 36% of Accounts Enroll.