Recovery is becoming the bigger account-security problem

I’m increasingly more worried about account recovery than login itself. A personal phone number is convenient, but making it the default recovery factor creates two separate problems: a carrier compromise can redirect SMS codes, and the same number handed to unrelated services becomes a useful way to correlate identity. It can expose more personal information than the recovery function actually requires.

I’ve noticed how often a new service asks for my number “just in case,” even when I already have other sign-in methods. Offline recovery codes, passkeys registered on multiple devices, or a separate recovery alias each reduce some risks, but introduce their own: codes can be lost or copied, passkeys depend on device or sync security, and an alias still needs protection.

Should services make users explicitly choose a recovery threat model instead of silently defaulting to phone-based recovery? I’m open to counterexamples, especially where phone recovery is genuinely the least-bad option.

The carrier step is the part people underestimate. SMS recovery is not merely “less elegant” than a passkey; it depends on another organization correctly resisting a number transfer. That is a poor abstraction boundary for a high-value account, even before considering privacy correlation.

The least-bad option matters. A recovery code hidden in a password manager is excellent until the user loses access to that manager. A second passkey is great until it lives on a phone left in a taxi. Products optimize for the recovery path people will actually complete.

NIST’s framing is useful here: PSTN verification is restricted, not forbidden. The sensible product requirement is to offer a non-phone alternative and explain the tradeoff, rather than pretend one recovery method is universally safe.

The correlation issue deserves equal billing. Even if an account never gets attacked, supplying the same personal identifier repeatedly can make unrelated records easier to match. A recovery alias does not erase that risk, but it can limit unnecessary reuse.

Support teams will resist anything that increases lockouts. Offline codes and multiple authenticators need clear enrollment and replacement procedures, not just a checkbox buried in settings. Otherwise users will fall back to support, which may be even more identity-intensive.

I’m not convinced “choose your threat model” belongs in onboarding. Most people want an account to work, not a seminar on adversaries. A good default plus a visible advanced option may produce better real-world security than making every user decide among unfamiliar failure modes.

Multiple devices seems like the most resilient general pattern, provided the user understands whether the passkey is synced or device-bound. Redundancy helps with loss, but synchronization moves trust into the account or manager that handles that sync.

The boring answer is probably still the best one: let me print recovery codes, register two devices, and decline the phone number. If a service insists on my number for convenience, it should be honest that convenience is part of the security trade.