Two-factor authentication

Problem Context

• The user has completed or started a primary sign-in step, returned from SSO, triggered a risk rule, opened a new device, or started a sensitive action.
• The product may support authenticator apps, SMS or email codes, push approvals, passkeys, hardware keys, backup codes, trusted devices, remembered browsers, or administrator recovery.
• Second-factor prompts can arrive during ordinary sign in, transaction authorization, account settings, factor enrollment, factor change, or recovery after device loss.
• MFA security depends on server-side enforcement; the UI cannot let users bypass the challenge through navigation, cached pages, API calls, or alternate tabs.
• Users may have no signal, a changed phone, a lost device, a new browser, an inaccessible challenge, or a recovery code stored separately from the device.

Selection Rules

• Choose two-factor authentication when the user must satisfy an additional factor after a primary credential, SSO return, passkey flow, risk signal, new device, or sensitive action.
• Use sign in for the broader authentication entry route that chooses identifiers, passwords, passkeys, SSO, recovery, and return destinations.
• Use login for the submitted credential result before a second factor is requested or after the factor result returns.
• Use password reset when the user cannot authenticate with the existing password and needs to replace it through recovery.
• Use password input only for reusable password entry; second-factor codes and recovery codes need their own autocomplete, expiry, resend, and attempt-limit behavior.
• Name the requested factor, protected destination or action, delivery channel hint, expected code length or approval device, and safe alternative methods.
• Allow paste, autofill, password-manager code fill, and native one-time-code behavior for short-lived codes.
• Show resend wait time, attempt limits, expired-code state, wrong-code state, and rate-limit state from server policy.
• Offer enrolled alternate factors, recovery codes, and support escalation without turning recovery into an easier path than the second factor.
• Make remember-device choices explicit, scoped to a browser or device, time-limited when policy requires, and revocable from account settings.
• Require reauthentication, existing factor proof, recovery-code use, or stronger support verification before disabling MFA, adding a new factor, or changing the recovery channel.
• After success, clear challenge state, record security events, notify when policy requires, and return to the original destination or sensitive action.

Required States

• Initial additional-factor challenge with factor name, destination or protected action, and primary account context.
• One-time-code entry state with autocomplete one-time-code, paste support, expiry hint, and submit control.
• Push approval or hardware-key waiting state with clear device or key instruction and fallback.
• Resend-limited state with wait time and delivery-channel hint.
• Wrong-code state with remaining attempts and no code echo.
• Expired-code state with resend or try-another-method action.
• Alternate-factor selection state limited to enrolled methods.
• Recovery-code state that treats each backup code as single-use and security-sensitive.
• Trusted-device choice state with scope, duration, and revocation explanation.
• Success state that returns to the protected task and clears challenge warnings.
• Lost-factor or support-required state with stronger identity verification.
• Factor-management state for add, remove, replace, or regenerate recovery codes.

Interaction Contract

• The challenge appears only when the server requires additional verification and the protected action remains blocked until success.
• The UI names the factor and destination without exposing unnecessary account details on shared screens.
• Code entry supports paste, autofill, correction, and screen-reader announcements without splitting focus into inaccessible traps.
• Wrong, expired, reused, or rate-limited codes are handled as distinct recoverable states without displaying the submitted secret back to the user.
• Alternate methods only list enrolled factors or approved recovery routes, not unverified contact details an attacker can add during the challenge.
• Recovery codes are single-use, rate-limited, treated as secrets, and followed by notification or factor-replacement guidance.
• Remember-device choices do not default on shared or risky contexts and can be reviewed or revoked later.
• Successful verification clears transient challenge state and returns to the sign-in destination or sensitive action.

Implementation Checklist

• Define factor types, assurance requirements, phishing-resistant options, code length, expiry, attempt limits, resend limits, recovery-code format, trusted-device scope, and factor-management policy with security owners.
• Map authenticator app, SMS, email, push, passkey, hardware key, recovery code, lost device, and support-assisted states to clear UI copy and server outcomes.
• Use autocomplete one-time-code for short-lived codes and test paste, autofill, password-manager fill, mobile keyboards, browser Back, refresh, and multiple tabs.
• Enforce MFA on protected endpoints, not only in the UI route, and test direct URL navigation, API access, cached pages, remembered devices, and session fixation cases.
• Protect codes, recovery codes, device identifiers, push details, and failure reasons from analytics, logs, screenshots, support tools, and URLs.
• Test wrong code, expired code, reused recovery code, resend rate limit, alternate method, lost device, disabled factor, factor change, trusted-device revocation, high-risk account, screen reader flow, and mobile layout.

Common Generated-UI Mistakes

• Showing a code field with no factor label, destination, expiry, resend timing, or alternate method.
• Blocking paste or autocomplete for one-time codes.
• Letting users bypass MFA through browser Back, deep links, cached pages, API calls, or another tab.
• Treating SMS as the only possible second factor for all users and all risk levels.
• Allowing recovery codes to be reused, stored like ordinary text, or regenerated without stronger verification.
• Defaulting remember-device on public or shared computers.
• Allowing factor removal, phone change, or authenticator replacement with only the password.
• Logging codes, recovery codes, push details, or exact failure reasons.

Critique Questions

• Which second factor is required here, and why is it being requested for this destination or action?
• Can users complete the challenge with paste, autofill, hardware keys, passkeys, mobile keyboards, and assistive technology?
• What are the server-backed expiry, resend, wrong-code, and rate-limit states?
• Can the challenge be bypassed through navigation, cached pages, API calls, remembered devices, or alternate tabs?
• Which recovery paths are available, and are they at least as protective as the factor they replace?
• How are trusted devices scoped, timed, displayed, and revoked?
• What proof is required before adding, removing, or replacing factors?