Google Authenticator Passkeys: A Potential New Attack Surface

Key Takeaways

• Google’s passkey ecosystem, particularly when using Google Password Manager (GPM), relies on a previously undisclosed cloud component at enclave.ua5v[.]com.
• This cloud authenticator performs critical cryptographic operations, including generating passkey keys and handling authentication requests, creating a centralized point of trust.
• Researchers from Unit 42 identified this architecture as a significant, undescribed attack surface, shifting sensitive key material to a remote enclave.
• The design means passkey private keys are never stored directly on a device in usable form but are decrypted and used in the cloud, raising concerns about cloud-side logic compromise.
• Users are advised to monitor Google accounts for unusual activity and consider hardware security keys for critical accounts.

Google’s Passkeys: A Hidden Cloud Component Unveils New Attack Surfaces

The promise of passwordless authentication has long been the elimination of account takeovers by replacing traditional passwords with cryptographically secure keys tied to physical devices. This vision aimed to render compromised credentials obsolete for unauthorized account access.

However, an in-depth analysis of Google’s passkey implementation reveals a more intricate system than the “passwordless” ideal suggests. This complexity potentially introduces novel attack paths that have not been publicly acknowledged or thoroughly discussed.

The Undisclosed Cloud Authenticator

Beneath every passkey login facilitated by Google Password Manager (GPM), a clandestine cloud component is actively executing sensitive cryptographic functions. This component, operating silently, may be inadvertently creating new vulnerabilities within the passkey ecosystem.

Contrary to the model of a conventional hardware authenticator tied to a single device, Google’s passkey system functions differently. When a Chrome user logs into a service using a passkey backed by GPM, the browser surreptitiously establishes a connection to a remote service hosted at enclave.ua5v[.]com.

This domain acts as a cloud-based authenticator, responsible for generating passkey keys, processing authentication requests, and maintaining credential synchronization across all of a user’s enrolled devices. As of January 2026, the critical role of this domain in passkey authentication remained largely undocumented, despite its widespread operation.

Researchers at Unit 42 uncovered this cloud-centric architecture during a comprehensive security review of Google’s passkey implementation. Their approach involved adopting an attacker’s mindset, focusing on the practical aspects of passkey storage, movement between devices, and the location of sensitive key material, rather than merely the theoretical soundness of the FIDO protocol.

This shift in perspective exposed an unexpectedly broad attack surface, one that existing FIDO and W3C technical documentation does not adequately detail or address.

Device Onboarding and State Management

The architecture relies on a background device onboarding process that must complete before passkeys can be utilized. During this process, Chrome generates two hardware-backed key pairs—an identity key and a user verification key—using the device’s Trusted Platform Module (TPM). These keys are then registered with the cloud authenticator.

The cloud authenticator stores these public keys, assigns a device-specific wrapping key, and issues a member key pair. This establishes the device as a trusted participant within the user’s security domain. The entire state resulting from this onboarding is saved locally in a file named passkey_enclave_state, located within the Chrome profile directory.

This hybrid model ensures that passkey private keys are never stored directly on a device in a usable format. Instead, they are encrypted with a Security Domain Secret (SDS) managed by the cloud authenticator. Every login requires Chrome to transmit the wrapped SDS back to the cloud, where it is decrypted and used to sign the authentication response on behalf of the device.

This design places significant trust in the cloud component, raising critical questions about the security implications if this cloud-side logic were to become a target for compromise.

Inside the Cloud Authenticator’s Authentication Flow

Communication between Chrome and the cloud authenticator is secured using the Noise Protocol Framework, specifically the Noise_NK_P256_AESGCM_SHA256 handshake variant.

Chrome initiates a WebSocket connection to wss[:]//enclave.ua5v[.]com/enclave, performs a Diffie-Hellman key exchange to establish a shared session key, and subsequently signs every request with a TPM-backed device key.

During a passkey login, Chrome sends a passkeys/assert command, along with the device ID and the wrapped SDS. The cloud authenticator then unwraps the SDS, decrypts the passkey private key, constructs the authentication response, and signs it before returning it to Chrome. The browser then forwards this signed response to the relying party, which verifies the signature to complete the login process.

While this design keeps key material off individual devices, it centralizes cryptographic authority within a remote cloud enclave. Should this enclave be compromised or impersonated, an attacker could potentially generate valid authentication responses for any enrolled user, bypassing traditional device-level security.

What You Should Do

• Organizations and individuals using synced passkeys via Google Password Manager (GPM) should vigilantly monitor their Google accounts for any unexpected device enrollments.
• Regularly audit authentication logs for unusual access patterns or suspicious login activities.
• For privileged or highly sensitive accounts, consider using FIDO2-compliant hardware security keys as an alternative to cloud-synced passkeys, as they offer a more robust, device-centric security model.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.