Why does losing your phone mean uploading your passport?

You have banked with them for nine years. They have your salary history, your address, your spending patterns, and roughly four thousand data points about your life. You lose a phone, and they ask you to photograph a passport and take a selfie, as though you were a stranger. There is a reason, and it is not a good one.

Picture the sequence, because most people reading this have lived some version of it.

The phone goes into the sea, or into a taxi, or into the gap behind a train seat where phones go to die. You borrow a laptop. You go to your bank, and you cannot get in, because the second factor was on the phone. You click "I no longer have access to this device", which is the correct and honest answer, and the bank asks you to upload a photograph of your passport and take a video selfie.

Your passport is at home, in a country you are not currently in. So you wait. You try the support line, where an agent asks for your mother's maiden name, a piece of information that is on your public family tree and was in three separate data breaches. You get through that, and the agent tells you the only way to restore access is the document flow.

Somewhere in this process a thought arrives, and it is the right thought: they have known me for nine years. Why are we starting from zero?

Why do companies ask for your ID when you lose your phone?

The honest answer is not malice, or laziness, or even compliance, although compliance gets blamed for most of it. The honest answer is that at the moment you contact them, the institution has no link between the person in the chat window and the person who opened the account.

Think about what they actually retained from the day you signed up. They ran an identity verification check: you photographed a document, a vendor confirmed the document appeared genuine, a face match confirmed the selfie resembled the document photograph, and a decision was recorded. That decision was stored, along with a timestamp, a reference number, and possibly the images themselves.

Notice what is missing. They kept a record that a check happened. They did not keep anything you can produce again on demand. The check was an event, not a relationship. So when you turn up two years later without your phone, the only thing the institution can do is run the same event again, because running it again is the only capability it built.

It is like a nightclub that checks your ID at the door, remembers that it checked, and then makes you produce the ID again every time you come back from the smoking area. Not because the doorman doubts you, but because the club never built a wristband.

The wristband is the missing primitive. Almost every recovery pathology downstream follows from its absence.

What is the difference between re-proofing and continuity?

These are two different questions that the industry routinely treats as one, and separating them is the single most useful idea in this post.

Re-proofing asks: who are you?

Re-proofing establishes identity from external evidence, with no reference to any prior interaction. It asks you to prove, to a stranger, that you are a particular named person who exists in the world. The evidence is necessarily external: a government document, an authoritative database, a credit file, an in-person appearance.

Re-proofing is genuinely necessary at exactly one moment, which is the first time an institution needs to know who it is dealing with. Regulated onboarding requires it. It is appropriate there and it is expensive there for good reasons.

Continuity asks: are you the same person as before?

Continuity is a completely different question with a completely different evidence base. It does not care what your name is. It asks whether the human in front of it now is the human who was in front of it previously, and it can be answered with evidence generated inside the relationship rather than imported from outside it.

The important property, and the one the industry keeps missing: continuity evidence is usually much stronger than re-proofing evidence, because it accumulates. A person who has held the same enrolled device for two years, signed forty transactions with it, and passed liveness checks at intervals has produced a body of evidence that no forged passport can imitate. A person presenting a document photograph has produced exactly one artifact, and artifacts can be manufactured.

Almost every account recovery in existence is a continuity question that the institution has no choice but to answer with re-proofing, because it never collected any continuity evidence. That is not a compliance requirement. That is an architecture decision made years ago by someone who is no longer at the company.

We laid out the strategic version of this in passkeys fixed the login, recovery is where the account gets stolen now. This post is about the mechanics: what evidence exists, what each piece costs, and how to sequence it.

Why is the document upload now the weakest step, not the strongest?

Here is the part that should genuinely alarm anyone who has designed a recovery flow in the last five years. The document flow is not merely inconvenient. It has quietly become the softest part of the entire account lifecycle, because it is the one place where the institution accepts a fresh claim of identity rather than a proof of continuity. It is the one door that opens for a stranger by design.

And the tooling for walking through that door has industrialised. The critical distinction, which we cover in depth in the camera is no longer evidence, is between presentation attacks and injection attacks.

