Account recovery is an authentication method, not just support

I think account recovery should be treated as a separate authentication method, not as harmless customer support. An email reset link, SMS code, trusted device, or support override can bypass the password, passkey, or MFA setup a service encouraged you to use. That makes the recovery path part of the real security boundary.

Services should show users every active recovery route, explain which ones are weaker or more phishable, and let them remove fallbacks they do not want. Changes to recovery details should notify an independent existing channel and perhaps sit behind a delay so the legitimate owner can cancel them. Standards already recognize recovery notifications and, in some cases, waiting periods.

The trade-off is real: stronger controls reduce takeover risk but can permanently strand someone who loses a device or access method. Which recovery controls do you actually use, and what compromise would you accept?

The useful distinction is not “strong” versus “weak” in the abstract. It is: what does the attacker already control? If they have the email account, email recovery is effectively gone. If they have a stolen unlocked device, a passkey or trusted-device path may be the problem. Inventory and threat modeling beat a universal ranking.

I support the inventory, but I would make the delay mandatory only for changing recovery factors, not for every recovery attempt. A person locked out during travel needs a path back in. A person changing the phone, email, and passkey simultaneously should trigger friction and independent notification.

The product problem is that recovery is judged by the worst ten minutes of a customer’s life, while takeover happens later and invisibly. Most services will bias toward “get back in now” unless users can make the stricter choice during setup. Defaults matter here more than another warning screen.

The standards framing is useful because it avoids pretending recovery is merely an operational exception. If it can establish control of the account after the normal authenticator is unavailable, it is authentication in practical terms. The notification requirement is especially important: silent recovery changes are difficult for the owner to contest.

Support overrides deserve their own audit trail and limits. “Talk to an agent” sounds informal, but it can become the strongest bypass if the agent can replace every factor. I would rather see a slower, documented escalation than a persuasive conversation deciding ownership in real time.

As a small developer, I worry about making this a compliance-shaped feature that nobody can implement correctly. Showing recovery methods and sending change alerts are straightforward. A safe delay is harder when the account controls payroll, billing, or deployment access. I’d start with a clear risk tier rather than one rule for every account.

There is an uncomfortable failure mode in “let users disable fallbacks”: users disable the inconvenient option, lose the remaining device, and then blame the service for enforcing their choice. I still want the control, but the setup flow should make the lockout consequence unusually explicit and require a durable recovery code or equivalent.

“Active recovery paths” should be visible in plain language, not buried under security jargon. I would want to see: who can send a code, which devices count, whether support can intervene, and what happens if I remove something. People cannot make a trade-off they cannot see.

Recovery codes are a good example of the resilience trade-off. They reduce dependence on a particular device, but they become another secret that needs safe storage and possibly rotation. I would prefer services to let people create several independent recovery options and clearly show when one is no longer valid.

A delay is sensible for changing recovery details, provided the service says exactly what is delayed. Otherwise users will discover that “security hold” means they cannot access an account during an urgent situation. Security controls that explain themselves are more likely to stay enabled.

For a small business, permanent lockout is not theoretical: the person who set up the account may leave, lose a phone, or forget where codes were stored. I’d accept a delay and alerts, but I need a recovery process that can involve more than one accountable owner without making support the final unreviewable authority.