Passkeys fixed the login. Recovery is where the account gets stolen now.

Every strong authenticator ships with a weak way back in. Attackers stopped attacking the front door years ago and moved to the spare key under the mat, which is why help desk resets keep turning into nine figure incidents. This is a field guide to Recovery Debt, and to the ceremony that pays it down.

The four minute phone call

The call lands at 3:40 on a Tuesday, which is the correct time to call a help desk if you want to be believed. Late enough that the queue has a tail on it. Early enough that nobody has started watching the clock.

The voice is calm and a little embarrassed. He gives an employee ID, and it is correct. He names his manager, and that is correct too. He mentions the office move last month, the one where half the floor lost their desk phones, and that also happened. Then he explains the problem. He dropped his phone in a parking garage. The screen is a spiderweb. He has a customer call in twenty minutes and he cannot get into anything, because every authenticator he owns lives on that phone.

The agent has a script, and the script has three checks: employee ID, manager name, one recent HR event. He passes all three, because all three are things you can learn from a corporate directory, a professional networking profile, and ten minutes of reading. The agent resets his multi factor enrollment, reads out a temporary code, and closes the ticket. Average handle time four minutes. By the metrics that the help desk is measured on, this was a good call.

Six hours later that account is walking through file shares.

Here is the part that should bother you. The organisation in this story did everything the industry told it to do. It had rolled out phishing resistant credentials. It had killed SMS codes for sign in. Its login was, genuinely, hard to attack. And none of that mattered, because the attacker never went near the login. He attacked the way back in.

What actually happens when you lose a device with passkeys on it?

To understand why recovery is where the money is, you have to look at what recovery actually is, and the honest answer is that it is two completely different problems wearing the same word.

The consumer path: recovering the platform, not the account

If you sign in to a shopping site with a passkey created on an iPhone, the private key material is typically synced through iCloud Keychain. On Android, through Google Password Manager. This was a deliberate and, on balance, correct design decision by the platform vendors. It solved the single biggest objection to hardware bound credentials, which was that losing your phone meant losing your identity.

But look carefully at what it did to the threat model. Your passkey for the shopping site is now protected by your Apple or Google account. Recovering your passkeys means recovering that account. And recovering that account means a recovery contact, a recovery key you were told to write down and did not, a phone number, a trusted device you no longer have, or in the worst case a support conversation with a large company that has to serve a billion people and cannot know you personally.

The passkey did not get weaker. The thing protecting it got broader. That is a real improvement over a reused password, and it is also a concentration of risk that did not exist before.

The enterprise path: recovering the human, badly

Inside a company, the picture is worse, because enterprises usually cannot rely on consumer cloud sync and instead build their own way back in. That path almost always ends at a human being with a script and a queue.

The employee tells the help desk they lost the device. The agent verifies them using knowledge, which is to say facts, which is to say things that can be learned. Then the agent does the single most powerful thing anyone in the company can do: they enroll a new authenticator. At that moment the attacker is not bypassing your authentication. They are being issued a brand new, fully valid, phishing resistant credential, by you, with a ticket number.

This is why the advisories keep repeating themselves. In the joint advisory on the threat group commonly tracked as Scattered Spider, CISA and the FBI described actors who social engineer help desks into resetting multi factor enrollment, then walk in through the front door with legitimate credentials (CISA advisory AA23-320A). The same pattern preceded the 2023 casino intrusions. MGM Resorts International later disclosed in an SEC filing that it expected roughly a $100 million impact on its third quarter results, and Caesars was widely reported to have paid a ransom in the region of $15 million. Two of the more expensive breaches of that year began with a conversation.

We covered the mechanics of that specific attack in the help desk can be fooled, the signature cannot. This piece is about the wider disease it is a symptom of.

Why is recovery always weaker than the thing it recovers?

There is a reason this keeps happening, and it is not incompetence. It is arithmetic.

Think about the front door of a house. You can spend as much as you like on the lock. You can fit a deadbolt, a reinforced strike plate, a door that does not splinter. The security of the house is now the security of that door, except that it is not, because there is a spare key under a flowerpot, and there is a window, and there is a back door that the previous owner fitted in 1997.

An attacker does not care about your deadbolt. An attacker cares about the cheapest way in. Security is not the average of your controls. It is the minimum.

Now apply that to authentication. A passkey is a very good deadbolt. It is bound to an origin, so it cannot be phished onto a lookalike domain, the private key does not leave the authenticator, and there is no shared secret in a database waiting to be dumped. Genuinely excellent engineering, and it closed off a class of attack that had been open since the web began.

