How Passkeys Sync Across Devices Safely

Log into a website with a passkey on your phone, then open the same website on your laptop, and you can often sign in there too, without typing a password. That works because the passkey itself synced securely between your devices through an encrypted cloud keychain, not because it was copied over an ordinary, exposed network connection. Unlike a traditional password, which is a single reusable secret transmitted to a server and vulnerable if that server is breached, a passkey relies on public-key cryptography (a system using a mathematically linked pair of keys, one public and one private, instead of one shared secret) and never transmits anything a server could leak that would let an attacker impersonate you elsewhere. This guide walks through exactly how that sync works, why it does not undermine the security model, and where the real limitations still are.

Why passkeys need a fundamentally different security model than passwords

A password is a shared secret: you and the website both need to know the same string of characters, and the website stores a version of it, ideally hashed (run through a one-way mathematical function that scrambles it), to check against future login attempts. If that stored password data is ever breached, and the same password is reused across other accounts, attackers can potentially access those other accounts too. That reuse problem is a major driver behind large-scale credential-stuffing attacks, where breached password lists from one site get automatically tried against many other sites.

Passkeys, built on the WebAuthn standard developed jointly by the FIDO Alliance and the World Wide Web Consortium (W3C), work entirely differently. When you create a passkey for a website, your device generates a unique cryptographic key pair, a private key and a public key, mathematically linked but computationally infeasible to derive one from the other. The private key never leaves your device's secure hardware storage, such as Apple's Secure Enclave, a dedicated security chip separate from the main processor, or a Trusted Platform Module (TPM) on Windows and Android devices. The public key gets sent to and stored by the website, and because it can only verify signatures rather than create them, it is useless to an attacker on its own (SentinelOne, 2026).

Logging in later involves the website sending a randomly generated challenge that your device signs using the private key, something only your device can do, and the website then verifies that signature using the public key it already has stored. The private key itself never crosses the network at any point in this exchange, at login or at registration.

