Confirm phone vs Phone number entry vs Confirm email vs Two-factor authentication vs Password reset

Choose confirm phone when a phone number has already been captured and the product must prove the user can receive a short-lived SMS or voice code before account activation, phone-number change, recovery eligibility, sensitive notification, or contact-route reliance continues.

Confirm phone live example Phone number entry live example Confirm email live example Two-factor authentication live example Password reset live example

Decision dimensions

Dimension	Confirm phone	Phone number entry	Confirm email	Two-factor authentication	Password reset
UI or UX	UI + UX - Phone reachability confirmation loop	UI + UX - Callable telephone contact capture field	UI + UX - Mailbox access confirmation loop	UI + UX - Additional-factor challenge and recovery flow	UI + UX - Account recovery and reset-token lifecycle
UI guidance	Render confirm phone as a code-confirmation loop with the target number when safe, channel, code entry, expiry, resend timing, change-number route, no-phone or no-access support, and verified-phone state.	Render phone entry as a labelled single-line field with number type in the label or hint, purpose and contact-timing text, type tel, autocomplete tel, field-specific errors, and review of both the user's displayed number and any dialable backend value.	Render confirm email as a mailbox-access proof loop with the target address, sent-message status, link or code instructions, expiry, resend timing, change-address route, pending or verified state, and clear blocking or non-blocking behavior.	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 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.
UX guidance	Use confirm phone only when the service must prove that the user can receive a text-message or voice code at the captured number before relying on it for activation, recovery, notification, or sensitive contact.	Use phone number entry when the product genuinely needs to call, text, verify, route, or recover contact with a user through a phone number.	Use confirm email when the service must know that the user can access the mailbox before activating an account, enabling recovery, sending sensitive notifications, accepting an invitation, or relying on the address for future access.	Use two-factor authentication when the product needs stronger proof after a password, passkey, SSO return, risk signal, new device, or sensitive action.	Use password reset when a user cannot authenticate with the existing password and needs a safe route back into the account without exposing whether the account exists.
Good UI	After account creation, the page says a 5-digit code was sent by text message to 07700 900982, shows the code expiry, accepts pasted digits with one-time-code autocomplete, and offers request-new-code and change-number actions.	An appointment service asks for UK mobile or international phone number, says it will call only if the appointment changes, uses type tel and autocomplete tel, and shows the number for review before saving.	After account creation, the page says We sent a confirmation link to maya@example.com, explains the link expires in 30 minutes, offers Resend email and Change email address, and returns to the draft after verification.	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 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.
Bad UI	A page says Enter code but hides which number received it and has no way to request another code or correct a typo.	A form stores phone as a number, removes the leading zero from 07700 900 982, and offers no way to correct the stored value.	The page says Check your inbox but hides which email address was used and has no resend or change-address action.	A page says Security check with one empty field, no factor label, no resend timing, and no recovery route.	The reset page says No account found for one email and Reset email sent for another.
Good UX	A user realizes the code was sent to a mistyped number, changes it, and receives a fresh code while the previous code can no longer verify the account.	A user pastes 07700 900 982, sees it preserved, reviews that calls may go to that number, and can choose email instead.	A user mistypes the address, notices the pending address on the confirmation page, changes it, receives a fresh link, and continues from the same account-activation step.	A user signs in from a new laptop, enters a code from an authenticator app, chooses not to trust the shared browser, and lands back on the requested workspace.	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.
Bad UX	A user waits for a text that never arrives and cannot resend, change the number, use voice, or contact support.	A user with an international number cannot type the plus sign because the field uses type number.	A user never receives the activation email and cannot resend, change the address, or continue in a limited pending state.	A user never receives an SMS code and can only keep pressing resend with no wait time, no alternate factor, and no support path.	A user mistypes their email and the form confirms the account does not exist, exposing account registration status.
Best fit	A captured phone number must be proven reachable before activation, contact-route reliance, recovery eligibility, phone-number change, or a sensitive action continues.	The product must capture a phone number for calls, texts, support callbacks, appointment changes, recovery, delivery coordination, verification, or contact records.	A user must prove access to a mailbox before account activation, invitation acceptance, recovery eligibility, or sensitive notifications.	A sign-in, new device, risk signal, or sensitive action requires proof beyond the primary credential.	Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable.
Avoid when	The product only needs to collect or review a phone number for low-risk contact.	The product only needs a name, label, username, reference, or other short text.	The email is only needed for a low-risk receipt, newsletter, or optional contact route.	The user is only choosing an authentication method on the initial sign-in page.	The user is merely signing in with a known current password or passkey.
Required state	Sent-code state with target phone number when safe, channel, purpose, code length, expiry, resend, and change-number or support action.	Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording.	Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.	Initial additional-factor challenge with factor name, destination or protected action, and primary account context.	Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.
Accessibility burden	Use a clear heading such as Check your phone and label the code input as a security code or phone confirmation code.	Use a visible label and hint that state the number type, purpose, and any contact timing.	Use a clear heading such as Confirm your email address and show the pending email address as text.	Use a clear heading and label that names the factor and does not rely on placeholder-only code fields.	Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier.
Common misuse	Treating phone-number format validation as proof that the user can receive texts or calls.	Using type number and losing leading zeros or plus signs.	Forcing email confirmation when the service only needs a low-risk contact or receipt address.	Showing a code field with no factor label, destination, expiry, resend timing, or alternate method.	Confirming whether an email, username, phone number, or account exists.

