When OTP Becomes a Spam Goldmine — And How to Stop It with One Shift

There’s a paradox in modern authentication that anyone who has worked with OTP systems long enough will eventually notice:

The very mechanism designed to secure users can also be weaponized at scale.

---

Part 1 — The Zalo Story

Take a platform like Zalo.

They fully understand how OTP can be abused — because they’ve lived through it. There was a time when users were heavily spammed with OTP messages. Not because the system was weak, but because the mechanism itself was exploitable.

If you expose an endpoint that sends OTP → it will be abused.

No matter how many rate limits or CAPTCHA layers you add, attackers adapt:

• Rotate IPs
• Simulate devices
• Distribute requests across sessions

Eventually, the cost of defense becomes higher than the cost of attack.

So what did they do?

They shifted the model.

Instead of sending OTP outward (SMS), they introduced user-initiated flows like inbound voice OTP. No outbound API → no spam vector.

But here’s the irony.

As a platform, they reduce OTP abuse.
As a service provider, they still offer ZNS OTP — now costing ~440 VND per message.

Which reveals an uncomfortable truth:

Outbound OTP is both a security feature and a monetizable surface — even though it’s also the root of the spam problem.

---

Part 2 — The Real Threat: Cross-App Abuse

Modern OTP spam isn’t sophisticated.

It’s industrialized.

There are public tools, tutorials, even ready-to-run scripts. Anyone can do it.

And the most dangerous part?

Attackers don’t target just one system.

They exploit the same OTP logic across hundreds of apps.

Even if:

• App A limits 1 OTP per phone number
• App B does the same
• App C does the same

An attacker can still trigger:

100 OTP messages → to the same victim → from 100 different apps

Each request:

• Comes from a different IP
• Uses a different device fingerprint
• Runs in a separate session

From the perspective of each system, everything looks legitimate.

So traditional defenses fail — not because they’re bad, but because:

You’re trying to solve an ecosystem-level problem at a system level.

---

Part 3 — The Global Product Reality

If you’re building for international users, SMS OTP becomes even worse.

You quickly realize this isn’t just a technical problem — it’s a regulatory maze:

• Some countries require sender registration
• Some filter or rewrite content
• Some delay messages unpredictably
• Some block entire routes without notice

At scale, OTP delivery turns into a compliance + telecom negotiation problem, not engineering.

---

Part 4 — The One Shift That Changes Everything

Here’s the core insight:

Stop sending OTP. Start making users request it.

This sounds trivial, but it changes the entire threat model.

Old model (vulnerable)

• Server sends OTP → user receives
• Attack surface = public API

New model (resilient)

• User initiates authentication
• Server responds only to verified intent

Examples:

• Inbound call OTP
• App-based approval (push)
• TOTP (Google Authenticator-style)
• Deep link / magic link
• Device binding

Now the attacker has a harder problem:

• They must control the user interaction channel
• Not just spam an API

That’s a completely different game.

---

Final Thought

OTP spam is not a bug.

It’s a business + architecture side-effect.

As long as:

• Sending OTP is easy
• And costs are externalized
• And APIs remain public

It will continue to be abused.

You can keep adding layers (rate limit, CAPTCHA, fingerprinting)...
Or you can change the model entirely.

Sometimes the most effective fix isn’t optimization — it’s elimination.

---

If you're building auth for a real-time product or scaling globally, this is not an edge case.

It's inevitable.

The only question is:
Do you design for it early — or react when it becomes a problem?