Account Recovery Design: The Flow That Determines Your Real Security Ceiling

Your account is only as secure as the weakest path that ends in access, and recovery is almost always that path. A passkey account that falls back to an SMS code has the phishing resistance of an SMS code, because an attacker picks the door, not you. Treat recovery as a first-class authentication flow, rank every method by whether it keeps the passkey's guarantees, and design the help desk as part of that flow rather than an exception to it.

Verified as of 27 September 2026 against the sources linked inline.

I founded LoginRadius in 2013 and scaled it past a billion identities. That work makes one pattern hard to unsee: teams spend months hardening login and an afternoon on the "forgot access" link. This post is the hub for that missing afternoon.

The Recovery Paradox: Your Security Ceiling Is the Weakest Reachable Path

Effective security equals the strength of the weakest path an attacker can reach to get into the account. Login is one path. Recovery is another. So is every agent who can reset a factor on a caller's say-so. The attacker only needs one of them to work, so the strongest path sets nothing and the weakest sets everything.

Passkeys make the paradox sharper. A passkey is phishing-resistant because the browser binds the credential to the real domain, so a lookalike site gets nothing useful. The FIDO Alliance's March 2025 white paper on the passkey journey classifies synced and device-bound passkeys as phishing-resistant. The same paper states that account recovery methods "are fundamentally forms of authentication" and must be counted when judging the strength an account really has.

That paper also draws the uncomfortable conclusion. In its "Optional Adoption" stage, a service offers passkeys but still allows fallback to phishable methods, and the paper says such services "lack phishing resistance." Only at "Full Prevention" do relying parties stop relying on phishable methods "for login or account recovery under any conditions." Shipping passkeys does not buy phishing resistance. Removing the phishable recovery paths does.

The same arithmetic applies to the attacker's cost. Phishing a passkey requires defeating origin binding, which is close to impossible remotely. Phishing an SMS recovery code requires a convincing text message, or a SIM swap, which the joint CISA and FBI advisory on Scattered Spider documents as a routine tactic. The attacker does the cheap one.

This is also why recovery is the prerequisite topic for passkeys right now. A team cannot make passkeys the default, or retire passwords, until it can say what happens when a user loses every device. Until then the old path stays as a safety net, and the safety net sets the ceiling. The enterprise passkey deployment playbook and the complete guide to passwordless authentication both hit this wall at rollout, and the passkey enrollment gap analysis shows how many users still hold only one credential.

Recovery Methods Ranked by Whether They Keep Phishing Resistance

The table ranks the common recovery methods from strongest to weakest. The test for each row is simple: after this method is available, does the account still have a passkey's phishing resistance? Classifications follow the FIDO Alliance paper above and NIST SP 800-63B-4, with my ranking on top.

Rank	Recovery method	Keeps passkey-level phishing resistance?	What the attacker must do
1	A second passkey already enrolled (another device or a hardware security key)	Yes. It is a passkey, bound to the real domain.	Steal a physical device and unlock it.
2	Passkey restored from the platform sync provider (Apple, Google, Microsoft)	Yes at your site. The ceiling moves to the provider's own recovery.	Beat the provider's escrow and device-unlock checks.
3	Saved recovery codes, stored offline, single-use, hashed server-side	Mostly. FIDO classifies them as phishable, but no carrier or inbox can leak them.	Trick the user into typing the code into a fake site, or find the paper.
4	Automated re-proofing with an ID document and liveness check	Not a phishing target, but only as good as the verification provider.	Defeat document and liveness checks.
5	Email magic link or emailed code	No. The ceiling becomes the security of the mailbox.	Take over the email account, or phish the code.
6	SMS or voice OTP	No.	Phish the code or SIM swap the number.
7	Help desk reset on a phone call	No. It bypasses the authenticator entirely.	Research the target, then call.
8	Knowledge-based questions (date of birth, first pet)	No. The answers are often public.	Search breach data and social profiles.

The two methods that preserve the ceiling

A second enrolled passkey is the only fallback that is itself phishing-resistant. NIST says CSPs "SHOULD encourage subscribers to maintain at least two separate means of authentication" and "SHALL permit the binding of multiple authenticators." For a consumer that means a phone plus a laptop, or a synced passkey plus a hardware key. For a workforce it means two hardware keys issued on day one. The FIDO2 developer guide covers the registration mechanics for allowing more than one credential per account.

Recovery codes come second, with a caveat worth stating plainly. The FIDO paper lists recovery codes as phishable, because a user can type one into a fake page. They still beat every channel below them because nothing in transit can intercept them. NIST's rules for saved recovery codes set the bar: at least 64 bits from an approved random generator, stored hashed, throttled, invalidated after use, and replaced with a new code.

Synced passkeys move the question, they do not remove it

