---
url: 'https://www.corbado.com/blog/passkey-account-recovery-authenticate-2026'
title: 'Passkey Account Recovery: How Attackers Bypass Passkeys'
description: 'Authenticate 2026: passkey account recovery after losing every passkey is the new takeover path. How Google, Microsoft, Amazon and Mercari rebuild it.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-10-29T13:48:38.747Z'
lastModified: '2026-10-31T07:00:43.761Z'
keywords: 'passkey account recovery, account recovery when all passkeys are lost, help desk social engineering, verifiable digital credentials account recovery, recovery assurance level'
category: 'Passkeys Strategy'
---

# Passkey Account Recovery: How Attackers Bypass Passkeys

## Key Facts

- Debayan Basu (Genuine Parts Company) placed passkeys at **NIST AAL2 (synced) or AAL3
  (device-bound)**, while SMS, email and help desk recovery sit at **roughly AAL1**.
- MGM lost **around $100 million** after Scattered Spider's help desk attack, and Caesars
  reportedly paid **$15 million**, as cited by Basu.
- **80% of MFA-bypass breaches use session token theft**, per the Microsoft Digital
  Defense Report 2025 shown by Microsoft's Tim Larson.
- Deepfake fraud attempts are **up more than 20x in three years**, according to Ben Christ
  (Amazon) citing Signicat.
- Amazon runs **more than 15 million ID verifications per year**, with verifiable digital
  credentials **below 10%** of them.
- Google hopes verifiable digital credentials become **a primary recovery option by
  2030**. Aadhaar alone can be provisioned on Android for **more than 1 billion users**.
- Palo Alto Networks showed an **active phishing kit (UNC6671)** that hijacks iCloud
  Keychain recovery to steal all synced passkeys.

## 1. Introduction

