Your SaaS team owns the abuse policy for SMS-based login recovery. Enforce limits in your application before requesting a message or accepting a code; use the SMS provider’s controls as an additional layer, not a substitute. There is no universal safe number of sends or guesses: choose thresholds against your threat model, legitimate traffic, destination geography, and provider behavior.
Who owns SMS OTP rate limits?
The application team decides which recovery requests are allowed, how often someone can request a code, and how many guesses are accepted. A hosted provider can enforce additional limits, but those controls do not necessarily know your account boundaries, recovery policy, or risk signals.
As an Amazon Associate I earn from qualifying purchases.
For example, Twilio Verify Service Rate Limits let an application supply keys and configure limits for those keys. When a configured limit is exceeded, Twilio returns HTTP 429 and does not create a verification. That is useful defense in depth, but the SaaS still has to make the decision to submit the request and protect its own recovery flow. Twilio: Protect Your Verify Application with Service Rate Limits
Six rules for designing the limits
1. Enforce an application-owned policy before calling the API
Check the request against your own budgets before asking the provider to send a code. Provider-side throttles can catch excess activity reaching the provider, while application checks can account for the user, account, tenant, recovery session, destination, and risk context relevant to your product.
#1 Best Overall
Configure provider limits as a second layer. Twilio documents HTTP 429 and error 60203 when a configured Service Rate Limit is exceeded. Twilio Service Rate Limits
2. Limit by recovery identity, not just IP address
Use a stable account or recovery-identity bucket, then combine it with useful context such as destination number, IP address, session, or device signals. IP-only limits are weak against distributed requests, and they can be unreliable behind a reverse proxy if the application does not have the true client IP.
Twilio Service Rate Limits support keys such as IP, phone number, country code, session ID, and user agent. Derive client context from trusted infrastructure; do not trust arbitrary forwarded headers supplied by a requester. Twilio Service Rate Limits OWASP REST Assessment Cheat Sheet
3. Budget code sends and code guesses separately
A resend can flood a person’s phone or generate unwanted messaging volume. A code check can be a brute-force attempt. Track both actions independently: apply a send budget to requests and a bounded failed-attempt counter to submissions. Invalidate a code after successful verification.
OWASP advises limiting recovery requests per account and treating recovery endpoints as authentication surfaces that need brute-force protections. OWASP Forgot Password Cheat Sheet OWASP API2:2023 Broken Authentication
4. Make each code short-lived and single-use
Set an expiry, reject expired or previously successful codes, and avoid logging OTP values. OWASP recommends short-lived, single-use OTPs and strict attempt limits.
Rank #4
Provider behavior is product-specific. Twilio Verify currently documents a 10-minute default token validity period, configurable from 2 minutes to 24 hours by contacting Support. During the validity period, a repeated request returns the same token until successful verification. Do not assume another provider or your own implementation behaves the same way. OWASP Multifactor Authentication Cheat Sheet Twilio Rate Limits and Timeouts
5. Prevent throttling from becoming a lockout weapon
A hard, long lock can let an attacker deny a victim access by repeatedly triggering it. Consider graduated delays, risk signals, and a safe alternate recovery path rather than relying only on a long lock. NIST describes increasing wait periods and adaptive signals as possible approaches; OWASP also cautions about lockout denial-of-service risk.
Best Value
NIST SP 800-63B-4 says that, unless a more specific authenticator description says otherwise, a verifier must limit consecutive failed authentication attempts on a single account to no more than 100. This is a general maximum for the stated scope—not a recommended target for SMS recovery, nor a resend allowance. Your product may need a stricter policy based on its threat model and legitimate traffic. NIST SP 800-63B-4 OWASP Forgot Password Cheat Sheet
6. Treat recovery like authentication and monitor provider limits
Recovery endpoints need login-grade protections against brute force. Return generic responses for existing and nonexistent accounts, and avoid response-time differences that reveal account status. Monitor provider errors and apply bounded retry behavior; repeatedly hammering the send endpoint can worsen throttling and messaging problems.
Twilio documents error 60245 for certain account, service, or destination messaging-volume and rate-limit conditions. Its Verify status-check API limits are 60 requests per minute, 180 per hour, and 250 per day; these are status-check limits, not code-send quotas. OWASP Forgot Password Cheat Sheet OWASP API2:2023 Broken Authentication Twilio Error 60245 Twilio Rate Limits and Timeouts
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How many OTP codes should a user be allowed to request?
The available standards and provider documentation do not establish a universal send threshold. Set your own per-identity and contextual budgets, then validate them against expected legitimate recovery traffic, abuse scenarios, geography, and provider behavior. Keep send limits distinct from failed-code limits; the NIST 100-attempt maximum applies to consecutive failed authentication attempts in its stated scope, not to code resends.
What to decide before launch
- Identity: Choose stable account or recovery identifiers and relevant contextual keys; do not rely on IP alone.
- Separate budgets: Define policy for sends and failed checks independently, and invalidate successful codes.
- Recovery experience: Keep responses generic and provide a way to recover that does not let a public attacker lock out a victim indefinitely.
- Provider behavior: Confirm the provider’s token lifetime, rate-limit semantics, and error handling for the specific service and configuration you use.
- Operations: Monitor throttles and messaging-limit errors, and use bounded retries rather than uncontrolled resend loops.
SMS is one recovery channel and this guidance does not establish it as the strongest option for high-risk accounts. The central design principle remains the same: application policy protects the user and account; provider controls add a separate enforcement layer.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
