At first, I thought the problem was simple: generate a 6-digit code, send it to the user, and verify it.

But the more I worked on it, the more I realized that OTP security is not really about the code itself.

It is about the channel, the context, and the system around it.

You can see the same idea today in financial systems. Many banks are moving away from SMS OTPs toward in-app approvals, not because OTP stopped working, but because SMS became a weaker place to put trust.

That was the first lesson:

OTP is not a vendor feature. It is a verification pattern.

Once you understand it this way, the problem becomes bigger than sending a 6-digit code.

You may need OTP for login, phone verification, password reset, transaction approval, device binding, or confirming a sensitive action.

And you may need to deliver it through SMS, email, WhatsApp, Telegram, push notifications, an in-app secure channel, or even an internal enterprise communication system.

Sometimes a vendor solves exactly what you need.

Sometimes it solves only the delivery part.

And sometimes your product has requirements that do not fit neatly into the vendor's predefined flow.

So at first, the task sounded simple:

1. Generate a 6-digit code.
2. Send it to the user.
3. Verify it when they enter it.

That's it, right? Not really.

The moment this flow becomes part of your system, it stops being "just sending a code."

Suddenly, you have to think about what happens when someone keeps requesting OTPs for the same phone number.

• What happens if they try to brute-force the code?
• What if an old code is still valid?
• What if the same code can be reused?
• What if your API response accidentally leaks whether a phone number exists in your system?
• What if attackers abuse your OTP endpoint and burn your SMS or messaging budget?

That was the second lesson:

The hard part of OTP authentication is not generating the code. The hard part is designing the system around it.

In this article, I'll break down the engineering decisions behind building a secure OTP system from scratch, not because every team should rebuild what providers already offer, but because understanding these decisions helps you design, evaluate, and secure OTP flows properly, whether you build the system yourself or use a vendor.

The Naive OTP Implementation

The first version of sequential flow most developers imagine looks like this:

1. Generate a random 6-digit code.
2. Save it in the database.
3. Send it to the user.
4. Compare the submitted code with the saved one.
5. If it matches, accept the user's verification.

Simple. Clean. DANGEROUS.

This implementation works in a demo, but it is not enough for production.

Why?

Because authentication systems are not only attacked through cryptography. They are attacked through much simpler behaviors.

Attackers do not need to break your random number generator if they can request unlimited codes.

They do not need to steal your database if OTPs are stored in plain text and logs leak them.

They do not need to know a user's password if they can brute-force a 6-digit code with no attempt limit.

A 6-digit OTP has only 1,000,000 possible combinations. It can be achieved easily using a simple script and not a very long expiry date.

That may sound like a lot for a human, but it is not much for an automated script hitting an unprotected API.

So the OTP itself is not the security system.

The rules around it are.

OTP Is a Verification Flow, Not Just a Code

One mistake I see often is treating OTP as a single value.

But in a real system, an OTP should be tied to context.

An OTP should answer questions like:

• Who is being verified?
• What action is being verified?
• When was it created?
• When does it expire?
• How many attempts were made?
• Was it already used?
• Which device or session requested it?

This context matters because the same OTP concept can be used for different purposes.

A code sent for login should not be valid for resetting a password.

A code sent to approve a transaction should not be valid for binding a new device.

That means your OTP record should not be just:

phone_number
otp_code

It should be closer to:

identifier // account identifier that the verification is tied to (phone/email/telegram/other)
purpose // purpose of the verification
otp_hash // the ciphered OTP value
created_at // generation time
expires_at // ISO date reporesents: generation time + timeout
attempt_count // current consumed number of verification attempts
status // status of OTP: verified/failed/pending

The exact fields depend on your system, but the idea is simple:

The OTP must be bound to intent and context.

Without that, your OTP system becomes too generic.

And generic authentication tokens are dangerous.

Never Store the OTP in Plain Text

If your database gets exposed, OTPs should not be immediately usable.

Even though OTPs are short-lived, they are still authentication secrets.

A safer approach is to store a hash of the OTP instead of the OTP itself.

When the user submits the code, you hash the submitted value and compare it with the stored hash. This is also should be done if the system checks the duplication of OTP before storing it.

The idea is not that OTPs are as strong as passwords.

They are not.

The idea is that secrets should not be stored in a directly usable form when you can avoid it.

And please, do not log OTPs.

Not in debug logs.

Not in analytics.

Not in failed response bodies.

Not in monitoring payloads.

Logs usually live longer than OTPs, and they often have wider access than production databases.

That makes them a very bad place for authentication secrets.

Expiration Is Not Optional

An OTP should have a short lifetime. Usually, something like 2 to 5 minutes is reasonable depending on the channel and user experience.

Too short, and users struggle with delayed messages.

Too long, and the attack window becomes bigger.

But expiration alone is not enough.

You also need to decide what happens when the user requests a new OTP.

In most cases, generating a new OTP should invalidate the previous one for the same identifier and purpose.

