The Lost Phone Is Part of the Login

Imagine a contractor arriving at a client site, opening a laptop, and finding the password rejected. The reset link goes to an old address. The second factor goes to a phone left in a taxi. The recovery codes are printed in a drawer that is now locked. Nothing has necessarily been hacked. The person has simply reached the part of the system that the login screen never described.

A password reset is not a recovery plan. It changes a secret when one particular route remains available. Recovery begins when that route is gone: the phone is lost, the mailbox is inaccessible, the authenticator was replaced, or the account was created by someone who no longer works there. The central question is no longer whether this user can choose a new password. It is what evidence the system can still accept that this account belongs to this person.

That distinction matters because the two jobs have different failure modes. A reset that is too easy can hand an account to whoever controls a weak fallback. A recovery process that demands a vanished device or an unreachable administrator can turn the rightful owner into an intruder in their own account. There is no frictionless solution hiding between those outcomes. The design chooses where the friction will be paid: during setup, during an emergency, or by the people who review an exception.

Consider three recovery options: a link by email, a code from an authenticator, and a support review. This looks like redundancy until all three depend on the same old phone, mailbox, or employer. They are then separate buttons attached to one dependency. A more durable arrangement spreads the proof across places that do not fail together: a code stored outside the device, a current contact route, a documented way to retire the old device, and an escalation path with evidence requirements. Each item adds work before it is needed. That is not waste; it is the price of having more than one way back.

The awkward part is that recovery plans decay. People change numbers, close addresses, replace phones, leave teams, and forget where they put the codes. A plan can be perfectly designed on the day it is written and useless a year later. It needs a small test while the normal login still works. Can the backup code be found? Does the recovery address still receive mail? Can the old device be removed without first using the old device? These are not hypothetical questions to the person standing outside the account.

This is also why a reset link is a poor answer to an outage or lockout. The link proves that one channel is reachable. It does not prove that the account's other dependencies are known, current, or independent. A recovery process is closer to a continuity plan than to a forgotten-password feature. It describes what happens when the most convenient proof disappears, not just how to repeat the usual login with a new secret.

There is a human cost to getting this wrong, but it is not solved by making support improvise. The person who cannot log in may be careless, unlucky, or under attack; the interface cannot settle that by sympathy. It needs a defined boundary between evidence and assertion, and a way to record which recovery choices are still trustworthy. Otherwise the system oscillates between a dangerous shortcut and an inflexible refusal.

The next time a service offers Forgot password?, the useful question is what remains when the link, phone, and remembered secret fail together. That answer is the real recovery design. When the ordinary login disappears, what does the system still recognize, and who decided that it would?