Every time you sign into Google now, there’s a polite little nudge: “Skip password when possible.” Microsoft calls it “going passwordless.” The tech industry has collectively decided that passkeys are the future of authentication, and they’re not shy about telling you, repeatedly, on every login screen, until you either give in or dig through settings to find the off-switch.
But here’s the thing nobody at the FIDO Alliance press events wants to admit: passkeys are a fundamentally different security architecture with a completely different threat model, and for individual users, that trade-off might not be worth it. The recent wave of passkey-themed phishing campaigns targeting Microsoft 365 proves the technology’s resilience has limits, and those limits are architectural, not implementation bugs.
Let’s dig into why.
The Phishing Problem They Did Solve
First, credit where it’s due. Passkeys solve a genuinely hard problem: credential phishing through fake login screens. Because passkeys are cryptographically bound to the site they were created for, a hacker’s fake login page can’t intercept them. If a site suffers a data breach, the server-side public keys are useless to attackers. That’s real, meaningful security improvement.
This makes passkeys exceptional for corporate environments. Enterprise IT teams can deploy hardware-bound FIDO2 keys and dramatically reduce the attack surface. For organizations dealing with regulatory compliance or nation-state adversaries, this is a game-changer.
But Ethan Hawksley, a computer science student at the University of Warwick, makes a compelling case in his post I don’t like passkeys that the technology solves the wrong problem for most individuals. His argument cuts to the heart of the architectural tension: the threats passkeys eliminate are less probable but more catastrophic than the ones they introduce.
The Lockout Problem: Your Identity, Held Hostage
Here’s the uncomfortable trade-off. With a password, your credential is a string you can memorize, write down, or store in a password manager. Export it by hand if you need to. Lose it? Reset it through an email link or SMS code, the recovery methods we’ve all used for decades.
A passkey is different. It’s tied to a specific authenticator. Drop your phone in a lake, and if you didn’t set up a backup, your account might as well be on Mars. Factory reset your laptop? That device-bound Windows Hello passkey is gone. The recovery architecture required to handle these scenarios is non-trivial and often completely missing from consumer implementations.
The SitePoint deep-dive on WebAuthn passkey recovery spells out exactly what a robust recovery system looks like: 128-bit entropy backup codes hashed with Argon2id, time-boxed recovery sessions, rate-limited verification endpoints. That’s not something your average consumer-facing website has built. And that’s the problem, the security ceiling drops to the weakest recovery method. If your “passwordless” account still allows SMS fallback, you’ve introduced a SIM-swapping vector that didn’t exist before.
The Platform Lock-in: Apple and Google Want Your Identity as Collateral
Both Apple and Google want your identity anchored to their ecosystems. The “happy path” for passkeys is their synced credential management tied to your Apple ID or Google account. That’s convenient, until their automated systems decide to ban your account.
Google’s algorithm mistakenly flagged a father’s account after he shared photos of his toddler’s medical procedure. Their system permanently locked his Google account, taking down his Android phone, Gmail, YouTube channel, and access to Google Play purchases. Now imagine that scenario with every passkey you’ve registered across hundreds of third-party sites synced to that account.
This is the architectural flaw that should worry you most: passkeys convert a single point of failure (your device) into a single point of failure (your platform account), and the recovery process, if one exists at all, is controlled by the same automated systems that might have locked you out.
The FIDO Alliance is working on passkey export interoperability, but the experience remains fragmented. Compare that to a password manager’s export function, which produces a plain text file you can carry anywhere.
Hardware Keys: The Scaling Nightmare
If you choose hardware keys instead of platform sync, you face a different problem. Passkeys can only be added or deleted from a hardware key, never moved. To maintain redundancy, you need to purchase multiple keys and enroll every key for every site. YubiKeys support discoverable credentials with limits of 25-100 accounts per key, with top-tier models holding up to 300.
If you’re the average user with 200+ online accounts, you’re either close to the limit on your primary key or buying additional hardware and repeating the enrollment process for every site. And unlike a password, which is just a string you can type in, this enrollment friction doesn’t scale.
The New Phishing Vector: Passkey Enrollment as Social Engineering
The most recent, and most concerning, developments show attackers adapting. Microsoft disclosed a passkey-themed social engineering campaign where threat actors impersonate IT help desks, call employees on their personal phones, and pressure them to “update” their passkey or MFA configuration immediately.
The victims receive SMS links to fake Microsoft sign-in pages. The attackers then push them through adversary-in-the-middle phishing or device-code authentication flows. The campaign has been running since May 2026, and Microsoft has observed attackers:
- Registering their own authentication methods (new phone numbers, authenticator apps) to maintain persistence
- Using Microsoft Graph to map the entire cloud environment, users, groups, directory roles, SharePoint sites, OneDrive files
- Deliberately keeping data exfiltration below 1,000 files or emails per hour to blend into normal traffic patterns
The attackers have registered domains like passkeyhelpdesk[.]com, setupmypasskey[.]com, and secure-passkey[.]com to make the phishing pages look legitimate.
Notice what’s happening here: passkeys didn’t eliminate phishing. They eliminated password phishing. The attackers simply weaponized the enrollment process, the exact flow that platforms force users through with repeated notifications that they should adopt passkeys. The security improvement made users more susceptible to a new class of social engineering, not less.
This is the architectural reality check: you can’t improve authentication in isolation. If the enrollment, recovery, and account review processes aren’t equally phishing-resistant, you’ve just moved the attack surface.
When Passkeys Simply Don’t Work
Beyond security, there are basic usability gaps that haven’t been addressed. Using a colleague’s computer? You can plug in a hardware key if you have one and if the ports are accessible. Or you could sign in with a synced passkey, but that means trusting the computer not to copy your entire passkey vault.
Hybrid transport was supposed to solve this: scan a QR code, authenticate via Bluetooth on your phone, and the computer gets a session. In theory, this is elegant. In practice, edge cases where Bluetooth connections fail or aren’t supported plague the experience. When authentication becomes less reliable than the system it replaces, users will find workarounds, and those workarounds are almost always less secure.
The Third-Party Ecosystem Inconsistency
Password managers like Bitwarden and KeePassXC support passkeys, but integrating third-party passkey management remains an afterthought. Operating systems have introduced APIs like Android’s Credential Manager for third-party tools, but the experience lacks the years of UX polish that went into password autofill.
The reality is that third-party passkeys will eventually be the right answer for individuals who want cross-platform flexibility without platform lock-in. But currently, the ecosystem is too immature to rely on.
The Verdict: Enterprise Yes, Consumer Not Yet
The honest assessment is that passkeys are a fantastic enterprise tool and immature consumer technology. The attacks on Microsoft 365 accounts demonstrate that even with passkeys deployed, enterprise environments need controls around enrollment, recovery flows, help-desk verification, and post-compromise session revocation. Authentication strength matters, but it’s only one component of a comprehensive identity strategy.
For individuals, the combined risks of permanent account lockout, platform lock-in, automated account bans, and new social engineering vectors pose a greater day-to-day threat than an AiTM proxy intercepting a TOTP code. The recovery and lockout risks of passkeys outweigh the phishing vulnerabilities they eliminate for most people.
Key Takeaways
- Enterprise: Strong implementation with proper controls and recovery flows.
- Consumer: High risk of lockout and platform dependence.
- Phishing: Reduces password phishing but introduces enrollment attacks.
- Recovery: Often lacks robust fallback mechanisms.
If you’re a user who previously reused passwords across all your sites, passkeys are a huge step up. For everyone else, the technology is currently a step back. The solution for most individuals remains randomly generated passwords stored in a third-party password manager, paired with an independent TOTP app and ideally a hardware key for critical accounts. That combination provides user control without sacrificing flexibility.
The passkey ecosystem will mature. Export standards will improve. Recovery flows will get better. But until then, the “ultimate solution to logging in” is a solution to a problem most individual users weren’t facing, introduced at the cost of new vulnerabilities they weren’t prepared for.
This connects to a deeper architectural concern: authentication isn’t just about cryptographic strength. It’s about trust boundaries and recoverability. The same way trust boundaries in edge AI determine where your data lives and who can access it, your authentication architecture determines who holds the keys to your digital identity. And right now, the passkey ecosystem has concentrated that control in platforms that may not have your best interests in mind.
The security industry often treats application-layer controls as sufficient protection when the real vulnerabilities lie in the surrounding infrastructure. Passkeys are the authentication equivalent: cryptographically sound at the protocol level, architecturally fragile at the ecosystem level. Hardened credentials don’t help if the enrollment flow is socially engineered or the recovery path reintroduces the vulnerabilities you tried to eliminate.
