Authentication Starts After Login: Recovery, Sessions, MFA, and Admin Access

A polished login form is the smallest part of an authentication system. The difficult questions begin after credentials are accepted: Can a user revoke a stolen session? What happens when they lose the second factor? Can a support agent enter an account? Does every API request verify the tenant? Can a former employee recover access through an old email address?

These paths determine the real security level. An attacker will use the cheapest path into an account, not the one featured in the product demo.

Draw the complete account state machine

List every route that can create, strengthen, recover, transfer, or end access:

• sign-up and email verification;
• invitations and team joining;
• password or passkey login;
• social or enterprise identity login;
• password reset;
• MFA enrollment, recovery, and factor replacement;
• email-address change;
• session listing and revocation;
• support access or impersonation;
• role change, suspension, and deletion.

For each route, record the required proof, rate limit, notification, audit event, and sessions that should be revoked. This exposes contradictions. A product may demand MFA for login but allow an email change from an old session without reauthentication, turning the email-change screen into the easiest takeover route.

Make recovery safe without making it revealing

The OWASP Forgot Password Cheat Sheet recommends consistent messages and timing for existing and nonexistent accounts, cryptographically random single-use tokens that expire, and rate limits against automated requests. The account should not change until a valid token is presented.

Implement recovery around these rules:

1. Always return a neutral response such as “If an account exists, instructions have been sent.”
2. Generate a high-entropy token, store only a protected representation where practical, bind it to a user and purpose, and set a short expiry.
3. Invalidate it after one successful use and invalidate older reset tokens when a new one is issued.
4. Notify the account through an existing channel when the password, email, or factor changes.
5. Offer to revoke all sessions after recovery, and force revocation for high-risk cases.

Do not use knowledge questions. Personal facts are discoverable and users reuse answers. Support should not bypass recovery merely because a caller knows an invoice number or can sound convincing.

Treat factor replacement as a privileged action

MFA reduces risk only if replacing the factor is not easier than using it. The OWASP Multifactor Authentication Cheat Sheet recommends reauthentication before factor changes, risk-based checks, out-of-band notification, and careful recovery-code handling.

When a logged-in user adds or removes a factor, require a recent high-confidence authentication. Do not trust session age alone. If the original factor is unavailable, use pre-generated recovery codes, an administrative recovery process with strong verification, or another previously enrolled factor. Notify the user through a channel that the newly added factor cannot control.

Store recovery codes as secrets, display them once, and make every code single-use. A set of printable codes is more dependable than a support agent improvising identity verification during an incident.

Rotate, expire, and revoke sessions

A session identifier is temporary authority. The OWASP Session Management Cheat Sheet calls for regenerating the session ID after authentication and privilege changes. Sessions also need idle and absolute expiration, secure cookie properties, revocation, and protection against fixation.

Give users a “devices and sessions” view with approximate creation time, last activity, client context, and a revoke action. On the server, validate that the session remains active on sensitive requests rather than trusting a long-lived token until its natural expiry.

Define explicit revocation events: password reset, account recovery, suspicious-login response, administrator suspension, role removal, and organization removal. For an enterprise identity provider, decide what happens when its session ends or access is revoked. “Single sign-on” is not the same as instant application-session revocation unless the product implements that lifecycle.

Authorization must be checked on every request

Authentication answers who the user is. Authorization answers what that identity can do to this exact resource. A secure SaaS product denies by default and validates permissions on every request, consistent with the OWASP Authorization Cheat Sheet.

Never accept an organization ID from the client and assume it belongs to the current user. Query or mutate records through an authorization boundary that includes user, organization, role, resource, and action. Test object identifiers from another tenant. Test a removed member using an old browser tab. Test a downgraded admin with an existing session.

Role names alone are often too broad. Translate roles into specific capabilities such as invoice.read, member.invite, or workspace.delete, and protect especially dangerous actions with recent authentication or a second approver.

Support impersonation needs visible guardrails

Impersonation can help support reproduce a customer problem, but it creates a powerful internal access path. Stytch’s impersonation security guidance highlights role controls, limited duration, mandatory reasons, and audit logs.

A production-safe flow should:

• restrict initiation to a small role;
• require reauthentication and a ticket or reason;
• issue a short-lived, distinguishable session;
• display a persistent banner to the support agent;
• block high-risk actions such as password, MFA, billing, API-key, and data-export changes;
• record initiator, target, time, reason, and actions;
• notify or expose the event to the customer where appropriate.

Do not ask customers for passwords. Do not create a universal support password. If read-only diagnostic tooling can solve the problem, prefer it to impersonation.

Build a test matrix around transitions

Happy-path login tests are insufficient. Add automated and manual tests for transitions:

• two reset requests followed by use of the older token;
• reset-token reuse after success;
• email change from a stale session;
• MFA removal without the original factor;
• session use after password reset or account suspension;
• invite acceptance by the wrong email identity;
• access to another tenant’s resource by changing an ID;
• support impersonation attempting a blocked action;
• identity-provider outage and deprovisioning delay;
• backup-code reuse.

Log security events without logging passwords, reset tokens, session tokens, or full recovery codes. Alert on unusual recovery volume, repeated factor changes, impossible tenant access attempts, and high-risk support activity.

Next steps

Map every account transition, then choose the three with the weakest proof. Usually they are recovery, email change, and support access. Add recent reauthentication, explicit session revocation, user notification, and an audit event to each.

The quality of authentication is not measured by how difficult login is for a legitimate user. It is measured by whether every alternate path preserves the same identity, authorization, and recovery guarantees.