And then, because humans lose phones, every deployment adds a way back in. Email a magic link. Text a code. Ask what street you grew up on. Let a support agent sort it out. Each of those is a door, and every one of them is cheaper to attack than the passkey.

An account with a passkey and an SMS recovery path is an SMS protected account with extra steps. The passkey raises the floor for the honest user and does nothing at all to the attacker, who was never going to attack the passkey in the first place.

What is Recovery Debt?

This pattern deserves a name, because unnamed problems do not get budgets.

Recovery Debt is the gap between the strength of an authenticator and the strength of the path that restores it. Like technical debt, it is incurred deliberately for good short term reasons, the interest is paid later by someone else, everyone knows it is there, and nobody owns it.

Recovery Debt has three properties worth internalising.

It is invisible in your security metrics. Your dashboard reports passkey enrollment percentage. It reports phishing resistant coverage. It does not report the strength of your weakest recovery path, because nobody has agreed on how to measure that. So the number that describes your actual exposure is not on the slide.

It grows as your authentication improves. This is the cruel part. The better your login gets, the higher the proportion of successful attacks that arrive through recovery. Not because recovery got worse, but because everything else got better. Teams read their incident reports, see that recovery is now the dominant path, and conclude that recovery has become more dangerous. It has not. It has become more attractive.

It is priced into the help desk, and priced wrong. Recovery is treated as a cost centre to be minimised, measured on average handle time and ticket volume. Nobody measures the help desk on how many attackers it turned away, because that number is unknowable, and the incentives that follow from that gap are exactly the ones an attacker wants you to have.

This is the same shape as the failure we described in why your identity provider tenant is your weakest agent era link. The control is strong. The seam around it is not.

How much does account recovery actually cost?

The economics explain the behaviour, so it is worth being concrete.

A widely cited Forrester figure puts the fully loaded cost of a single password reset at around $70 once you count agent time, systems, and the user's lost productivity. Gartner analysis has been quoted, including in vendor summaries, as attributing roughly 40 percent of help desk call volume to access related issues. Put those together for a 10,000 person organisation and industry write ups land in a range from roughly $50,000 to well over $400,000 a year, depending on how often your users get locked out.

Passkeys genuinely help with this. Aflac reported a meaningful reduction in recovery requests, on the order of a third, after a large passkey rollout across hundreds of thousands of enrollments. That is a real operational win and nobody should talk them out of it.

But watch the residual. The easy cases, the forgotten password, the expired credential, mostly disappear. What is left is the hard case: the genuinely lost device, the new phone, the person who changed platforms. Those cannot be self served, so they route to a human. Volume goes down and the average risk of each remaining recovery goes up, because every one is now a full re-enrollment of a phishing resistant credential, performed by a person under time pressure. You did not remove the risk. You concentrated it.

Read the right hand column downward. That column is your actual security posture. Everything above the last three rows is a door an attacker can afford.

Why does re-verifying an ID document not solve this?

The instinctive fix, once a team understands the problem, is to make recovery harder by demanding stronger proof of identity. Upload your driving licence. Take a selfie. Let a vendor compare them.

It feels rigorous. It is expensive, unpleasant, and it answers the wrong question.

Think about what a document check establishes: that at this moment, a person holding a credential has a face matching the photograph on it. That is a statement about right now. It is not a statement about last year.

The question recovery has to answer is different, and stranger: is the person in front of me the same person who set this account up? Those are not the same question, and a document check cannot distinguish between them. If an attacker obtains a genuine identity document belonging to your user, or a convincing forgery, they pass the check with a perfect score. The system was never asked whether this was the same human. It was asked whether this face matched this document, and it answered honestly.

Then there is the direction of travel on the attack side. Identity verification providers have been reporting large volumes of injection attacks, where the attacker does not hold a fake document up to a camera at all but feeds synthetic video directly into the capture pipeline through a virtual camera. Yoti's published figures for 2025 describe injection attacks in the millions, with a sharp spike around the introduction of new age assurance duties in the United Kingdom, and Group-IB's research documented thousands of attempts against a single financial institution's liveness checks over an eight month period. The specific numbers vary by vendor and methodology, and you should read each with its own caveats, but the direction is not in dispute.

So the expensive, high friction recovery path is also the one whose underlying assumption, that a camera sees a real person in a real room, is being actively dismantled. We covered that shift in the deepfake defence vendor matrix.

There is one more objection to document re-proofing that rarely gets said out loud. You are asking someone to hand over a government identity document in order to get back into an account they already own. If the answer to a lost phone is to build a database of everyone's passport, you have solved a login problem by creating a breach problem.

What would a correct recovery ceremony look like?

