Passkeys eliminate phishing and credential stuffing. But new research shows they introduce attack surfaces that most developers aren't prepared for, from synced private key extraction to silent authentication without user interaction.
Passkeys were supposed to end the password era. Backed by Apple, Google, and Microsoft under the FIDO Alliance banner, they replace shared secrets with public-key cryptography. No password to steal, no code to intercept, no credential database to breach. As Ars Technica described when the standard launched, passkeys are "completely resistant to credential phishing, credential stuffing, and similar account takeover attacks."
That's true, as far as it goes. But it doesn't go far enough. Several years into real-world adoption, security researchers are finding that passkeys don't eliminate risk so much as relocate it. The old threats fade. New ones emerge. And the new ones live in places most developers aren't looking: sync infrastructure, account recovery flows, and the gap between what the FIDO spec requires and what platforms actually enforce.
The Old Threats Passkeys Actually Fix
Credit where it's due. Passkeys solve real problems that decades of password policies, managers, and MFA tokens never could.
A passkey is a cryptographic key pair. The private key stays on your device (or in your platform's cloud sync). The public key goes to the server. During authentication, your device proves it holds the private key without ever transmitting it. There's nothing to phish, since the credential is bound to the legitimate site's origin; nothing to stuff, since the secret never crosses the network; nothing to reuse, since each passkey is unique to a single service.
This is a genuine improvement over passwords, which fail in predictable ways: users reuse them, phishing pages harvest them, breached databases expose them in bulk. Traditional MFA helps, but it's bolted on after the fact and introduces its own friction and failure modes (SIM swaps, TOTP code theft, push fatigue attacks).
Passkeys collapse the password-plus-MFA stack into a single cryptographic operation. For the threats they target, they work.
Where the New Attack Surface Lives
The problem is everything around that cryptographic operation. Palo Alto Networks' Unit 42 research team published detailed findings on what they call "new attack classes against passwordless authentication," focusing on Google's synced passkey ecosystem. Their work, part of a multi-part series, reveals how implementation decisions — not the core cryptographic protocol — create exploitable gaps.
Three findings stand out.
-
Silent authentication without user interaction. Unit 42 demonstrated that malware on a compromised endpoint can authenticate using a synced passkey without any user involvement. The FIDO spec includes a "User Verified" flag that's supposed to confirm biometric or PIN verification happened. But when relying parties (the websites and apps accepting passkeys) fail to validate this flag, authentication degrades from multi-factor to single-factor. An attacker with device access can silently log in.
-
Private key extraction. The research showed that an attacker can extract all synced passkey private keys from Google's Cloud Authenticator on a compromised device. This is significant because synced passkeys — the kind most consumers use — store private keys in cloud infrastructure precisely so they can roam across devices. That convenience creates a centralized target. Compromise one endpoint, potentially harvest every passkey the user has.
-
Onboarding and recovery workflow abuse. Unit 42 also demonstrated attacks against the workflows that let users set up passkeys on new devices or recover access after losing one. These flows necessarily relax security constraints to let legitimate users back in, and attackers can exploit that relaxation.
The pattern here is clear: the cryptographic core of passkeys is sound. The ecosystem around it — sync, recovery, device trust, flag validation — is where vulnerabilities concentrate.
The Control Problem: Who Really Owns Your Passkey
Beyond these technical exploits lies a structural concern: who actually controls passkey credentials? A detailed critique on the independent newsletter Nonfunctional — whose author's credentials are unclear — argues that passkeys differ from every previous authentication method in a fundamental way: users don't have ultimate control over them.
With passwords, you choose where to store them. With authenticator apps, you pick which one to use. With hardware security keys, you physically possess the credential. But passkeys introduce what the author calls "a hidden dial" — relying parties can set policies that restrict how passkeys are stored, synced, and exported.
The FIDO Alliance's spec includes a concept called "attestation," which lets websites verify which authenticator created a passkey. In practice, this means a service could reject passkeys stored in a third-party password manager and require you to use, say, Apple's iCloud Keychain or Google's Password Manager. The user's choice of tooling gets overridden by the service's policy.
This isn't hypothetical. The FIDO spec allows relying parties to require device-bound passkeys (which don't sync and can't be exported) or to mandate specific authenticator types. For enterprise deployments, that's reasonable security policy. For consumer services, it raises questions about lock-in and portability that the "passkeys are just better passwords" marketing glosses over.
What Developers Get Wrong
The Unit 42 research also points to specific developer mistakes that undermine the security model.
Not validating the User Verified flag. This is the most consequential error. If your server accepts authentication responses without checking that the user actually performed a biometric or PIN verification, you've reduced passkey auth to "does this device have the key?" That's one factor, not two. Unit 42 demonstrated this directly: malware can misuse device trust workflows to authenticate silently when this flag goes unchecked.
Treating synced passkeys as equivalent to device-bound passkeys. A passkey stored in iCloud Keychain has a different threat model than one stored on a YubiKey. Synced passkeys are vulnerable to cloud account compromise. Device-bound passkeys aren't, but they create recovery headaches. Developers need to understand which type they're accepting and adjust their risk assessment accordingly.
Weak fallback and recovery flows. The hardest part of any authentication system is account recovery. When a user loses their device, what happens? If the answer is "we send a magic link to their email," you've reintroduced all the phishing and account-takeover risks that passkeys were supposed to eliminate. Recovery flows are the soft underbelly of every passkey deployment, and they deserve the same scrutiny as the primary authentication path.
Ignoring platform differences. Apple, Google, and Microsoft all implement passkey sync differently. Key storage, export capabilities, cross-platform behavior, and attestation support vary. A passkey created on iOS behaves differently from one created in Chrome on Android or Windows Hello. Developers who treat passkeys as a uniform technology will miss platform-specific edge cases.
The Broader Security Lesson
The passkey story rhymes with a pattern that repeats across security engineering. A new technology eliminates a well-understood class of attacks, and everyone celebrates. Then attackers shift to the new technology's assumptions, dependencies, and implementation gaps, and the cycle continues.
This doesn't mean passkeys are bad. They're measurably better than passwords for the threats they address. Credential phishing, the single largest source of account compromise, becomes structurally impossible with properly implemented passkeys. That matters enormously.
But "better than passwords" is a low bar, and it's not the same as "secure." The sync infrastructure that makes passkeys convenient also creates new centralized targets. The recovery flows that make passkeys practical also reintroduce legacy vulnerabilities. The attestation mechanisms that give relying parties control also reduce user autonomy.
For developers, the practical takeaway is straightforward: implement passkeys, but do it with eyes open. Validate the User Verified flag. Understand the difference between synced and device-bound credentials. Scrutinize your recovery flows with the same rigor you'd apply to primary authentication. Don't assume the FIDO spec handles everything — the spec is sound, but the gap between spec and implementation is where attackers will live for the next several years.
Passkeys are a real improvement. They're also a new attack surface. Both things are true, and pretending otherwise serves no one.