Account recovery is now the cheapest way into a passkey-protected account. At
[Authenticate 2026](https://www.corbado.com/blog/android-restore-credentials-zero-tap-sign-in) in October,
Debayan Basu (Genuine Parts Company) put passkeys at [NIST](https://www.corbado.com/blog/nist-passkeys)
[AAL2](https://www.corbado.com/blog/nist-passkeys) or [AAL3](https://www.corbado.com/blog/nist-passkeys) and typical recovery via SMS,
email or help desk at roughly
[AAL1](https://www.corbado.com/faq/authenticator-assurance-levels-aal-digital-identity). 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](https://www.corbado.com/blog/identity-fraud-layered-authentication-identiverse-2026) 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](https://www.corbado.com/blog/android-restore-credentials-zero-tap-sign-in). 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](https://www.corbado.com/glossary/authentication-assurance-level) defined in
[NIST SP 800-63](https://pages.nist.gov/800-63-4/). Synced passkeys meet at least
[AAL2](https://www.corbado.com/blog/nist-passkeys) and [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific)
[AAL3](https://www.corbado.com/blog/nist-passkeys). SMS codes, email links, security questions and help desk
calls sit at roughly [AAL1](https://www.corbado.com/faq/authenticator-assurance-levels-aal-digital-identity). Our
article on [NIST and passkeys](https://www.corbado.com/blog/nist-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.

![Passkey sign-in at AAL2 and AAL3 compared with SMS, email link and help desk recovery at roughly AAL1](https://www.corbado.com/website-assets/account_recovery_weakest_path_assurance_levels_72d74d9dc5.png)

_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](https://www.corbado.com/blog/passkey-fallback-recovery). This article
covers users with no working credential left.

## 3. How do Attackers exploit Recovery Flows today?

Attackers [exploit](https://www.corbado.com/glossary/exploit) recovery through three paths shown at
[Authenticate 2026](https://www.corbado.com/blog/android-restore-credentials-zero-tap-sign-in): 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/malware) was involved and no cryptography
was broken. Debayan Basu cited around $100 million in losses for MGM and a reported $15
million [payment](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/paypal-passkeys)) 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](https://www.corbado.com/glossary/authenticator) registration as a privileged action. Our FAQ on
[how passkeys prevent account takeovers](https://www.corbado.com/faq/how-can-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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/icloud-keychain) recovery factor. The attacker's
device joins the victim's keychain and receives every
[synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys). Our article on
[synced passkey attacks](https://www.corbado.com/blog/synced-passkey-attacks-threat-models) 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.

![Microsoft Lifecycle Assurance Model: prove the person at onboarding, preserve trust in daily use and recover with the same assurance](https://www.corbado.com/website-assets/authenticate_2026_microsoft_lifecycle_assurance_model_f71f1fee13.jpg)

_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](https://www.corbado.com/glossary/authenticator).
- **Recover with the same assurance as onboarding:** Treat recovery as re-onboarding and
  avoid help desk shortcuts.

Larson's caveat: [identity verification](https://www.corbado.com/blog/digital-identity-guide) 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](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges) 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.

| Tier        | Situation                                                  | Recovery path (Basu, Genuine Parts Company)                                                              |
| ----------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Low risk    | Secondary or synced passkey on another device              | Sign in directly, no downgrade                                                                           |
| Medium risk | No passkey, but identity proofing with a document succeeds | New passkey after a cooling-off period of about 30 minutes, with a one-click "this wasn't me" revocation |
| High risk   | No authenticator and no proofing possible                  | Documented manual process, physical document check, more than one person involved                        |

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](https://www.corbado.com/blog/world-passkey-day-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](https://www.corbado.com/blog/world-passkey-day-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](https://www.corbado.com/faq/passkeys-reduce-password-resets-otp-costs) with
[identity proofing](https://www.corbado.com/blog/digital-identity-guide). Meta is testing the removal of
phishable methods, including at recovery, for consistent passkey users.
[eBay](https://www.corbado.com/blog/ebay-passkeys) 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](https://www.corbado.com/faq/multiple-passkeys-per-account) at the level of the email link.
Mercari now offers [identity proofing](https://www.corbado.com/blog/digital-identity-guide) 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](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication), 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](https://www.corbado.com/blog/ebay-passkeys)) said
[eBay](https://www.corbado.com/blog/ebay-passkeys) proactively deletes passkeys after account recovery or
security events. [eBay's](https://www.corbado.com/blog/ebay-passkeys) 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](https://www.corbado.com/blog/digital-credentials-api) (VDCs) are the strongest
candidate for [phishing](https://www.corbado.com/glossary/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.

![Google forecast of account recovery methods from 2026 to 2035 with digital ID growing to about 50%](https://www.corbado.com/website-assets/authenticate_2026_google_recovery_methods_forecast_3c0abfab9e.jpg)

_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](https://www.corbado.com/glossary/issuer) that lives in a
[wallet](https://www.corbado.com/blog/digital-wallet-assurance) app on the phone. Google calls it
"[digital ID](https://www.corbado.com/blog/digital-identity-guide)" in its talk. The [issuer](https://www.corbado.com/glossary/issuer)
can be a [government](https://www.corbado.com/passkeys-for-public-sector), 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](https://www.corbado.com/glossary/issuer). Our [digital identity guide](https://www.corbado.com/blog/digital-identity-guide) and
the [verifiable credential](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/digital-wallet-assurance) 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](https://www.corbado.com/glossary/sim-swap). A VDC is phishing resistant, its trust
comes from the [issuer's](https://www.corbado.com/glossary/issuer) proofing and it is built on ISO, OpenID and
W3C standards such as the [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api). Our
article on the [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) covers the browser
side.

### 7.1 How fast are Verifiable Digital Credentials scaling?

Verifiable [digital credentials](https://www.corbado.com/blog/digital-credentials-api) 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](https://www.corbado.com/blog/how-to-use-google-pay) at more than 250 airport checkpoints. In
India, Aadhaar can already be provisioned on
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), which covers more than 1 billion
residents. In Japan, the My Number Card works in Apple
[Wallet](https://www.corbado.com/blog/digital-wallet-assurance) and, since October 2026, in
[Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) as well. In the European Union, all 27 member
states must offer citizens a [digital identity](https://www.corbado.com/blog/digital-identity-guide) wallet by
the end of 2026, which we track in our article on the
[EUDI Wallet rollout](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026).

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](https://www.corbado.com/blog/digital-identity-guide) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/observe), the
[authentication observability](https://www.corbado.com/blog/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](https://www.corbado.com/faq/authenticator-assurance-levels-aal-digital-identity) share of your recovery
traffic into a number.

[Video: Subflow explorer](https://www.corbado.com/videos/features/subflow-explorer.mp4) ([See Subflow Explorer in Corbado Observe](https://www.corbado.com/observe/subflow-explorer))

[Authenticator Inventory](https://www.corbado.com/observe/authenticator-inventory) names every credential your
users hold from its [AAGUID](https://www.corbado.com/glossary/aaguid) and counts synced and device-bound
credentials apart. That shows how many users already have the secondary or
[synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) that Basu's low-risk tier depends on.
[User debugging](https://www.corbado.com/observe/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](https://www.corbado.com/connect) then reduces how often users reach recovery at all. Its
components are built around the
[identifier-first approach](https://www.corbado.com/faq/identifier-first-approach-passkey-login) and connected to
[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence),
which decides on [passkey availability](https://www.corbado.com/faq/are-passkeys-available) 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](https://www.corbado.com/blog/digital-identity-guide)
vendors and session logic stay where they are.
[Rollout Rules](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption) 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](https://www.corbado.com/faq/multiple-passkeys-per-account) topic of the year:
[AAL2](https://www.corbado.com/blog/nist-passkeys)/[AAL3](https://www.corbado.com/blog/nist-passkeys) 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](https://www.corbado.com/faq/authenticator-assurance-levels-aal-digital-identity).
They should also treat the registration of a new [authenticator](https://www.corbado.com/glossary/authenticator)
after a phishable sign-in as a privileged action, because that is how attackers persist.
Verifiable [digital credentials](https://www.corbado.com/blog/digital-credentials-api) 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.

## 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.
