SMS OTP Latency Budget: How to Set Expiry and Targets Without Relying on the Average
Learn how to break down, measure, and govern SMS OTP latency using percentiles, segmentation, and functional signals, without confusing acceptance, DLRs, and actual code use.
What Problem Does a Latency Budget Solve in an SMS OTP Flow?
An SMS OTP latency budget turns a vague expectation — “the code should arrive quickly” — into a measurable operational model. Its purpose is to separate the stages of the journey, assign ownership, select observable signals, and decide how long a code remains valid without relying on a global average delivery time.
In an out-of-band authentication flow, the verifier generates a temporary secret, sends it through a secondary channel such as SMS, and the user returns it through the primary channel. The relevant journey therefore does not end when a platform accepts the send request, nor necessarily when a delivery receipt arrives: it ends when the verifier accepts a valid OTP submission.
The budget supports product and operational decisions: setting a reasonable expiry period, determining when to show a resend option, detecting degradation by destination or route, and avoiding attributing a delay caused by the application or an internal queue to the mobile network.
- Define the functional outcome as successful OTP validation, not merely message submission.
- Model the stages separately before setting any time target.
- Measure by operational segment; a global figure may hide concentrated degradation.
- Keep security as a design constraint: the code must be temporary and accepted only once.
Why Average Latency Is Not Suitable for Setting Code Expiry
The average is a poor answer to a critical product question: how much time the vast majority of legitimate users need to complete the flow. A set of fast deliveries can lower the average even when there is a meaningful tail of slow experiences. If expiry is set using that average, tail cases will expire repeatedly while the aggregate metric may still appear healthy.
Expiry also does not represent SMS transport alone. It must cover the time from secret creation to entry and validation, including internal processing, transmission, possible network delay, handset availability, and the time the user needs to read and enter the code.
NIST states that, for time-based OTPs, the validity period should account for expected clock drift, an allowance for network delay, and user entry time. This principle prevents designing expiry around a single latency measure from a provider or route.
- Do not use the average as the primary expiry criterion or as the only SLO.
- Observe high percentiles for time to validation, together with success and expiry rates.
- Analyze comparable time windows, not only historical aggregates.
- Distinguish transport delay from late validation caused by user interaction.
Operational Definitions and Minimum Timestamps
Before measuring, define each event precisely and record its timestamp. Ambiguous definitions create invalid comparisons across teams, providers, or destinations. Use an internal correlation identifier for the authentication attempt and a message identifier for the send, while keeping correlation data non-sensitive.
A practical sequence starts with OTP creation and its association with the authentication transaction. It then records the request to the delivery channel, acceptance of that request through API or SMPP, available queuing and sending events, any received DLR, and finally successful or failed code validation.
API or SMPP acceptance only confirms that the provider successfully received the command or request. It does not confirm that the SMS reached the device. Likewise, a DLR is an asynchronous signal whose meaning depends on the received report and the delivery chain; it should be retained as operational evidence without treating it as proof of reading or as the definitive delivery clock.
- t0: OTP creation and start of its validity period.
- t1: send request issued by the application.
- t2: API or SMPP acceptance and assignment of the message identifier, where available.
- t3: sending or status-change events available from the platform.
- t4: DLR receipt and, where provided, the timestamps and attempts contained in the report itself.
- t5: OTP submission and successful validation, or a record of expiry, failure, or abandonment.
What Each Party Controls
The sender controls the experience design, code generation, request creation, application behavior, its own queues, expiry rules, attempt limits, and instrumentation. It can also choose available connectivity, define destination policies, and act on routes according to its agreements and operational controls.
The messaging provider and intermediaries control parts of acceptance, processing, and delivery to connected networks, depending on the applicable architecture and agreements. The mobile network controls routing and reported delivery elements within its domain. The handset, available coverage, device status, and user behavior are outside the sender’s direct control.
This separation should be reflected in diagnosis. If the time between creation and acceptance rises, investigate the application or outbound connectivity first. If acceptance remains stable but the distribution of DLRs or validations changes for a destination, investigate the affected segment without concluding that a single event proves the cause.
- Application: generation, secure storage, expiry, UI, request, and validation.
- Sending connectivity: acceptance, technical response, and message identifiers.
- Route and mobile network: delivery processing and any reportable status signals.
- Handset and user: practical availability of the code, reading, and entry.
- Verifier: final decision to accept or reject the submitted OTP.
How to Build a Stage-by-Stage Latency Budget
Build the budget from the outcome that matters: a valid verification before expiry. Start by collecting events from real authentication attempts, correlating the attempt, message, and verification result. Exclude events that cannot be reliably linked from the definition, but quantify that missing correlation as an observability limitation.
Calculate distributions for each interval: creation to request, request to acceptance, acceptance to any later available signal, and creation to successful validation. Keep validated, expired, abandoned, failed, and incorrect-code attempts separate. Combining them into one series hides security, UX, and delivery issues.
The final budget is not a promise that every message will be completed within a fixed time. It is a policy: a validity window accompanied by resend limits, attempt controls, alternative authentication methods where appropriate, and operational thresholds by segment.
- 1. Define the start event: typically OTP creation.
- 2. Define the functional end event: successful validation by the verifier.
- 3. Record intermediate intervals with distinguishable timestamps.
- 4. Classify the outcome of every attempt.
- 5. Calculate percentiles by segment and time window.
- 6. Set expiry by considering transport, human interaction, and security requirements.
- 7. Review the policy after changes to routing, product, connectivity, or traffic behavior.
Percentiles, Time Windows, and Destination Segmentation
Use percentiles to describe the distribution, not just a central point. Percentiles for time to validation help reveal the experience of the slower portion of users who complete the flow. They should be read alongside the share of attempts that expire, the validation rate, and volume, because a percentile calculated from few observations may be unstable.
Segment at least by destination. When data and volume allow, add dimensions that are useful for operations: route, sender, number type, traffic type, application version, or risk policy. Do not combine segments with different behavior and then expect one global threshold to explain the cause of a deviation.
Compare each segment with its own baseline using consistent time windows. A window that is too short reacts to noise; one that is too long can delay detection. Also establish a minimum observation volume before making automated decisions or escalating an alert.
- Measure creation-to-validation time as the primary functional metric.
- Measure creation-to-acceptance time to isolate internal or connectivity delays.
- Retain DLRs and their timestamps as supplementary telemetry, not as a substitute for validation.
- Analyze expiry percentage, resends, failed attempts, and successful validations alongside timing.
- Require sufficient volume before comparing percentiles across segments.
Expiry, Resends, Request Limits, and Duplicate Prevention
The expiry window should be wide enough to cover the expected legitimate experience, but it must not become a substitute for security controls. For NIST-covered out-of-band authentication, the transaction must be completed within 10 minutes, and a given secret may be accepted only once during its validity period. Always apply the regulatory, contractual, and risk requirements relevant to your use case.
A resend should not create a message storm or indefinitely expand the attack surface. Before issuing another SMS, check whether there is an active OTP associated with the same transaction and explicitly decide whether it is reused, invalidated and replaced, or whether the request is limited. The policy must be consistent so that multiple ambiguous active codes do not exist without a clear validation rule.
For short secrets, effectively limit consecutive failed attempts. Issuing a new secret must not reset the failure counter. You can use progressive delays and risk signals to strengthen the flow when anomalous patterns emerge, while maintaining alternative authentication methods when risk, coverage, or accessibility requires them.
- Maintain a single authoritative state per authentication transaction.
- Make each OTP single-use.
- Define an explicit policy for what happens to the previous OTP after a resend.
- Limit resend requests by account, session, destination, and relevant risk signals.
- Do not reset failed-attempt limits when issuing a new code.
- Offer alternative authentication methods when SMS/PSTN is unsuitable or unavailable.
What a DLR May Indicate and What It Cannot Prove
A DLR can provide useful operational information: reported status, delivery attempts, and, depending on the interface, timestamps for the attempt and report receipt. It is valuable for investigating trends and for separating an initial technical response from a delivery status communicated later.
However, a DLR alone does not prove that the user read, understood, or entered the code. Nor should it be used as the clock for immediately deciding that an outbound delivery delay exists. Receipts or events generated by operators can arrive late; AWS documentation warns that they may be received up to 72 hours later and should not be used to determine an outbound delivery delay.
Successful OTP validation is a stronger functional signal: it shows that the code became available to the user and was presented to the verifier. Even so, this does not make the DLR irrelevant; the two signals answer different questions and should be retained separately.
- Send acceptance: the command or request was successfully received.
- DLR: an asynchronously reported delivery result, with uncertainty in timing and scope.
- Successful validation: functional evidence that the code was correctly presented to the verifier.
- No DLR: should not automatically be interpreted as no delivery.
- DLR Delivered: does not prove reading or correct code entry.
Frequently asked questions
Which metric should guide SMS OTP expiry?
The most useful reference is the distribution of time from OTP creation to successful validation, segmented by destination and other relevant operational dimensions. It should be supplemented by expiry, resend, and failure rates, not by an isolated delivery average.
Does API or SMPP acceptance mean that the SMS reached the phone?
No. It indicates that the command or request was successfully received by the accepting system. It does not prove receipt on the destination device.
Does a Delivered DLR prove that the user received and read the OTP?
No. A DLR represents a reported delivery result and can be useful as an operational signal, but it does not prove that the code was read, understood, or entered. Successful validation is the stronger functional signal.
How long should an SMS OTP remain valid?
There is no universal duration that can be derived from an average delivery time. Define it based on the distribution of time to validation, expected interaction time, risk, and applicable requirements. For NIST-covered out-of-band authentication, the transaction must be completed within 10 minutes.
Should a new code be generated every time the user requests a resend?
An explicit policy must exist. If a new one is generated, define what happens to the previous code to prevent ambiguity, and do not reset failed-attempt controls. It is also advisable to limit resend requests and apply delays or adaptive measures where appropriate.
How can you detect SMS OTP route degradation?
Compare time-to-validation percentiles, expiry rates, resends, and delivery signals with each segment’s own baseline, segmented by destination, route, sender, or other available dimensions. Require sufficient volume and sustained deviation before attributing an isolated spike to a route issue.
Sources consulted
- NIST SP 800-63B: autenticación fuera de banda y secretos temporalesNational Institute of Standards and Technology (NIST)
- AWS End User Messaging SMS User Guide: eventos, DLR y feedback de mensajesAmazon Web Services (AWS)
- Azure Communication Services SMS Delivery Reports APIMicrosoft
- Azure Communication Services: eventos SMSMicrosoft
- OWASP Authentication Cheat SheetOWASP Foundation