One-time passcode
A text field paired with CTAs enabling users to a request single-use code to authenticate a transaction or session.
One-time passcodes (OTP) are a set of random numbers generated by the system. They allow users to authenticate their account for a single transaction or session by entering their code into an input field.
Also known as: Verification codes, two-factor authentication (2FA) code.
Anatomy
A. Label (required): Text indicating the purpose of the field.
B. Input (required): Text field for users to enter the one-time passcode.
C. Inline message (optional): Text communicating format requirements or relevant guidance.
D. Call to action (required): Button component enabling users to submit the code and proceed.
E. Resend option (required): Text and link allowing users to request a new code if needed.
Usage
| When to use | When not to use |
|---|---|
| To allow users to authenticate a single transaction or session. | For systems where users need continuous access and shouldn’t be interrupted by cumbersome authentication processes. |
| For scenarios requiring additional security beyond a standard password authentication, such as two-factor or multi-factor authentication, account recovery, secure financial transactions, and remote access. | For high-risk scenarios where an OTP might not provide sufficient security. For low-security scenarios or environments where the risk of unauthorized access is low. |
Best practices
- Enable the passcode to be copied from the verification method and pasted in the interface requesting the code.
- Enable auto-detection or auto-population of the passcode input field, where possible.
- Enable users to specify their preferred verification method, which is typically a phone number or email. Consider including the user’s email automatically as a verification method if it’s already associated with their account.
- Only include numbers in the generated one-time passcode.
- Don’t use the term PIN when referring to one-time passcodes. PINs are specific to recurring identification codes for ATM transactions or debit cards.
- Follow all best practices for Input, Button, and Link when implementing those items in the one-time passcode pattern.
Do Mask personally identifiable information (PII), such as the user’s phone number or email address.
Don't Expose the user’s phone number or email address, as this can make it easier for fraudulent users to access the account.
Do Expose the OTP digits in the input field.
Don't Mask the OTP digits in the input field.
Do Communicate important supplementary information using inline messaging.
Don't Obstruct the main content with supplementary information.
Behaviors
OTP supports several features including new code requests, a resend countdown timer, and OTP code auto-population.
New OTP requests
When a user needs to request a new OTP, they select the “Send code” button to receive a one-time passcode. This sends a unique code to the user’s preferred verification method. Users can then enter the passcode to verify their account.
- Provide clear next steps if the user enters an incorrect code, such as reminding them to re-check the code they received.
Resend requests
Users may request a new code using the “Resend” link if they didn’t receive the initial OTP. Users can choose to verify their identity through the same method they used the first time or choose a different method. For security reasons, limit new code requests to three attempts to prevent fraudulent users from accessing sensitive data or account credentials.
- Limit the number of new code requests to three attempts.
- Ensure each generated OTP is a unique set of numbers.
- Provide clear next steps if the user has exceeded the number of allowed OTP requests, such as offering a technical support contact method.
Resend timer
The resend timer creates a buffer between how often users can request for their OTP to be resent. This is referred to as debouncing, and it prevents users from creating duplicate resend code requests.
- Remove the “Resend” link and implement a thirty-second countdown timer after the user requests a new code.
- Enable users to request a new code after 30 seconds, if they haven’t reached their maximum number of attempts.
Input methods
The OTP can be filled automatically or manually by the user. Automatic input, which auto-fills the OTP from a text message or app notification, is convenient and fast. Manual input, where the user types in the OTP themselves, offers more control and can be a fallback if automatic input fails.
- Display the keyboard when the OTP screen appears, reducing the need for user interaction.
- Maintain a seamless input experience if the user minimizes or switches screens by reactivating the keyboard upon return.
- Keep essential information visible when the keyboard is displayed, ensuring important content like the input field, instructions, or error messages aren’t obscured.
Content
- Use a minimum of four digits and maximum of eight digits for the OTP. The default code is set to six digits.
- Use clear, actionable language for call-to-action labels.
Inline message
- Limit all inline messages (including errors) to one to two short sentences with punctuation.
- Use inline messages to provide additional guidance such as format or specific syntax or values to help avoid errors.
- Provide concise, descriptive, and helpful guidance about the field’s usage and necessity, avoiding technical jargon.
Inline error message
- Use inline error messages to draw attention to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
Platform considerations
OTP flows have been designed for both web and mobile platforms. Examples of each can be found in our Task flows (internal only).