Start from the actual requirement, stated plainly.

Recovery is not authentication. Recovery is re-establishing continuity of a human across a change of device.

Sit with that sentence, because everything follows from it. Authentication asks: does the holder of this key control it right now? Recovery asks: is this the same person as before, given that the key is gone? Those questions need different evidence. We have spent twenty years answering the second question with tools built for the first, which is why the answers keep being wrong.

Once you frame it as continuity, there are exactly three honest sources of evidence, and every credible design uses one or more of them.

1. A second key enrolled before the loss

The cleanest answer, and the one the FIDO Alliance has recommended from the beginning. If the user enrolled two authenticators when things were calm, losing one is an inconvenience rather than a crisis. The second key was enrolled by the real user at a time when they were verified, so possession of it is strong evidence of continuity.

The problem is not the mechanism, it is human nature. Enrolling a second factor is a task with no immediate benefit, offered at the exact moment the user wants to get on with something else. Completion rates for optional second enrollment are poor across the industry, and the users least likely to complete it, less technical and single device, are precisely the ones who will need it.

Do it anyway. Make it mandatory at onboarding rather than optional later. It is the cheapest security control in this entire article. It just does not cover everyone, and you need a plan for the people it misses.

2. A co-signature from something that survived

The user lost their phone, but they still have a work laptop with a platform credential on it. Or a tablet. Or a colleague, a manager, a trusted contact who is themselves enrolled and can vouch.

Here the recovery is not a reset at all. It is a signed statement: a key that this account trusted before the loss asserts that this new key should be trusted now. The relying party checks a signature rather than a story. Nothing in that flow can be talked past by a persuasive caller, because the caller is not part of it.

This is the model that scales best in enterprises, because enterprises actually do have a second trusted device for most people, and they have a manager relationship they can bind to. It is weaker in consumer settings where a genuine single device user is common.

3. A continuity ceremony on a companion device

This is the case that matters when the other two are unavailable, and it is the one the industry has mostly left unsolved.

The mechanism, in the shape Manav implements it: at first enrollment, the user's device computes a face embedding locally and derives a one way person key from it. The embedding never leaves the device. What the service holds is a key, not a face, and the key cannot be reversed into an image. It is a fingerprint of a fingerprint.

At recovery time, the new device runs the same computation. It performs a liveness challenge, a randomised prompt that a still photograph or a pre rendered video cannot satisfy in real time, and derives the same person key from the live capture. If the derived key matches the enrolled one, the service has evidence that the human recovering is the human who enrolled, without ever having stored a biometric template and without asking anyone to upload a passport.

Manav runs this as the Beam ceremony. The desktop shows a rotating pattern rather than a scannable link, specifically so that an attacker cannot photograph a code and send it to a victim to scan, which is the failure mode that has plagued QR based flows. The phone claims the pattern, performs the liveness challenge, and binds the result to a one time token. You can watch the mechanics in the walk up demo, which runs with no signup at all.

Show me the machinery

Concretely, here is what a relying party's recovery endpoint does. This is pseudo code, but the field names and the shape are real.

// 1. User arrives at recovery. Do not issue anything yet.
const ceremony = await manav.recover.begin({
  account_ref: "acct_8842",           // opaque; no PII crosses the boundary
  require: ["liveness", "continuity"], // what evidence this RP demands
  cosigners_allowed: true              // accept a surviving key if present
});

// 2. User completes Beam on a new device. Face match is on device.
//    We receive evidence, not biometrics.
const result = await manav.recover.complete(ceremony.id);

/* result =
{
  continuity: "matched",        // matched | weak | none
  liveness:   "passed",
  person_key: "pk_9f3c...",     // one-way, stable across devices
  enrolled_at:"2024-11-02",     // when this person key was first seen
  cosigned_by: ["dev_laptop_31"],// surviving keys that vouched
  receipt:    "eyJhbGciOiJFZERTQSJ9..." // Ed25519, verify offline
}
*/

// 3. Policy is YOURS. Evidence level drives what you unlock.
if (result.continuity === "matched" && result.cosigned_by.length > 0) {
  enrollNewPasskey();                      // full restore
} else if (result.continuity === "matched") {
  enrollNewPasskey();
  freezeHighValueActions({ hours: 24 });   // restore, but cool down
} else {
  routeToManualReview();                   // do not guess
}

Three things in that snippet are worth pausing on.

First, the evidence is graded, not binary. Real recovery is not a yes or no question, and a system that pretends otherwise will either lock out honest users or admit attackers. A tiered outcome lets you restore access while limiting what it can immediately do, the most useful policy lever in this domain.

