Blog | Samuel Eng
Samuel Eng
SAMUEL ENG

Synced vs Device-Bound Passkeys: Technical Comparison

Introduction

Passkeys have rapidly evolved from emerging technology to enterprise necessity. With phishing attacks representing one of the costliest security threats and traditional passwords remaining the weakest link in security infrastructure, phishing-resistant authentication is no longer optional—it's a baseline requirement for every enterprise. NIST SP 800-63-4's recognition of passkeys for AAL2 compliance in August 2025 solidified their role in modern security architectures, while major platforms like Apple, Google, and Microsoft have deployed widespread passkey support across their ecosystems.

Yet beneath this unified adoption lies a critical architectural choice: device-bound passkeys that never leave their hardware, or synced passkeys that replicate across cloud-connected devices. Both approaches use identical FIDO2/WebAuthn cryptographic protocols during authentication—the fundamental difference is key lifecycle management. Device-bound keys never leave their generating hardware, while synced keys leave in encrypted form to enable multi-device convenience. Understanding the technical differences, security implications, and operational trade-offs between these two approaches is essential for organizations building passwordless authentication strategies.


Understanding Attestation

Attestation is like a digital certificate of authenticity that proves a passkey comes from a legitimate, trusted device. During registration, authenticators provide an identifier and verification data that allows organizations to confirm they're dealing with genuine security hardware rather than fake or compromised devices.

Device-bound passkeys offer full attestation—organizations can verify exactly which security key model is being used and enforce policies requiring specific hardware types. Synced passkeys provide limited attestation because the cloud synchronization process doesn't support the same level of hardware verification. This matters primarily for enterprises that need to maintain strict inventory control and verify authenticator security properties for compliance auditing.


Comparison Table

Dimension Device-Bound Passkeys Synced Passkeys
Phishing resistance Yes - Cryptographically bound to website origin Yes - Cryptographically bound to website origin
Storage location Hardware security module only (TPM, Secure Enclave, TEE, Security Key chip) Encrypted in cloud sync fabric (iCloud Keychain, Google Password Manager, Microsoft Password Manager)
Key exportability Non-exportable by design; private keys physically cannot leave hardware Encrypted and synced across devices within same ecosystem
Cross-device availability Single device only; requires physical possession Available on all devices signed into same account (Apple ID, Google Account, Microsoft Account)
Recovery from device loss Permanent credential loss; requires re-enrollment with fallback method Automatic restoration from cloud backup on new device
Attestation support Full hardware attestation with AAGUID; verifiable authenticator properties Limited or none for consumer implementations; self-attestation only
Platform examples YubiKey, Windows Hello, Smart Cards, FIDO2 security keys iCloud Keychain, Google Password Manager, 1Password
Primary attack surface Physical device theft + PIN/biometric compromise; hardware tampering Cloud account takeover; recovery process exploitation; browser extensions; sync fabric compromise
Lifecycle management Full enterprise control: hardware inventory, issuance tracking, revocation management Limited visibility into personal cloud accounts; users control credential lifecycle
User experience High friction: multiple device enrollments required; must carry physical key; lost key = re-enrollment Seamless: single enrollment syncs everywhere; automatic availability; intuitive recovery

NIST AAL Compliance (as of SP 800-63-4, July 31, 2025):

  • Device-bound passkeys: AAL2 and AAL3 capable
  • Synced passkeys: AAL2 capable only (SHALL NOT be used at AAL3 due to key exportability)