Implementing SMS 2FA: the complete security guide for businesses
SMS as a second login factor has one advantage over authenticator apps and push: it always arrives, on any phone, with no install and no account in an extra app. For most SaaS, banking and e-commerce apps it is the optimal trade-off between security and reach. This guide shows how to implement SMS 2FA so it is both secure and abuse-resistant — not just "works in a demo".
When SMS 2FA makes sense (and when it does not)
SMS works as 2FA wherever reach and simplicity matter: panel login, payment confirmation (PSD2 SCA), number verification at sign-up, authorizing sensitive operations. It is also the best fallback when a push notification fails to arrive — because the user changed phones, has no internet, or uninstalled the app.
Let us be honest about the limits: for the highest-risk accounts, hardware keys or TOTP are worth considering, since SMS is theoretically exposed to SIM swapping. For 95% of business use, SMS remains the best ratio of security to conversion — everyone can copy a code from an SMS, not everyone will configure a TOTP app.
Architecture: do not keep OTP logic on your side
The most common mistake is generating and storing codes in your own database. That is needless risk. With our 2FA API you do it with two calls:
POST /otp/send → generates and sends the code
POST /otp/verify → checks the code, returns true/falseYou configure code length (4, 6 or 8 digits) and lifetime (30 seconds to 10 minutes). 6 digits and 5 minutes is a sensible default.
Rate-limiting and abuse protection
Without limits, 2FA becomes an attack vector — and a costly one, since every SMS sent is an expense. Apply layered protection:
- Per-number limit — max 3–5 codes per hour per number (guards against "SMS bombing").
- Cooldown — at least 30–60 seconds between code requests.
- Verification attempt limit — lock after 3–5 wrong codes to block brute force.
- Per-IP limit — cap the number of phone numbers served from one address.
Our API has built-in per-number rate-limiting and a full audit log of every OTP: when sent, when verified, from which IP.
Deliverability = security
A code that does not arrive means a locked-out user — in practice an abandoned cart or a support ticket. The median SMS delivery time in Poland is about 2 seconds. The key is route quality: failover to an alternate carrier saves the day when the first attempt fails. As a UKE-registered Polish carrier we have direct connections to domestic networks, which translates into high, stable OTP deliverability.
Code UX: small details that matter
Security must not kill convenience. A few proven practices: put the service name and the code near the start of the message (iOS/Android autofill reads it); add the @domain #code prefix for the Web OTP API; do not send a link and a code in one SMS (it trains phishing). Set the sender field to your brand name — see our piece on Sender ID.
PSD2 and GDPR compliance
In payments, SMS OTP is an accepted element of Strong Customer Authentication (SCA) — combine it with a knowledge factor (password/PIN) for full PSD2 compliance. On data: we process numbers only on EU servers, under a full processing agreement, and keep logs only as long as the law requires. Integration details are in the documentation, and a test account with 100 free SMS is on the sign-up page.
FAQ
Do I have to generate and store OTP codes myself?+
No. /otp/send generates and sends the code, /otp/verify validates it. You keep no logic and no codes on your side.
How do I protect against flooding (SMS bombing)?+
The API has per-number rate-limiting (e.g. 3–5 codes/hour) and an audit log. Also add a cooldown, a wrong-attempt limit and a per-IP limit.
Does SMS 2FA meet PSD2 SCA requirements?+
Yes. SMS OTP is an accepted "possession" element of Strong Customer Authentication. Combine it with a knowledge factor (password) for full compliance.
Is SMS 2FA safe despite SIM-swap risk?+
For most business use, yes — it is the best balance of security and conversion. For extreme-risk accounts, add TOTP or hardware keys.