A one-time password (OTP) is a short numeric code that is valid for a single login or action and only for a few minutes. You send it to a channel the user controls, usually their phone number, and they type it back to prove they hold that channel. It is possession-based verification, not a permanent secret like a password.
This guide explains what an OTP is, the rules that make it safe, how it is delivered, the attacks it faces, and how to implement a flow without reinventing the parts that are easy to get wrong.
What does an OTP actually verify?
An OTP proves that whoever is completing an action can receive messages on a specific channel right now. That is a narrower claim than "this is the right person", and it is worth being precise about it.
- It proves current control of a phone number, email address or app, not identity.
- It acts as a second factor (something you have) on top of a password, or as the primary factor in passwordless login.
- It is single use and time boxed, so a stolen code is worthless minutes later.
Because it only proves channel control, an OTP is strongest when combined with other signals such as a password, device history or a risk score.
How long should a code be, and how long should it live?
The specifications are clear, and it is better to follow them than to guess.
- RFC 4226 (HOTP), checked 22 October 2026, requires at least six digits; many systems use six to eight.
- NIST SP 800-63B, checked 22 October 2026, says an out-of-band code must be at least six digits, the attempt is invalid unless completed within 10 minutes, and each code is single use.
- NIST also says verifiers must rate limit failed attempts, with a default cap of 100 consecutive failures, and that issuing a new code does not reset the failure count.
- RFC 6238 (TOTP), for authenticator-app codes, recommends a 30 second time step and forbids accepting the same code twice after a success.
In plain terms: six digits, a short expiry (many teams use two to five minutes for SMS so a slightly late message still works), single use, and a hard cap on wrong guesses per code and per account.
How is an OTP delivered?
The code has to travel over a channel the user can read quickly, and each channel has trade-offs.
- SMS: the widest reach, works on any phone, but it can be delayed, intercepted, or expensive on some routes.
- WhatsApp: rich and low cost where it is installed; Meta authentication templates use fixed preset text and can offer one-tap autofill on Android.
- Voice call: reads the code aloud, which helps feature phones, low-literacy users, or cases where SMS is failing.
- Email: cheap and global, but slower and more phishable, so it fits as a fallback or for lower-risk actions.
- M-PESA and mobile money: in markets like Kenya a payment prompt can double as a verification step.
A robust system does not pick one channel and hope. It falls back: try SMS, and if it fails or is not entered in time, try voice or WhatsApp with the same code.
What attacks does an OTP face?
Knowing the failure modes tells you which controls to add.
- SIM swap: an attacker moves the victim's number to a new SIM and receives the SMS code. A carrier account PIN and watching for sudden loss of signal help.
- SS7 and number porting: OWASP's multi-factor guidance notes that SMS and PSTN codes can be intercepted through SS7 and advises against SMS for high-value applications, and NIST SP 800-63B treats SMS and voice verification as restricted, meaning you should also offer a stronger alternative.
- Phishing relays: a fake site asks for the code and replays it to the real site in real time. A short expiry and binding the code to the original session shrink the window.
- SMS pumping (artificially inflated traffic): bots hammer your send endpoint to generate paid messages to number ranges where a complicit party shares the termination fee. Defences include rate limits, a CAPTCHA on suspicious traffic, country allowlists, and spend caps.
How do you implement an OTP flow safely?
The send and verify endpoints are simple; the safety is in the rules around them.
- Generate the code with a cryptographically secure random function, not a predictable sequence.
- Store only a hash of the code, together with its expiry and attempt counter, never the plain code.
- Make the code single use: invalidate it the moment it verifies.
- Rate limit sends per number, per IP and per device, and add a resend cooldown.
- Cap wrong attempts per code and per account, and do not reset that count when a new code is issued.
- Make sends idempotent so a double tap does not fire two messages or two charges.
- Normalise phone numbers to E.164 before sending.
- Log every send and verify result so you can watch delivery health and spot abuse.
Teams that build all of this in-house usually end up rebuilding fallback, rate limiting, delivery tracking and per-country routing. That is the work a verification API removes.
When should you move beyond SMS OTP?
SMS OTP is still useful, especially in markets where it is the only channel that reaches everyone. For high-value accounts, follow the standards: offer a stronger factor such as an authenticator app (TOTP), a push approval, or a passkey, and keep SMS as a fallback rather than the only line of defence. The right design is usually layered, not a single channel.
If you would rather not build and maintain all of this, Tambua, our OTP verification API for Africa, sends and verifies codes across SMS, WhatsApp, voice, email and M-PESA, with an automatic fallback journey of up to three channels that reuses the same code, signed HMAC-SHA256 webhooks, and free test keys that return the code in the API response so you can build without sending real messages. You pay only for carrier-accepted attempts, not failed ones. The API reference lives under /docs, and if you are weighing options, see our provider comparisons under /compare, such as /compare/africas-talking. That is the idea behind Tambua: OTPs without the complexity.