Passkey Account Recovery: How Attackers Bypass Passkeys

1. Introduction#

Account recovery is now the cheapest way into a passkey-protected account. At Authenticate 2026 in October, Debayan Basu (Genuine Parts Company) put passkeys at NIST AAL2 or AAL3 and typical recovery via SMS, email or help desk at roughly AAL1. Microsoft's Tim Larson cited the Microsoft Digital Defense Report 2025: 80% of MFA-bypass breaches use session token theft, often followed by the attacker registering their own passkey. Amazon cited Signicat data showing deepfake fraud attempts up more than 20x in three years. This article covers what speakers from Google, Microsoft, Amazon, Mercari and Meta recommend when a user has lost every credential.

2. Why is Account Recovery the weakest Link in Passkey Deployments?#

Account recovery is the weakest link because attackers do not need to break WebAuthn cryptography. They use the recovery path instead. Debayan Basu (Principal IAM Engineer, Genuine Parts Company) described recovery as "the new control plane for account takeover" at Authenticate 2026. If a passkey can be restored with an SMS code, the account is only as strong as that SMS code.

Basu mapped this to the authentication assurance levels defined in NIST SP 800-63. Synced passkeys meet at least AAL2 and device-bound passkeys AAL3. SMS codes, email links, security questions and help desk calls sit at roughly AAL1. Our article on NIST and passkeys explains the levels in detail.

Claire Forszt (Product Manager, Google) agreed: a passkey that can be recovered at a lower security bar than the passkey itself loses its security benefit.

Source: Corbado, based on the NIST SP 800-63 mapping by Debayan Basu (Genuine Parts Company), Authenticate 2026

Login fallbacks, where a passkey is just missing on the current device, are covered in our guide to passkey fallback and recovery. This article covers users with no working credential left.

3. How do Attackers exploit Recovery Flows today?#

Attackers exploit recovery through three paths shown at Authenticate 2026: help desk social engineering, session theft followed by passkey registration and hijacking the credential manager's own recovery. In every case presented, attackers went around phishing-resistant sign-in at the moment a new credential was issued.

3.1 Help Desk Social Engineering#

Tim Larson (Principal Product Manager, Microsoft) broke down the Scattered Spider attacks on MGM and Caesars into four steps: reconnaissance from public and breach data, a pretext call to the help desk, weak proof through knowledge questions and a reset that moved MFA to the attacker's device. No malware was involved and no cryptography was broken. Debayan Basu cited around $100 million in losses for MGM and a reported$15 million payment by Caesars. Larson's conclusion: recovery must be as strong as the credential it restores.

3.2 Session Theft followed by Passkey Registration#

Larson also described an adversary-in-the-middle campaign in which a phished session token let the attacker enroll their own passkey, which then survives resets. Rakan Khalid (Sr. Director, Identity Product Management, PayPal) reported the same pattern: attackers take over accounts through phishable fallbacks, then create passkeys in their own password managers. Microsoft's answer is to treat authenticator registration as a privileged action. Our FAQ on how passkeys prevent account takeovers covers the sign-in side.

3.3 Credential Manager Recovery Hijack#

Arie Olshtein (Sr. Staff Security Researcher, Palo Alto Networks) presented a live phishing kit run by the threat actor tracked as UNC6671. It phishes the Apple ID, relays a real verification code and then asks for the iPhone passcode, which is also an iCloud Keychain recovery factor. The attacker's device joins the victim's keychain and receives every synced passkey. Our article on synced passkey attacks describes the campaign in detail.

4. What does "Recovery must match the Passkey" mean in Practice?#

Matching recovery to the passkey means the evidence accepted at recovery must be as strong as the evidence accepted at sign-up and sign-in. Microsoft's Marina Sanchez and Tim Larson framed this as "possession is not personhood": a passkey proves only possession of a key. It does not prove who holds it. Recovery is therefore effectively re-onboarding and needs the same assurance as onboarding.

Source: Tim Larson and Marina Sanchez (Microsoft), Authenticate 2026

Microsoft proposed a three-stage lifecycle model at Authenticate 2026:

• Prove the real person before the first credential: Verify identity at onboarding, before any passkey is issued.
• Preserve trust and re-proof only when risk changes: Ask for proof again for sensitive actions, such as registering a new authenticator.
• Recover with the same assurance as onboarding: Treat recovery as re-onboarding and avoid help desk shortcuts.

Larson's caveat: identity verification must stay quick, so Microsoft uses it at the "front and back doors" only.

Hana Kim (Senior Product Manager, Microsoft) recommended testing six moments before enforcing passkeys, including the case where a user loses every credential. Sangeeta Ranjit (Principal Lead PM, Microsoft) showed that Microsoft Entra already supports a self-service flow: ID document check with a provider such as IDEMIA or Onfido, a Face Check, then a Temporary Access Pass and a new passkey.

5. Which Risk Tiers work for Recovery when all Passkeys are lost?#

A tiered model routes each recovery by the evidence available. Debayan Basu proposed three tiers at Authenticate 2026. A user with a second passkey recovers instantly. A user with only identity documents recovers after a delay. A user with neither goes through a documented manual process with more than one reviewer.

