A one-time password (OTP) is a short code, usually six to eight digits, that is valid for one sign-in or a short time window and then expires. It is typically used as the second factor in two-factor authentication (2FA): the user enters their password, then a code sent by text message or email, or generated by an authenticator app or hardware token. Because each code is single-use, a stolen code is of little value later, though it can still be phished in real time.
At a glance
- A code that is valid once or for a short window, used alongside a password.
- Delivered by SMS, voice call or email, or generated on the user’s device from a shared secret.
- The open algorithms are HOTP (counter-based, RFC 4226) and TOTP (time-based, RFC 6238).
- Stops reuse of stolen passwords, but codes can be phished or intercepted, so OTP is not phishing-resistant MFA.
- Still widely used as a fallback and for systems that don’t support stronger methods.
What problem it solves
A password can be reused indefinitely once stolen. An OTP adds something that changes every time, so an attacker who has the password still needs the current code. That defeats most automated attacks with leaked passwords and makes accounts much harder to take over at scale.
OTP methods are also widely compatible. Almost any phone can receive a text or run an authenticator app, and many older applications, VPNs and network devices accept codes even when they don’t support security keys or passkeys.
How it works
OTPs are either generated on the user’s device from a secret shared with the service, or generated by the service and sent to the user.
Types
| Type | How the code is produced | Typical use | Main weaknesses |
|---|---|---|---|
| SMS or voice OTP | The service generates a code and sends it to the user’s phone number | Consumer accounts, fallback methods | SIM swaps, number porting fraud, interception, phishing |
| Email OTP | The service sends a code or link by email | Account verification, low-risk sign-in | Depends on the email account’s security; phishing |
| TOTP (time-based) | An app or token computes a code from a shared secret and the current time, usually every 30 seconds | Authenticator apps, many workforce MFA setups | Phishing in real time; secret exposed if enrollment QR code is captured |
| HOTP (counter-based) | A token computes a code from a shared secret and a counter that advances each use | Some hardware tokens and older systems | Phishing; counters can drift out of sync |
Generated codes. For TOTP and HOTP, the service and the user’s app or token share a secret, usually set up by scanning a QR code. Both sides run the same calculation, a keyed hash of the secret and the time step or counter, and shorten the result to a numeric code. The service checks whether the code matches what it expects. The RFCs use HMAC-SHA-1 by default, allow stronger hashes for TOTP, and recommend that servers accept a code only once, tolerate small clock or counter drift, and limit failed attempts.
Sent codes. For SMS, voice and email, the service generates a random code, stores it briefly and sends it to the user. Security depends on the delivery channel as much as the code.
Policy. Your identity provider usually decides which OTP methods are allowed and for whom. Many organizations disable SMS and voice for staff, allow app-generated codes as a step up, and require stronger methods for administrators.
When it matters for buyers
- When setting MFA policy. Decide which OTP methods to allow, and whether SMS remains as a fallback.
- For legacy systems. Some VPNs, network devices and older apps accept only codes, often via RADIUS; check whether they can use your identity provider instead.
- For high-risk users. OTP stops password reuse but not real-time phishing; admins and finance staff often need phishing-resistant methods. Training users to spot fake login pages and smishing helps too.
- When planning recovery. Phone changes are the most common cause of lost OTP access; decide how codes are moved or reset.
- At insurance and audit time. Questionnaires may ask which MFA methods you use, not just whether you have MFA.
Questions to ask vendors
- Which OTP methods do you support, and can we disable SMS, voice or email codes for some users?
- Do you support TOTP from third-party authenticator apps, hardware OTP tokens, or both?
- What rate limiting and lockout apply to failed code entries?
- How are OTP secrets protected on your side, and how are they enrolled and re-enrolled?
- Can systems that only accept codes, such as our VPN, use your service?
- What phishing-resistant methods can replace OTP for high-risk users?
How it differs from an authenticator app
An OTP is the code itself; an authenticator app is one place codes come from. Authenticator apps usually generate TOTP codes, but many also offer push approvals and, increasingly, passkeys, which are not one-time passwords at all. OTPs can also arrive by text or email, or come from a hardware token, with no app involved. To help staff recognize fake login pages that collect codes, see our security awareness training overview.