How to review password reset without bypassing MFA

A password-reset link should let a person replace the password, then return to normal authentication. It should not produce an application session with MFA already satisfied, enroll a replacement factor, or change a privileged role. Review the reset flow as a sequence of states: request, token delivery, token redemption, password update, session invalidation, and the next login. Give each state only the authority it needs. OWASP's Forgot Password Cheat Sheet recommends single-use, expiring recovery tokens and session handling after reset; its MFA guidance treats factor replacement as a separate high-risk action.

The answer changes if the user has lost the MFA factor as well as the password. That is an account recovery procedure, not a password-reset shortcut. It needs a documented recovery method appropriate to the account's assurance requirements, restricted recovery state, an audit trail, new factor enrollment and qualifying authentication before protected application access. A pre-enrolled recovery method need not require a support agent's discretionary approval. Sending a second email to the same mailbox does not create an independent factor.

Illustrative case: reset link becomes an authenticated session

Illustrative SaaS and accounts. In a staging copy of Meridian Desk, an engineer uses two synthetic users. Dana has a password and an authenticator-app factor. The reset email contains a one-use token. When Dana follows the link and sets a new password, the handler calls a general createSession(user) function. That function normally runs only after the MFA challenge, and it marks the resulting session mfa_complete=true. The reset page then opens protected customer reports without a factor challenge.

The mistake is the state transition, not the mere presence of a reset endpoint. Someone with temporary access to Dana's mailbox could redeem the reset link and gain a protected session. The engineer has not demonstrated compromise of a real mailbox or production account. The source path supports a plausible bypass; an authorized staging observation can confirm what the deployed handler actually does. The safe transition is from RESET_PROVEN to PASSWORD_CHANGED, followed by a new sign-in that proves the required factors.

The table is a review artifact. The exact names are illustrative; the required property is that each transition grants only its stated authority. A reset-token check cannot be reused as proof that the current browser completed MFA.

Read the helper that creates the session

The defect becomes clearer in two small fragments. They are synthetic and unexecuted:

# Before: helper assumes its caller already completed MFA
redeem_reset(token, new_password):
    user = consume_valid_reset(token)
    update_password(user, new_password)
    return create_full_session(user, mfa_complete=true)

A helper that is safe after a challenge can be unsafe when called from recovery. The reset token proved the reset purpose, not the MFA event. Repair the transition instead of merely renaming the helper:

# After: completion has no application-read authority
redeem_reset(token, new_password):
    atomically validate/consume reset and update the bound user's password
    invalidate affected sessions and refresh authority under the reset policy
    return reset_complete_then_normal_login()

The exact transaction and issuer invalidation mechanisms depend on the system. If password update and session revocation cannot commit atomically across services, use a durable restricted state that prevents old authority from being reused while recovery completes; do not announce universal revocation before it is established. OWASP's reset guidance recommends returning to ordinary login rather than automatically logging in after reset.

Eliminate the old-cookie confound

A developer tests the changed reset flow in a browser that already has a valid MFA session. After reset, the reports page opens. That observation alone does not identify a new MFA bypass: the page may have reused the old session. It could instead reveal failed session invalidation, or simply a policy that intentionally retains some sessions. Trace which credential authorized the read.

Use two controlled browser contexts in the validation plan:

Then sign in using the new password and stop before the enrolled factor. Direct report, export and factor-management requests must remain denied under Meridian's policy. Completing MFA should restore only the user's current account permissions; recovery must not revive a removed membership.

Keep expected and observed columns separate. This article supplies the plan and source reasoning, not results from running it. A blank or failed login fixture cannot count as a successful security denial.

Check the SSO-only branch before enabling a local password

For an SSO-only account, a local reset request must not create a native credential that bypasses enforced federation. A generic outward response can avoid exposing account status, while the internal branch routes the legitimate user to the configured IdP recovery process or an approved administrator process. Inspect the identity record after redemption: did the app merely update an existing authorized native credential, or did it create a new sign-in method?

Finally check replay and concurrency. One reset token has one account and purpose, and two concurrent redemptions must not produce two usable recovery transitions. Invalid or expired tokens must leave no session behind. The completion page should contain no protected report payload even if it offers a convenient link to sign in. These checks address the actual authority gained by each transition, rather than whether the reset email looks correct.

