Your passkey isn't broken — the master key gets copied

On 3 August, Unit 42 published three ways into passkey-protected accounts without breaking a single line of cryptography. None of them needs administrator rights. The first asks for no fingerprint, no PIN and puts nothing on screen; the other two come in through device re-enrolment, so the user sees the same old dialog asking for their Google recovery PIN, types it without suspecting a thing, and the dirty work happens behind it. And all of them start in the same place: a Windows machine already running malware. The important part, in the first sentence, so nobody walks away with the wrong idea: we still recommend passkeys. What fell over is not the technology, it is a marketing line.

The three doors, in order

The research is called Pass the Passkey and it aims at something very specific: the Google Password Manager cloud authenticator inside Chrome, on Windows with a TPM. No CVE was assigned. There are three techniques, and they are worth taking apart because they do not buy the same thing.

• Pass-ta-key. The malware impersonates the trusted device using the identity key Chrome holds backed by the TPM, and asks for an authentication response. What decides whether it works is a single bit: the assertion comes back with the "user verified" flag not set. Against a service that checks that bit, it fails. Against one that does not, it works — and the published example is eBay, which accepted them until it was told, whereas GitHub was already validating it.
• Silver Pass-ta-key. One step up: it forces a device re-enrolment and, during that recovery window, registers a user-verification key belonging to the attacker. The lever is uncomfortably simple: deleting the local enclave state file is enough, and the researchers note that "there are no built-in protections that prevent its removal". From then on the "user verified" bit really is set, so checking it no longer saves you: the assertion is legitimate, it is just not you signing it.
• Golden Pass-ta-key. The serious one. During that same re-enrolment, the security domain secret — 32 bytes, the key that encrypts every passkey synced to the account — sits briefly in plaintext in Chrome's process memory, and that is where it gets lifted from. Those 32 bytes decrypt the private keys of every synced passkey, not one site's. And one sentence from the researchers that should not be skimmed: "In Google's current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key."

Google removed that secret from Chrome's FIDO logging output after the researchers' report. The sentence that closes that point in the research is the one to read slowly: "the SDS is still sent to the client and remains accessible in Chrome's process memory". Meaning: what got fixed is that it was written to a log; what did not get fixed is that it is there at all.

A 32-byte master key

Picture a room full of safe deposit boxes. Each box has its own lock, different from every other and impossible to force with the neighbouring box's key: that is exactly what a passkey is, a unique key pair per site that is worth nothing anywhere else. But because the customer wants to open their box from any branch, somebody decided there would be one key that opens all of them and travels with them. That key is the convenience. And that key is the 32 bytes.

This is nobody's oversight: it is the price of syncing, and it was on the table from day one. Wanting your passkeys on the phone, the laptop and the home computer requires a recoverable secret to exist somewhere; without it, changing phones would mean losing every account. What this research did is not discover the master key, it is show how low it hangs: within reach of a process running as the ordinary Windows user, with no more privileges than that user's own.

What this is NOT

Now the boring part, which is the part that prevents bad decisions. This does not break WebAuthn or FIDO2. There is no mathematical flaw, no guessed private key, no fallen algorithm. Visiting a website is not enough. No criminal campaign using it has been described. And all of it starts from a machine that is already lost: the researchers themselves sum it up by saying that "all presented attacks rely on malware already existing on the victim's device".

The caveat that cuts against the easy headline is true as well: if you have malware reading your browser's memory, you had a serious problem before 3 August. Session cookies were already stolen that way, and a valid session cookie does not require authentication either. This does not open the breach. What it does is widen the haul: where they used to take the open sessions on that machine, they can now take the keys to every synced account, including the ones you never opened on that laptop.

Why it matters anyway

It matters because the starting position these three techniques assume — a Windows machine with malware running as a normal user — is not a laboratory hypothesis: it is a product. SpyCloud's figures for 2025 describe that industry: 13.2 million infostealer infections, 642.4 million credentials recaptured from them and 8.6 billion cookies and session artefacts recaptured from criminal sources. That last number is the one that matters here, because it is exactly the same kind of secret: material stolen from the machine, not from the person.

Two days ago we wrote about the token that never asks for MFA again. There the problem was who you had granted permission to; here it is where the proof that you are you actually lives. Different question, same blind spot — but not the same scale: a stolen cookie gets you one service's session, and these 32 bytes get you the whole vault.

And still: yes to passkeys

