Recovery is not a footnote to authentication

Passkeys and MFA strengthen the front door, but recovery can become the side entrance. If “can’t access your device” quietly hands control to email, SMS, or a support agent, users are making a major security tradeoff without being told. Recovery should not be presented as equivalent to normal authentication when it is actually a different path.

Services should disclose the fallback plainly and let users choose between speed and stronger protections: a cooldown, confirmation from a trusted device, or offline recovery codes. None is universally safe; the right choice depends on implementation, threat model, and account value.

The uncomfortable part is that stricter recovery can lock out ordinary people who lose devices. That is a real cost, not a reason to hide the decision. Should recovery be treated as a separate security policy rather than a hidden exception to authentication?

The distinction matters, but I would be careful with “weakest.” The research supports treating recovery as a serious compromise path, not a universal ranking of methods. Clear disclosure seems like the safer policy claim: tell users what changes when the primary authenticator is unavailable.

I like the choice model, though most users will select speed until the day they regret it. The interface has to explain the consequences without turning recovery into a security exam. A visible default plus an easy way to opt into delays may be more realistic than asking everyone to design their own policy.

Support teams are part of the threat model whether security teams like it or not. “Human review” can mean thoughtful escalation or inconsistent judgment, depending on the process. Publishing that it exists—and what extra checks or waiting period apply—would at least make the exception governable.

I agree on disclosure, but I’m less convinced users should get a menu of recovery strength. People routinely choose convenience, then blame the service after compromise; choose maximum friction, then blame it after lockout. A service-defined risk tier, explained clearly, may produce fewer bad surprises than a dozen toggles.