Confirm phone

UI or UX: UI + UX - Phone reachability confirmation loop
UI guidance: Render confirm phone as a code-confirmation loop with the target number when safe, channel, code entry, expiry, resend timing, change-number route, no-phone or no-access support, and verified-phone state.
UX guidance: Use confirm phone only when the service must prove that the user can receive a text-message or voice code at the captured number before relying on it for activation, recovery, notification, or sensitive contact.
Good UI: After account creation, the page says a 5-digit code was sent by text message to 07700 900982, shows the code expiry, accepts pasted digits with one-time-code autocomplete, and offers request-new-code and change-number actions.
Bad UI: A page says Enter code but hides which number received it and has no way to request another code or correct a typo.
Good UX: A user realizes the code was sent to a mistyped number, changes it, and receives a fresh code while the previous code can no longer verify the account.
Bad UX: A user waits for a text that never arrives and cannot resend, change the number, use voice, or contact support.
Best fit: A captured phone number must be proven reachable before activation, contact-route reliance, recovery eligibility, phone-number change, or a sensitive action continues.
Avoid when: The product only needs to collect or review a phone number for low-risk contact.
Required state: Sent-code state with target phone number when safe, channel, purpose, code length, expiry, resend, and change-number or support action.
Accessibility burden: Use a clear heading such as Check your phone and label the code input as a security code or phone confirmation code.
Common misuse: Treating phone-number format validation as proof that the user can receive texts or calls.

Phone number entry

UI or UX: UI + UX - Callable telephone contact capture field
UI guidance: Render phone entry as a labelled single-line field with number type in the label or hint, purpose and contact-timing text, type tel, autocomplete tel, field-specific errors, and review of both the user's displayed number and any dialable backend value.
UX guidance: Use phone number entry when the product genuinely needs to call, text, verify, route, or recover contact with a user through a phone number.
Good UI: An appointment service asks for UK mobile or international phone number, says it will call only if the appointment changes, uses type tel and autocomplete tel, and shows the number for review before saving.
Bad UI: A form stores phone as a number, removes the leading zero from 07700 900 982, and offers no way to correct the stored value.
Good UX: A user pastes 07700 900 982, sees it preserved, reviews that calls may go to that number, and can choose email instead.
Bad UX: A user with an international number cannot type the plus sign because the field uses type number.
Best fit: The product must capture a phone number for calls, texts, support callbacks, appointment changes, recovery, delivery coordination, verification, or contact records.
Avoid when: The product only needs a name, label, username, reference, or other short text.
Required state: Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording.
Accessibility burden: Use a visible label and hint that state the number type, purpose, and any contact timing.
Common misuse: Using type number and losing leading zeros or plus signs.

Confirm email

