Your recovery path is part of your login threat model

I think account recovery deserves the same threat-modeling as login. People retire a phone number, abandon a backup email, or leave a “contact support” route attached to an important account, then assume a strong password or passkey covers them. It doesn’t if recovery can bypass those protections. NIST calls authenticator recovery a weak point in many systems, and human-assisted recovery brings social-engineering risk.

I’m not arguing that recovery should disappear. Losing a phone, changing numbers, or losing credentials is ordinary, and removing every fallback can lock out the legitimate owner. But services should offer a visible recovery audit: which channels can reset access, when each was last used, and what level of trust it carries. A stale number should be hard to ignore. How do you manage your own recovery setup, and where would you draw the line between security and usability?

The “last used” field would be useful, but I’d treat the trust label carefully. Unless the provider can explain how it is calculated, users may read “high trust” as a guarantee. Showing the actual reset capability and the notifications triggered would be more concrete.

Recovery is an alternate authentication protocol, whether the product admits it or not. If the main path requires a passkey but support can replace it after a short conversation, the system’s effective security is the support process.

The hard product problem is that the people most likely to need recovery are also least likely to maintain an audit. Make the warning appear during number or email changes, not buried in settings. A useful nudge beats another dashboard nobody opens.

“Old number” is a very human category, not a security category. People remember that they changed it, but not every account where it was stored. The interface should make cleanup part of the change flow, while still offering a safe grace period for mistakes.

Support teams need a bounded recovery procedure, not just a vague instruction to verify identity. Every extra exception becomes a path attackers will test, but a rigid no-exceptions policy creates stranded customers. Logging and post-recovery notification seem like the minimum operational hygiene.

I’d like to see recovery methods separated by purpose: backup authentication, notification, and human escalation. An email that only warns me is not equivalent to an email that can reset the account. Users often cannot tell those apart today.

The proposed audit could create false confidence if it reduces a complicated policy to a traffic-light score. “Medium trust” does not tell me whether the method is vulnerable to number reassignment, social engineering, or an attacker who already controls another factor.

My practical rule is two independent methods, stored codes offline, and no old phone numbers. I’m willing to accept a slower recovery process for an account that controls money or source code. For a low-value account, I’m not filling out a risk questionnaire.

Most settings pages already have too many red dots. Still, a quarterly “these three things can get you back in” message would be harder to misunderstand than a security center nobody visits.

There’s also a resilience angle. If recovery depends entirely on a provider’s support queue, an outage or locked mailbox becomes part of your threat model. Exportable recovery codes and a second device are less elegant than support, but they fail more locally.

For organizations, the audit needs an owner and an event trail. A user-facing view is helpful, but administrators also need to know when a recovery factor changed and whether the old factor remained temporarily valid. Otherwise incident review starts with guesswork.

I understand why services keep several fallbacks: customers lose phones and forget passwords at inconvenient times. But I’d rather be told plainly, “this support route can reset your account,” than see it described as a harmless contact option.

The key distinction is reset versus notification. If a backup email can receive a warning but cannot establish a new authenticator, its risk is different. Providers should document that behavior instead of making users infer it from trial and error.