SMS OTP Circuit Breaker: Thresholds, States, and Safe Recovery

What problem an SMS OTP circuit breaker solves

An SMS OTP circuit breaker is an operational control that temporarily reduces or changes sending when signs of degradation appear in a specific segment. Its purpose is to protect authentication flow continuity, limit the impact of an affected route or destination, and prevent an incident from amplifying retries, duplicates, and code expirations.

It does not replace OTP security controls. Limits on code validation attempts, secret lifetime, single use, and abuse defenses are separate controls. The circuit breaker acts on the decision to send or handle messaging requests; it must not reset authentication limits simply because a new code is issued.

In an out-of-band SMS flow, a short-lived secret is generated for an authentication operation and delivered through a secondary channel. Therefore, a delivery problem can prevent a legitimate authentication from being completed, but the solution is not necessarily to stop all traffic. The affected segment should be isolated and a proportionate response applied.

• Objective: limit the blast radius of degradation.
• Scope: sending, queueing, throughput, routing, or permitted alternative authenticator decisions.
• It is not: a fraud test, a substitute for verification rate limiting, or a delivery guarantee.
• Operational principle: reversible, segmented, and auditable decisions.

Why an increase in negative DLRs is not enough to automatically block sending

An identifier returned when a message is submitted to an API, provider, or SMSC confirms acceptance of that submission according to the protocol or integration; it does not confirm that the phone received the OTP. Delivery is a later phase and must be observed separately through the available statuses.

It is also not advisable to treat every negative DLR as sufficient reason to open a global circuit. In SMPP, there are intermediate statuses such as ENROUTE and final statuses such as DELIVERED, EXPIRED, DELETED, or UNDELIVERABLE. An intermediate message may still be in progress or being retried before reaching a final status.

The absence of a DLR does not automatically mean non-delivery either. Receipt reporting depends on registered_delivery configuration and on the implementation of the message center or provider. A sound policy defines which absence of final status matters, for how long, and for which cohorts, rather than assuming every silence is a failure.

• Separate submission acceptance, delivery status, and successful OTP validation.
• Classify ENROUTE as an intermediate status, not a final outcome.
• Assess negative DLRs in the context of volume, time, destination, and route.
• Treat missing DLRs as observability uncertainty, not proof of non-receipt.
• Do not assume that a DELIVERED DLR independently proves receipt or reading by the user.

The signals that should be kept separate

The circuit should not be driven by a single blended metric. Each signal describes a different phase and may require a different action. Combining API failures with late DLRs, for example, can hide whether the incident is in the integration, before acceptance, in status observability, or in a delivery route.

Define normalized events and a stable taxonomy before setting thresholds. The value of the mechanism depends on the same condition producing the same classification, even when the on-call team or route implementation changes.

• Integration or transport errors: authentication failures, connectivity issues, timeouts, and protocol errors between the application and the submission endpoint.
• Pre-submission rejections: requests not accepted by the sending interface. These must be distinguished from messages that were accepted but later did not reach a favorable final status.
• Negative final statuses: final outcomes reported later for accepted messages.
• Intermediate statuses: messages still in progress; they should not simply be counted as final failures.
• Latency: time from accepted submission to the available final status, analyzed by cohort.
• Missing final status: messages without a final status within the policy-defined period.
• Resend behavior: repeated requests, potential duplicates, newly issued OTPs, and subsequent validations.

A three-state model: closed, open, and controlled recovery testing

The simplest and most traceable model uses three states. In closed state, the segment operates under normal policy and signals are observed. In open state, the defined protective action is applied to that segment. In controlled recovery testing, a limited and explicitly governed portion of traffic is released to determine whether the degradation has cleared.

There is no universal percentage, duration, or error rate that works for every destination. These values must be policy parameters approved by the responsible team and adjusted to volume, OTP validity, available alternatives, and the risk of affecting legitimate users.

The transition must be deterministic. Specify which signals open the circuit, how long it initially remains open, when it may enter testing, and what condition returns it to open. Avoid unrecorded manual changes, as they prevent reconstructing why a decision was made.

• Closed: normal sending and signal collection by segment.
• Open: pause, limiting, conditional queueing, or permitted alternative according to policy.
• Controlled testing: limited, observed release before restoring normal operation.
• Reopening: immediate return to open if the defined signals reappear.
• Closing: restoration only after meeting stability criteria and sufficient volume.

