Passkeys won. The debate is over. Every enterprise we've worked with in 2026 either has a passkey rollout in production or has one on the quarter's roadmap. That's great for users and bad for attackers — in the long run.
In the short run, passkey rollouts have a particular shape of attack surface. We've seen the same five paths in engagement after engagement. None of them break the cryptography. All of them break the rollout.
1. The account recovery flow
Passkeys are unphishable. Account recovery rarely is.
Every passkey rollout needs an answer to: "what happens when the user loses their device?" The answer, in most rollouts we've tested, is:
- Email a magic link.
- Verify by knowledge questions.
- Call the help desk.
Each of those is a phishable downgrade. An attacker who phishes email credentials can trigger account recovery and enroll their own passkey. The strongest auth in the chain is now gated by the weakest.
The pattern that works: hardware-attested recovery keys, issued at enrollment, held by the user, used only for recovery. Anything less accepts the downgrade.
2. Sync fabric dependencies
Consumer passkeys sync through iCloud Keychain, Google Password Manager, or 1Password. Most enterprise rollouts leaned into sync — it's what makes passkeys feel painless.
But an attacker who compromises a user's iCloud account now holds every passkey synced to it, including the enterprise ones. We've seen engagements where the SOC monitored the corporate IdP perfectly, while the user's personal iCloud was the actual identity root.
Enterprise-grade rollouts have to answer: is this passkey synced off-device, and if so, to where? The answer shapes the blast radius of a personal-account compromise.
3. Device binding vs. device trust
Passkeys are bound to a device or a sync fabric. They are not, by default, bound to a device your endpoint management system has verified.
In one engagement we phished an attested-passkey enrollment event by racing a genuine enrollment. The user enrolled their Mac; our malicious extension enrolled a second key to the same account during the same session. The IdP accepted both. The device-posture check ran on login, not on enrollment.
Fix: enrollment policy is a distinct control from login policy. You need device attestation on enrollment or you've just moved the phish window.
4. MFA policy fallback
Conditional access policies that say "require phishing-resistant MFA" are common. What's also common: an exception list that says "unless the user is accessing from a trusted network" or "unless the app is legacy".
Every exception is a downgrade target. Attackers know this. We find conditional-access exception lists the same way we find open S3 buckets — enumerate, try, confirm.
If your policy has exceptions, the exceptions are the policy. Review them quarterly.
5. Cross-origin confusions
Passkeys are bound to a relying-party ID (the site origin). In multi-tenant SaaS, the RP ID is often the tenant subdomain. When a customer adds a custom domain or a CNAME, the passkey's binding does not follow.
We've seen rollouts where moving a customer to a vanity domain silently broke passkey login — users fell back to password+OTP, which the attacker phished. The passkey wasn't the problem. The RP-ID management was.
What good rollouts do
- Attested enrollment. The enrollment event is gated by device posture, not just user auth.
- Recovery as a first-class design. Not an afterthought.
- Explicit sync-fabric inventory. Every enrolled credential tagged with where it syncs.
- Zero MFA downgrades. Exception lists go through a security review, not a help-desk ticket.
- Single canonical RP ID. Not many that "work".
Passkeys are a huge upgrade. They're also a rollout, and rollouts have defects. Test yours before an attacker tests it for you.