New Pass-ta-key attack reveals all the things we didn't know about passkeys

The reported technique, dubbed Pass-ta-key, demonstrates that an infected Windows system can retrieve the full set of passkeys held by the Google Password Manager application. The researcher showed that the malware can read the encrypted blobs that the app uses to sync passkeys, contrary to the expectation that the keys are locked inside a TPM. This extraction works because the Windows version of the manager does not keep the private material in a hardware enclave.

The underlying reason for this behavior is that the FIDO 2 standards leave storage implementation up to each platform, and only Microsoft offers an optional TPM-backed mode. Other operating systems have moved to local device storage within secure enclaves to enable seamless cross-device syncing, which they consider safe due to strict app sandboxing. Windows, however, runs applications with the user's full privileges, and its sandboxing only isolates the victim app, not the attacker, allowing direct access to the manager’s data files.

For developers building or integrating passkey support, the key takeaway is that the default Windows storage path introduces a new attack surface that does not exist on macOS, iOS, or Android. If an application relies on the cloud-blob model, it must assume that a compromised host can read those blobs, and therefore should provide an option to store keys in the TPM or another hardware-bound store. Implementing such an option may require additional code to interface with TPM APIs and to handle key migration for existing users.

Mitigating the risk involves either enabling the TPM-only mode where available or adding layers of runtime protection, such as integrity checks or process isolation, to prevent malware from reading the blob files. The cost of adopting these mitigations includes development effort to detect the platform, configure the appropriate storage backend, and possibly educate users about the security trade-offs. On platforms where hardware-backed storage is not an option, developers should reinforce sandboxing and monitor for suspicious access patterns.

The attack does not extend to platforms that keep passkeys inside secure enclaves, because the operating system prevents arbitrary processes from reading those protected areas without a kernel-level compromise. Consequently, the vulnerability is largely confined to Windows environments that use the cloud-blob approach. Engineers should therefore prioritize hardening Windows deployments while continuing to rely on the existing enclave protections for other operating systems.