Synced passkeys solve most lost-phone cases, which is why they matter so much for recovery. They also hand your ceiling to the platform. Apple's iCloud Keychain escrow requires the Apple Account credentials, an SMS verification, and the iCloud security code. The escrow service allows 10 attempts before destroying the record. Google Password Manager requires either its PIN or the Android screen lock on a new device. Those are strong designs, and they are not yours to control, which is exactly why the device-bound versus synced passkey decision framework matters for high-value accounts.

The methods that lower the ceiling

Email magic links are the most common passkey fallback on consumer sites. The FIDO paper declines to call them phishable or phishing-resistant, saying they have no "theoretical protection against phishing." The practical point is simpler. With email recovery, your account's security equals the mailbox's security, and you do not run the mailbox.

SMS and voice codes are weaker still. CISA's advisory describes Scattered Spider convincing carriers to move a victim's number to a SIM the attackers control, then receiving MFA codes. Knowledge questions are the weakest. Mandiant's May 2025 hardening guidance warns against verifying with "publicly available personal data" such as date of birth or the last four digits of an SSN, because the group "often possesses this information." NIST already prohibits prompting for knowledge-based authentication or security questions when users choose passwords.

Three Design Principles for Account Recovery

Recovery design comes down to three rules, each anchored in NIST SP 800-63B-4 or shipping platform practice.

1. Recovery must never be easier than authentication

If resetting access takes less proof than signing in, attackers will reset instead of signing in. NIST applies this logic to binding: adding a new authenticator requires authentication at the highest assurance level the account currently has, or the level the new authenticator will serve, whichever is lower. Its recovery rules follow the same idea. To recover an AAL2 account, NIST requires two recovery codes from different methods, or one recovery code plus a single-factor authenticator, or repeated identity proofing.

Read that list again with an SMS-only recovery flow in mind. A single texted code does not meet it. The test for your system is one question: can someone reach a fresh passkey enrollment with less evidence than it takes to sign in today?

2. Verification should be proportional to account value

A newsletter account and a domain administrator should not share a recovery flow. NIST scales recovery by assurance level. An AAL3 account proofed at IAL3 requires a biometric comparison against the sample collected during in-person proofing. Mandiant's guidance says positive identification before any change to security information should, at a minimum, cover privileged accounts, using methods such as on-camera or in-person verification and ID checks.

Microsoft now ships a self-service version of this idea. Microsoft Entra account recovery re-proofs a locked-out user with a government ID and a liveness check through a third-party provider, then issues a Temporary Access Pass to register new methods. Microsoft's documentation also warns that default name-only matching "may not provide sufficient assurance for high-risk accounts." Proportionality still has to be configured.

3. Re-enroll immediately, notify out of band, and delay high-value changes

A recovery is not finished when the user gets back in. It is finished when the account is back on phishing-resistant credentials. Route every successful recovery straight into passkey enrollment, and retire the recovery credential that was used. NIST requires that a used recovery code be invalidated and replaced, and that compromised authenticators be suspended or invalidated promptly.

Notification is mandatory under NIST: "account recovery SHALL cause a notification to be sent to the subscriber." New authenticator bindings must trigger a notice through a mechanism independent of the transaction. Send it to every verified channel on file, not only the one used to recover. Then revoke existing sessions, because a recovered account may already have an attacker's session attached; Device Bound Session Credentials address the stolen-cookie half of that risk.

For high-value accounts, add a cooling-off period. NIST notes that recovery "may involve extended waiting times." Apple's Stolen Device Protection applies a one-hour security delay, away from familiar locations, before changing the Apple Account password or adding a Recovery Key or Recovery Contact. A delay gives the real owner a window to see the notice and stop the change. I would apply one to administrator and high-balance accounts, and skip it where lockout harm outweighs takeover risk.

The Help Desk Path: The Recovery Flow Nobody Threat-Models

Every organization has a recovery method that does not appear in its authentication architecture diagram: a person who can reset a factor. Help desk social engineering has driven several of the highest-profile breaches of recent years. It works because it skips the authenticator entirely. When an agent resets a password and registers a new device for a caller, the MFA then works exactly as designed, for the attacker.

The FIDO white paper explains why this path survives. It leaves customer-support verification uncategorized because it "is resource-intensive, making it impractical for scalable attacks." That is true for bulk phishing. It is irrelevant to a crew that picks one company and makes a few calls. CISA's advisory, updated on 29 July 2025, describes Scattered Spider impersonating employees to get help desk staff to reset passwords and transfer MFA to attacker-controlled devices.

What the primary sources show