A presentation attack holds something up to a real camera: a printed photograph, a mask, a screen displaying a video. Liveness detection was designed for this and is reasonably good at it, and the ISO/IEC 30107 standards series exists to test exactly that.

An injection attack never touches the camera. It uses a virtual camera driver, an emulator, or a modified mobile application to feed synthetic frames directly into the capture pipeline. Every liveness signal the vendor checks for is present, because the attacker generated all of them. The blink is there. The head turn is there. The skin texture is there. There was simply never a face.

The published telemetry is striking, and it deserves a caveat before the numbers rather than after. These figures come from vendors who sell defences against the thing they are counting, and they can only count attacks they detected, which by definition excludes the successful ones. Read them as evidence of scale and direction, not as a census.

With that said: Yoti's published 2025 research reported injection attacks on the order of 3.2 million across the year, with a monthly peak above five hundred thousand in August, coinciding with the rollout of age assurance duties under the UK Online Safety Act. Group-IB's Weaponized AI report, published in January 2026, documented 8,065 attempts to bypass liveness checks at a single financial institution between January and August 2025, using biometric injection with AI generated imagery. One institution. Eight months.

So the recovery flow that feels like the most rigorous step in the whole product, the one that makes honest customers photograph their passports in bad hotel lighting, is the step an attacker is best equipped to defeat. The honest customer experiences maximum friction. The attacker experiences a software configuration.

What does the institution keep, and why is that a liability?

There is a second cost to the document flow that does not appear on the fraud team's dashboard: the data it creates.

To run document verification you must collect a government identity document and a facial image. To defend a decision later, most institutions retain them. That retention converts a fraud control into a data asset, and a data asset of exactly the kind that is most damaging when it leaks and most expensive when it is litigated.

Identity images have been a specific target rather than incidental collateral. Coinbase disclosed in a securities filing in 2025 that overseas support contractors had been bribed to access customer data, with identity documentation among the material involved, and estimated remediation costs in a range running into the hundreds of millions of dollars. We wrote about the structural version of that problem in when support staff can be bought. Separately, biometric privacy statutes such as Illinois' Biometric Information Privacy Act have produced a sustained stream of class action litigation over the collection and retention of facial data, and the General Data Protection Regulation treats biometric data used to uniquely identify a person as a special category under Article 9.

So the full cost of a document-based recovery flow is: the vendor fee per check, plus the support cost of the failures, plus abandonment from customers who give up, plus permanent custody of the most sensitive data your organisation will ever hold, plus the regulatory and litigation exposure attached to it. Widely cited industry figures put the cost of a single assisted password reset in the region of seventy dollars, and a substantial share of help desk volume as access related. Treat those as directional rather than precise, but the direction is not in doubt.

The institution is paying all of that to answer a question it should never have needed to ask.

What would a graduated recovery design look like?

Not one mechanism. A ladder, where the strength of evidence required scales with what is being restored, and where the document flow is the last rung rather than the first.

The key insight is that recovery does not have to be all or nothing. Most designs treat recovery as a binary: either you are back in with full powers, or you are locked out. That binary is what forces every recovery through the heaviest possible check. If recovery can restore partial access, you can accept weaker evidence for weaker restoration.

Read the attacker column downwards. It gets easier for the attacker as you descend, at the same time as it gets harder for the honest user. Levels 0 through 3 are cheap for the legitimate person and expensive for the adversary. Level 5, the one almost every institution uses as its primary path, is the only rung where that relationship inverts.

Level 4 deserves a note because it is underused and nearly free. Time is genuine evidence. An attacker is working against detection and usually cannot wait seventy-two hours with notifications firing. A real user who has lost a phone can almost always wait, especially if they get read-only access immediately and full powers on Thursday. Restoring function in stages, rather than as a single switch, converts an impossible security decision into a manageable one.

What the check actually looks like

The mechanism at level 2 is the one people ask about, so here it is concretely. At enrollment, a face embedding is computed on the device and reduced to a one-way key. The embedding is discarded. The image is never uploaded. What the institution stores is a key that cannot be reversed into a face, which is the entire point: there is no template to leak and nothing to hoard.

