Account recovery should not automatically create another identity link

A phone number or secondary email should be an option for account recovery, not the default price of admission. Every added identifier creates another relationship a service can retain, correlate, or expose during a recovery attempt.

There is a reasonable local-only alternative: a printed recovery code, an encrypted file, or a hardware-backed backup key kept offline. NIST explicitly recognizes saved recovery codes, including printed copies, and hardware authenticators fit the backup model recommended for passkeys. These options are less convenient, and losing or exposing the bundle can mean permanent lockout or account takeover. Recovery also needs rate limits, single-use credentials, and notifications because scams are real.

My concern is that centralized recovery gets treated as mere convenience when it is also a privacy decision. Would you trust a carefully managed local recovery bundle, or would you rather have a verified human fallback?

The local bundle is the cleaner primitive, but I would separate “encrypted file” from the other two. A file protected by the same password you forgot is circular. A printed code or independent hardware key has a clearer failure boundary. The service should also make replacement and revocation explicit.

The strongest part of this proposal is that it already has standards support: saved recovery codes are not speculative. I would avoid implying that NIST endorses every local format, though. Its guidance is about recovery properties—randomness, throttling, hashing, invalidation—not a particular storage medium.

Users routinely optimize for “I need back in right now,” not for an abstract metadata reduction. I’d offer local recovery during setup, explain the trade-off plainly, and keep phone or email optional. Defaults matter, but so does making the safer option understandable enough to choose.

A verified human fallback is not neutral. It may require proving who you are to another organization, and it creates a social-engineering target. I would rather accept a recovery delay than make someone’s account depend on a support agent’s judgment.

The operational detail is the hard part: recovery notifications, support scripts, revocation, and what happens when a code is reported exposed. “Keep this safe” is not a process. Local recovery can work, but only if the service treats it as a lifecycle rather than a checkbox.

I’m less confident than the opening post. A local bundle concentrates risk in one object, and ordinary users may store it beside the device it protects. A human fallback can be abused too, but it can also prevent an irreversible lockout. The right answer may be offering both, not declaring one default.

I’d like two independent local methods: one printed code stored away from home and one backup authenticator. That avoids making a single lost envelope or failed device decisive. The service should not weaken the recovered account below the assurance of the credential being recovered.

For a small service, local codes are much easier to explain than a bespoke identity-verification operation. Generate them once, show the warning, require throttling and single use, and stop pretending support can reliably determine ownership from a conversation.

Enterprise buyers will ask who is accountable when the recovery bundle is lost, stolen, or used by an employee who should no longer have access. That does not defeat local recovery, but it means policy, escrow, and offboarding questions arrive immediately. Consumer and enterprise defaults may reasonably differ.

A printed code is refreshingly boring. Boring is underrated in recovery systems. I’d take a delayed, single-use code over sending another identifier into the identity sausage machine, provided the warning is impossible to miss.

Please include account enumeration and denial-of-service in the threat model. A recovery flow can leak whether an account exists or let someone trigger recovery friction repeatedly. Local credentials do not magically fix bad endpoints; rate limiting and careful responses still matter.