Synced Passkeys Are Not the Security Risk You've Been Told

A recent article on How-To Geek argued that syncing passkeys to Google — or any cloud service — defeats the whole point of passkeys.

It's a reasonable concern. It's also pointed at the wrong layer of the problem.

Passkey syncing doesn't create a new security problem — it exposes an old one: account recovery.

We care about this at Brianni because we don't use passwords. Authentication on brianni.co is passkey-based, tied to the biometric on your device. So when people ask us whether syncing their passkeys weakens that model, it's worth answering properly.

Let's break it down.

What a passkey actually is

A passkey replaces your password with something much stronger.

Instead of a shared secret like a password, your device creates two linked keys: a public key stored by the website, and a private key kept protected on your device. When you log in, your device proves it holds the private key — without ever sending it anywhere.

That means there's nothing to steal from a database, nothing to reuse across sites, and nothing to phish. That alone eliminates entire classes of attacks.

This is why Brianni uses passkeys instead of passwords. There is no password database to breach, no reusable secret for an attacker to phish, and no credential that works anywhere other than on brianni.co.

What "syncing" actually means

This is where most of the confusion comes from.

When you use something like Google Password Manager or iCloud Keychain, your passkey is encrypted on your device before it is sent anywhere. That encrypted version is stored in the cloud, and your other trusted devices can access and use it.

The important detail: the provider cannot use the key material in any usable form. iCloud Keychain uses end-to-end encryption, meaning Apple holds no usable key at all. Google Password Manager uses strong encryption tied to your account and device trust model — meaning the practical barrier to misuse is very high, even if the architecture differs slightly between providers.

So yes — the key is synced. But only as locked data that only your trusted devices can unlock.

This is the same principle that underpins everything in Brianni's vault: content is encrypted on your device before it ever reaches us, and we cannot read it, preview it, or hand it over.

The claim: "If your Google account is hacked, everything is lost"

This sounds alarming, but it mixes up two separate things: the security of the passkey itself, and the security of your broader account — your email, your recovery options, your connected services.

Those are not the same thing.

The part that gets missed

Even with syncing, using a passkey still requires a trusted device and your fingerprint, face scan, or PIN. That check happens on your device — not in the cloud.

So an attacker who gets into your Google account can read your emails and access your files — but they cannot simply use your passkeys. To do that, they would also need to enrol a new trusted device. That process is defended separately: providers like Google and Apple impose waiting periods, risk checks, and identity verification before a new device is trusted and sync is enabled. It is a meaningfully harder problem than account recovery alone.

That said, it is not impossible. If an attacker fully defeats account recovery and successfully navigates device enrolment, the system will eventually treat their device as legitimate — and the synced passkey becomes accessible on it. But notice what that actually means: the attacker did not break passkey cryptography, did not extract keys from a server, and did not bypass the platform. They became the account owner through the identity system — and the system behaved exactly as designed.

That is an account ecosystem failure — not a passkey failure.

So where is the real risk?

The real issue is not passkeys — it is account recovery.

If a service allows someone to reset your account using email links, SMS codes, or weak verification flows, an attacker can go around your passkey rather than through it. This is sometimes called a recovery downgrade attack: the passkey was not broken, it was bypassed entirely.

Blaming synced passkeys for this is like blaming a strong front door lock because someone climbed in through an open window. The lock did its job. The window is a separate problem.

Are synced passkeys the same as a password in a manager?

No — and this distinction matters.

A stolen password can be typed into any login form, anywhere in the world. A synced passkey is different:

• it only works on the real website it was registered for
• it cannot be entered into a fake login page
• it requires your device to actively approve its use

Even when synced, it is not a portable secret. It is something your device holds and mediates — and that does not change because it is available on more than one of your devices.

"But device-bound passkeys don't have this problem"

The original article suggests that keeping passkeys tied to a single device — never synced — avoids these risks entirely. It's worth addressing this directly, because it's not quite right either.

Device-bound passkeys do remove one attack surface: there is nothing in the cloud for an attacker to eventually access, even after a full account takeover. That part is genuinely stronger.

But the account recovery downgrade attack does not disappear — it simply moves to a different layer.

If you use a device-bound passkey on a website, but that website also offers email-based account recovery, an attacker who controls your email can still trigger "I lost my passkey" and reset access without ever touching your passkey. The passkey remains physically locked to your device and cryptographically intact — and it still gets bypassed entirely.

So device-bound passkeys shift where the downgrade attack happens, not whether it can happen. The vulnerability moves from the sync provider layer to the relying party's own recovery layer.

The only scenario where device-bound passkeys genuinely close this gap is if the website has no account recovery fallback at all. That is extremely rare in practice, because most services cannot afford to permanently lock out users who lose or break their device.

The more accurate comparison is this:

• Synced passkeys are vulnerable to downgrade attacks via provider account recovery and device enrolment.
• Device-bound passkeys are vulnerable to downgrade attacks via the website's own recovery flow.

Both share the same category of risk. The attack surface is in a different place — but the underlying problem is identical.

The implication that device-bound passkeys sidestep this issue entirely does not hold up. The real fix is not choosing one passkey storage model over another — it is improving account recovery flows across the board, at every layer.

How this shapes Brianni

This is exactly the reason Brianni's security model does not stop at authentication.

Signing in with a passkey protects access to your account. But the content in your vault is protected by a separate layer: client-side encryption, keyed to material that only your device can derive. Even if someone somehow bypassed passkey authentication, they would still land on encrypted data they cannot decrypt.

Delivery to recipients works the same way. Packages are unlocked with a challenge question only the recipient can answer — the answer is never sent to our servers, the decryption key is derived on the recipient's device. A compromised inbox does not unlock a package, because the package was never readable by email in the first place.

Auth is one layer. Encryption is another. Recovery has to be hardened independently of both. That's the lesson the synced-vs-device-bound debate keeps circling around without quite naming.

The bottom line

Syncing passkeys does not weaken them. It makes them usable.

Without sync, losing your device means losing access. With sync, your credentials follow you safely — without becoming something an attacker can simply steal and replay elsewhere.

Are there still risks? Yes. But they are the same ones that have always existed: account recovery flows, email security, and weak fallback systems. Passkeys do not make those worse — they just do not fix them on their own.

Final thought

Passkeys are doing exactly what they were designed to do: stop phishing, stop password reuse, and stop credential leaks from being useful to attackers. Syncing does not undo any of that.

If anything, sync is what makes passkeys practical enough for real people to actually use.

The real work now isn't abandoning passkeys — it's fixing the rest of the authentication system around them.

Brianni is one small part of that. We chose passkeys for sign-in because we think passwords are the wrong primitive for a privacy-first product, and we layered client-side encryption underneath because authentication alone is never enough.

You can try Brianni free at brianni.co — no password required.