Second, the cool down. If continuity matched but nothing co-signed, you restore the account and freeze payments, beneficiary changes, and export for a day. An attacker who somehow got through gains an account they cannot monetise before you notice. A genuine user regains their email and their calendar immediately and waits a day to move money. That asymmetry is close to free.

Third, the receipt. The recovery emits an Ed25519 signed artifact stating what evidence was presented, at what level, at what time. It verifies against a published key with no callback to anyone. When a fraud team, an auditor, or an insurer asks six months later how this device came to be trusted, there is an answer that does not depend on a ticket comment.

A worked example

Say you run identity at a mid size bank. A customer calls: new phone, old phone in a river, wants back in.

Today that call takes eleven minutes, ends with an agent enrolling a new authenticator based on knowledge questions, and leaves a ticket note reading verified DOB and last transaction. If the caller was an attacker with a stolen statement, you find out in about a week.

With a continuity ceremony, the call becomes a link. The customer opens it on the new phone, sees a randomised liveness prompt, completes it in about twenty seconds. Your endpoint receives continuity: matched and cosigned_by: [], because the river took the only device. Policy fires: new passkey enrolled, mobile banking restored, external transfers and payee additions frozen for twenty four hours, customer told exactly that in plain language. Cost to you: pennies. Cost to the attacker who does not have the customer's face, live, on demand: the attack does not work.

Note what did not happen. Nobody uploaded a passport. No agent made a judgement call under time pressure. No biometric template was stored anywhere. And you have a receipt.

Are synced passkeys a mistake?

No, and it is worth being fair about this, because the discourse is unusually bad.

Cloud synced passkeys solved a real problem that was blocking adoption entirely. Before sync, losing a phone meant losing every credential on it, which made hardware bound authentication unshippable for consumers. Sync made passkeys deployable to a billion people, and a phishing resistant credential that people actually use beats a perfect one they refuse.

What sync did was move risk rather than remove it. Your passkeys are now as strong as the platform account that syncs them, which for most people is an account they have had for a decade, possibly with an old recovery phone number on it and a security question about a first pet. The risk did not vanish. It relocated, and it concentrated.

There has also been published research through 2026 looking at attacks on synced credential material, including work reported in August 2026 on recovering synced passkeys. Treat that carefully. The reporting is real, the details matter enormously, and the honest summary for a practitioner is: this is an area of active research, the platform vendors respond quickly, and you should not build your architecture on the assumption that sync is either perfectly safe or fundamentally broken. Build it so that a compromise of the sync account is survivable, which means step up proof at the actions that matter rather than trust inherited from a login. That is the argument we make in full in how do I prove I am human in 2026.

Honest limits

Every control has an edge. Here are this one's, stated plainly, because a vendor who will not tell you where their thing stops is telling you something else.

• Continuity requires a prior enrollment. The ceremony proves this human matches the human who enrolled. If there was no enrollment, there is nothing to match against. First contact is a different problem with a different answer, and it usually still involves a document check or an in person moment.
• A single device user with no prior receipts will still need a fallback. If someone enrolled once, on one phone, and that phone is gone, continuity via a new device is the only thread available. It is a good thread. It is one thread. Keep a manual path for the cases where it snaps, and instrument that path heavily.
• Face match has a false reject rate. It is not zero and not evenly distributed. Lighting, injury, ageing, and the documented demographic variance in face matching all affect it. Any deployment needs a dignified route for legitimate users the ceremony fails, and must measure that route by demographic rather than assume it is fine.
• A coerced user is still a user. Continuity proves who, not why. Someone standing next to the account holder with a threat is not a problem cryptography can see. Cool downs and out of band notifications help. Nothing eliminates it.
• This does not fix the platform account. If your users' passkeys sync through a consumer cloud account, a compromise there is outside your control. What you can control is what a restored session is allowed to do before it earns trust again.
• Enrollment is still the trust bottleneck. Every scheme in this article, including ours, assumes that at some point the right human was bound to the right key. Get that moment wrong and everything downstream is confidently wrong.

The Recovery Path Audit: what to do this week

You do not need a project to start on this. You need an afternoon and a willingness to write down an uncomfortable number.

