Google Authenticator’s Hidden Passkey Architecture Could Open New Passwordless Attack Paths

Home Cyber Security News Google Authenticator’s Hidden Passkey Architecture Could Open New Passwordless Attack Paths Passwordless authentication was supposed to mark the end of account takeovers. Designed to replace traditional passwords with cryptographic keys tied to physical devices, it promised a future where stolen credentials could no longer unlock user accounts. But a close examination of how Google has actually built its passkey ecosystem reveals something far more complex than the clean, secure image that “passwordless” typically projects. Beneath every passkey login powered by Google Password Manager, a hidden cloud component is silently performing sensitive cryptographic operations — and it may be creating new attack paths that have never been publicly discussed. Google’s passkey system does not work like a conventional hardware authenticator locked to a single device. Every time a Chrome user logs into a service using a passkey backed by Google Password Manager (GPM), the browser quietly opens a connection to a remote service hosted at enclave.ua5v[.]com. This domain functions as a cloud-based authenticator responsible for generating passkey keys, handling authentication requests, and keeping credentials synchronized across all of a user’s enrolled devices. As of January 2026, almost no public information described this domain’s role in passkey authentication, despite the fact that it was silently powering logins at scale worldwide.  A search for the Google Authenticator URL returns only a few non-informative results (Source – Unit42) Unit 42 researchers identified this cloud-based structure while conducting a deep security review of Google’s passkey implementation, approaching the work from an attacker’s point of view. Rather than asking whether the FIDO protocol itself was theoretically sound, they asked where passkeys actually live, how they move between devices, and which components carry the most sensitive key material. That shift in perspective exposed a surprisingly broad attack surface — one that existing FIDO and W3C technical documentation does not fully describe or address. The architecture relies on a device onboarding process that runs in the background before passkeys can be used. Chrome generates two hardware-backed key pairs using the device’s Trusted Platform Module (TPM) — an identity key and a user verification key — then registers them with the cloud authenticator. High-level overview of the device onboarding (Source – Unit42) The cloud authenticator stores these public keys, assigns a device-specific wrapping key, and issues a member key pair to establish the device as a trusted participant in the user’s security domain. The entire state resulting from this onboarding is saved locally in a file called passkey_enclave_state, stored within the Chrome profile directory. Parsed view of the passkey_enclave_state file, extracted using a custom script (Source – Unit42) What this architecture creates is a hybrid model where passkey private keys are never stored directly on a device in usable form. Instead, they are encrypted with a Security Domain Secret (SDS) managed by the cloud authenticator. Every login requires Chrome to send the wrapped SDS back to the cloud, where it is decrypted and used to sign the authentication response on the device’s behalf. Chrome-mediated auathentication flow using a synced passkey (Source – Unit42) This places substantial trust in the cloud component — and raises pointed questions about what happens when that cloud-side logic becomes a target. Inside the Cloud Authenticator’s Authentication Flow The communication between Chrome and the cloud authenticator is protected by the Noise Protocol Framework, using the Noise_NK_P256_AESGCM_SHA256 handshake variant.  Chrome-cloud authenticator secure communication flow (Source – Unit42) Chrome opens a WebSocket connection to wss[:]//enclave.ua5v[.]com/enclave, performs a Diffie-Hellman key exchange to establish a shared session key, and then signs every subsequent request with a TPM-backed device key.  WebSocket initialization (Source – Unit42) During a passkey login, Chrome sends the command passkeys/assert along with the device ID and wrapped SDS. The cloud authenticator 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 response to the relying party, which verifies the signature and completes the login. This design keeps key material off the device but concentrates cryptographic authority within a remote cloud enclave that, if compromised or impersonated, could allow an attacker to generate valid authentication responses on behalf of any enrolled user. Organizations and individuals relying on synced passkeys through GPM should closely monitor their Google accounts for unexpected device enrollments, regularly audit authentication logs for unusual access patterns, and consider using FIDO2-compliant hardware security keys for privileged or high-sensitivity accounts instead of cloud-synced passkeys. Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google. RELATED ARTICLESMORE FROM AUTHOR Cyber Security News ClawHub Vulnerability Let Attackers Manipulate Rankings to Become the #1 Skill Cyber Security News FCC Banned Foreign-made Consumer Routers Over Security Risks Cyber Security News LiteLLM PyPI Package With 95 Million Downloads Compromised by TeamPCP Hackers Top 10 Essential E-Signature Solutions for Cybersecurity in 2026 January 31, 2026 Top 10 Best Data Removal Services In 2026 January 29, 2026 Best VPN Services of 2026: Fast, Secure & Affordable January 26, 2026 Top 10 Best Data Security Companies in 2026 January 23, 2026 Top 15 Best Ethical Hacking Tools – 2026 January 15, 2026