Every day billions of six-digit codes travel across the planet so that someone can prove they hold a particular phone. The one-time password (OTP) is so familiar that it is easy to forget how many moving parts sit behind it. If you build signup flows, test them, or simply want to understand what happens when you tap Send code, this guide walks through the whole chain.
What an OTP is — and what it is not
An OTP is a short secret that is valid once, for a short window. That is the whole point: even if someone sees the code after you have used it, it is worthless. Compare that with a password, which is valid indefinitely until changed.
OTPs show up in three main jobs:
- Possession checks at signup — "prove this phone number is yours" before an account is created.
- Second factor at login — something you have (the phone) on top of something you know (the password).
- Transaction confirmation — banks and wallets ask for a fresh code before moving money; under Europe's PSD2 rules this is part of strong customer authentication.
An OTP is not encryption and it is not identity proof on its own. It only shows that, at a given moment, someone could read messages sent to a specific number or device.
The two families: counter-based and time-based
Most codes you see come from one of two open standards:
- HOTP (RFC 4226) derives each code from a shared secret plus an incrementing counter. Every time a code is generated, the counter moves forward. The server accepts a small look-ahead window in case the user generated a code without using it.
- TOTP (RFC 6238) replaces the counter with the current time, usually sliced into 30-second steps. Authenticator apps such as Google Authenticator or 1Password use TOTP. Because both sides know the time, nothing needs to be transmitted — the code is computed locally.
Both run the secret and the moving factor through HMAC, then truncate the result into a human-friendly number of digits.
Where SMS fits in
SMS OTPs are different: the server simply generates a random code, stores a hash of it with an expiry, and texts it to you. There is no shared secret on the phone at all — the security rests on the assumption that only the number's holder receives the message.
A typical server-side flow looks like this:
- User submits a phone number.
- Server creates a random 6-digit code, stores
hash(code), the number, an expiry (often 5–10 minutes) and an attempt counter. - An SMS gateway delivers the text through carriers.
- User types the code; the server compares hashes, checks expiry and attempts, then marks the code used.
The weak points are delivery (carrier filtering, delays, international routing) and the phone number itself (SIM-swap, number recycling). That is why standards bodies such as NIST classify SMS as a restricted authenticator — acceptable, but not the strongest option for high-value accounts.
Why SMS still dominates
If authenticator apps and passkeys are stronger, why does almost every app still send an SMS?
- Universal reach. Every phone can receive a text. Not every user will install an authenticator.
- Zero setup. The user does nothing until the code arrives.
- Identity signal. A phone number is a scarce, semi-verified identifier, which makes mass fake signups more expensive.
- Regulatory familiarity. Banks, payment providers and marketplaces have years of compliance processes built around SMS.
For product teams, SMS OTP is the lowest-friction way to put a real-world cost on account creation.
Good practice for teams that send OTPs
If you are on the sending side, a few habits separate a robust flow from a fragile one:
- Hash codes at rest and compare in constant time.
- Expire quickly — five minutes is plenty for most flows.
- Limit attempts per code and per number, and rate-limit the send endpoint by IP, device and destination prefix.
- Bind the code to the action: a code issued for "change email" must not unlock "withdraw funds".
- Offer stronger factors (passkeys, TOTP) for users who want them, and fall back to SMS rather than the other way around.
- Watch for SMS pumping — sudden bursts of sends to premium or unusual country ranges. We cover that in detail in our SMS fraud guide.
Where temporary numbers come in
On the receiving side, many people do not want to hand their personal number to every app they try, and developers need clean numbers to test signup flows without burning their own SIM. That is exactly what a temporary number service is for: you rent a real mobile line for one verification, read the SMS in a web inbox, and the number goes back to the pool.
OTP Bolt does this across 200+ countries with a live inbox and automatic refunds when a code never arrives. If you test regularly, the developer API lets you rent a number, poll for the code and close the activation from your own scripts.
Key takeaways
- An OTP is valid once and briefly; its job is to prove possession at a moment in time.
- HOTP and TOTP compute codes from a shared secret; SMS OTPs are random codes delivered over the phone network.
- SMS is weaker than app-based factors but remains the most widely used because it is universal and frictionless.
- Senders should hash, expire, rate-limit and bind codes to actions; receivers can use temporary numbers to protect privacy and to test flows realistically.