Use two-factor authentication for the additional-factor challenge, recovery, trusted-device, and factor-management states; use sign in for the broader returning-access journey, login for submitted credential outcomes, and password reset for replacing a forgotten password through a recovery artifact.
Use two-factor authentication for the additional-factor challenge, recovery, trusted-device, and factor-management states; use sign in for the broader returning-access journey, login for submitted credential outcomes, and password reset for replacing a forgotten password through a recovery artifact.
Practice the judgment: Imagine this situation: The app lets users skip the second factor by changing the URL, using Back, opening another tab, or calling the protected endpoint directly. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Two-factor authentication | Sign in | Login | Password reset | Password input |
|---|---|---|---|---|---|
| UI or UX | UI + UX - Additional-factor challenge and recovery flow | UI + UX - Returning-account authentication and session start flow | UI + UX - Credential-verification attempt lifecycle and login outcome handling | UI + UX - Account recovery and reset-token lifecycle | UI + UX - Authentication secret entry control |
| UI guidance | Render two-factor authentication as a focused additional-factor challenge with factor name, destination or protected action, delivery hint, code or approval input, resend timing, alternate factor, recovery-code route, trusted-device choice, and safe failure handling. | Render sign in as a focused authentication surface with a clear service or destination name, account identifier field, current-password or passkey path, password-manager-friendly attributes, recovery routes, create-account route, and neutral error area. | Render login as the outcome-sensitive credential verification state: pending verification, neutral failure, remaining attempts or wait time when policy allows, throttling or lockout state, unlock or recovery route, and successful session-created confirmation. | Render password reset as a recovery journey with a neutral request form, reset delivery confirmation, token or code validation, expired and already-used link states, new-password handoff, session cleanup choices, and post-reset notification. | Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input. |
| UX guidance | Use two-factor authentication when the product needs stronger proof after a password, passkey, SSO return, risk signal, new device, or sensitive action. | Use sign in when users are returning to an existing account, protected resource, invitation, draft, checkout, or workspace and need to prove control of an authenticator. | Use login when users have already chosen an authentication route and submitted credentials or an authenticator output, and the product must explain the verification result safely. | Help legitimate users recover by making the next step visible, preserving privacy with neutral copy, rate-limiting repeated requests, handling expired links cleanly, and explaining what happens to active sessions after the reset. | Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership. |
| Good UI | A code screen says Enter the 6-digit code from your authenticator app to continue to payroll settings, uses autocomplete one-time-code, shows Try another method, and explains recovery codes. | A sign-in page names the workspace, shows email or username, password with current-password autocomplete, passkey option, forgot-password link, create-account link, and a destination reminder such as Continue to Q2 budget review. | After a failed login, the page keeps the email address, clears the password, shows Check your details and try again, gives 2 attempts remaining, and keeps forgot password and use passkey routes available. | A forgot-password page asks for email, then always shows If an account uses this email, we sent reset instructions, with resend timing and a support route. | A reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt. |
| Bad UI | Attackers bypass the prompt through a direct endpoint, cached page, or remembered browser weakness. | A failed sign-in says This email exists but the password is wrong, exposing account status. | Account enumeration through differentiated login outcomes. | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. | A login form uses a normal text field named Password and leaves the secret visible on screen. |
| Good UX | A user lost the phone, uses a single-use recovery code, receives a notification, and is prompted to add a replacement factor after reauthentication. | A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation. | A user mistypes the password twice, sees remaining attempts and a neutral account-details error, uses a passkey instead, and reaches the intended workspace with retry warnings cleared. | A user enters their email, sees a neutral delivery confirmation, opens a time-limited link, creates a new password, chooses to sign out other sessions, and receives a reset notification. | The person reaches the intended result with clear feedback. |
| Bad UX | Attackers bypass the prompt through a direct endpoint, cached page, or remembered browser weakness. | A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context. | Account enumeration through differentiated login outcomes. | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. | A failed login page says the password is wrong, confirming that the username exists. |
| Best fit | A sign-in, new device, risk signal, or sensitive action requires proof beyond the primary credential. | Users need to access an existing account or protected destination. | Users have submitted credentials or authenticator output and need a safe verification result. | Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable. | The user needs to enter an existing password, passphrase, or PIN-like memorized secret. |
| Avoid when | The user is only choosing an authentication method on the initial sign-in page. | The user is creating a new account, choosing a new password, or verifying a new contact method. | The problem is choosing an authentication method or explaining why authentication is required before credentials are submitted. | The user is merely signing in with a known current password or passkey. | The task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection. |
| Required state | Initial additional-factor challenge with factor name, destination or protected action, and primary account context. | Initial sign-in state with service or destination context. | Ready-to-submit login state with chosen identifier and authenticator route. | Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in. | Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control. |
| Accessibility burden | Support paste into one field for codes and avoid multi-field inputs that trap focus or break screen-reader reading order. | Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts. | Keep retry, recovery, unlock, support, and accessible challenge alternatives reachable by keyboard. | Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier. | Use a visible label that names the password purpose, such as Password or Current password. |
| Common misuse | Blocking paste or autocomplete for one-time codes. | Using account-specific error messages that reveal whether an identifier exists. | Returning different messages for unknown account, wrong password, disabled account, or locked account. | Confirming whether an email, username, phone number, or account exists. | Using type text for passwords. |