UI or UX: UI + UX - Mailbox access confirmation loop
UI guidance: Render confirm email as a mailbox-access proof loop with the target address, sent-message status, link or code instructions, expiry, resend timing, change-address route, pending or verified state, and clear blocking or non-blocking behavior.
UX guidance: Use confirm email when the service must know that the user can access the mailbox before activating an account, enabling recovery, sending sensitive notifications, accepting an invitation, or relying on the address for future access.
Good UI: After account creation, the page says We sent a confirmation link to maya@example.com, explains the link expires in 30 minutes, offers Resend email and Change email address, and returns to the draft after verification.
Bad UI: The page says Check your inbox but hides which email address was used and has no resend or change-address action.
Good UX: A user mistypes the address, notices the pending address on the confirmation page, changes it, receives a fresh link, and continues from the same account-activation step.
Bad UX: A user never receives the activation email and cannot resend, change the address, or continue in a limited pending state.
Best fit: A user must prove access to a mailbox before account activation, invitation acceptance, recovery eligibility, or sensitive notifications.
Avoid when: The email is only needed for a low-risk receipt, newsletter, or optional contact route.
Required state: Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.
Accessibility burden: Use a clear heading such as Confirm your email address and show the pending email address as text.
Common misuse: Forcing email confirmation when the service only needs a low-risk contact or receipt address.

Two-factor authentication

UI or UX: UI + UX - Additional-factor challenge and recovery flow
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.
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.
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.
Bad UI: A page says Security check with one empty field, no factor label, no resend timing, and no recovery route.
Good UX: A user signs in from a new laptop, enters a code from an authenticator app, chooses not to trust the shared browser, and lands back on the requested workspace.
Bad UX: A user never receives an SMS code and can only keep pressing resend with no wait time, no alternate factor, and no support path.
Best fit: A sign-in, new device, risk signal, or sensitive action requires proof beyond the primary credential.
Avoid when: The user is only choosing an authentication method on the initial sign-in page.
Required state: Initial additional-factor challenge with factor name, destination or protected action, and primary account context.
Accessibility burden: Use a clear heading and label that names the factor and does not rely on placeholder-only code fields.
Common misuse: Showing a code field with no factor label, destination, expiry, resend timing, or alternate method.

Password reset

UI or UX: UI + UX - Account recovery and reset-token lifecycle
UI guidance: 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.
UX guidance: Use password reset when a user cannot authenticate with the existing password and needs a safe route back into the account without exposing whether the account exists.
Good UI: 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.
Bad UI: The reset page says No account found for one email and Reset email sent for another.
Good UX: 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.
Bad UX: A user mistypes their email and the form confirms the account does not exist, exposing account registration status.
Best fit: Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable.
Avoid when: The user is merely signing in with a known current password or passkey.
Required state: Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.
Accessibility burden: Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier.
Common misuse: Confirming whether an email, username, phone number, or account exists.

Decision rules

Choose confirm phone when a phone number has already been captured and the product must prove the user can receive a short-lived SMS or voice code before account activation, phone-number change, recovery eligibility, sensitive notification, or contact-route reliance continues.
Choose phone number entry when the problem is collecting, formatting, validating, explaining, reviewing, or changing the number string before any proof of access to that phone exists.
Choose confirm email when the product must prove access to a mailbox through an email link or code rather than reachability of a phone number.
Choose two-factor authentication when an already enrolled factor is required to authenticate or authorize access; phone confirmation can be one enrollment or challenge path, but SMS and voice have restricted-authenticator risk that requires alternatives and notice at higher assurance.
Choose password reset when the code or message replaces a forgotten password through a recovery artifact rather than confirming an ordinary phone contact route.
A confirm-phone flow should show the target number when safe, the channel used, code length, expiry, resend wait, change-number path, voice or other alternative, no-phone recovery, and verified-phone state.
Phone confirmation codes should be time-limited, rate-limited, bound to the phone number and purpose, invalidated when the number changes, and protected from logs, analytics, support transcripts, and visible replay.
Successful phone confirmation should update verified-phone state separately from number syntax, dialability, SMS capability, account sign-in, and two-factor enrollment.

Inspect live examples

Confirm phone Phone number entry Confirm email Two-factor authentication Password reset

Failure modes

The service treats a syntactically plausible phone number as verified phone access.
A user cannot change a mistyped number after the text message is sent.
A landline, shared phone, inaccessible phone, or no-phone user is forced into an SMS-only path with no voice or support alternative.
The code expires or too many attempts fail, but the page gives no resend, wait, or help route.
The flow labels SMS confirmation as strong MFA without explaining PSTN risk or offering unrestricted alternatives.
A previous code remains valid after the user changes the phone number.