Designing account recovery as a security-sensitive workflow

Design account recovery as an authorization workflow: establish eligibility, verify a recovery proof, permit only the intended credential changes, and explicitly handle sessions and notifications. A successful recovery should satisfy a defined policy—not simply demonstrate that someone clicked a link.

The policy examples below are application-design recommendations, not descriptions of an identity provider’s defaults.

Separate recovery eligibility by failure type

Start by distinguishing three situations that a single “Forgot password?” screen can obscure:

Situation	Policy to define	Boundary to preserve
Forgotten password	Which previously established recovery method authorizes password replacement?	Password recovery should not implicitly authorize MFA removal.
Lost MFA authenticator	Which remaining authenticator or separately approved recovery procedure authorizes factor replacement?	Knowing the password should not, by itself, authorize bypassing the missing factor.
Lost recovery address	Which alternative, previously established evidence is acceptable?	A newly supplied address should not authorize its own enrollment.

OWASP lists several possible MFA recovery approaches, including single-use recovery codes, multiple enrolled authenticator types, and support assistance with rigorous identity verification. These are alternatives to evaluate against the application’s risks, not interchangeable proofs. OWASP Multifactor Authentication Cheat Sheet

Document eligibility before implementing the interface. Include accounts without an enrolled recovery method, accounts with multiple credentials, and accounts for which self-service recovery is intentionally unavailable. Where acceptable proof is absent, provide a defined escalation or refusal outcome rather than improvising an exception.

Make recovery initiation private and abuse-resistant

OWASP recommends consistent messages and response times for existing and nonexistent accounts. It also advises against changing the account—including locking it out—before a valid recovery token is presented. OWASP Forgot Password Cheat Sheet

A suitable public response is:

If the account is eligible for recovery, instructions will be sent to its recovery address.

Extend that consistency into acceptance criteria for status codes, redirects, and error handling. Compare end-to-end response timing rather than checking message wording alone.

Define separate abuse-control budgets for:

• Initiation: how frequently recovery can be requested.
• Delivery: how frequently messages can be sent to a destination.
• Verification: how many incorrect proofs can be submitted.

Treat submission throttling as a recovery control, not as permission to disable normal account access in response to an unauthenticated request.

Verify proofs with explicit lifetimes and single-use behavior

OWASP recommends recovery tokens or codes that are generated using a cryptographically safe algorithm, sufficiently long to resist brute force, securely stored, single-use, and subject to an appropriate expiry period. Its OTP guidance also calls for strict attempt limits and invalidation after successful verification. OWASP Forgot Password Cheat Sheet · OWASP Multifactor Authentication Cheat Sheet

Translate those properties into explicit server-side state. One useful application model is:

requested → proof_verified → replacement_authorized → completed

Add terminal outcomes such as expired, attempts_exhausted, and cancelled. For each transition, define the permitted actor, required evidence, and resulting authority.

Bind a proof to its intended account and operation. A password-replacement proof should not also authorize changing the recovery address unless the policy explicitly permits that operation. Enforce those decisions on the server rather than trusting a browser-supplied purpose or account identifier.

Make successful proof consumption atomic. Two simultaneous submissions should not both obtain independent replacement authority from the same single-use proof. Define retry behavior as well: a network timeout after successful verification should not create an undocumented second authorization path.

For OTP implementations, OWASP recommends generating a new OTP and replacing the old record on resend. Make resend behavior an explicit acceptance criterion, and separately specify whether failed attempts accumulate across restarted flows. OWASP Multifactor Authentication Cheat Sheet

Constrain credential replacement

After proof verification, authorize the smallest useful operation. Prefer an explicit permission such as “replace this account’s password” over unrestricted account administration.

For each recovery route, specify:

• Which credential may be replaced or removed.
• Whether another enrolled factor is still required.
• Whether profile and recovery-address changes are prohibited.
• How long replacement authority lasts.
• What happens if the user abandons the process after verification.

Treat changing a recovery destination as a separate policy decision. Do not let a password-reset form quietly become a mechanism for replacing every future recovery channel.

Keep retries and partial failures in the design. Decide whether a failed credential update permits another attempt under the same constrained authorization, and enforce expiration throughout that process.

