Your login has MFA. Do the protected routes agree?

An application announces that multifactor authentication is enabled. The sign-in screen asks for a second step. Everybody feels a little better, and with reason: an additional factor can make a stolen password less useful. The interesting review begins after that reassuring screen.

The application still has to decide what a partially signed-in visitor may do. A password accepted five seconds ago is not the same state as a completed second-factor challenge. If a protected route recognizes only the first state, a very polished login page may be standing in front of a side entrance.

Authentication has stages

Consider a hypothetical customer portal. After the password check, the visitor has a temporary session that permits completing the second factor. After the challenge succeeds, the application establishes the authenticated state required for account access. Those states need explicit meanings in the server-side access rules.

A page can hide its navigation until the second step is complete while a report endpoint still accepts the temporary session. The interface looks disciplined; the download route has different ideas. That is why a review examines protected requests directly rather than inferring protection from the buttons on the screen.

The policy belongs on the server

OWASP treats multifactor authentication as part of a broader account lifecycle, including recovery and sensitive account changes. Its authorization guidance also calls for permission validation on every request. Together, those principles suggest a useful review question: does each sensitive operation require the authentication state and permissions that its policy promises? [1] [2]

Central access checks help keep the answer consistent. Individual endpoints still need clear declarations of what they require. An administrative export, an ordinary account page and a second-factor enrollment route may have different rules. The difference should be deliberate and testable, rather than an accident of which template a developer copied.

Recovery is part of the design

People lose phones. Authenticators fail. Accounts change hands. A recovery process therefore needs to exist, but it deserves the same attention as the main sign-in flow. Otherwise the strongest front door in the building may share its key with a very accommodating reception desk.

Review who can reset a factor, which evidence that action requires, how existing sessions are handled and what the account owner is told. Support staff need an understandable procedure and a way to recognize unusual requests. Avoid treating a recovery email, help-desk exchange or remembered browser as automatically equivalent to the intended second factor.

A small, clear test matrix

In an isolated application with synthetic accounts, compare requests in four states: signed out, password accepted with the challenge still pending, fully authenticated and signed out after a previously valid session. Select representative page, API and download routes. Record the expected decision before checking the observed one.

That exercise should verify useful behavior as well as rejection. A legitimate user who completes the challenge must still reach the account. A visitor completing enrollment should be able to reach exactly the enrollment functions intended for that state. Security tests are stronger when they show both the boundary and the valid work it permits.

Know what the result establishes

Record the route, synthetic identity, authentication state, required permission and observed outcome. If a correction is needed, repeat the same checks and keep the before-and-after result. Logs should explain the decision without recording recovery codes, session tokens or the second-factor secret itself.

Passing a bounded test does not certify every part of an identity system. It does provide concrete evidence about a set of important paths. The practical objective is straightforward: the server should agree with the promise on the sign-in screen, including when a visitor arrives by a route the screen never displayed.