SMS OTP Rate Limiting: Limits by User, Number, IP and Device Without Harming Authentication

Why OTP rate limiting is an operational policy, not just a technical control

SMS OTP rate limiting protects several assets at once: the authentication flow, messaging budget, operational capacity and the experience of people trying to access legitimately. A policy that is too permissive can enable automated requests, flood the recipient’s SMS channel and generate artificial traffic. A policy that is too strict can prevent legitimate access or become a denial-of-service path against specific accounts.

The aim is not to block SMS indiscriminately. It is to decide, in a measurable and reviewable way, when to allow a request, when to introduce a delay or additional friction, and when to temporarily restrict a high-risk action. The control unit should match the protected action and the observed risk.

• Separate request abuse from failures when entering the code.
• Avoid allowing a restriction based on one signal, such as an IP address, to determine the outcome on its own.
• Measure the impact of every limit on security, conversion, resends and cost.
• Maintain an authorised recovery path for people who cannot complete the usual flow.

What should be protected in an SMS OTP flow

An OTP flow contains distinct actions, and they do not necessarily need to share the same quota. At a minimum, it is advisable to handle the initial code request, resend, code validation, and switch to an alternative or recovery channel separately. Each action has a different abuse surface.

Code validation requires especially careful protection. When the authentication secret is short, NIST requires an effective limit on consecutive failed attempts per account and states that issuing a new code must not reset that counter. The code must be single-use, and the out-of-band process is no longer valid if it is not completed within ten minutes.

A request or resend should not, by itself, modify an account’s state. A repeated request may justify a delay, an additional check or a temporary restriction of the action, but it should not produce sensitive changes until a valid secret is provided.

• Initial request: protects against automation and SMS traffic generation.
• Resend: prevents duplicates, recipient fatigue and artificial pressure on transport.
• Validation: limits code guessing and must retain the failure counter even when a new code is issued.
• Channel switching or recovery: requires its own rules and a proportionate risk assessment.

Limit across multiple entities, not only by IP address

A policy based only on IP addresses is insufficient. An attacker can distribute attempts across multiple addresses, while legitimate users may share the same network exit point. OWASP recommends associating the failure counter with the account rather than relying exclusively on the IP address.

The most useful approach is to combine dimensions. The account or sign-in identity helps protect the authentication process; the MSISDN controls the SMS destination; the IP address provides source context; and the device, session, campaign or application can help identify concentration. No signal should be interpreted as conclusive proof on its own.

Before applying quotas by number, normalise the destination consistently using an international numbering format such as E.164. Without normalisation, different representations of the same number can fragment counters or lead to inconsistent decisions.

• Account: essential for limiting consecutive validation failures and protecting against distributed brute force.
• Normalised MSISDN: useful for controlling requests and resends directed to the same destination.
• IP address: a supplementary signal for detecting volume, automation or concentration, not user identity.
• Device: provides context, but should be used proportionately because it may be shared.
• Session: makes it possible to link requests and validations to a specific flow.
• Campaign or application: helps isolate issues and prevents one integration from affecting others.

How to choose windows, quotas and cooldowns

There is no universally verifiable quota that works for every service. Thresholds should be derived from the use case’s risk, expected population, fraud tolerance, service capacity and the impact of blocking a legitimate person. They should be documented and reviewed using your own data.

A fixed window is easy to explain and audit, but it can concentrate requests near its boundaries. A sliding window provides a more continuous view of recent behaviour, although it requires more careful implementation and observability. Progressive cooldowns reduce immediate repetition without imposing a long ban from the outset.

OWASP identifies three elements that should be explicit: the number of failures that triggers the restriction, the period in which they are counted, and the duration of the restriction. It also describes exponential lockout, where the delay starts short and increases after successive failures.

• Use simple windows when operational explainability and auditing are the priority.
• Use sliding windows when it matters to prevent artificial spikes around a time-based reset.
• Apply progressive cooldowns to repetitive actions before resorting to extensive lockouts.
• Document each rule: entity, action, threshold, window, duration, authorised exception, owner and reversal condition.

Separating request, resend and validation prevents contradictory controls

