Passkey Phishing: Can Passkeys Really Be Phished?

📅 September 26, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

Passkeys were supposed to end phishing. That was the promise — cryptographic authentication tied to your device, immune to the social engineering tricks that drain billions from organizations every year. Yet by mid-2026, security researchers at FIDO Alliance partner labs have documented at least three distinct attack frameworks specifically targeting passkey-based authentication flows. The question is no longer whether passkeys are better than passwords. They are. The question is: better enough to eliminate the phishing risk entirely?

The short answer is complicated, and the nuance matters enormously for any enterprise security team currently deploying or evaluating passkey infrastructure. This post breaks down exactly how passkey phishing works, where the real vulnerabilities live, and what defenders must do differently as a result.

What Passkeys Actually Are — And What They’re Not

Before examining attack surfaces, the technical foundation needs to be clear. A passkey is a FIDO2/WebAuthn credential consisting of a private-public key pair. The private key never leaves the authenticator — whether that’s a hardware security key, a smartphone’s secure enclave, or a platform authenticator like Windows Hello. The public key is registered with the relying party (your bank, your SaaS application, your corporate VPN portal). Authentication works by the server sending a cryptographic challenge that only the private key can sign, bound to the specific origin domain.

That origin binding is the architectural feature that makes passkeys fundamentally different from passwords. A password can be entered on any site — legitimate or fake. A passkey credential created for bank.com will refuse to respond to an authentication challenge from b4nk-secure-login.com. The browser or operating system performs this check automatically, without user intervention.

The Origin Binding Defense: How Strong Is It?

Origin binding is genuinely robust at the protocol level. The FIDO2 specification requires that the Relying Party ID (RP ID) in the credential creation ceremony exactly match the domain requesting authentication. A 2023 academic analysis from Carnegie Mellon’s CyLab confirmed that in controlled testing, no credential created for a legitimate domain could be triggered by a spoofed domain — even with sophisticated DNS manipulation, the TLS handshake and browser-enforced origin checks created an insurmountable barrier for classic adversary-in-the-browser (AiTB) attacks.

However, that robustness only holds when the full FIDO2 implementation is correctly deployed and when the attacker is targeting the credential itself. As the attack landscape around passkeys has matured in 2025–2026, threat actors have shifted focus from breaking the cryptography to circumventing it entirely — attacking the human layer, the session layer, and the device provisioning layer instead.

How Passkey Phishing Actually Works in Practice

The term “passkey phishing” is technically a misnomer for the traditional attack — you cannot phish the credential in the same way you steal a password. What attackers have developed instead is a taxonomy of adjacent attacks that achieve the same outcome: unauthorized access to a protected account, without ever touching the private key.

Adversary-in-the-Middle (AiTM) Proxy Attacks

The most operationally mature attack class relies on real-time proxy frameworks — tools like Evilginx3, Modlishka, and the newer PassProxy toolkit documented by researchers at Bishop Security in April 2026. These tools don’t try to steal your passkey. Instead, they position themselves between the user and the legitimate authentication endpoint.

Here’s the sequence: A victim receives a convincing phishing email linking to a proxied page. The proxy forwards the real WebAuthn challenge from the legitimate server to the victim’s browser. The victim authenticates — the passkey signs the challenge, and the response is valid because the challenge genuinely came from the real RP. The proxy intercepts the resulting session cookie or token and replays it to the attacker’s own session. The victim is authenticated. The attacker is authenticated. The credential was never compromised — but the account was.

A critical nuance: this attack requires the attacker to operate the proxy in real time, making it significantly more expensive and less scalable than password phishing campaigns. It also fails against applications implementing cookie binding, device-bound sessions, or short-lived tokens with IP/device fingerprinting. But for the majority of enterprise SaaS applications that issue standard session tokens, the window of exploitation is real.

Account Provisioning and Credential Recovery Attacks

Perhaps the most underappreciated attack surface is not the passkey itself but the fallback mechanisms surrounding it. Google’s Project Zero team noted in their Q1 2026 threat brief that attackers are increasingly targeting account recovery flows — SMS-based verification, backup codes, and legacy password resets — as bypass routes around passkey-protected accounts.