We will take a side, because a post that only frightens people is useless. A passkey is still better than anything that came before it, for a reason this research does not touch: it is bound to the domain. It cannot be typed into a fake site, cannot be read out over the phone, cannot be forwarded to anybody on WhatsApp. Phishing and social engineering lose their target. That is why Microsoft is retiring SMS as a second factor and pushing in exactly this direction, and why we keep recommending them.

What falls over is not the decision: it is the line that came attached to it. "With passkeys you no longer have to worry about the endpoint" was never part of the deal, however often it has been repeated in presentations — including some we were sitting in. Replacing the password solves password theft. It does not solve theft of the place where you keep the thing that replaced it.

Five things you can actually do this week

• If you publish a service with WebAuthn, check the bit that comes back. The researchers' recommendation is literal: set userVerification to required and verify the user-verified flag the assertion returns, instead of trusting what you asked for in the request. It is a couple of lines of server code, and it is what separates eBay from GitHub in this story.
• Decide where the company's passkeys live. A corporate-account passkey synced into an employee's personal Chrome profile is not under the company's control: it is not audited, it cannot be revoked from any console and it does not stay on the laptop the day that person leaves. This is not a new technical problem, it is a governance one, and it is the same one you already had with passwords saved in the browser.
• Alert on enrolments, not just on sign-ins. Two of the three techniques go through a device re-enrolment. A new device registered against an account should raise a flag at least as visible as a sign-in from another country. In most places today, it does not — and this is not our idea: the research's sixth recommendation is exactly that, improving detection of abnormal passkey usage.
• Assume that cleaning the machine does not close the case. This is the part that is hardest to swallow: in Google's current implementation there is no way to rotate or revoke that secret — the researchers' own words — so creating a fresh passkey does not close the hole, because it is born protected by the same master key. A machine that has had an infostealer on it forces you to treat that account's synced passkeys as compromised and to sort it out at the account, not on the laptop. Wiping the laptop is the easy part.
• Put detection where the attack happens. None of these three techniques is visible from the identity portal: no odd sign-in, no impossible country, no failed MFA challenge. The only layer looking in the right place is the one running inside the machine. It is the same conclusion we reached with a provider's management agent: when the attack uses legitimate mechanisms, the signal is not in the central log, it is on the host. What does not count as an answer is going back to passwords with SMS: that would trade a risk requiring malware on your machine for one that only requires a well-executed phone call.

The weak link moved; it did not vanish

For twenty years the weak link in identity was the password, and the whole industry — us included — built around that idea: complexity policies, managers, expiry, second factors. Passkeys sweep that problem away, and that is genuinely good. What they do not sweep away is the need for somebody to watch the machine the person works from, with its browser, its extensions, its downloads and its user in a hurry.

Which is why the question that separates a serious identity policy from a slide is not "do we have passkeys yet?". It is "if one of our laptops picks up an infostealer tomorrow, how many accounts do we consider compromised, and how fast do we sort them out?". If the answer is "none, we have passkeys", you already know what needs reviewing.

Sources (verified): Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, Unit 42 (Palo Alto Networks), 03 Aug 2026 — the names of the three techniques; the scope ("Google Password Manager in Chrome on Windows, specifically on devices equipped with a Trusted Platform Module (TPM)"); the prerequisites ("without requiring privilege escalation, device unlock or user interaction" for the first technique; the other two go through re-enrolment, during which "Chrome begins onboarding with the cloud authenticator in the background while prompting the user to enter the Google Password Manager (GPM) recovery PIN"); the unset user-verified flag and the eBay case ("Following our report, eBay addressed this verification gap and now properly validates the UV flag") versus GitHub; deleting the enclave state file, "as there are no built-in protections that prevent its removal"; the 32-byte security domain secret extracted from Chrome's process memory; "In Google's current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key"; "All presented attacks rely on malware already existing on the victim's device"; Google's removal of the secret from Chrome's FIDO logging output, with the note that "the SDS is still sent to the client and remains accessible in Chrome's process memory"; and the six recommendations, including improving detection of abnormal passkey usage. The absence of an assigned CVE and the post-compromise framing, from the coverage in The Hacker News, 03 Aug 2026 and BleepingComputer, 03 Aug 2026. The 2025 figures (13.2 million infostealer infections, 642.4 million credentials recaptured from them and 8.6 billion cookies and session artefacts recaptured from criminal sources): SpyCloud, 2026 Identity Exposure Report. The criteria, the reading of the case and the opinions are ours.