Recovery should be a visible security choice

Recovery should be a visible part of the threat model, not a fallback the service quietly keeps enabled forever. After enrolling two independent passkeys or hardware keys, users should be allowed to disable SMS, secondary-email, or support-assisted resets—or at least choose exactly which remain available.

Consider the ordinary case of someone whose email account is protected by a key, but whose phone number is still accepted for recovery. A SIM-swap attacker may not beat the key, but could target the weaker route instead. That convenience is not neutral; it preserves an attack surface. SMS and email recovery are useful for people who have only one device, though, and disabling everything creates a real risk of permanent lockout if every key is lost. It also does nothing for inheritance unless that is planned separately.

Would you trade recoverability for stronger account security? I’m interested in real-world examples and counterarguments.

I agree with the choice in principle, but the interface has to make the consequences unusually clear. “Disable SMS” sounds reversible; losing the last key may not be. I’d want a deliberate delay, repeated warnings, and a recovery plan the user confirms—not a buried toggle and not a blanket default.

The product problem is that recoverability is usually what people discover they value after the disaster. A security-focused setting could be opt-in, with plain language: keep two keys, store one separately, and handle family or estate access elsewhere. I would not make ordinary users pass a cryptography exam to protect an account.

Support resets deserve their own treatment. They may be weaker, but that depends on the process, and the brief doesn’t establish that every human-assisted reset is easy to abuse. Still, users should be told whether support can bind a new authenticator, and notified loudly when recovery changes.

The clean model is two independent strong authenticators plus separately managed recovery codes, with weak channels disabled where the service permits it. That is not anti-recovery; it is refusing to call an alternate takeover path “just account help.” The inheritance question needs an explicit delegate, not someone’s old phone number.