FreeThe +45-page Authentication Analytics Whitepaper — measuring real login journeysDownload
Back to Overview

How is the Private Key of a Passkey synced?

How iCloud Keychain, Google, Microsoft, 1Password, Bitwarden and Dashlane encrypt and sync a passkey's private key and where it is decrypted.

Vincent Delitz
Vincent Delitz

Created: August 30, 2024

Updated: October 2, 2026

private key sync passkeys

How is the Private Key of a Passkey synced?#

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.

  • Encrypted before upload: the private key of a synced passkey leaves the device only in encrypted form. Apple cannot read iCloud Keychain, with or without Advanced Data Protection.
  • New devices need approval: a new device gets access only after an existing device approves it or the user enters that device's passcode, screen lock or PIN.
  • Guessing is capped: Apple, Google and Microsoft allow at most 10 attempts for these recovery secrets, enforced by secure hardware on their servers.
  • Two models: Apple, Google on Android, 1Password and Bitwarden decrypt the key only on the user's devices. Google in desktop Chrome, Microsoft Password Manager and Dashlane use it inside a cloud enclave run by the provider.

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).

The Private Key is encrypted and uploaded to iCloud Keychain#

  • After passkey creation, the iPhone stores the passkey as an iCloud Keychain item. The Secure Enclave protects the keys that encrypt this item.
  • Before syncing, the item is encrypted so that only the user's trusted devices can decrypt it. Apple's servers store and forward it, but Apple states that "it can't be decrypted by any other devices or by Apple."
  • A simple comparison: iCloud works like a safe-deposit company. It keeps the locked box but never gets a copy of what opens it.

The MacBook must be approved by a trusted Device#

  • Every Apple device has its own key pair, its "syncing identity" (P-384). The MacBook creates one when the user signs in to iCloud.
  • The MacBook only receives the keys to the keychain after it joins the user's trusted devices. Either the iPhone approves it with "a voucher signed by its identity keys", or the user enters the passcode of an older device.
  • Think of a family house key: a new family member only gets a copy if someone who already has one hands it over.

The Private Key is decrypted on the new Device#

  • The MacBook downloads the encrypted keychain item from iCloud and decrypts it locally. The plaintext private key is never exposed during transfer.
  • Once decrypted, the passkey is ready for use on the MacBook, so the user can sign in with the same passkey on their iPhone and MacBook.

Why this matters from a Security Point of View#

  • Protected at rest and in transit: iCloud Keychain's end-to-end encryption protects the private key in the cloud and on the way. Per Apple, this applies even without Advanced Data Protection.
  • Stolen iCloud password is not enough: an attacker also needs a trusted device or the passcode of one. Passcode recovery runs through Apple's hardware security modules (HSMs) and "after the 10th failed attempt, the HSM cluster destroys the escrow record" (Apple).
  • Not a Secure Enclave key: a key created inside the Secure Enclave can never leave it (Apple), so a synced passkey cannot be one. The Secure Enclave guards the keychain encryption keys and the Face ID, Touch ID and passcode checks instead.
Substack Icon

Subscribe to our Passkeys Substack for the latest news.

Subscribe

What do all synced Passkey Systems have in common?#

  • Encrypted record: the device creates the key pair and stores the private half only as an encrypted record.
  • Key hierarchy: the provider's ordinary servers cannot open that record.
  • Second factor for new devices: a new device only gains access after approval from a trusted device or a secret like a screen lock, PIN or master password.
  • Visible to websites: WebAuthn marks synced passkeys with the Backup Eligibility (BE) and Backup State (BS) flags. The AAGUID usually reveals the provider. How the provider protects the key is not visible.

How do Apple, Google, Microsoft and Password Managers compare?#

The table compares the sync mechanisms as of October 2026.

ProviderWhere the key is decryptedProtected byNew device needsAll devices lost
Apple iCloud KeychainOn the devicePer-device keys of all trusted devicesApproval from a trusted device or old passcodeHSM escrow, passcode, max. 10 attempts
Google Password Manager (Android)On the deviceAccount key, only on the user's devicesScreen lock of an existing Android deviceScreen lock check in secure hardware, max. 10
Google Password Manager (Chrome)In a Google cloud enclaveAccount key, used inside the enclaveAndroid screen lock or GPM PINGPM PIN, locks after 5 failed attempts
Microsoft Password Manager (Edge)In an Azure cloud enclaveAzure Managed HSM, released to attested codeMicrosoft Password Manager PINPIN, max. 10 attempts
1PasswordOn the deviceAccount password plus 128-bit Secret KeyPassword and Secret Key, or device approvalEmergency Kit, recovery code
BitwardenOn the deviceMaster password (PBKDF2 or Argon2id)Master password, or approval from a deviceEmergency Access, admin recovery
DashlaneIn an AWS Nitro EnclaveMaster password or device keyMaster password, or approval from a deviceRecovery key, admin-assisted recovery

How does Google Password Manager sync Passkeys?#

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.

How does Microsoft sync Passkeys?#

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.

How do 1Password, Bitwarden and Dashlane sync Passkeys?#

Password managers store a passkey as a normal vault item and sync it with the same end-to-end encryption as passwords:

  • 1Password: the account password (PBKDF2 with 650,000 iterations) and the 128-bit Secret Key together unlock the vault. "AgileBits has no ability to decrypt your or your team's data" (white paper).
  • Bitwarden: the master password (PBKDF2 with 600,000 iterations or Argon2id) derives the master key, which is "never stored on or transmitted to Bitwarden servers" (white paper). Whoever knows the master password and passes the login checks can decrypt the vault.
  • Dashlane: since May 2025, Dashlane uses the passkey inside AWS Nitro Enclaves instead of in the app. The decryption key stays with the user.

Source: Dashlane

Is the Private Key decrypted on the Device or in a Cloud Enclave?#

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.

How Corbado can help#

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

About Corbado

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 →

See what's really happening in your passkey rollout.

Book a Demo

Share this article


LinkedInTwitterFacebook