Make session handling and notification explicit

Include a session-disposition policy in the recovery specification. Inventory the application’s session and token types, then decide which must be invalidated after each recovery outcome. Do not leave this as an assumed side effect of changing a password.

For suspected compromise, require invalidation of existing sessions and outstanding password-reset and recovery proofs. OWASP’s recovery guidance calls for these controls, alongside reviewing recovery destinations and MFA methods with the verified account owner and removing unauthorized changes. OWASP Forgot Password Cheat Sheet

For other recovery routes, document any decision to retain sessions. Test the selected behavior using sessions created before recovery, including sessions in another browser or device. Separately define how the recovery-granted authority itself expires or is revoked.

Make post-change notifications an explicit requirement. OWASP recommends notifying users through applicable registered notification addresses, including established channels that remain safe, and providing instructions for reporting unauthorized recovery. It also recommends out-of-band notifications when MFA factors change. OWASP Forgot Password Cheat Sheet · OWASP Multifactor Authentication Cheat Sheet

State what changed without including passwords, recovery codes, or reusable authentication material. Define how notification-delivery failures are retried without repeating the credential change.

Keep support-assisted recovery inside the same policy

Treat support-assisted recovery as another route through the authorization model, not as a bypass around it. OWASP identifies a rigorous identity-verification process as part of support-assisted MFA recovery. OWASP Multifactor Authentication Cheat Sheet

Define acceptable evidence, staff permissions, approval requirements, and the exact changes that support may authorize. Do not permit an agent to disable MFA merely because a requester knows profile information or supplies a new email address.

For higher-impact exceptions, consider a second approver and a narrowly scoped recovery action rather than broad administrative access. Record the decision and outcome without recording recovery secrets.

Include an explicit failure outcome: if the requester cannot meet the recovery policy, support should not invent substitute evidence during the conversation. Make that limitation understandable to users and staff.

Integrate Ory recovery without assuming an MFA reset

Ory documents recovery through a link or one-time code sent to the account’s configured recovery address. Successful recovery grants a privileged session and takes the user to account settings to create a new password. The same documentation explicitly states that recovery does not reset the user’s second authentication factor. Ory account recovery documentation

Treat that privileged session as an integration boundary. Verify which settings it can access and which operations require MFA in your deployed configuration. Keeping a second factor enrolled and requiring that factor before a settings change are separate questions; define acceptance criteria for both.

Ory identifies one-time codes as its default and recommended recovery method. It describes magic links as supported but legacy and deprecated. One drawback Ory identifies is that email virus scanners may open and invalidate recovery links. Ory also warns that switching from links to codes may require UI changes. Ory account recovery documentation

The documentation describes the recovery flow’s lifespan setting as the time available to complete the UI flow. In your acceptance tests, check UI-flow expiration, proof expiration, and privileged-session duration separately rather than treating “recovery timeout” as one undifferentiated requirement. Ory account recovery documentation

For session revocation, Ory documents the revoke_active_sessions action in after-recovery hooks and says Ory Network enables this behavior when a project is created. Verify your deployed configuration, and test the disposition of application sessions and tokens separately. Ory account recovery documentation

Ory supports custom authentication and profile-management interfaces through its SDKs and REST APIs. Whichever interface you build, make settings authorization, MFA requirements, and session disposition integration acceptance criteria—not assumptions based on the screens shown to the user. Ory Kratos introduction

Test failure paths as security properties

Build tests around rejected transitions as well as successful recovery:

• Compare responses and timing for known and unknown accounts.
• Exercise repeated initiation, delivery, and incorrect-code attempts separately.
• Submit expired proofs and proofs belonging to another account or purpose.
• Redeem the same proof concurrently and after successful use.
• Request another code and verify resend invalidation and attempt-count behavior.
• Interrupt the workflow between proof verification and credential replacement.
• Attempt unrelated settings changes using recovery authority.
• Check MFA requirements and existing-session behavior after completion.
• Exercise notification failures and support requests with insufficient evidence.
• For link-based recovery, test automated link opening and browser changes.

The central invariant is simple: recovery should grant only the authority justified by the accepted evidence, for a bounded time, with a predictable outcome on failure.