Keep lost-factor recovery on a separate path

A user may truthfully have no enrolled factor available. Requiring the missing factor to recover itself is not a workable design, but treating a reset email as a replacement factor lets mailbox compromise defeat MFA. Give support and identity teams a documented recovery process: verify the person using independent evidence appropriate to the account's risk, suspend or restrict existing access, record the request and approver, enroll a replacement factor in a restricted state, then require a fresh qualifying login. Notify the user through an established channel and review old factors and sessions. OWASP's MFA Cheat Sheet describes the takeover risk in factor changes; NIST's account-recovery section gives a formal recovery model.

For a privileged account with a hardware-backed authentication rule, recovery must restore that rule before privileged access. A temporary password plus email code should not silently become a weaker administrator path. The recovery procedure may need a second trained operator or pre-enrolled spare authenticator; record who can authorize it and how a compromised support account is contained.

Failure and uncertainty branches

If the identity provider does not expose reliable session invalidation, do not claim all sessions ended. Document which tokens remain valid, their expiry, and whether the application checks current authorization on every protected request. If the MFA assurance claim's origin is unclear, classify the route as unverified and inspect the server-side event that sets it. A passing happy-path reset is not a test of bypass resistance.

Inspect what the reset credential can reach

The restricted reset state should have a small, explicit set of operations. In Meridian, it can identify the bound reset request, accept a new password under policy, and report completion. It should not be accepted by a general authentication helper simply because it contains a user ID. Trace the middleware and shared session utilities that distinguish recovery authority from an ordinary application session.

A useful synthetic counterexample is a report endpoint that checks only whether context.user exists. The reset handler may legitimately populate that field to know whose password to replace, but the report endpoint needs evidence of completed normal authentication and current account authority. The repair is to preserve the distinction between identity known for a restricted purpose and permission to read reports.

Review the reset completion response as well. It may include navigation or a confirmation message. It should not preload the customer's report summary, account-member list, or a broadly usable API token while waiting for the next sign-in page. Protected data returned in the response remains delivered even if the UI never renders it.

Keep password and factor recovery decisions separate in support

A support procedure can accidentally reintroduce the bypass removed from code. For example, an operator trying to help Dana may mark MFA complete after verifying the reset email. That action grants a different kind of authority from replacing the password. Give support a documented distinction between ordinary password reset, lost-factor recovery, and restoration after suspected compromise.

For the synthetic lost-factor case, the recovery owner should record the evidence used to establish identity, which existing factors or sessions were restricted, and what must happen before normal access resumes. A recovery credential should remain limited to the intended enrollment steps. If the process uses pre-enrolled recovery material, inspect its actual lifecycle and one-use behavior; do not assume it is equivalent to an email link because both appear on a recovery screen.

The technical review should also identify who can invoke an administrative override and what the override produces. A support action that returns a fully privileged session is materially different from one that authorizes restricted factor enrollment. The organization may have a legitimate emergency process, but it must be explicit rather than hidden inside a generic “unlock user” button.

Interpret reset observations with the right credential history

A clean browser context is essential for the first post-reset read, but also record the old session's history. Was it authenticated before the password change? Does the chosen reset policy invalidate all sessions, only a token family, or a defined subset? Which application actually accepts the credential? Without those facts, the reviewer may confuse an MFA bypass with a session-revocation gap or expected retained access.

Use the resulting evidence to choose a narrow repair. If the reset endpoint issues a new full session without MFA, repair the transition. If it issues no session but the old token still reads reports contrary to policy, repair invalidation or resource authorization. If both are correct but the browser displays cached data already received, describe that client behavior separately.

Finally, revisit removed membership. A fresh qualifying login after recovery should restore only current rights. It should not reactivate a customer account from which Dana was removed, nor revive old invitations merely because her identity is now proven again. The reset flow changes a credential; it does not approve new business access. This is the point where password recovery rejoins the application's ordinary membership and resource checks.

Next, have a developer fill the state table for one real reset flow and trace a direct API read after token redemption. Use how to check MFA on sensitive routes to widen the route inventory and how to design session revocation after access removal to close pre-reset sessions consistently.