The back door sets the strength of the lock: recovering accounts without handing them to attackers

Reconstructs the common shape of an account-recovery system from NIST, FIDO, Okta, Google, Apple and GitHub, then sets it against six failures: the 2023 help-desk resets, Retool's synced second factor, Reddit's SMS factor, the Honan chain, and two recovery bugs still open in Keycloak and Ory Kratos. A reader can map their own recovery paths, pick a proof by account tier, and see which choices flip with the value at risk.

What you get out of it

• An account is as strong as the weakest path that can change what it trusts (the recovery ceiling), and the help desk is usually that path.
• A second factor stored under a recoverable account inherits that account's strength: Retool's synced codes made MFA single-factor.
• A reset that ends in a session or counts as a factor bypasses the controls it restores; Keycloak #12759 has been open since June 2022.
• A delay protects only if an alert reaches the owner on a channel the attacker does not control; NIST requires notification on every recovery.
• The public record has no lockout-rate data for the strict policies, so adopting one is running the first experiment.

Scope

Why this, now. Phishing-resistant login is shipping widely, which moves attacker effort onto the reset and help-desk paths, and Google launched recovery contacts in October 2025 while a Keycloak reset-flow bypass open since 2022 is only now getting a proposed default change.

What it does not cover. Phishing-resistant login itself, session theft after login, credential stuffing, regulated customer onboarding beyond NIST re-proofing, and machine credentials.