The FIDO Alliance, whose members include Apple, Google, Microsoft, and major financial institutions, notes that because passkeys use a unique key pair generated separately for every website, a data breach at one company cannot expose credentials usable to log into a completely different, unrelated service, unlike reused passwords ([FIDO Alliance](https://fidoalliance.org/mobileidworld-tech-giants-microsoft-google-and-apple-drive-global-passkey-adoption-with-visa-support/)).

What actually happens when you create a passkey on a new device

The moment you tap "create a passkey" on a website, your device's operating system, not the browser and not the website, handles the cryptographic heavy lifting. It generates the key pair inside secure hardware, and that private key is marked as non-exportable at the hardware level, meaning even the operating system itself cannot pull it out in plaintext form under normal operation. This is sometimes called a device-bound passkey when it stays locked to that specific piece of hardware, as opposed to a synced passkey designed from the start to move between your own devices through an encrypted channel.

The distinction matters because it explains why "syncing" a passkey is not the same operation as, say, copying a file to a USB drive. A raw private key sitting unencrypted in a sync payload would defeat the entire point of storing it in secure hardware in the first place. So platform providers built a separate, purpose-built pipeline for moving that key between devices you control, and that pipeline is where the real engineering work sits.

Does every passkey sync automatically, or do some stay locked to one device?

Not every passkey syncs. Security keys such as YubiKeys generate device-bound passkeys that never leave that specific hardware token by design, which is a deliberate tradeoff for higher assurance environments. Passkeys created through a phone or laptop's built-in platform authenticator, by contrast, are typically synced passkeys, designed to move with you across your other devices signed into the same account.

How the private key actually syncs between your devices

Since the whole security model depends on the private key never leaving secure storage in an exposed, plaintext form, syncing a passkey between an iPhone and a Mac, for example, cannot simply copy the raw key over an ordinary network connection. Instead, platform providers like Apple's iCloud Keychain and Google Password Manager sync passkeys using end-to-end encryption (encryption where only the sender and the intended recipient devices hold the keys needed to decrypt the data, not any server in between). The private key data is encrypted before it ever leaves your device and can only be decrypted by another device that is itself authenticated as belonging to your same account, protected by that device's own local security, such as a passcode or biometric unlock.

Apple documents this explicitly for iCloud Keychain: keychain items, including passkeys, are transferred from device to device, traveling through Apple's servers, but are encrypted end-to-end so that "Apple and other devices can't read their contents" (Apple Support, iCloud Keychain security overview). Apple's dedicated passkey security documentation adds that this sync uses "strong cryptographic keys not known to Apple" and is rate-limited against brute-force attempts even from a privileged position on the cloud backend (Apple Support, About the security of passkeys). Apple's secure keychain syncing documentation describes the mechanism more precisely: each synced item is encrypted so it can only be decrypted by a device within the user's established "circle of trust," a set of devices that have each separately proven they belong to the same account, and it cannot be decrypted by any other device, or by Apple itself (Apple Support, Secure keychain syncing).

This is similar in concept to how an end-to-end encrypted messaging app syncs your message history across your own devices. The data travels through a cloud service, but that cloud service itself never has access to the readable, decrypted content, only encrypted data it cannot independently interpret. Think of it less like mailing a spare house key through the postal service, where anyone who intercepts the envelope could use it, and more like sending a locked safe through the mail while the only matching combination lives in the memory of people who already proved, through a separate and secure process, that they are you.

Apple's own documentation states that during iCloud Keychain sync, each item is encrypted so it "can be decrypted only by a device within the user's circle of trust," and explicitly "can't be decrypted by any other devices or by Apple" ([Apple Support, Secure keychain syncing](https://support.apple.com/guide/security/secure-keychain-syncing-sec0a319b35f/web)).

Why can't a stolen password database also be used to compromise passkeys?

Because the private key half of a passkey never leaves your device, even in encrypted transit between your own devices, a website's database breach can only expose your public key. That public key is useless to an attacker on its own since it can only verify signatures, not create them, giving an attacker no way to actually log in as you using the stolen data.

Cross-device sign-in when your passkey has not synced yet

Sometimes you need to log into a website on a device that has never held that passkey at all, such as a public library computer or a friend's laptop. The FIDO Alliance built a separate mechanism for exactly this case, distinct from the cloud-sync mechanism described above, so it is worth pulling apart because the two get conflated often.

When you scan a QR code on an unfamiliar computer's login screen with your phone, your phone establishes a short-range, encrypted Bluetooth connection with that nearby device, in addition to an internet connection, specifically to prove the two devices are physically close to each other. Bluetooth's short range acts as a proximity check that resists remote phishing attempts where an attacker might otherwise show you a QR code from across the internet. Your phone then signs the login challenge locally using your device-held private key and relays the resulting signature to the unfamiliar computer over that encrypted channel. The private key itself still never leaves your phone, and it is never copied to or stored on the unfamiliar computer at any point in the process.

Apple, Google, and Microsoft jointly committed in May 2022 to expand support for this shared FIDO/WebAuthn standard, including this kind of cross-device authentication where a phone can approve a sign-in for a nearby app or website "regardless of the OS platform or browser they are running" (Apple Newsroom, May 2022). That announcement is what set the stage for the passkey rollout that followed across iOS, Android, Windows, and major browsers over the following years.

Why this design change matters for everyday security

Passkeys are specifically designed to resist phishing, a major weakness of traditional passwords, since a passkey is cryptographically bound to the specific website domain it was created for. Even if a user is tricked into visiting a convincing fake login page, the device will not offer up a signature using the passkey meant for the real site, because the domain does not match. This binding happens automatically, at the protocol level, without requiring the user to notice anything suspicious about the fake page first. Traditional passwords carry no such built-in protection, since a user can be tricked into typing the same password into a fake site that looks pixel-identical to the real one.

Major platforms including Apple, Google, and Microsoft have rolled out passkey support broadly across their ecosystems since the 2022 joint FIDO commitment, and organizations like the FIDO Alliance have positioned passkeys as a long-term replacement path for passwords specifically because they eliminate several of the most common password-related attack vectors, phishing, credential reuse, and server-side password database breaches, simultaneously.

The practical effect of this is a shift in what a large-scale breach can actually do to you. A leaked password database today, whether it stores plaintext or improperly hashed passwords, can be catastrophic if you reused that password anywhere else. A leaked public-key database from a site that only supports passkeys is, by contrast, close to worthless to an attacker, because a public key by itself cannot be turned into a working login.

What this means for phishing-resistant authentication compared to older methods

It helps to see where passkeys sit relative to the authentication methods most people have used for years. The table below compares the most common approaches on the specific dimension of phishing resistance, since that is the attack passkeys were built to close off.

Authentication method	What it relies on	Resistant to phishing	Resistant to database breach reuse
Password alone	A shared secret typed and transmitted at login	No	No
Password + SMS one-time code	A shared secret plus a code sent over the cellular network	Partial	Partial
Password + authenticator app (TOTP)	A shared secret plus a time-based code generated locally	Partial	Partial
Passkey (WebAuthn/FIDO)	A device-held private key that signs a domain-bound challenge	Yes	Yes

Only passkeys are cryptographically bound to the requesting domain, which is why they are the only method in this table that fully resists a user being tricked into authenticating on a convincing fake login page.

SMS one-time codes and authenticator app codes both meaningfully raise the bar over a password alone, because an attacker needs to compromise a second factor in addition to the password. But neither is domain-bound: a sufficiently convincing phishing page can prompt a victim to type their SMS code or TOTP code directly into the fake site, and the attacker relays it to the real site within the short validity window. That relay attack, sometimes called a real-time phishing or adversary-in-the-middle attack, is precisely the category passkeys were designed to close, since there is no code for a user to be tricked into typing anywhere. The signature itself is generated locally and is useless outside the domain it was created for.

The U.S. federal government's phishing-resistant authenticator guidance specifically calls out FIDO2/WebAuthn credentials, the same standard underlying passkeys, as meeting its bar for phishing resistance, distinguishing them from SMS and app-based one-time codes ([IDManagement.gov, Phishing-Resistant Authenticator Playbook](https://www.idmanagement.gov/playbooks/altauthn/)).

Common misconceptions about passkey syncing

A frequent misunderstanding assumes syncing a passkey to the cloud means the cloud provider itself has access to your private key and could theoretically use it to log in as you. In reality, the end-to-end encryption architecture used by Apple's iCloud Keychain and Google Password Manager is specifically designed so the cloud provider only ever handles encrypted data it cannot decrypt or use, with decryption only possible on a device already authenticated to your account.

Another common error assumes losing access to all your synced devices means permanently losing access to every account secured with passkeys. Most platforms provide recovery mechanisms tied to account-level security, such as other trusted devices or account recovery processes, though the specifics vary by provider and represent an area still actively being refined as passkey adoption grows. Apple, for example, requires a device to already be established within the circle of trust before it can decrypt synced keychain items, which means account recovery after losing every trusted device is intentionally harder than recovering a forgotten password, a direct tradeoff for the stronger security guarantee.

A third misconception treats "passkey" as a single, uniform technology with identical guarantees everywhere. In practice, a device-bound passkey stored only on a hardware security key offers different recovery and portability properties than a synced passkey stored in a cloud keychain, and users moving between an iPhone and a Windows laptop, or switching password manager providers entirely, may find that passkey portability between ecosystems is still maturing. Groups within the FIDO Alliance have been actively working on credential exchange standards to make moving passkeys between different providers more seamless, an acknowledgment that this area is not yet fully solved (Security Boulevard, 2026).

A fourth misconception assumes passkeys eliminate the need for any device security at all. They do not: because the private key's use is gated by your device's local unlock mechanism, a passcode or biometric, a passkey's real-world security is only as strong as that local unlock. A device with no passcode set at all significantly weakens the overall guarantee, since anyone holding the unlocked device could potentially trigger a signature.

Where passkey sync still has real limitations

It is worth being direct about what this architecture does not solve, rather than presenting passkeys as a flawless replacement for every password-related problem. First, cross-ecosystem portability between different platform providers is genuinely still a work in progress; a passkey created inside Google Password Manager does not automatically show up inside Apple's iCloud Keychain, even though both implement the same underlying WebAuthn standard. Second, account recovery after losing all synced devices is intentionally harder than a traditional "reset your password" flow, which is a deliberate security tradeoff but a real usability cost for some users. Third, not every website supports passkeys yet, so most people are managing a hybrid mix of passkeys and passwords for the foreseeable future, which means password hygiene has not become obsolete. Fourth, the security of the whole system still ultimately depends on your platform account itself, meaning securing your Apple ID or Google Account with strong protections remains essential, since that account is effectively the master key controlling which devices can join the circle of trust that can decrypt your synced passkeys.

The takeaway

Passkeys sync safely across devices because the sensitive private key half of the credential is protected by end-to-end encryption throughout the entire sync process, meaning the cloud service moving that data between your devices never has access to a usable, decrypted version of it. Combined with the fact that the private key never needs to be transmitted to a website at login time at all, only a signature the website can verify but not reuse, this architecture is exactly why a breach at one company using passkeys cannot cascade into compromised accounts elsewhere, the way reused, breached passwords so often do. The remaining rough edges, mainly cross-provider portability and account recovery after total device loss, are active engineering problems the FIDO Alliance and platform vendors are still working through, not flaws in the core cryptographic design.

---

Read next:

• How digital signatures prove a file is authentic
• How OLED screens create true black
• How LiDAR measures distance

FAQ

Q: How is a passkey different from a traditional password?

A password is a shared secret transmitted to and stored by a website, while a passkey uses a unique cryptographic key pair per website; the private key never leaves your device, and login involves signing a challenge rather than sending any reusable secret across the network.

Q: How does a passkey actually sync between my phone and laptop without exposing it?

Platform providers like Apple's iCloud Keychain and Google Password Manager use end-to-end encryption, encrypting the private key data before it leaves your device so the cloud service handling the sync never has access to a readable, decrypted version, and only a device already inside your established circle of trust can decrypt it.

Q: Can a website data breach compromise my passkeys?

No, not in the way password breaches work. A breach can only expose your public key, which can verify signatures but cannot create them, giving an attacker no way to actually log in as you using that stolen data.

Q: Why are passkeys considered resistant to phishing attacks?

A passkey is cryptographically bound to the specific website domain it was created for, so even if a user is tricked into visiting a convincing fake login page, the device will not produce a valid signature for that fake site, since the domain does not match the one the passkey was registered to.

Q: What happens if I lose all my devices that have my passkeys synced?

Most platforms provide account-level recovery mechanisms, such as other trusted devices or provider-specific recovery processes, though the exact recovery options vary by platform and remain an area actively being refined as passkey adoption grows.

Q: Do all passkeys sync to the cloud automatically?

No. Passkeys created through a phone or laptop's built-in authenticator are typically synced passkeys designed to move across your devices, while passkeys generated on dedicated hardware security keys, like a YubiKey, are usually device-bound and stay locked to that one piece of hardware by design.

Q: What's the difference between using a passkey and using SMS-based two-factor authentication?

SMS codes add a second factor beyond your password but can still be phished, since a fake login page can trick you into typing the code, which the attacker then relays to the real site. A passkey has no code to type at all; the signature it produces is bound to the real site's domain, so it cannot be reused on a phishing page.