// Enrollment, once
embedding   = faceModel.run(camera)      // stays on device, never transmitted
personKey   = oneWayDerive(embedding)    // irreversible
send(personKey)                          // this is all the server ever sees

// Recovery, months later
embedding2  = faceModel.run(camera)      // again, on device
personKey2  = oneWayDerive(embedding2)

if (personKey2 == storedPersonKey && livenessPassed && deviceAttested) {
  // continuity established: same human, no template compared, no image sent
  grant(RECOVERY_LEVEL_2)
}

The comparison happens between two keys, not between two faces. The server never holds anything that could be used to identify someone from a photograph, which means a breach of the server yields keys that are useless outside the system that created them. You can try the flow yourself in the walk-up demo, which runs with no signup and no account, and the receipt format and continuity levels are documented in the developer documentation.

Manav exposes continuity as three levels rather than a single boolean: enrolled for a first binding, glance for a fresh face match, and place for a trusted device in a familiar context. A relying party maps those to recovery scope, which is what makes the graduated ladder implementable rather than theoretical.

What about people without a smartphone, a second device, or a friend?

This objection is the one that decides whether a recovery design is serious, and it is usually answered with a shrug.

Every rung above level 4 assumes something: a working modern phone, a second device, a designated contact, a stable appearance, a quiet place with reasonable lighting to complete a check. Real populations fail those assumptions constantly. People who share a household device. People whose appearance has changed through illness, treatment, transition, or simply five years. People with tremors or visual impairment for whom camera flows are hostile. People fleeing domestic abuse for whom "designate a trusted contact" is a dangerous instruction. People whose documents are held by an employer, a family member, or an immigration process.

Three design rules follow, and they are not optional extras.

A staffed path must always exist. Not as a formality, but as a real, findable, adequately resourced route to a human who can make a judgment. Any system that can permanently lock a person out of their own money because a camera did not recognise them has failed, however elegant its cryptography.

The staffed path must itself be gated. This is the tension, and pretending it does not exist is how you get the help desk attacks discussed in the takeover button is labelled add authenticator. A human fallback that accepts a mother's maiden name is a bypass with a friendly voice. Gate it with time, with limited restoration, with multiple staff, or with in-person appearance for the highest tiers, but gate it.

Never make the fallback the default. If the easy path is the weak path, everyone uses the weak path, including the attacker. The ladder only works if the strong rungs are also the fast rungs, which they naturally are when they are set up in advance.

What are the honest limits?

The first anchor still requires a proofing decision. Continuity proves sameness, not identity. Somebody, once, has to decide that this human is the customer they are permitted to serve. For regulated onboarding that remains a document check, an authoritative database, or an in-person appearance. This approach does not replace identity verification vendors, it stops them from being the answer to every subsequent question. The goal is one anchor, not zero.

On-device matching trusts the device. The security of a device-side check rests on platform attestation, and attestation is weaker on rooted, emulated, or heavily modified devices. This is a real limit and any implementation should treat an unattested device as a lower rung on the ladder rather than an equivalent one.

Appearance drifts. Face matching over multi-year intervals has genuine error, and the error is not evenly distributed across all faces, which is a fairness problem as well as an accuracy one. Thresholds must be tuned for the consequence, and a failed match must route to another rung rather than to a locked door.

Regulators may require fresh proofing anyway. Some supervisory regimes and some institutions' own policies mandate periodic re-verification regardless of continuity evidence. Revision 4 of NIST Special Publication 800-63 gives more room for reuse and continuity than earlier guidance, but the practical answer varies by jurisdiction and by product, and anyone building this should get it reviewed rather than take a blog post's word for it.

Nothing here defeats coercion. A person forced to complete a liveness check completes it. Continuity establishes sameness of the human, not freedom of the human, and no identity technology solves the second problem.

What to set up before you lose your phone

For readers who came here as a customer rather than as a builder, this is the practical part, and it takes about fifteen minutes today for accounts that matter.

