Password managers earn trust on their cryptography. The vault is encrypted, the key derives from a master password, and auditors spend weeks on that boundary. The reset flow that gets a locked-out user back into the same vault usually gets a fraction of that attention. Recovery is authentication by another door, and the door is often weaker.

The Recovery Path Nobody Audits

Vault encryption draws scrutiny because it is the product's claim to existence. Recovery draws none of that scrutiny because it is framed as customer support. The result is a second way into the vault, built by whoever owned the help desk ticket queue that quarter, reviewed against a checklist that asks whether the user can get back in rather than whether the wrong user can.

Auditors test login. They try weak passwords, session fixation, token replay, and timing side channels on the unlock screen. Reset flows appear in scope documents as a line item, and the finding is usually a note about rate limiting rather than a full adversarial pass. A reset endpoint that mints a session is an authentication endpoint. Treating it as a support feature is where the gap starts.

The asymmetry is structural. Login has one owner, usually the security team, and one threat model. Recovery has several owners: support, identity, sometimes a growth team that wanted fewer drop-offs at the lockout screen. Nobody holds the whole map, so nobody can say with confidence which paths reach the vault.

There is also a documentation problem underneath the ownership problem. The login surface is described in architecture diagrams because it is part of the product. The reset surface is described in runbooks, support macros, and the heads of the two engineers who built it. When one of them leaves, the institutional knowledge of how recovery actually works leaves with them, and the next person to touch the handler is reading code with no design intent attached.

How Recovery Becomes the Weak Link

Email reset inherits mailbox security. If the password manager lets a reset link reach an email account protected by a reused password and no second factor, the vault's encryption strength is irrelevant. The attacker does not break the cipher. They log into the inbox and click a link.

Support-assisted recovery invites social engineering. A help desk agent under pressure to close tickets in minutes is asked to verify identity over chat. Account numbers, billing details, and a plausible story are often enough. The agent is measured on resolution time, and the attacker knows it. The verification script is the control, and the script is usually written by someone optimizing for the honest majority.

Legacy recovery questions are guessable by anyone who can read a public profile. Mother's maiden name, first school, first pet: most of these answers sit in old forum posts or a family member's social feed. Backup codes are the fourth door. Users print them, and the printout ends up in a desk drawer beside the laptop, or in a notes app on the same device as the vault.

Device-transfer and trusted-device flows add a fifth. A feature that lets a user approve a new phone from an old one assumes the old device is still in the right hands. Resale, repair, and hand-me-down phones break that assumption quietly, and the approval gesture looks identical whether the person tapping it is the owner or someone who bought a used handset with the previous session still live.

What a Post-Mortem Actually Shows

A typical post-mortem timeline runs from a reset request to vault access in under an hour. The attacker requests a reset, receives the email, and logs in from an unfamiliar address. Nothing in the login logs looks anomalous because the session is legitimate by the system's own rules. The intrusion looks like a user who forgot a password.

The gap between policy and implementation is usually visible in hindsight. The policy says support verifies identity with two independent factors. The implementation gives agents a dropdown with one option, or a script that asks for the email address on file. Logs on recovery endpoints are frequently thinner than login logs, sometimes absent entirely, so the investigation reconstructs the sequence from email provider records.

Retention is the other half of the problem. Login events often sit in a security data store with months of history and a schema someone maintains. Recovery events, when they are captured at all, land in the support tool's activity feed, which may rotate on a much shorter window. By the time a user notices unfamiliar activity and reports it, the recovery trail may already be gone. Investigators then work from billing records and inbox timestamps, which is a slow and partial way to rebuild an hour of attacker activity.

The fix ships in days once the path is known: a mandatory second factor on reset, a cooldown before the new session can read the vault, alerting on recovery attempts from new devices. The audit that would have caught it takes months to schedule. That timing gap, not the technical complexity, is the recurring story.

The Engineer's View in 2026

Recovery code is owned by no single team. It sits between identity, support tooling, and the client apps, and each group assumes another is watching it. Threat models stop at the login screen because that is where the security review was scoped. The reset handler was written by a contractor in 2021 and has not been touched since.

Small teams carry a large blast radius. A password manager with fifteen engineers protects credentials for millions of people, and the recovery service is often one of the least-staffed components. A single misconfigured reset endpoint can hand over every vault the service holds. Teams that would never ship an unaudited crypto change will ship an unaudited reset flow before a Friday release.

Vulnerability reports rarely cover recovery. A researcher who finds a flaw in the vault encryption submits it through the published security contact. A researcher who finds that the reset endpoint accepts an expired token often has nowhere obvious to send it. The security.txt standard exists for exactly this reason, and it is worth checking whether the contact address routes to someone who understands the recovery surface, not just the cryptography.

Tooling compounds the gap. Static analysis and dependency scanners are wired into the build for the client and the crypto libraries, because those are the repositories with owners and CI configs. The support integration that mints recovery tokens may live in a different repository, maintained by a different group, with a lighter pipeline. Nobody decided that recovery deserved less scrutiny. The scrutiny followed the organizational chart.

Why the Gap Persists

Recovery is a user-experience problem before it is a cryptography problem. Every added verification step costs conversions at the lockout screen, and the product metric is completed recoveries. Abuse is rare and invisible until it is not. The team optimizing for the common case has no dashboard showing the uncommon one.

Metrics track uptime, not abuse. A recovery service at 99.99 percent availability looks healthy while accepting forged tokens. Compliance checklists ask whether reset flows exist and whether they are documented, not whether they resist an attacker who controls the email inbox. Users choose convenience over verification when the prompt arrives, and the design follows the users.

There is a real trade-off here, and the support side holds it. Hardening recovery slows down legitimate locked-out users, sometimes by hours, and those users are often the ones who already lost access to their second factor. A strict cooldown is the correct security call and a genuine cost to the person on the other end. The honest position is to make the cost explicit rather than pretend it does not exist.

Insurance and procurement are starting to move the needle, slowly. Buyers of enterprise seats increasingly ask recovery questions in security questionnaires, which means the answers get written down and someone has to defend them. That pressure is uneven, and it rarely reaches consumer tiers, but it is one of the few forces that makes a support-owned flow visible to the people who fund it.

Auditing Your Own Recovery Path

Map every reset and recovery entry point before writing any code. Include email links, support-assisted resets, backup codes, legacy questions, device-transfer flows, and any admin tool that can mint a session. If the list has more than three items, the threat model probably missed some.

Treat email and support as authentication factors. Score the mailbox's own protections and the help desk's verification script the same way you would score a password policy. A reset link delivered to an inbox without a second factor is a single-factor login.

Log and alert on recovery attempts with the same detail as logins: source address, device, time to first vault read, and whether the request came from a new location. Test recovery with the same rigor as login, including expired tokens, reused links, and concurrent reset requests. Publish a security.txt contact that reaches the team owning the recovery surface, and route recovery findings to it. Teams that already treat build pipelines as a security boundary, as this site has argued in a piece on CI contracts, will recognize the pattern: the unglamorous path is where the access lives. The same logic applies to maintainers kept on call for systems nobody budgeted to watch.