Otherwise, users and attackers may have multiple valid codes at the same time.

That increases the chance of successful guessing and makes the system harder to reason about.

A clean rule could be:

For the same identifier and purpose, only the latest active OTP is valid.

This makes the flow predictable and easier to secure.

Limit Verification Attempts

A 6-digit OTP cannot survive unlimited guesses.

So every OTP challenge should have a strict attempt limit.

For example:

• No more than 2 wrong attempts per OTP challenge allowed
• Then invalidate the code
• Require the user to request a new one
• Add cooldown period if repeated failures continue

The important detail is that attempt limits should be attached to the OTP challenge itself, not only to the API endpoint.

Endpoint-level rate limiting helps, but it does not fully solve the problem.

You need limits around:

• the OTP record
• the phone number, email, or user identifier
• the IP address
• the device or session
• the purpose of the OTP

Because attackers can rotate IPs.

Users can request new codes.

Bots can distribute attempts across sessions.

A secure OTP system needs layered limits and well-organized defense lines.

Not one global counter and good wishes.

Control OTP Requests, Not Just OTP Verification

Many systems protect the verification endpoint but forget the request endpoint.

That is a mistake.

The request endpoint is where cost abuse happens.

If your system sends SMS, WhatsApp messages, or paid provider calls, attackers can abuse your API to generate real financial cost.

So you need limits on requesting OTPs too.

For example:

• Maximum OTP requests per identifier per time window
• Maximum OTP requests per IP
• Cooldown between resend attempts
• Daily limits per phone number or email
• Abuse detection for unusual countries, carriers, or traffic patterns
• Optional CAPTCHA or step-up checks after suspicious behavior

The goal is not to punish normal users.

The goal is to make automated abuse expensive and slow.

A small cooldown like "wait 2 minutes before requesting another code" can dramatically reduce accidental spam and basic abuse.

This is where progressive friction becomes useful:

First request: normal.

Second request: short cooldown.

Repeated requests: longer cooldown.

Suspicious pattern: CAPTCHA, temporary block, or manual review depending on your product.

Security is not always about blocking immediately.

Sometimes it is about slowing the attacker and increasing his attack's cost without destroying the user experience.

Avoid User Enumeration

OTP flows often leak information unintentionally.

For example:

This phone number is not registered.

or:

OTP sent successfully.

These responses may look harmless, but they can allow attackers to check which phone numbers or emails exist in your system.

That is called user enumeration.

A safer pattern is to return a generic response:

If this account can receive a code, we will send one shortly.

This way, the API response does not confirm whether the identifier exists.

Of course, your internal logic can still decide whether to send the code or not.

But externally, the response should avoid leaking account existence.

This is especially important for login, password reset, and account recovery flows.

Make OTP Single-Use

An OTP should be consumed after successful verification.

Once it is used, it should not work again.

This sounds obvious, but it is an important rule.

If a code remains valid after success, it can be reused in replay attacks or scenarios.

After success, mark it as used immediately.

This update should ideally be atomic to avoid race conditions where two verification requests succeed at almost the same time. Because in authentication, "almost impossible" bugs are exactly the kind of bugs attackers like to test.

Delivery Channel Matters

OTP is a general pattern, but the channel changes environment of the risk.

SMS is widely available, but it has weaknesses like SIM swap, delivery delays, and interception risks.

Did you notice that many banks and financial systems are migrating recently from SMS OTPs to in-app OTPs? It's because of the SIM Swap attacks!

Email is convenient, but it depends on the security of the user's email account.

WhatsApp or Telegram may offer better delivery in some regions, but they introduce dependency on platform rules, bot APIs, and account availability.

Push notifications can be smooth, but they depend on device registration and notification reliability.

An internal secure channel can be powerful, but it requires more engineering and trust modeling.

So the question is not only:

How do we send the OTP?

The better question is:

What security assumptions does this channel introduce?

A system that supports multiple delivery channels should treat the channel as part of the OTP context.

That means a code sent through email should not accidentally verify a challenge that expected SMS, unless your product intentionally allows that fallback.

When OTP should verify

That said, in summary, the OTP verification should only succeed if:

• the OTP exists
• it is not expired
• it is not already used
• it has not exceeded max attempts
• it belongs to both of the expected account identifier and purpose

Final Thought

Building an OTP system taught me that authentication is rarely simple.

The code is easy.

The hard part is everything around it:

the context, the limits, the abuse prevention, the expiration rules, the storage model, the delivery assumptions, the monitoring, and the user experience.

Ready-made providers can send the code for you.

But they do not automatically design your authentication flow.

And once OTP becomes part of login, account recovery, transaction approval, or device binding, it becomes a security system.

Not just a 6-digit number.

So whether you build it yourself or rely on a vendor, the real question is not:

How do I generate an OTP?

The real question is:

How do I design a verification flow that remains secure under abuse?

That is where the engineering starts.