The private key of passkeys is securely synced across devices using end-to-end encryption, for example through iCloud Keychain on Apple devices, ensuring that the plaintext private key is never exposed during transfer or storage. The key is wrapped (encrypted) on the original device before it is synced, and the cloud only stores the encrypted copy. A new device can only decrypt it after a trusted device approves it or the user enters the passcode, screen lock or PIN of an existing device.
Apple, Google, Microsoft and the big password managers all follow this principle but differ in the details. The comparison table below shows how. Note: KeePassXC stores passkeys in a local database and relies on user-managed file synchronization rather than providing integrated cloud sync.
To fully understand how the private key of passkeys is synced, it's important to understand the roles of iCloud Keychain, the Secure Enclave and the encryption involved. Let's explain it with a scenario where the user creates a passkey on their iPhone (old device) and wants to use it on their MacBook (new device).
Subscribe to our Passkeys Substack for the latest news.
The table compares the sync mechanisms as of October 2026.
| Provider | Where the key is decrypted | Protected by | New device needs | All devices lost |
|---|---|---|---|---|
| Apple iCloud Keychain | On the device | Per-device keys of all trusted devices | Approval from a trusted device or old passcode | HSM escrow, passcode, max. 10 attempts |
| Google Password Manager (Android) | On the device | Account key, only on the user's devices | Screen lock of an existing Android device | Screen lock check in secure hardware, max. 10 |
| Google Password Manager (Chrome) | In a Google cloud enclave | Account key, used inside the enclave | Android screen lock or GPM PIN | GPM PIN, locks after 5 failed attempts |
| Microsoft Password Manager (Edge) | In an Azure cloud enclave | Azure Managed HSM, released to attested code | Microsoft Password Manager PIN | PIN, max. 10 attempts |
| 1Password | On the device | Account password plus 128-bit Secret Key | Password and Secret Key, or device approval | Emergency Kit, recovery code |
| Bitwarden | On the device | Master password (PBKDF2 or Argon2id) | Master password, or approval from a device | Emergency Access, admin recovery |
| Dashlane | In an AWS Nitro Enclave | Master password or device key | Master password, or approval from a device | Recovery key, admin-assisted recovery |
On Android, Google Password Manager encrypts passkeys end-to-end with a key "only accessible on the user's own devices", according to Google's security blog (2022). A new device needs the screen lock of an existing Android device. Google checks it in secure hardware with "maximum guesses, which cannot exceed 10 attempts, even by an internal attack." After a screen lock change, the old one still works for recovery for up to 64 days.
Since September 2024, Chrome on Windows, macOS and Linux syncs these passkeys too. The first time, Chrome asks for the screen lock of the Android phone or a Google Password Manager PIN:
Source: Google Chrome for Developers
On desktop, the passkey is used in a Google-run cloud enclave. Chrome's open-source code shows the enclave decrypting the passkey and returning only the signature.
Windows Hello passkeys are device-bound and never sync. Synced passkeys came with Microsoft Password Manager in Edge 142 in November 2025 for personal Microsoft accounts. A new device needs the Microsoft Password Manager PIN, with a maximum of 10 attempts.
Creation, sign-in and recovery run inside Azure confidential computing. The encryption keys sit in Azure Managed HSM and are only released to attested code. The client devices use Windows Hello and device-bound keys to authorize each operation:
Source: Microsoft Edge Blog
Microsoft does not describe this model as end-to-end encryption. Microsoft Entra work accounts were not supported at launch.
Password managers store a passkey as a normal vault item and sync it with the same end-to-end encryption as passwords:
Source: Dashlane
In the device model, only the user's devices can decrypt the private key, and the provider stores ciphertext. In the enclave model, the provider decrypts and uses the key inside hardware-isolated servers and returns only the signature. Both keep the key away from ordinary servers. With an enclave, "not even the provider can use the key" depends on hardware attestation and the provider's enclave code.
Malware on the user's device defeats both models. In August 2026, Palo Alto Networks Unit 42 showed that malware already running on a Windows PC can steal the Google Password Manager master key from Chrome's memory.
Which sync model protects a company's users depends on the providers they choose. Corbado Observe reads the AAGUID and the backup flags on every passkey registration and login. The Authenticator Inventory shows the share of synced, device-bound and security-key credentials per provider, for example iCloud Keychain, Google Password Manager or 1Password.
See Authenticator Inventory in Corbado Observe →Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →
Table of Contents
Related Articles