Passkeys were supposed to be the thing that finally killed the password. No more typing a string a phishing site can screenshot. No more reused logins sitting in a breached database. Researchers at Palo Alto Networks’ Unit 42 just showed why that promise still has a soft spot. In research published August 3, 2026, Unit 42 researcher Arie Olshtein detailed three attack chains, nicknamed Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, that let ordinary Windows malware hijack Google Password Manager’s synced passkeys on compromised Windows devices without needing any privilege escalation, fingerprint sensor, PIN pad, or password field, according to Unit 42’s own August 3, 2026 technical write-up. BleepingComputer, reporting the same day, confirmed that Golden Pass-ta-key compromises all passkeys synced to Google Password Manager, not just one site’s credential. The most severe variant recovers a single 32-byte key that decrypts every passkey tied to a victim’s Google account, and Google currently has no built-in way to rotate or revoke it once it leaks.
None of this breaks the underlying WebAuthn cryptography passkeys run on. Unit 42’s own language on the finding is blunt about that part: the math holds. What breaks is the software built around that math, the onboarding, recovery, and device-trust plumbing that lets a passkey follow a user from a phone to a laptop. That distinction matters for anyone deciding whether to trust, delay, or rethink a passwordless rollout for the rest of 2026.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What the Pass-ta-key Research Actually Found
Unit 42 published its findings in a paper titled “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication.” The research centers on how Google Password Manager behaves as what Unit 42 calls a cloud authenticator for synced passkeys inside Chrome on Windows. Instead of attacking the FIDO2 or WebAuthn protocol directly, the three attack paths abuse how that cloud authenticator establishes trust with a device, re-enrolls a machine after a reset, and recovers access when a user switches hardware.
Each variant assumes the attacker already has malware running as the logged-in Windows user, the kind of foothold commodity infostealers get every day. From there, Unit 42 says an attacker can escalate from a single fraudulent sign-in to control of every synced passkey an account owns. Google Password Manager, the Chrome-based tool built to store and sync FIDO2 credentials across a user’s devices, sits at the center of all three techniques.
Three Attack Paths: Pass-ta-key, Silver, and Golden
Unit 42 grouped its findings into a three-stage escalation, each variant more damaging than the last. The naming borrows from Kerberos attack terminology security teams already recognize, Golden Ticket and Silver Ticket, a signal that these bugs sit in the identity and trust layer rather than in the cryptography itself.
Pass-ta-key and Silver Pass-ta-key
The base-level Pass-ta-key technique lets malware obtain a valid authentication assertion for the victim’s account without a fingerprint, PIN, or on-screen prompt, but only against relying parties that don’t strictly enforce user verification during login. That’s a meaningful caveat. Sites that properly check the WebAuthn user-verification flag close this door, though plenty of production sites in 2026 still don’t enforce it strictly.
Silver Pass-ta-key goes a step further. Rather than borrowing an existing session, the malware convinces Google’s cloud authenticator that the user has already completed verification, then registers a single new, attacker-controlled verification key inside the account, a detail SecurityWeek confirmed in its August 5, 2026 report on the disclosure. That planted key works like a spare house key cut without the owner’s knowledge. It keeps functioning for future logins even after the original malware infection gets cleaned up, which makes Silver Pass-ta-key a persistence technique as much as an access technique.
Golden Pass-ta-key: The Master-Key Problem
The Golden variant is the one that turned heads across the security press. Every synced passkey in a Google account is encrypted with a single 32-byte Security Domain Secret, known as the SDS. Unit 42 found that the SDS passes through Chrome’s process memory in plaintext during device re-enrollment and recovery flows, where ordinary user-level malware can read it. Security Boulevard’s August 2026 write-up on the disclosure zeroed in on the same detail, noting that Golden Pass-ta-key can extract that single 32-byte master key and use it to decrypt 100% of a victim’s synced passkeys protected by Chrome in one shot, not just one site’s credential.
The comparison to a Kerberos Golden Ticket is deliberate. A Golden Ticket forges the master key a Windows domain trusts implicitly, and Golden Pass-ta-key does the same thing to Google’s passkey trust chain. Google’s architecture currently has no built-in way to rotate or revoke the SDS once it leaks. A stolen password gets reset in a few clicks. A stolen SDS, by Unit 42’s account, does not yet have an equivalent kill switch.
How Google’s Synced Passkeys Work Under the Hood
To understand why the SDS matters this much, it helps to see how Chrome handles passkey sync on Windows in the first place. When a user sets up a synced passkey, Chrome generates a TPM-backed device identity key on that machine, then exports it as an encrypted blob using Windows CNG, the operating system’s native cryptography API. That blob lets Google’s cloud authenticator recognize the device as trusted on future logins. Security outlet InformationSecurity Taiwan reported on August 4, 2026 that this dependency is exactly why Pass-ta-key isn’t universal: the attack chain requires malware running on TPM-equipped Windows devices specifically, since the whole trust mechanism hinges on that chip-backed identity key.
During an actual sign-in, a relying party, the site the user is logging into, issues a fresh cryptographic challenge. Chrome opens a WebSocket connection to Google’s cloud authenticator, signs the handshake using the device’s identity material, and the cloud authenticator responds with a valid WebAuthn assertion forwarded back to the site to complete the login. It’s a smooth flow for the end user. No typing, no copying codes from a text message.
Normal synced-passkey sign-in flow:
1. Relying party issues a fresh WebAuthn challenge to Chrome
2. Chrome opens a WebSocket session with Google's cloud authenticator
3. Chrome signs the handshake using the device's TPM-backed identity key
4. Cloud authenticator verifies device trust and returns a signed assertion
5. Chrome forwards the assertion to the site, completing sign-in
Where Golden Pass-ta-key inserts itself, per Unit 42's disclosure:
- Malware already running as the logged-in user reads the 32-byte
Security Domain Secret from Chrome's process memory during a
device re-enrollment or recovery flow
- That secret decrypts every synced passkey private key in the account
- No fingerprint, PIN, or on-screen prompt is required to complete this chainThat convenience is exactly the surface Unit 42 tested. If malware on the machine can imitate the identity material a legitimate device would present, or can read the master secret that unlocks every passkey outright, the chain of trust collapses from the inside. None of it requires forging a cryptographic signature or breaking the public-key math WebAuthn relies on. It requires reading memory the victim’s own browser already trusts.
Why This Isn’t a Break of WebAuthn Cryptography
Let’s be precise about what Unit 42 did not find. WebAuthn’s underlying public-key cryptography, the part that makes passkeys resistant to phishing in the first place, holds up fine here. Unit 42’s own summary is direct about it: the attacks do not break WebAuthn cryptography. RSA characterized the same finding in its August 6, 2026 write-up on the disclosure, concluding that Pass-ta-key exploits weaknesses in how Chrome and Google’s cloud authenticator handle device trust, describing it as a flaw in passkey implementation rather than a break in the cryptography itself. What the three variants exploit instead is the operational code wrapped around that cryptography, the onboarding, recovery, and device-trust workflows that make passkeys convenient enough for a mainstream user to adopt in the first place.
This is a familiar split in security research. Algorithms get broken far less often than the code implementing them. Heartbleed didn’t break TLS. It leaked memory through a buffer bug in OpenSSL’s implementation of a TLS extension. Pass-ta-key follows a similar pattern: sound cryptography, undermined by an implementation detail nobody stress-tested against a malware-equipped attacker. For a technology marketed as a wholesale replacement for passwords, that distinction won’t comfort security teams much. An attacker doesn’t care whether a system fails at the math layer or the plumbing layer. Either way, the account opens.
The eBay Disclosure: Proof This Works in the Real World
Research findings are one thing. Real-world validation is another, and Unit 42 has at least one confirmed case. The team demonstrated a working Pass-ta-key attack path against eBay as part of responsible disclosure, and eBay patched the issue before Unit 42 published its findings. eBay made a specifically instructive demo target: 9to5Google reported in August 2026 that the marketplace’s login flow didn’t validate the User Verified flag during passkey authentication, the exact gap the base Pass-ta-key variant is built to exploit. That detail matters more than it might first appear. It confirms the attack chain isn’t a theoretical lab exercise against a hypothetical relying party. It worked against a major, publicly traded e-commerce platform that millions of consumers trust with saved payment methods.
Unit 42 hasn’t published a broader list of affected sites beyond eBay, and no CVE identifier has been assigned to any of the three variants as of August 2026, a gap Unit 42 flagged at disclosure and that later coverage has continued to note without update. That’s partly a function of where the bug lives. It’s spread across relying-party implementations, Chrome’s handling of Google Password Manager, and Windows-specific memory behavior, rather than sitting in one product with one clean patch to ship.
Google’s Response and Why the Key Still Can’t Be Rotated
Google has already rolled out two mitigations, according to SecurityWeek’s August 5, 2026 reporting. Tech outlet WWWhatsNew reported on August 17, 2026 that one of those fixes removed the SDS from Chrome’s internal debug logs, closing one path researchers had used to grab the secret. But Unit 42 says the core problem remains: the SDS is still recoverable from Chrome’s process memory during device re-registration, and there is currently no mechanism to rotate or revoke that master secret once it has been compromised.
That last point is the one worth sitting with. Change a leaked password and the old one stops working the moment the new one is set. Revoke a stolen hardware security key and it’s cut off from the account instantly. A leaked SDS, under the design Unit 42 describes, doesn’t have that off switch yet. Every synced passkey encrypted under a compromised SDS stays exposed to whoever captured it, indefinitely, until Google ships an architectural fix rather than a logging tweak.
Microsoft, whose Windows platform hosts the vulnerable memory behavior, has made one narrower move on its own side of the stack: on July 14, 2026, Microsoft patched CVE-2026-34348 by truncating logged signatures down to 6 bytes, shrinking the amount of signing material an attacker could pull from Windows logs. That’s a smaller fix than what the core Pass-ta-key disclosure calls for, and it’s consistent with where most of the bug actually sits, inside Chrome’s implementation of Google Password Manager rather than in a Windows component Microsoft controls end to end.
Pass-ta-key Attack Variants at a Glance
The three variants scale in severity, not in how they start. Each still needs a foothold on the victim’s Windows machine before anything else works. Here’s how they compare side by side.
| Variant | What It Steals or Forges | Verification Bypassed | Survives Malware Cleanup | Severity |
|---|---|---|---|---|
| Pass-ta-key | A single valid authentication assertion | Fingerprint, PIN, or on-screen prompt (where the site skips strict checks) | No | Moderate |
| Silver Pass-ta-key | An attacker-registered verification key | User-verification check for future logins | Yes | High |
| Golden Pass-ta-key | The 32-byte Security Domain Secret | Every passkey in the account at once | Yes, until the SDS is invalidated | Critical |
Historical Context: The Long Road From Passwords to Passkeys
Passkeys didn’t appear out of nowhere. The FIDO Alliance built the FIDO2 and WebAuthn standards specifically to kill off phishable, reusable passwords, and Apple, Google, and Microsoft each rolled out consumer passkey support starting around 2022 and 2023. The pitch was straightforward: replace something a user types, and can be tricked into typing on a fake site, with a cryptographic key pair a phishing page can’t extract no matter how convincing the fake login form looks.
Adoption has been real, not just marketing talk. Major platforms across banking, retail, and social media added passkey support through 2025 and into 2026, and tech-insider has tracked that shift in passkey adoption data measured against traditional passwords and two-factor codes. The FIDO Alliance’s own numbers, published in May 2026, put a scale on that momentum: the Alliance estimated 5 billion passkeys in use worldwide, 90% of consumers surveyed said they’re familiar with passkeys, 75% had already enabled them on at least one account, 49% used passkeys whenever possible, and 68% of organizations reported deploying, piloting, or actively rolling out passkey support. The pattern has consistently favored passkeys on phishing resistance.
Pass-ta-key doesn’t reverse that trend, but it’s the most serious crack in the passwordless narrative since the standard went mainstream. Every prior passkey criticism centered on rough edges: confusing sync interfaces, awkward cross-device recovery, platform lock-in. This is the first widely covered research showing a path from off-the-shelf malware to full account compromise that skips the passkey’s core protection entirely.
How Pass-ta-key Compares With Other Authentication Bypasses
Pass-ta-key joins a growing list of techniques that don’t attack authentication factors directly. They attack the systems managing them. Session-cookie theft through infostealer malware already lets attackers bypass MFA entirely by stealing a browser’s active login token, no password or code required. Adversary-in-the-middle phishing kits proxy a real login form in real time, capturing whatever a victim enters, including one-time codes from an authenticator app. SIM-swapping defeats SMS-based one-time codes by hijacking the phone number itself, not the underlying math.
What sets Golden Pass-ta-key apart is scope. Session-cookie theft usually nets one active session. SIM-swapping nets whatever depends on that phone number. Golden Pass-ta-key, if Unit 42’s account holds, nets every synced passkey an account has ever created, in a single theft, with no session expiration to eventually shut the door. Tech-insider’s own coverage of the Verizon Data Breach Investigations Report already flagged exploited vulnerabilities overtaking stolen credentials as a leading breach vector this year. Pass-ta-key fits that same shift toward attacking systems and implementations rather than guessing or phishing individual passwords.
Authentication Security Posture Compared
Zooming out from Google’s implementation specifically, here’s how synced passkeys stack up against other common authentication methods now that Pass-ta-key is public knowledge.
| Method | Resists Phishing | Resists Endpoint Malware | Revocable If Compromised | 2026 Status |
|---|---|---|---|---|
| Password alone | No | No | Yes, immediately | Legacy, still widely used |
| SMS one-time code | Partial | No | Yes, new number needed | Declining, SIM-swap risk |
| TOTP authenticator app | Yes | Partial | Yes | Common, phishable via AiTM kits |
| Hardware security key (FIDO2) | Yes | Yes | Yes, physically removable | Gold standard, lower adoption |
| Synced passkey (pre-disclosure assumption) | Yes | Assumed yes | Yes | Mainstream rollout across 2025-2026 |
| Synced passkey (Golden Pass-ta-key risk) | Yes | No, if endpoint is compromised | No mechanism yet, per Unit 42 | Under active scrutiny |
Market Impact: A Stress Test for the Passwordless Push
The timing complicates things for the industry. 2026 was supposed to be the year passkeys crossed from early-adopter feature to default login method across major consumer platforms, a push the FIDO Alliance’s 2025 index measured at 26% of sign-ins handled by passkeys in October 2025, and identity and access vendors including Palo Alto Networks have spent the past two years building products and marketing around the phishing-resistance argument Pass-ta-key now complicates. Unit 42 is itself part of Palo Alto Networks, which makes the disclosure something of an inside job. The same company selling zero-trust and endpoint security also just handed the industry a reason to slow down and check its passwordless assumptions.
Enterprise security teams evaluating passkey rollouts now have a genuine complication to plan around. Not passkeys themselves, but the assumption that a passkey removes malware risk from the authentication conversation entirely. It doesn’t. An attacker with user-level code execution on a Windows endpoint can, per Unit 42’s account, still walk away with account access. That reframes passkeys as phishing-resistant rather than malware-immune, a narrower claim than most rollout messaging has used up to now.
Cyber insurers and compliance auditors, who have increasingly treated passkey adoption as a checkbox that lowers account-takeover risk, may need to revisit that assumption too. A control that can’t be rotated once compromised behaves differently in a risk model than one that can.
What Security Teams and Developers Should Do Now
None of this means abandoning passkeys. They remain meaningfully harder to phish than a password typed into a fake login page, and Pass-ta-key requires an attacker to already have malware running on the victim’s machine, a bar that plenty of other attacks clear just as easily against password-based accounts. The practical response looks less like panic and more like defense in depth.
Relying parties should enforce strict user-verification checks server-side rather than trusting whatever a client claims, closing the door the base Pass-ta-key variant relies on. Enterprises with high-value accounts should pair passkeys with hardware security keys for anything sensitive, since a physical FIDO2 key doesn’t sync a master secret across devices the way Google Password Manager does. Endpoint detection remains the actual first line of defense here, since every variant Unit 42 documented needs malware on the box before anything else happens.
For admins managing FIDO2 passkey deployments, this is a good moment to audit which relying parties in the environment properly enforce user verification, and to treat a completed passkey rollout as a partial answer rather than a finished project.
Expert and Industry Reactions
Coverage of the research converged on a similar theme within days of publication: the cryptography survived, the surrounding software didn’t. The Hacker News summarized it plainly, noting that “three separate research efforts last week demonstrated ways to defeat passkey protections without breaking the cryptography they rest on.”
Malwarebytes put the practical takeaway in consumer terms, writing that “passkeys can be very secure but the software surrounding them still has weaknesses.” Tech Times zeroed in on the detail that worries security teams most, reporting that “the 32-byte master key that encrypts every passkey in a victim’s Google account passes through Chrome’s process memory in plaintext, can be extracted by ordinary endpoint malware, and, once stolen, cannot be rotated or revoked.”
Threat-intelligence platform Mallory framed the consumer risk directly in its August 5, 2026 report, noting that “malware on a compromised Windows system can hijack Google-synced passkeys and take over accounts without the victim entering a password, PIN, or biometric factor.” Security newsletter Phishing Tackle followed on August 11, 2026 with its own breakdown of the three attacks against Google’s synced passkeys, and HowToGeek reported as recently as August 31, 2026 that Pass-ta-key can still steal every locally synced passkey from Google Password Manager on Windows, a sign the exposure window remains open weeks after disclosure. Not every outlet treated the research as alarming. Ars Technica’s August 11, 2026 coverage argued the practical, day-to-day risk to most individual users stays low given the malware prerequisite, even as it agreed the architectural gap is real.
5 Predictions for Passwordless Security After Pass-ta-key
Where does this leave passwordless authentication for the rest of 2026 and beyond? A few likely paths stand out.
- Google ships an SDS rotation mechanism. An unrevocable master secret is not a sustainable design once attackers know it can be extracted. Expect Google to prioritize a rotation path in an upcoming Chrome or Google Password Manager update.
- Relying parties tighten user-verification enforcement. Sites that skip strict UV checks are the ones exposed to the base Pass-ta-key variant, and that’s a server-side fix available today, not a future patch.
- Hardware security key sales get a bump. Enterprises unsettled by the unrevocable-key detail will push higher-value accounts toward physical FIDO2 keys, which don’t carry the same synced master-secret exposure.
- More researchers go looking at cloud authenticator implementations. Unit 42 just showed this class of bug is findable, and that tends to invite copycat research against other vendors’ passkey-sync architectures too.
- Passkey marketing gets more careful. Expect vendors to shift language from implying malware immunity toward the narrower, more accurate claim of phishing resistance, closer to what the standard actually guarantees.
Frequently Asked Questions
What is the Pass-ta-key attack?
Pass-ta-key is a set of three attack techniques, disclosed by Palo Alto Networks’ Unit 42 on August 3, 2026, that let malware already running on a Windows machine hijack Google’s synced passkeys. The most severe version, Golden Pass-ta-key, steals a single master key that decrypts every passkey tied to the victim’s Google account.
Does Pass-ta-key break passkey encryption?
No. Unit 42 says the attacks don’t break WebAuthn’s underlying cryptography. They exploit the surrounding software, specifically how Google Password Manager handles device trust, re-enrollment, and recovery on Windows, rather than the cryptographic algorithms passkeys rely on.
Do I need malware on my computer for this attack to work?
Yes. Every variant Unit 42 documented requires an attacker to already have code running as the logged-in user on the victim’s Windows machine. This isn’t a remote, unauthenticated exploit that works over the internet against an unsuspecting user with a clean device.
Can Google revoke a stolen passkey master key?
Not currently, according to Unit 42’s research. The Security Domain Secret that Golden Pass-ta-key targets has no built-in rotation or revocation mechanism as of this writing, meaning a compromised secret stays exposed until Google ships an architectural fix.
Should I stop using passkeys because of this?
Most security researchers covering the story, including Ars Technica’s response piece, argue against abandoning passkeys. They remain more phishing-resistant than passwords, and the attack requires a malware infection that would put a password-based account at risk too. The safer response is pairing passkeys with strong endpoint protection rather than reverting to passwords.
Is there a CVE for Pass-ta-key?
No CVE identifier had been assigned to any of the three variants as of this writing. The issue spans relying-party implementations, Chrome’s Google Password Manager integration, and Windows memory behavior, rather than sitting in a single product with one clean patch.
Which platforms are affected?
The research focuses on Windows devices using Chrome with Google Password Manager’s synced passkeys. Unit 42’s published findings don’t cover Apple’s iCloud Keychain passkeys or Microsoft’s own passkey implementation, though researchers say similar cloud-authenticator architectures are worth the same scrutiny.
What is a Security Domain Secret?
It’s the 32-byte master key that encrypts every synced passkey in a Google account. Unit 42 found it briefly appears in plaintext in Chrome’s process memory during device re-enrollment and recovery, where malware running as the logged-in user can read it.