Basu also recommended a recovery hold, for example giving a newly registered passkey reduced permissions, such as no transactions above a set amount. Proofing needs presentation and injection attack detection, because AI-generated faces, documents and voices now fool help desk staff.

His three self-check questions for any team:

• Can a phone call or SMS code recover an account? If yes, recovery sits below the passkey's assurance level.
• Has recovery been red-teamed? Recovery should be tested through a red team or fraud simulation.
• Does the SOC see recovery events? Recovery events must be visible to the security operations center.

Corbado's own survey data shows how common the downgrade still is. In the Passkey Benchmark 2026 (Q1 2026, authentication teams behind large consumer deployments), 69% of teams fall back to passwords when users lose all passkeys, 47% to MFA and 35% to help desk recovery. Only 33% use backup passkeys (Passkey Benchmark 2026).

6. How are Mercari, Meta and eBay handling Recovery today?#

Consumer platforms at Authenticate 2026 are rebuilding recovery in different ways. Mercari replaced email-link password resets with identity proofing. Meta is testing the removal of phishable methods, including at recovery, for consistent passkey users. eBay deletes all passkeys after a recovery event, which creates stale credentials. None of these approaches is finished, and Mercari and Meta both described recovery as work in progress.

Mercari replaced email links with identity proofing: Tatsuya Karino (Engineer, Mercari) explained that recovery via email magic link would have capped passkey security at the level of the email link. Mercari now offers identity proofing through an ID document plus selfie or Japan's My Number Card, which is verified with a PIN. Verified attributes are matched to the account.

The user then recovers with a passkey or updated email and phone, and the password is disabled. Karino said the proofing success rate is "not actually high" and called recovery one of Mercari's biggest problems.

Meta removes phishable recovery for consistent passkey users: Jason Cheung (Product Marketing Manager, Meta) described "passkey fortification": for users who consistently use their passkey, Meta is testing and rolling out the removal of phishable methods at 2FA, login challenges, certain reauth flows and recovery. Meta is still working out account recovery itself with the wider industry.

eBay deletes passkeys after recovery and pays for it in stale credentials: Manisa Mondal (Senior Product Manager, eBay) said eBay proactively deletes passkeys after account recovery or security events. eBay's passkey sign-in success is 93%, and about 95% of failures come from stale passkeys, partly caused by that cleanup.

7. Can Verifiable Digital Credentials replace SMS and Help Desks for Account Recovery?#

Verifiable digital credentials (VDCs) are the strongest candidate for phishing-resistant recovery when every device is lost. Google's Claire Forszt and Bill Chen presented a model in which a user links a VDC, such as a mobile driver's license, once and later presents it on a brand-new phone to recover the account. Google hopes VDCs can become a primary recovery option by 2030, while SMS keeps the scale advantage today.

Source: Claire Forszt and Bill Chen (Google), Authenticate 2026

A VDC is a signed credential in a wallet: Bill Chen (Product Manager, Google) defined it as an ID from a trusted issuer that lives in a wallet app on the phone. Google calls it "digital ID" in its talk. The issuer can be a government, a bank, a telco or a private identity company, as long as it proofs identity strongly before issuing. Keys sit in secure hardware, the presentation is bound to the verifier and verification is blind to the issuer. Our digital identity guide and the verifiable credential glossary entry explain the model.

Google's recovery model stores only a hash: At enrollment, a sealed enclave verifies the VDC and stores only a stable hash with the account. In the "cold start" case (new phone, no old device, no backup codes) the user adds the VDC to any wallet during setup and presents it. If the hash matches, recovery succeeds without SMS and without revealing ID data to the provider.

VDCs beat SMS OTP on phishing, trust and standards: Chen noted that an SMS OTP only proves possession of a phone number at one moment. It can be phished, replayed and intercepted via SIM swap. A VDC is phishing resistant, its trust comes from the issuer's proofing and it is built on ISO, OpenID and W3C standards such as the Digital Credentials API. Our article on the Digital Credentials API covers the browser side.

7.1 How fast are Verifiable Digital Credentials scaling?#

Verifiable digital credentials are moving from pilots to population scale in the US, India, Japan and the EU. Google's Bill Chen admitted at Authenticate 2026 that SMS OTP still "wins handily" on reach, because nearly everyone has a phone. But he cited four signals that VDCs are on a path to billion-user scale, which makes recovery with VDCs a matter of when, not if.

In the United States, the TSA accepts mobile driver's licenses and IDs in Google Wallet at more than 250 airport checkpoints. In India, Aadhaar can already be provisioned on Android, which covers more than 1 billion residents. In Japan, the My Number Card works in Apple Wallet and, since October 2026, in Google Wallet as well. In the European Union, all 27 member states must offer citizens a digital identity wallet by the end of 2026, which we track in our article on the EUDI Wallet rollout.

