Google passkey design adds a cloud layer that could create new attack paths, researchers warn

Google’s synced passkey system may expose a broader attack surface than many users realize, according to new Unit 42 research into how Google Password Manager handles passkey creation, storage, and login on desktop Chrome. The core finding is not that passkeys are broken. It is that Google’s implementation adds a cloud-based authenticator layer that performs sensitive cryptographic operations during synced passkey use.

Unit 42 says Chrome connects to a cloud authenticator during synced passkey operations and that this component plays a direct role in passkey creation and assertion flows. In the researchers’ view, that means defenders should not look only at WebAuthn and FIDO on paper. They should also examine the real implementation path, especially the cloud-side logic that sits between Chrome, Google account services, and the relying party.

Google’s own developer documentation confirms the broader design principle behind synced passkeys. Google says passkeys stored in Google Password Manager are encrypted on-device before sync and can then be used across Android devices and Chrome browsers signed into the same Google account. That convenience improves usability, but it also means the system depends on more than one local device component.

The research focuses on synced passkeys for desktop users, not on the entire passkey standard. Unit 42 says the FIDO specifications do not explicitly define a cloud-based authenticator, even though Google’s implementation uses one. That distinction matters because a secure standard can still produce new risks when large-scale cloud coordination enters the picture.

What Unit 42 says happens behind the scenes

According to Unit 42, device onboarding generates account secrets and sets up a security domain tied to Google services. The researchers say the system uses a security domain secret, or SDS, as a symmetric master key to encrypt and decrypt synced passkeys for the account. They also say onboarding state gets stored locally, including data in a file named passkey_enclave_state.

When a user creates a synced passkey, Unit 42 says Chrome sends a passkeys/create request to the cloud authenticator, along with device and wrapping information. The cloud side then unwraps the secret, generates a new P-256 key pair, encrypts the private key with the SDS, and returns the public key and encrypted private key to Chrome.

When a user later signs in with that synced passkey, Unit 42 says Chrome sends a passkeys/assert request. The cloud authenticator then unwraps the SDS, decrypts the passkey’s encrypted private key, builds the authenticator response, signs the data, and returns the assertion to Chrome, which forwards it to the relying party.

That architecture does not prove an active exploit. But Unit 42 argues it concentrates important cryptographic authority in a remote component, which creates fresh places for attackers to focus if they ever find a way to compromise, impersonate, or misuse that cloud-side path.

Why researchers say this matters

The main concern is trust concentration. In a traditional user mental model, a passkey often sounds like something locked to a local device. Unit 42 says Google’s synced implementation works differently for desktop Chrome users because cloud-side services participate directly in generating and using the credential.

That does not automatically make synced passkeys unsafe. Google still says passkeys are encrypted on-device before sync, and Unit 42 also describes secure communication measures in the design. But the research argues that defenders should stop treating “passwordless” as shorthand for “simple” or “local-only.”

Unit 42 says Chrome protects communication with the cloud authenticator through a secure protocol and uses a Google OAuth2 access token as the main authorization signal for cloud authenticator operations. Even so, the researchers say the existence of this remote authenticator layer deserves more scrutiny because it becomes part of the real attack surface for synced passkeys.

What Google documents publicly

Google’s developer documentation says passkeys can live in password managers such as Google Password Manager and synchronize across the user’s Android devices and Chrome browsers signed into the same Google account. It also notes that users on Android 14 or later can choose compatible third-party password managers.

That public explanation highlights the sync model, but it does not go into the same implementation detail as the Unit 42 research. The gap between high-level product messaging and low-level architecture is one reason this research is getting attention. That is an inference based on comparing Google’s developer documentation with Unit 42’s technical write-up.

Key points at a glance

Area	What the research says
Main issue	Synced passkeys rely on a cloud authenticator, not just local device hardware
Research focus	Desktop Chrome users using Google Password Manager synced passkeys
Sensitive material	The SDS and encrypted passkey private keys play a central role
Login flow	Cloud side helps decrypt and sign assertion data during authentication
Research takeaway	The implementation adds attack surface beyond the core passkey standard

Source basis for this table comes from Unit 42’s technical breakdown and Google’s passkey documentation.

What users and organizations should do

Organizations that use synced passkeys through Google Password Manager should review device enrollment activity, watch for unusual authentication patterns, and apply stricter controls to high-sensitivity accounts. Unit 42 specifically recommends considering FIDO2 hardware security keys for privileged or sensitive access instead of relying only on cloud-synced passkeys.

For regular users, the article does not suggest panic or abandoning passkeys. The more practical takeaway is to understand which passkeys are hardware-bound and which are cloud-synced, then use stronger options for your most important accounts. That recommendation follows directly from Unit 42’s architecture analysis and Google’s sync model.

FAQ