Passkey Architecture In Google Authenticator Poses New Cyberattack Threats

Google Authenticator’s widely adopted passwordless architecture introduces a hybrid model that blends hardware security with cloud-based key management, creating new and largely unexplored attack surfaces.

Security researchers have uncovered hidden mechanisms in how these synced passkeys operate, revealing potential vulnerabilities that could allow attackers to impersonate devices and bypass authentication.

The Cloud Architecture

Passwordless authentication is often viewed as the ultimate solution to account takeovers, but real-world deployments tell a different story.

Attackers rarely target theoretical protocols; instead, they focus on common implementations where usability meets complex architecture.

Google’s passkey ecosystem relies on a largely undocumented cloud-based component located at the domain enclave.ua5v.com.

This domain handles highly sensitive cryptographic operations and synchronizes passkeys across macOS, Windows, Linux, and ChromeOS devices.

When a user sets up a passkey on their first device, Chrome initiates a background onboarding process.

A search for the Google Authenticator URL returns only a few non-informative results (Source: paloaltonetworks)
A search for the Google Authenticator URL returns only a few non-informative results (Source: paloaltonetworks)

These keys are registered with the remote cloud authenticator, which then creates a unique wrapping key to encrypt future communications.

Additionally, the first device generates a Security Domain Secret (SDS) and a recovery PIN.

The SDS serves as a master key to encrypt all synced passkeys, ensuring they can be securely distributed across the user’s trusted devices without exposing raw key material.

High-level overview of the device onboarding (Source: paloaltonetworks)
High-level overview of the device onboarding (Source: paloaltonetworks)

Synchronization And Risks

Once a device joins the security domain, creating and using passkeys involves a complex, encrypted exchange.

When a user registers a new passkey, Chrome establishes a secure, peer-to-peer connection with the cloud authenticator using WebSockets and the Noise Protocol framework.

The cloud authenticator decrypts the master SDS, generates a new passkey, encrypts it, and sends it back to the device.

This encrypted passkey is then uploaded to Chrome Sync, making it available to all other enrolled devices in the user’s ecosystem.

Google prompt for creating a PIN (Source: paloaltonetworks)
Google prompt for creating a PIN (Source: paloaltonetworks)

Google’s hybrid approach moves sensitive key operations to an isolated cloud environment while keeping every request anchored to hardware-backed device keys.

According to Palo Alto Networks research, while this design enables seamless cross-device synchronization, it also opens the door to new threats.

If a remote attacker compromises communication channels or exploits cloud-based weaknesses, they may be able to impersonate a trusted synced device.

This would allow threat actors to perform valid passkey authentications and gain unauthorized access to critical accounts.

To defend against these emerging vectors, security teams must treat cloud identity infrastructure as a dynamic attack surface, monitoring for anomalous authentication patterns and misconfigured access permissions.

Follow us on Google News , LinkedIn and X to Get More Instant UpdatesSet Cyberpress as a Preferred Source in Google.

Varshini
Varshini
Varshini is a Cyber Security expert in Threat Analysis, Vulnerability Assessment, and Research. Passionate about staying ahead of emerging Threats and Technologies..

Trending News

Related Stories