Relying parties see the same shift. Ben Christ (Identity Verification Lead, Amazon) reported that Amazon runs more than 15 million ID verifications per year. VDCs still account for below 10% of them, but a wallet-based check takes about five seconds, compared with several attempts over days for a document upload. Amazon plans to accept EU digital identity credentials from the end of November 2026. For recovery teams, this means VDC acceptance can start now as an optional path next to existing proofing, and grow with issuance.

8. What must the Industry still solve for phishing-resistant Recovery?#

Phishing-resistant recovery still depends on ecosystem work that no single relying party controls. Google named four requirements at Authenticate 2026: VDC provisioning during device setup, near-real-time issuance, credential manager adoption and public-private partnership. Until all four exist, Google expects SMS and email to remain the default recovery for years.

• Device setup must allow adding a VDC: OSes and OEMs must let users add a VDC during the out-of-box experience.
• Issuance must happen in near real time: The VDC must be issued within the same device setup session.
• Credential managers must adopt VDC recovery: A credential manager recovered with a VDC brings back every passkey with that trust. Bill Chen's advice to relying parties: ship passkeys now.
• Governments and companies must build acceptance together: Both sides must educate users and build acceptance of VDCs for recovery.

Claire Forszt put the timeline for SMS and email at "at least a few years, potentially many".

9. How Corbado can help#

This article argues that recovery decides whether a passkey rollout raises security or only moves the attack. Before a team can close the assurance gap, it needs to know how often recovery runs, which paths users take and how many users already hold a second passkey that would make recovery unnecessary. That is a measurement question first.

Corbado Observe, the authentication observability layer, answers it from the login you already run. Funnel keeps recovery as its own sequence, with separate diagrams for login, enrollment, recovery and signup and the drop-off between stages. Subflow Explorer counts each phishable path on its own, the SMS code, the email code, the TOTP app and the push confirmation, with completion rate, error rate and duration percentiles. That turns the AAL1 share of your recovery traffic into a number.

See Subflow Explorer in Corbado Observe →

Authenticator Inventory names every credential your users hold from its AAGUID and counts synced and device-bound credentials apart. That shows how many users already have the secondary or synced passkey that Basu's low-risk tier depends on. User debugging replays a single journey with its device context, which helps support and fraud teams review a suspicious recovery followed by a new passkey registration.

Corbado Connect then reduces how often users reach recovery at all. Its components are built around the identifier-first approach and connected to Passkey Intelligence, which decides on passkey availability from the client environment and the user's existing passkeys. Connect works as an add-on to your existing identity provider, so recovery policies, identity proofing vendors and session logic stay where they are. Rollout Rules let teams remove fallbacks for passkey users step by step, per platform and at a share they control.

10. Conclusion#

Authenticate 2026 made recovery the central passkey security topic of the year: AAL2/AAL3 passkeys vs. roughly AAL1 recovery, session token theft behind 80% of MFA-bypass breaches and deepfakes up more than 20x. The answers converge on an order of priorities. A second passkey comes first, because it is the only recovery without a downgrade. Identity proofing with liveness and injection detection comes second, combined with a cooling-off period and one-click revocation for medium-risk cases.

Teams can start today by mapping every recovery path to an assurance level and comparing it with their passkey's AAL. They should also treat the registration of a new authenticator after a phishable sign-in as a privileged action, because that is how attackers persist. Verifiable digital credentials are the long-term replacement for SMS and help desk recovery, and with TSA, Aadhaar, My Number and the EUDI Wallet they are scaling faster than many teams expect.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (more than 80% passkey activation rate). Talk to a Passkey Expert →

Frequently Asked Questions#

What is the passkey recovery paradox?#

The passkey recovery paradox describes accounts protected by phishing-resistant passkeys but recoverable through phishable methods. Debayan Basu of Genuine Parts Company explained at Authenticate 2026 that passkeys reach NIST AAL2 or AAL3, while SMS codes, email links and help desk calls sit at roughly AAL1. Attackers therefore target recovery instead of sign-in, as the Scattered Spider attacks on MGM and Caesars showed.

Do device-bound passkeys or security keys prevent recovery attacks?#

No passkey type prevents recovery attacks on its own. Microsoft explained at Authenticate 2026 that once an attacker enters through a phishable fallback, the attacker can register a new synced passkey, device-bound passkey or security key, whatever the organization allows. The defense is to treat authenticator registration as a privileged action and to require identity verification when risk signals appear.

How does account recovery with a verifiable digital credential such as a mobile driver's license protect user privacy?#

In the model Google presented at Authenticate 2026, a sealed enclave verifies the verifiable digital credential (VDC), for example a mobile driver's license, and stores only a stable hash with the account. The account provider never sees raw ID data. At recovery, the user presents the same VDC from any wallet, the enclave recomputes the hash and access is restored if both hashes match. No SMS and no prior device are needed.

What is a recovery cooling-off period?#

A recovery cooling-off period delays the use of a newly enrolled passkey after a medium-risk recovery. Debayan Basu of Genuine Parts Company proposed about 30 minutes at Authenticate 2026, combined with notifications and a one-click "this wasn't me" revocation. An attacker who passed proofing with forged documents can be stopped before the new passkey is used.