1. Enrol a second authenticator on every important account. A second phone, a tablet, a hardware key in a drawer. This single step moves you to level 0 and skips the entire document flow. It is the highest return action available to you.
2. Buy one hardware security key and leave it at home. They cost less than a dinner. Register it on your bank, your primary email, and your password manager. It does not travel, so it does not get lost with the phone.
3. Check what your bank's recovery flow actually is, before you need it. Find the help page. Note whether it requires a document, and whether it offers a trusted contact option.
4. Designate a trusted contact where the option exists, if it is safe for you to do so. Many financial institutions offer this and almost nobody enables it.
5. Make sure your recovery email is not reachable only from the phone. A recovery chain that loops back to the lost device is not a recovery chain.
6. Photograph your documents and store them encrypted, in a password manager rather than a photo library that syncs to everything.
7. For builders: instrument your abandonment rate at the document step. Most organisations have never measured it separately from overall recovery success, and the number is usually the argument that funds the work.

Frequently asked questions

Why do I have to upload my ID again to recover my account? Because the institution never kept anything you could produce on demand. It stored the record of a one-time document check rather than binding you to a durable key, so at recovery it cannot ask whether you are the same person as before and instead asks who you are from scratch, using the only evidence it knows how to evaluate.

How can a company verify I am the same person without storing my face? By computing a face embedding on your device, reducing it to a one-way key, and storing only that key. At recovery the device computes the key again and the two keys are compared. The image and the embedding never leave the device, so there is no template on the server to leak, and the key cannot be reversed into a face.

How do injection attacks defeat selfie verification? They bypass the camera entirely, using a virtual camera driver or a modified application to feed synthetic video into the capture pipeline. Because the attacker generates every frame, all the liveness signals a vendor checks for are present. Liveness detection was designed to catch things held up to a real camera, which is a different attack.

Is a one-way key from my face still biometric data under privacy law? Possibly, and it depends on the jurisdiction and on how reversible the derivation is. Illinois' Biometric Information Privacy Act, the General Data Protection Regulation's Article 9, and various state statutes each define the category differently. Storing only an irreversible key is materially better than storing images or templates, but anyone deploying this should get a legal opinion for their jurisdiction rather than assuming.

What is the difference between account recovery and identity verification? Identity verification establishes who someone is, from external evidence, with no reference to past interactions. Recovery should establish that this is the same person as before, which is a different and usually easier question answerable with evidence generated inside the relationship. Conflating the two is why recovery is expensive.

Does this remove the need for identity verification vendors? No. It reduces document proofing from something repeated at every recovery to a one-time anchor at the start of the relationship. Regulated onboarding still needs a proofing decision, and document verification vendors remain the right way to make it. The change is in frequency, not in necessity.

What if my face has changed since I enrolled? Matching over long intervals has real error, so a failed check must route you to another rung of the ladder rather than locking you out. A well-designed flow treats a failed match as an absence of evidence rather than as evidence of fraud, and offers a trusted contact, a time-delayed restoration, or a staffed path instead.

Sources

1. Yoti, published research on identity verification and injection attack volumes during 2025, including the August peak coinciding with UK Online Safety Act age assurance duties: yoti.com/blog
2. Group-IB, Weaponized AI report published January 2026, documenting 8,065 liveness bypass attempts against a single financial institution between January and August 2025: group-ib.com research hub
3. Coinbase Global, disclosure filing describing bribery of overseas support contractors and access to customer identity documentation, with estimated remediation costs: SEC EDGAR full text search
4. NIST Special Publication 800-63A, Digital Identity Guidelines on identity proofing and enrollment, including the revision 4 treatment of reuse and continuity: pages.nist.gov/800-63-4
5. ISO/IEC 30107, Information technology, biometric presentation attack detection: iso.org
6. Illinois Biometric Information Privacy Act, 740 ILCS 14: ilga.gov
7. Regulation (EU) 2016/679, General Data Protection Regulation, Article 9 on special categories of personal data: eur-lex.europa.eu

The safest institution is not the one that checks your passport most often. It is the one that never needs to see it twice.