On-Premise OTP & 2FA Delivery From Your Own Network
Send one-time passwords (OTP) and two-factor authentication (2FA) codes by a local HTTP call through your own SIM cards. The phone number and the code are generated, stored and delivered inside your network.
Why OTP belongs on your own network
An OTP is a short message with a high consequence. Every extra party in that path is another party that can see the code.
The number stays inside
The recipient number and the code are written to your database. Nothing is forwarded to a messaging vendor, so there is no third-party copy to retain or breach.
Cost does not scale with logins
Ten logins or ten thousand, the software cost is the same. Your SIM plan carries the traffic, which matters when verification volume grows.
Your stack keeps working
Call the local HTTP API from your identity service, or bind an SMPP client you already use. No SDK migration. For monitoring alerts on the same gateway, see IT alerting.
OTP latency: local API vs public internet
Latency is the honest differentiator, so here is what we can and cannot state.
| Path | What we can state | Basis |
|---|---|---|
| LAN HTTP call to the gateway | Typically under 100 ms on a wired LAN | Local network, no internet hop; not a guarantee |
| Cloud API round trip | Not measured by us; depends on region and vendor | Vendor documentation, varies by network |
| Carrier delivery time | Usually seconds; can be minutes | Depends on carrier routing and congestion |
Tested and reviewed 2026-11. Latency claims are device and network specific; test on your own LAN before committing to an SLA.
OTP redundancy with more than one modem
OTP traffic fails loudly. Two devices and a retry rule turn a dead stick into a delayed code instead of a failed login.
curl -X POST http://192.168.10.5:8080/sms/send -H "Content-Type: application/json" -d '{"to":"+12025550147","text":"Your code is 481922","device":"SIM1","retry":1}'
Two SIMs, two carriers
Route OTP traffic to a primary device and fall back to a second SIM on a different network.
Retry with a limit
One immediate retry is usually enough. More than two retries produces duplicate codes and confused users.
Expiry is your job
The gateway delivers the code. Generating, hashing and expiring it belongs in your identity service.
For alerting that uses the same devices when the office network fails, see out-of-band SMS alerting. The Windows feature set is on the desktop software page.
OTP audit and retention
Every OTP send is written locally with the recipient, the device, the time and the carrier response. The code itself can be excluded from the log if your policy requires it.
Retention is a setting, not a vendor policy: keep 30 days, keep a year, or delete on a schedule. Because the data never left your network, a subject access request can be answered without opening a support ticket with a third party.
For a formal process, see the compliance guide and the privacy policy.
What an audit row contains
- Timestamp and sending SIM
- Recipient number (maskable)
- Carrier status and error code
- Message reference returned by the modem
Capability and limits
Supports
OTP delivery by local HTTP API, two-way confirmations, per-device retry, local audit records.
Not supported
No code generation, no fraud scoring, no hosted number, no uplink redundancy beyond the SIMs you own.
Depends on
Carrier delivery time, your modem count and your identity service's expiry policy.
OTP questions
Does the software generate the OTP?
No. Your identity service generates and validates the code. The gateway delivers the text and records the attempt.
Can it work without any internet connection?
Yes. Your application calls the gateway on the LAN and the modem sends over the mobile network. No internet route is involved.
What happens if the primary modem fails?
The API returns an error for that device and can retry on a second device if you configure one. Two SIMs on different carriers is the simple redundancy plan.
Is the OTP stored in the log?
By default the message text is stored. You can mask or exclude it if your retention policy requires that.
Can we keep the numbers out of the logs entirely?
Yes. The audit row can store a masked recipient and the carrier reference only. The trade-off is weaker troubleshooting.