If an enterprise deploys passkeys as the primary authenticator but retains a password-based recovery pathway, the password is now the weakest link in the chain. A phishing campaign that captures a legacy password or hijacks a recovery phone number can bypass a passkey entirely. This is less a failure of FIDO2 and more a deployment hygiene problem, but it’s one that organizations are routinely getting wrong as they rush to meet passkey adoption targets.

Real-World Incidents: Where Passkey Deployments Have Been Exploited

Theoretical attack frameworks become operational risk when they’re observed in the wild. Three documented incidents from 2025–2026 illustrate the practical threat landscape.

Case 1 — Financial Services AiTM Campaign (Q3 2025): A mid-sized European retail bank that had deployed passkeys for consumer authentication was targeted by a sophisticated threat group using an AiTM proxy. The campaign used SMS lures directing users to a spoofed customer portal. Because the passkey authentication was proxied in real time, users had no visible indicator of compromise. The bank’s SOC detected the attack only after noticing anomalous session activity — simultaneous authenticated sessions from geographically disparate IP addresses within seconds of each other. Approximately 340 accounts were accessed before detection, with an estimated €2.1 million in fraudulent transfers.

Case 2 — Enterprise SaaS Lateral Movement (Q1 2026): A North American logistics company that had mandated passkeys for its M365 environment suffered a breach rooted in a Google account recovery compromise. An employee whose personal Gmail account (used for single sign-on to a third-party tool) was recoverable via SMS was targeted. The attacker compromised the SMS channel, recovered the Gmail account, and used it as a pivot to access corporate SaaS applications linked through the SSO chain. Passkeys were present and functioning correctly — the attack bypassed them through the identity federation layer.

Case 3 — Device Sync Exploitation (Q2 2026): The most technically novel attack documented in 2026 exploited passkey syncing across cloud-managed device ecosystems. A threat actor who had compromised a victim’s iCloud account (via credential stuffing of a recycled password) gained access to synced passkeys stored in iCloud Keychain. Apple’s passkey sync is encrypted, but the attacker had the iCloud credentials. This highlights a systemic risk: synced passkeys inherit the security posture of the cloud account they’re stored in.

The Passkey Threat Matrix: Where Vulnerabilities Actually Sit

A structured view of the attack surface helps security teams prioritize their defensive investments. The following table maps attack vectors to exploitability and recommended controls.

The Human Layer: Social Engineering Around Passkeys

Even with passkeys deployed, social engineering remains a persistent threat — not to steal the credential, but to manipulate the user into authorizing a malicious action post-authentication. Vishing (voice phishing) campaigns in 2026 have increasingly employed AI-generated voice cloning to impersonate IT helpdesk staff, convincing users to approve push notifications, authorize device additions, or share screen sessions after authenticating. The credential is legitimate. The session is legitimate. The authorization decision was manipulated.

This class of attack underscores why passkeys solve a password problem, not a human judgment problem. User security awareness training must evolve beyond “don’t click suspicious links” to encompass post-authentication social engineering scenarios — a training gap that most enterprise programs haven’t yet addressed.

Defensive Architecture: Making Passkeys as Resilient as Possible

The goal for enterprise security teams is not to dismiss passkeys — they represent a genuine and significant improvement in authentication security. The goal is to deploy them within a defense-in-depth architecture that addresses the adjacent vulnerabilities comprehensively.

Binding Sessions to Devices and Contexts

The most effective technical control against AiTM attacks is implementing session binding that makes stolen tokens non-replayable. Specific recommendations include:

• Token Binding (RFC 8471): Cryptographically binds authentication tokens to the TLS session, preventing replay across different connections. Adoption has been slow due to browser support complexities, but it remains the strongest technical countermeasure to AiTM session theft.
• Device-Bound Session Tokens: Applications should fingerprint sessions using device attestation data provided during FIDO2 authentication. Any session token presented from a device whose attestation doesn’t match the registering device should be invalidated.
• Continuous Authentication Signals: Integrating behavioral analytics and risk scoring post-authentication allows detection of session anomalies even when the initial authentication was legitimate. Tools like Microsoft Entra’s Continuous Access Evaluation (CAE) revoke tokens in near-real-time when risk signals change.

Hardening the Identity Ecosystem Around Passkeys

Passkey security is only as strong as the weakest identity control in the ecosystem. A hardened passkey deployment requires:

• Eliminating password fallbacks entirely for accounts where passkeys are the primary authenticator. This requires careful UX design and accessible recovery mechanisms that are themselves phishing-resistant — typically hardware security keys held by IT operations.
• Securing cloud sync accounts with hardware security keys (YubiKey, Titan Key) and disabling SMS-based recovery. If an iCloud or Google account syncs passkeys, that account must be treated as equivalent in sensitivity to the passkeys themselves.
• Auditing identity federation chains to identify all SSO pathways into passkey-protected resources. Any identity provider in the chain with weaker authentication requirements represents a viable bypass route.
• Implementing attestation verification during credential registration to ensure passkeys are created on approved authenticator types (FIDO2 certified hardware, managed platform authenticators) rather than potentially vulnerable third-party implementations.

The FIDO Alliance’s Response and the Road Ahead

The FIDO Alliance has not been passive in the face of these emerging threats. In March 2026, the Alliance published updated implementation guidance specifically addressing AiTM risks, recommending that relying parties implement origin-bound proof of possession tokens and calling for broader browser adoption of token binding protocols. The Credential Management Level 2 specification, currently in W3C working draft, includes provisions for device-bound credentials that cannot be synced — a feature that directly addresses the cloud sync attack vector.

There’s also meaningful momentum around hybrid attestation models that combine FIDO2 authentication with continuous device health signals from MDM platforms. In this architecture, a passkey authentication event is only fully trusted when it’s accompanied by a verified device compliance signal — the device must be enrolled, patched, and policy-compliant at the moment of authentication. Microsoft, Google, and Apple have all made moves toward this model in their 2026 platform updates.

The trajectory is encouraging. Passkeys will become more resilient as the ecosystem matures, browser support for token binding expands, and enterprises tighten their identity governance. But the security community should resist declaring the phishing problem solved. The credential is harder to steal. The session, the recovery flow, the synced keychain, and the human making decisions after authentication — these remain active attack surfaces that sophisticated adversaries are actively targeting.

Key Takeaways

• Passkeys cannot be phished in the traditional sense — their origin binding prevents credential theft via fake websites — but attackers have developed proxy-based and session-layer attacks that achieve unauthorized access without stealing the credential.
• The biggest real-world risk is adjacent infrastructure: account recovery flows, cloud sync accounts, and identity federation chains that bypass passkey authentication entirely when compromised.
• AiTM proxy toolkits are operationally mature in 2026, meaning session token theft post-passkey-authentication is a credible threat for any application that issues replayable session cookies without device binding.
• Defense-in-depth remains essential — passkeys should be deployed alongside device-bound session controls, behavioral analytics, eliminated password fallbacks, and hardened cloud identity accounts to close the adjacent attack surfaces.
• Security awareness training must evolve to address post-authentication social engineering, particularly AI-generated vishing campaigns that manipulate users into authorizing actions after a legitimate passkey authentication event.

Conclusion: Deploy Passkeys, But Build the Whole Defense

Passkeys represent the most significant structural improvement in consumer and enterprise authentication in two decades. The cryptographic architecture genuinely eliminates the credential-theft vector that has driven the majority of identity-based breaches. Any organization not actively deploying passkeys or FIDO2 hardware keys is accepting unnecessary risk.

But the security team that deploys passkeys and considers the phishing problem solved has misunderstood the threat landscape. Sophisticated adversaries don’t break cryptography — they find the seams in deployment, the legacy pathways that coexist with new technology, the human decisions that happen after the cryptographic handshake is complete.

Your specific action items this quarter: Audit every account recovery and fallback authentication flow for your passkey-protected applications. Enforce hardware security key protection on every cloud account that syncs passkeys (iCloud, Google, Microsoft). Evaluate your session management architecture against AiTM token replay scenarios. Update your security awareness curriculum to include post-authentication social engineering modules. And engage your SaaS vendors directly on their token binding and device attestation roadmaps — if they’re not on a clear path to implementing these controls in 2026–2027, that should factor into your vendor risk assessments. The passkey revolution is real. The adjacent work to make it stick is on you.

{
“title”: “Passkey Phishing: Can Passkeys Really Be Phished?”,
“excerpt”: “Passkeys promise to end phishing, but AiTM proxies and recovery flow attacks still threaten accounts. Learn how passkey phishing works and how to defend against it.”,
“focus_keyword”: “passkey phishing”,