Passkeys aren't stored where most people think they are

Most readers assume the passkeys on their devices live in a tamper-proof chip, the dedicated security hardware that ships in most modern PCs. The cross-industry FIDO2 specification that defines how passkeys work does not require that. A passkey is just a cryptographic key pair, and on most platforms, including Google Password Manager, the private half is kept in ordinary software on disk.

That storage choice is why a researcher-coined technique, "Pass-ta-key," can pull every passkey out of Google Password Manager for Windows from a machine that is already infected. Arie Olshtein of Palo Alto Networks named the attack in a recent writeup; the portmanteau mixes "passkey" with "pass the key" and nods to a plate of pasta. The underlying technique is older than the name.

The Ars Technica analysis of Olshtein's work characterized the demonstrated attacks as "neither novel nor unique to passkeys" (Ars Technica). That framing is technically accurate. The same malware that lifts a saved password from Chrome, a cookie from a browser session, or a token from an authenticator app will lift a passkey, because on most platforms the passkey sits in the same software neighborhood. The "nothingburger" verdict answers a question most readers were not asking and skips the more useful one: where do passkeys actually live?

The answer runs through FIDO2, the set of rules maintained by the FIDO Alliance that lets a phone, a laptop, or a security key speak the same passkey language across the web. FIDO2 does not say passkeys must live in a TPM, the Trusted Platform Module chip built into most modern PCs, or in analogous secure hardware on phones (Apple's Secure Enclave, Android's StrongBox). It allows it. The spec calls hardware-backed credentials "device-bound" and treats the software-only case as a normal, supported configuration.

Every mainstream platform that ships passkeys today takes the software path for the default consumer experience. Google Password Manager stores its passkeys in the user's profile, encrypted at rest but readable by anything running as the user. Apple iCloud Keychain and most third-party passkey managers work the same way. The exceptions are narrow and well-marked: Microsoft Windows Hello passkeys can be tied to the TPM, and the company recommends that path for enterprise-managed machines rather than for the consumer flow. Hardware security keys, the small USB or NFC devices sold as a second factor, generate and keep their keys on the device itself, a separate category from a platform-synced passkey.

The practical consequence is that the threat model for passkeys is the threat model for everything else a password manager holds. If malware on the machine can read a saved password, it can read a passkey. If it can read browser cookies, it can read a passkey. The defense is the same: keep hostile code off the device, patch the operating system and browser, and treat the saved credential as a target once the perimeter is breached. None of that changes because the credential is a passkey instead of a password.

Olshtein's writeup is useful for making the storage question concrete, but it does not describe a new class of vulnerability. The passkey is recoverable for the same reason a saved password is recoverable: the data has to live somewhere the legitimate client can read, and most clients today read from software, not from a silicon vault. The next time a vendor markets a passkey as "stored on a secure chip," ask which chip, on which platform, and whether the consumer flow actually uses it.