- Malware on a compromised device can hijack passkeys without ever triggering a fingerprint scan, a face check, or even a PIN.
Passkeys were supposed to be the password killer — the cryptographic solution that would finally make phishing obsolete. Unlike passwords, passkeys can’t be shared, stolen in a data breach, or accidentally handed over to a convincing fake login page.
They promised a future where biometrics and hardware-backed security would render credential theft a relic of the past. But according to new research from Palo Alto Networks’ Unit 42, that future has arrived with some dangerous baggage: malware on a compromised device can hijack passkeys without ever triggering a fingerprint scan, a face check, or even a PIN.
The core problem isn’t the passkey standard itself. It’s how passkeys are implemented in real-world, widely deployed systems — specifically, Google’s synced passkey ecosystem within Chrome and Google Password Manager.
Unit 42 researchers devised three distinct account takeover attacks, collectively branded “Pass-ta-key,” that exploit architectural gaps in how Google authenticates passkey requests. The worst of these attacks allows an attacker to extract and decrypt every passkey synced to a victim’s Google account — effectively handing over the keys to every online service the victim uses.
To understand why these attacks matter, it’s worth understanding what Google’s synced passkey system gets right. Google generates and stores actual passkey private keys in an isolated cloud enclave environment. Those keys never leave that enclave. What lives on the user’s device are two hardware-backed keys stored inside the Trusted Platform Module (TPM) or Secure Enclave: user verification (UV) key and an identity (ID) key.
When a user signs into a service with a passkey, the flow works like this: the user’s biometric or PIN unlocks the UV key, which proves the human is present. The ID key simultaneously proves the request is coming from a genuine, previously registered device.
Both signatures travel to Google’s cloud authenticator, which verifies them and signs the user into the service using the correct passkey. In theory, this chain of trust is robust. In practice, Unit 42 found it has multiple broken links.
Pass-ta-Key — Skipping verification entirely
The first and simplest attack, which the researchers simply call Pass-ta-key, exploits a startling reality: many online services don’t actually check whether the user was verified at all.
The attack works by initiating a login to a target service and completing the authentication challenge using only the ID key signature — the UV key is never touched. The malware, running with ordinary user privileges and without elevated access, mimics Chrome’s own behavior to request a signature from the device’s TPM.
From the cloud authenticator’s perspective, the request appears to originate from a trusted device making a legitimate request, so it produces a valid assertion response. That assertion is forwarded to the relying party — the online service — which accepts it and grants the attacker full control of the victim’s account.
The critical failure here lies in a single bit: the User Verified (UV) flag. The WebAuthn standard includes this flag so that relying parties can check whether a biometric or PIN check actually occurred. But Unit 42 found that numerous services, including eBay at the time of testing, simply trusted whatever value the flag carried — and malware can trivially set it to “true.”
The service never verified that a fingerprint was scanned or a face was shown. It just took the assertion at face value. eBay has since patched the issue.
“We identified relying parties that accepted authentication because they did not properly validate the UV flag,” the researchers wrote. “This allowed the attack to succeed despite the absence of user verification.”
Not every service fell for it. GitHub, notably, correctly rejected the attack — an indication that proper validation is entirely possible, just not universally implemented.
Silver Pass-ta-Key — Forging the UV key itself
The second attack goes further. Where Pass-ta-key simply ignored the UV key, Silver Pass-ta-key forges one.
Google’s cloud authenticator maintains a record of each registered device and its associated UV key. When malware executes a device/forget command, it invalidates the legitimate UV key stored on the device. The attacker then initiates a fresh device registration — and here is where the second architectural gap appears: Google’s cloud authenticator accepts the new UV key and onboarded the device without verifying that a genuine hardware TPM signed it.
In effect, the malware convinces Google that it is setting up a brand-new device, complete with a UV key controlled entirely by the attacker. Once registered, the attacker can generate valid UV signatures on demand, satisfying even those services that properly check the UV flag. This attack unlocks access to highly sensitive accounts, including those in banking and federal systems where stronger authentication requirements are enforced.
The implication is sobering: even when relying parties do everything right, the authentication chain can be broken further upstream, at the cloud authenticator level.
Golden Pass-ta-Key — Stealing every synced passkey
If the first two attacks represent targeted account takeovers, the third is a full-scale credential heist.
All of a user’s synced passkeys are protected by a master key called the security domain secret (SDS). This key is the crown jewel: if an attacker obtains it, they can decrypt every passkey associated with the victim’s Google account and authenticate as a fully verified user to every service where passkeys are used.
Google designed the system so that the SDS is not directly accessible to the user or to anything running on the device. Users store only an encrypted version, and only Google’s cloud service holds the key to decrypt it.
Or so the design intended. Unit 42 researchers found the SDS leaking in plain text — inside Chrome’s own debug logs, during the device onboarding process. The most secret key in the entire passkey architecture was being written to logs that malware with user-level access could read.
Google removed the SDS from Chrome’s logging output following Unit 42’s disclosure. But the researchers warn that the fix is incomplete. The SDS is still sent to the client device during the recovery flow and remains accessible in Chrome’s process memory. “If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory,” the report notes.
Golden Pass-ta-key is the worst-case scenario: total compromise of the victim’s passkey ecosystem, with no service left untouched.
The malware prerequisite
All three attacks share one prerequisite: malware must be running on the victim’s device. At first glance, this might seem like a significant limitation. But Unit 42 and the broader security community have repeatedly demonstrated that achieving this initial foothold is often trivial.
Automated phishing campaigns like ClickFix have proven remarkably effective at tricking users into downloading and executing malicious payloads. These campaigns target the masses, not specific high-value individuals, and they succeed at scale.
Once the malware is present, the Pass-ta-key attacks require no privilege escalation, no device unlock, and in the case of the first attack, no user interaction at all.
This marks a critical difference from traditional password theft. When malware steals passwords from a device, the attacker typically still faces a second factor — a push notification to a smartphone, a hardware security key, or a one-time code.
That second factor lives on a separate device, creating a meaningful barrier. But with passkeys, many services collapse the entire authentication process into a single assertion. If that assertion can be forged or stolen, there is no second factor to fall back on. The passkey, designed to replace passwords and MFA simultaneously, becomes a single point of failure.
Recommendations
Unit 42’s report includes a set of urgent recommendations. Relying parties — the online services that accept passkey assertions — must stop blindly trusting the UV flag and enforce strict validation that user verification actually occurred.
Google should verify that newly registered devices and their UV keys are backed by genuine hardware TPMs before onboarding them. The registration and recovery flows need hardening to prevent memory-based extraction of the security domain secret. The researchers also call for additional detective controls and monitoring around device registration events.
For users, the immediate takeaway is nuanced. Passkeys remain a significant improvement over passwords for the average person — they eliminate credential stuffing, server-side database leaks, and traditional phishing.
But they are not a silver bullet. Endpoint compromise remains a critical part of the threat model, and as the researchers conclude, attackers are likely to pivot toward these emerging techniques as passkey adoption grows.
“A central takeaway is that endpoint compromise remains a critical part of the threat model,” the report states. Passkeys raise the bar for remote attackers, but they may actually lower it for attackers who have already established a presence on the device — collapsing what was once a multi-step, multi-device authentication challenge into a single assertion that can be hijacked.
The passwordless future is still coming. But if the Pass-ta-key research teaches us anything, it’s that the architecture underpinning that future needs to be built with the same paranoia that made passwords necessary in the first place.