How to define thresholds with minimum volume, time windows, and segmentation

Calculate thresholds on coherent operational cohorts. At a minimum, segment by country or numbering plan. Where telemetry is reliable, add destination operator and route. A global average can hide localized degradation or, conversely, open a broad block because of the behavior of a small portion of traffic.

Every threshold must declare three elements: a time window, a minimum observation volume, and a degradation condition. Without a minimum volume, a small sample can create an extreme and unstable rate. Without a window, an old event can influence decisions for too long, or a brief spike can trigger an overreaction.

Keep thresholds for integration, rejection, final outcome, latency, and missing final status separate. It is also advisable to establish a policy for new or low-volume segments: rather than inferring a conclusive rate, operational review may be required or a more conservative, reversible action may be applied.

• Recommended segment: numbering destination; extend by operator and route where reliable data is available.
• Window: specify the exact calculation period and update method.
• Minimum volume: do not evaluate opening rates before the approved minimum is reached.
• Condition: define which combination of signal, proportion, and persistence triggers the transition.
• Exclusions: document maintenance, planned changes, or instrumentation events that invalidate the reading.
• Versioning: assign a version to each threshold set and retain its history.

What actions to apply when the circuit opens

Opening a circuit does not necessarily mean discarding every request. The action must respect OTP validity and the effect on the user. A queue is useful only if the code will remain valid and if the delay will not cause the person to repeatedly request new messages. If it no longer retains value, it is preferable not to reactivate the old request.

Authentication alternatives must be enabled and approved before an incident occurs. Do not improvise an alternative channel that authentication policy does not authorize. In particular, email must not be used for out-of-band authentication according to NIST, although it may have other uses, such as address confirmation or recovery, under its own policy.

The decision may differ by severity. A complete integration failure may require an immediate pause within the affected scope. Increased latency or DLR uncertainty may justify throughput limiting or testing authorized routes, provided the organization has those options and can observe their outcomes.

• Pause new sends for the affected segment.
• Limit throughput to reduce the amplification of degradation.
• Queue only requests that can be completed within the OTP's useful validity period.
• Reroute according to a pre-approved policy to an available alternative or route.
• Present the user with an alternative authentication method that is already permitted and configured.
• Do not reuse consumed OTPs or indiscriminately reactivate old requests.

How to avoid blocking legitimate users

A poorly segmented circuit breaker can turn localized degradation into an access denial for legitimate users. To reduce that risk, limit the initial scope, favor reversible actions, and assess the control's negative effects alongside its operational effectiveness.

Do not allow resending to become an unlimited escape route. When the user does not receive an OTP, retries can increase volume, create duplicates, and generate codes with overlapping validity periods. The flow must have clear rules for linking requests, preserving authentication limits, and deciding which secret remains valid according to policy.

SMS/PSTN has its own limitations and risks, including phishing, SIM swapping, number porting, and service redirection. A circuit breaker can improve sending continuity, but it does not remove those risks. Authentication decisions must retain their risk controls and alternative authenticators regardless of delivery status.

• Apply the circuit to the narrowest segment explained by the signals.
• Measure abandonment, retries, and verification failures after each activation.
• Do not reset authentication failure limits when issuing a new secret.
• Offer recovery paths and alternative authenticators for people who cannot use PSTN.
• Distinguish a messaging issue from a fraud signal or verification failure.

Recovery design: gradual testing, closing, and reversal

Recovery must be as explicit as opening. After the initial open period, the system may move into controlled testing if policy requirements are met. That test must have limited scope, enhanced observation, and immediate stop criteria if degradation signals reappear.

Do not close the circuit simply because time has passed. Require evidence in the same affected cohort: sufficient volume, expected acceptance behavior, delivery outcomes available within the applicable period, and the absence of the condition that caused the opening. If DLR observability is incomplete, do not declare delivery recovery based solely on the absence of errors.

A safe reversal prevents a fluctuating incident from turning the system into a poorly explainable sequence of openings and closings. Maintain an initial open duration, rules for re-entering testing, and a clear reopening condition. Record every transition.

• Enter testing only with prior, documented criteria.
• Release limited traffic within the exact cohort being tested.
• Observe the same signals that triggered opening, not only one favorable metric.
• Close after policy-defined stability and sufficient volume.
• Return to open if the degradation condition reappears.
• Review the configuration if the circuit repeatedly oscillates.