A new passkey attack has created confusion about how the authentication technology actually works. According to Ars Technica, security researcher Arie Olshtein of Palo Alto Networks described an attack called Pass-ta-key that could obtain all passkeys stored in Google Password Manager for Windows when the target machine is already infected with malware. The important distinction, Ars argues, is that this is not a new reason to abandon passkeys. The publication says the demonstrated attacks are neither novel nor unique to passkeys, even though the research has been discussed as a “novel attack surface.” The story is less about a collapse of the passkey model and more about where passkeys are stored, how Windows treats application permissions, and what malware can do once it is already running on a user’s machine. The confusion starts with a common assumption: that passkeys live exclusively inside a TPM, the locked-down hardware enclave used on Windows machines for sensitive cryptographic material. Ars reports that this assumption is wrong. The FIDO 2 specifications, managed by the FIDO Alliance, do not require passkeys to be stored in a TPM or any equivalent dedicated hardware enclave. That design choice matters because passkeys are meant to be usable across a person’s devices. Ars reports that operating-system and third-party app developers moved toward local device storage because mandatory hardware-backed storage would make syncing difficult. If every passkey had to be loaded into the TPM of each new device, users would need to recreate credentials one by one, making broad adoption unlikely. According to Ars, most platforms and third-party passkey managers do not store passkeys in dedicated hardware. Microsoft is described as the major exception: Windows gives users the option to store passkeys in the Windows TPM, though Ars says Microsoft mainly recommends that route for enterprises rather than consumers. The security model instead depends heavily on operating-system isolation. Ars says architects of the FIDO specifications concluded that local storage could be safe if applications could not access one another’s private-key material. On macOS, iOS, and Android, Ars reports, malware generally cannot break that isolation unless the operating system itself is compromised through an exotic zero-day exploit, and those assumptions have held up in real-world practice. Windows is the outlier in Ars’ account. The provided report says Windows apps generally run with the privileges of the user, while other platforms encourage more restrictive app permissions. That difference helps explain why a malware-infected Windows system running Google Password Manager for Windows can present a different risk profile than the same passkey concept on more tightly sandboxed platforms. The practical takeaway is narrower than the headline panic around passkeys suggests. Ars’ reporting supports the view that Pass-ta-key is a Windows-and-malware scenario affecting how one passkey manager stores and protects credentials, not evidence that passkeys as a category are broken. But it also shows that passkey security depends on implementation details that many users and even security professionals may not have understood. Who benefits: Security teams that already segment consumer and enterprise credential policies benefit from the clarification. Microsoft’s TPM-backed option may remain more relevant for enterprise environments, according to Ars’ description of Microsoft’s recommendation. Who's exposed: Users running Google Password Manager for Windows on malware-infected machines are the specific exposure described in the report. More broadly, organizations that assumed all passkeys are necessarily stored in TPM-style hardware may need to revisit that assumption.