The initial request and resend consume messaging capacity; validation consumes verification capacity and faces the risk of guessing. A single counter for the entire flow mixes causes and makes it harder to investigate what is happening.

A prudent implementation can maintain challenge state per session or transaction: normalised destination, account where present in the flow, request identifier, issuance time, expiry, usage state, failed validation counter and pseudonymised references to risk signals. The OTP secret must not be logged in plaintext.

Idempotency is also important. If the client retries a request because of a lost response or a network condition, the service should be able to recognise the repeat within a controlled context rather than unnecessarily generating several messages. This decision reduces duplicates and makes request counting more reliable.

• Do not reset validation failures when generating a new code.
• Mark the code as consumed after valid use to prevent reuse.
• Make it clear to the user when they can request another send, without revealing account information.
• Design technical retries to be idempotent so they are not confused with new human requests.
• Keep delivery queues separate from authorisation logic: accepting a request does not confirm authentication.

Safe responses and progressive friction

An OTP endpoint response should remain neutral about the existence, status and possible lockout of an account. OWASP recommends consistent messages and uniform timing to reduce enumeration through differences in content or response time.

When a risk signal increases, progressive friction is preferable to a broad lockout. For example, a visible delay before resending, an additional anti-automation check or a risk review can be proportionate measures. CAPTCHA can act as defence in depth and may be introduced after some failures, rather than necessarily on the first attempt.

Restrictions should prevent abuse without allowing a third party to lock legitimate users out. Therefore, it is not advisable to apply an extensive account suspension solely because someone has repeatedly requested codes for that destination.

• Use messages such as: “If the flow is valid, you will receive instructions or be able to continue when the waiting period ends.”
• Display a resend countdown tied to the transaction, not information about whether an account exists.
• Increase friction based on repetition, speed and concentration of signals, not on one isolated observation.
• Reserve higher-impact restrictions for corroborated risk and a defined duration.
• Offer authorised recovery when the usual channel is not viable.

Signals that justify reviewing or tightening controls

Risk signals help prioritise review and adjust controls; on their own, they do not amount to identity or proof of fraud. OWASP recommends treating data received from clients, devices, networks or external services as untrusted, because it may be missing, repeated, modified or forged.

Look for patterns of concentration and repetition: many requests for the same destination, rapid activity from one source, resend sequences without validation, persistent code failures or anomalous volume within one application. In PSTN channels, NIST recommends considering indicators such as a device change, SIM change, number porting or other anomalous behaviour before sending the secret.

Devices require especially careful treatment. They can provide a useful signal against abuse at scale, but devices are also shared. Do not turn a device association into an automatic access ban for multiple legitimate users.

• Concentration: repetition involving an account, number, session or application.
• Speed: a cadence incompatible with the expected normal use of the flow.
• Failure pattern: multiple incorrect validations or requests with no completion.
• Destination: unusual changes in destination patterns within an application.
• Contextual risk: indicators of device changes, SIM changes or porting, treated as signals rather than certainties.
• Signal quality: incomplete or untrusted data should reduce confidence in a decision, not automatically make it stricter.

What to log without storing more data than necessary

Logs make it possible to explain a decision, investigate abuse and detect false positives. OWASP recommends logging authentication successes and failures, attempts to exceed limits and suspicious business-logic activity, using a consistent and documented taxonomy.

For each event, retain the context of when, where, who and what happened: timestamp, interaction identifier, action, outcome, applied rule and confidence level. Use pseudonymised identifiers or protected references where appropriate for the account, number, device or session.

Do not log OTP secrets, passwords, access tokens, session values or unnecessary personal data. Apply masking, hashing, encryption or pseudonymisation as appropriate, and ensure log access controls match the sensitivity of the data.

• Interaction or transaction ID to correlate request, delivery and validation.
• Timestamp, action, outcome and decision reason.
• Rule identifier, limited entity and quota state, without exposing secrets.
• Pseudonymised reference to the destination and other signals needed for correlation.
• Technical source context only to the extent needed for security and investigation.
• Exception, manual review and reversal events to preserve traceability.