• MGM Resorts, September 2023. MGM's Form 8-K estimated a negative impact of about $100 million on Adjusted Property EBITDAR. MGM never said how the attackers got in. TechCrunch reported that Scattered Spider claimed it found an employee on LinkedIn and called the help desk.
• Transport for London, 2024. The Register reported from court that attackers impersonated an employee and got a helpdesk worker to reset a password. The CPS reported two defendants were each jailed for five years and six months in July 2026.
• Marks & Spencer, April 2025. M&S estimated in its full-year results an impact of about £300 million on 2025/26 operating profit, before mitigation and insurance. BleepingComputer reported that the chairman told MPs attackers tricked a third party into resetting an employee's password.

The UK's NCSC responded to the 2025 retail incidents with a 4 May 2025 blog post. It told organizations to "review helpdesk password reset processes, including how the helpdesk authenticates staff members credentials before resetting passwords." Microsoft's Entra documentation says the same thing from the vendor side: "Traditional helpdesk recovery is vulnerable to social engineering attacks." The Scam Atlas entry on help desk reset impersonation tracks the pattern and its sourced cases.

Controls the attacker cannot research

A good help desk control has one property: research and persistence cannot satisfy it. A callback to a number from the HR system, never from the caller, passes that test. So do on-camera verification against a photo you already hold, and a second approver for privileged resets. Security questions, employee IDs and manager names fail it. Every reset should end the same way self-service recovery does: fresh passkey enrollment, notifications, and session revocation.

Account Recovery Design Checklist

Use this checklist to audit an existing flow or to spec a new one. Each item maps to a principle above.

1. Inventory every path to access. List login, self-service recovery, email change, phone change, help desk, admin console resets and vendor-run support. Anything missing from the list is still reachable.
2. Prompt for a second passkey at enrollment. Ask again after the first successful sign-in on a new device.
3. Offer saved recovery codes to passkey users. Generate at least 64 bits of randomness, store them hashed, throttle attempts, and rotate after every use.
4. Remove SMS and knowledge questions as standalone recovery. If SMS stays, pair it with a second, different factor, as NIST requires at AAL2.
5. Tier recovery by account value. Stronger proof, and possibly re-proofing, for administrators, payment accounts and high-balance users.
6. Force re-enrollment after recovery. The recovered user lands on passkey setup, not the dashboard.
7. Notify every verified channel. Include time, location and a one-click "this was not me" path.
8. Revoke sessions and tokens on recovery. Old sessions should not outlive the credential change.
9. Add a delay for high-value changes. Hold changes to recovery settings long enough for the owner to react.
10. Write the help desk runbook. Callback to a number of record, on-camera checks for privileged users, a second approver, and no knowledge-based verification.
11. Log and alert on factor changes. Mandiant recommends reviewing MFA registrations and contacting users when new ones appear.

What to Do This Quarter

• Week 1: Draw every path to account access, including help desk and vendor support, and mark each one with its rank from the table above.
• Weeks 2 to 3: Add a second-passkey prompt and saved recovery codes for passkey users. Measure how many accounts have two phishing-resistant credentials.
• Weeks 4 to 5: Make re-enrollment, multi-channel notification and session revocation mandatory at the end of every recovery.
• Weeks 6 to 8: Replace knowledge-based help desk verification with callback and on-camera checks for privileged accounts. Pull 90 days of help desk resets and check how many used a number of record.
• Weeks 9 to 12: Remove SMS-only recovery for administrators and high-value accounts. Add a cooling-off delay to recovery-setting changes on those accounts.

The metric that matters at quarter end is the share of high-value accounts whose weakest reachable recovery path is phishing-resistant. Everything else is activity.

Frequently Asked Questions

Why does account recovery determine my real security level?

Attackers choose the easiest path into an account, and recovery is a path into the account. If login needs a passkey but recovery accepts an SMS code, the attacker attacks the SMS code. The FIDO Alliance treats recovery methods as forms of authentication for exactly this reason.

What is the most secure way to recover a passkey account?

A second passkey enrolled in advance, on another device or a hardware security key. It keeps phishing resistance because it is itself a passkey. Saved recovery codes stored offline are the strongest fallback after that, though the FIDO Alliance still classifies them as phishable.

Is SMS acceptable for account recovery?

Not on its own for accounts that matter. SMS codes can be phished and intercepted through SIM swapping, and NIST SP 800-63B-4 requires more than a single recovery code at AAL2. If SMS remains, pair it with a different second method and a notification to other channels.

How do you stop help desk social engineering?

Use verification that research cannot satisfy: callbacks to a number already on record, on-camera identity checks for privileged users, and a second approver. Drop date of birth and similar questions, which Mandiant warns attackers often already hold. End every reset with passkey re-enrollment and notifications.

Do synced passkeys solve account recovery?

They solve most lost-device cases, because the passkey restores from Apple, Google or Microsoft onto a new device. They also move your recovery ceiling to the provider's account recovery. For administrators and high-value accounts, add a device-bound hardware key as a second credential.