1. List every path back in. Self service reset, email link, SMS, security questions, help desk, the admin who can do it manually, the legacy API from 2019 nobody has looked at. If it can result in a new credential being trusted, it is a recovery path.
2. Score each path by attacker cost, not by how it feels. For each one, write the cheapest realistic way an attacker exercises it. Use the table above as a starting scale. Be honest about the help desk.
3. Find your minimum and put it on the slide. Your recovery posture is the weakest path, not the average. Publish that single number next to your passkey adoption percentage. They belong on the same chart.
4. Make second authenticator enrollment mandatory at onboarding. Not a prompt. Not a reminder. A gate, at the moment when the user is already in a setup mindset. This is the highest return item on the list.
5. Take the help desk out of the trust path. Agents should help with anything except being the thing that establishes identity. Move that to a ceremony the agent cannot complete on the caller's behalf, which also protects the agent from being the person who let the breach in.
6. Add a post recovery cool down. Restore access immediately, hold high value actions for twenty four hours, and tell the user why in one clear sentence. Cheap, and it converts a total loss into a survivable event.
7. Emit a receipt for every recovery. Record what evidence was presented and at what level, in a form that verifies later without trusting your own logs. See audit trail design for AI agents for the tamper evidence patterns.
8. Rehearse it. Have someone from your team, or a red team, call your own help desk with a plausible story and see how far they get. Do it quarterly. The result is always instructive and occasionally career defining.

If you want to see the ceremony rather than read about it, the no signup demo runs the enrollment and match flow in a browser, and the integration docs show the recovery endpoints.

The uncomfortable conclusion

The industry declared the login problem solved and very nearly did. What we did not do is finish the job. We built a door that cannot be picked, left the window open, and then measured ourselves on the door. Attackers, who are ruthless about arithmetic, went to the window immediately.

The fix is not another factor. It is a different question. Stop asking recovery to re-prove identity from scratch and start asking it to prove continuity: that the human in front of you is the human who was here before. That question has a good answer, it needs no document upload and no biometric database, and it is cheaper than the phone call it replaces.

Frequently asked questions

What happens to my passkeys if I lose my phone? If they were synced through iCloud Keychain or Google Password Manager, they restore when you sign in to that platform account on a new device. If they were device bound, or the service does not use sync, you need that service's recovery path, which is usually email, SMS, or a support conversation. That path, not the passkey, is your real security level.

Are passkeys only as strong as account recovery? Yes. Security is the minimum of your controls, not the average. An account protected by a passkey but recoverable by SMS is, from an attacker's point of view, an SMS protected account. The passkey improves the honest user's experience and does not change the attacker's cheapest route.

How should a bank recover a passkey account safely? Require continuity evidence rather than restarting identity proofing. Accept a co-signature from any surviving enrolled device, fall back to a liveness ceremony that matches the enrolled person key, grade the evidence, restore access immediately, and freeze high value actions for a cool down period. Emit a signed receipt of what evidence was accepted.

Why is document re-verification not enough for recovery? A document check proves a face matched a credential today. It does not prove this is the same human who opened the account. A stolen or forged document passes it. Identity vendors are also reporting large volumes of injection attacks that feed synthetic video straight into the capture pipeline, which targets exactly this check.

Does a continuity ceremony store my face? Not in the Manav design. The face embedding is computed on the device and converted to a one way person key. The key is what leaves. It cannot be reversed into an image, there is no template database to breach, and no identity document is collected.

What is Recovery Debt? The gap between the strength of an authenticator and the strength of the path that restores it. It is incurred deliberately for usability, it is invisible in standard security metrics, and it grows in relative importance as the rest of your authentication improves.

Will requiring two authenticators fix this on its own? It fixes most of it and is the single highest return action available, which is why it should be mandatory at onboarding rather than optional. It does not cover users who genuinely own one device, or the case where both devices are lost together, so you still need a continuity path and a well instrumented manual fallback.

Sources

1. CISA and FBI, joint cybersecurity advisory AA23-320A on Scattered Spider, describing help desk social engineering and multi factor reset abuse: cisa.gov
2. MGM Resorts International, Form 8-K disclosure of expected financial impact from the September 2023 cybersecurity issue, filed with the SEC: SEC EDGAR full text search
3. FBI Internet Crime Complaint Center, 2025 Internet Crime Report and the November 2025 public service announcement on account takeover fraud: ic3.gov
4. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator binding, account recovery, and re-binding requirements: pages.nist.gov
5. W3C Web Authentication (WebAuthn) Level 3 specification: w3.org
6. FIDO Alliance guidance on passkeys, credential exchange, and multi authenticator enrollment: fidoalliance.org
7. Yoti research on injection attacks against identity verification during 2025, and Group-IB research on biometric bypass attempts against financial institution liveness checks: yoti.com, group-ib.com
8. Forrester research on the fully loaded cost of a password reset, and Gartner analysis on access related help desk volume, as cited across industry reporting.

Your security is not the average of your controls. It is the minimum, and for most organisations running passkeys today, the minimum is a four minute phone call.