Google Authenticator: The Hidden Mechanisms of Passwordless Authentication

Summary

Palo Alto Networks' Unit 42 published deep technical research into Google's passwordless authentication implementation, focusing on synced passkeys in Google Authenticator and the cloud-based enclave.ua5v.com service. The analysis examines key management, device onboarding, and cryptographic operations to identify previously undisclosed attack vectors in real-world passwordless deployments. The research deliberately shifts perspective from protocol security to implementation vulnerabilities where usability, scale, and architecture intersect.

Full text

Threat Research CenterThreat ResearchCloud Cybersecurity Research Cloud Cybersecurity Research Google Authenticator: The Hidden Mechanisms of Passwordless Authentication 13 min read Related ProductsCortexCortex CloudUnit 42 Cloud Security AssessmentUnit 42 Incident Response By:Arie Olshtein Published:March 23, 2026 Categories:Cloud Cybersecurity ResearchThreat Research Tags:GoogleGoogle authenticatorGoogle ChromeIdentityPasskeyPasswordless Share Executive Summary Passwordless authentication is often presented as the end of account takeover. But to understand the real threat landscape, we need to examine how passwordless is actually deployed in the real world. Attackers do not break protocols in theory. They target the most common implementations, the places where usability, scale and architecture intersect. Focusing on one of those common implementations, we examine Google Authenticator. This discussion explores the hidden mechanisms behind synced passkeys and their implementation within the Google ecosystem. Our aim is to help defenders better understand the technology, to lay the groundwork to show how new attack vectors could emerge in a passwordless environment. This post is Part 2 in our series examining passkey adoption from a security perspective. If you haven’t read Part 1 yet, we recommend starting here: The Art of the Invisible Key – Passkey Global Breakthrough. Palo Alto Networks customers are better protected from threats that take advantage of issues with cloud authentication through the following products and services: Cortex Cloud Identity Security CyberArk Identity Protection Unit 42 Cloud Security Assessment If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Related Unit 42 Topics Google, Chrome, Cloud Background on Passkey Authentication When we set out to evaluate the security of passkeys, we deliberately thought like attackers. Instead of asking whether Fast IDentity Online (FIDO) is secure, we asked where passkeys live, how they move, how they sync and which components handle the most sensitive operations. That shift in perspective revealed a surprisingly broad and largely unexplored attack surface. Many of the findings we uncovered have not been publicly discussed, and we will reveal them throughout this series. However, before diving into new attack vectors, we need to establish a clear architectural foundation. The FIDO and W3C specifications define the authentication protocols in detail, but the real protection of key material often extends beyond those documents. In practice, critical implementation details are embedded in browsers, operating systems and cloud services, and are rarely described publicly. We therefore began with one of the most widely adopted passwordless ecosystems: Google’s passkey authentication. In this article, we examine the architecture behind synced passkeys for desktop users and explore the lesser known Google Authenticator, a cloud-based component that performs sensitive cryptographic operations. Once we understand how this system is built, we can analyze the new attack vectors it introduces and discuss how to mitigate them in the next part of this series. Disclaimer: This analysis reflects our understanding of a complex, evolving system, based on client code, runtime behavior, network traces and public sources. The research detailed here was conducted for responsible, ethical security analysis. To keep the discussion readable, we simplify certain internal flows and use illustrative pseudocode. Although the Google Authenticator is used by Chrome across platforms, our focus here is Chrome on Windows with Trusted Platform Module (TPM) support. Meet the Invisible Authenticator Whenever users authenticate with passkeys backed by Google Password Manager (GPM) across desktop platforms (macOS, Windows, Linux and ChromeOS), we see a connection to the domain enclave.ua5v[.]com. As of January 2026, searching for enclave.ua5v[.]com yields surprisingly little public information about its role in passkey authentication (as shown in Figure 1). This is despite powering logins worldwide. Figure 1. A search for the Google Authenticator URL returns only a few non-informative results. The FIDO specifications do not explicitly define a cloud-based authenticator. However, related building-block elements exist in Client-to-Authenticator Protocol (CTAP) Hybrid transports, where Bluetooth Low Energy (BLE) physical proximity can be used to establish a tunnel service to Google’s caBLE.ua5v[.]com domain. While Chrome still leverages portions of the Hybrid (caBLE) transport code, understanding the actual implementation requires examining Chrome’s behavior and the cloud authenticator, as observed through its network interface and Chromium source code (as shown in Figure 2). Figure 2. Google Chromium source code referring to Cloud Enclave Passkey Authenticator. Onboarding Device A Chrome user can perform passkey operations synchronized with their Google account, making passkeys available across all connected devices. Before any passkey can be used, Chrome runs a dedicated onboarding flow behind the scenes (shown in Figure 3). This allows the remote Google Authenticator to verify both the device’s identity and the user’s possession of it. Figure 3. High-level overview of the device onboarding. To establish trust between the device and the cloud authenticator, Chrome assigns two TPM-backed key pairs: Identity key: Represents “something you have.” In WebAuthn terms: “Register a particular client device as a ‘trusted device’, so the client device itself acts as a something-you-have authentication factor for future authentication.” User verification key (UV key): Represents “something you know or are.” This key can only be created or used after the user authenticates (verifies) with the same method they use to unlock the device (biometric or PIN). After generating the device keys, the client sends a registration request to the cloud authenticator. The message includes: Commands: "device/register", "keys/genpair" Identity_public_key: Public key corresponding to the TPM-protected identity key. UV_public_key: Public key corresponding to the TPM-protected UV key. Device_id: SHA256 hash of the identity public key (SPKI). The cloud authenticator creates a new record and stores the device’s hardware-backed public keys associated with the device ID: devices[device_id] = { hw: identity_public_key, uv: uv_public_key } In addition, the cloud authenticator generates and stores a device-specific wrapping key. This key is used to encrypt secrets, allowing them to be stored on the device as opaque blobs and unwrapped only by the cloud authenticator: wrapping_keys[device_id] = random(32) Finally, the cloud authenticator generates a member key pair. The private member key is encrypted with the wrapping key. This key is then returned along with the public member key intended for joining the device as a trusted member within the account’s security domain of authorized devices: (member_private_key, a member_public_key) = Generate P-256 key pair wrapped_member_private_key = encrypt(member_private_key, key:wrapping_key) First Device On the first device, the onboarding process also includes generating the account secrets: Security domain secret (SDS): A symmetric master key used by the cloud authenticator to encrypt and decrypt all synced passkeys for the account GPM PIN Code: A user-chosen secret that allows newly added devices to access the account’s synced passkeys Figure 4 shows the start of the recovery PIN process. Figure 4. Google prompt for creating a PIN. Establishing a security domain backed by Google’s Trusted Vault service, linking the user’s authorized devices and managing the encryption keys used by Chrome Sync to securely synchronize passkeys Creating a PIN-protected recovery mechanism to store and recover the SDS securely Joined Device During the first passkey operation on a

Indicators of Compromise

• domain — enclave.ua5v.com
• domain — caBLE.ua5v.com