Designing SMS Verification for Delivery Reliability and Security

SMS one time passwords (OTPs) continue to serve as a practical authentication factor for phone verification, login flows, and multi factor authentication. However, the asynchronous nature of SMS delivery introduces failure modes that directly impact both security and user experience. Delivery delays, network issues, and carrier filtering can prevent codes from reaching users, while poorly designed retry mechanisms may create enumeration vulnerabilities or allow brute force attacks. This article examines how to design SMS verification around delivery reliability and retry risk using approaches aligned with NIST SP 800-63B and OWASP recommendations.

Understanding SMS Delivery Risk Factors

SMS delivery is not guaranteed. Carriers apply spam filtering, number validation, and regional restrictions that can silently drop messages. Temporary carrier outages, number portability delays, and VoIP number blocks further increase failure rates. When designing verification flows, applications must account for these failure modes rather than assuming every SMS reaches the intended device.

NIST SP 800-63B addresses out of band authentication including SMS OTPs and specifies requirements for authenticator lifecycle, retry limits, and rate limiting. The standard emphasizes that authentication codes delivered via SMS should be treated as resistant to interception but vulnerable to delivery failures and certain attack vectors. Proper implementation requires attention to code lifetime, attempt limits, and retry backoff to maintain security without degrading usability.

Authenticators that use out of band or OTP messages SHOULD be rate limited and require the authenticator to be proof of possession of a specific device.

Configuring Code Lifetime and Attempt Limits

One of the primary security controls for SMS OTP is limiting both the validity window and the number of verification attempts. NIST specifies that authentication codes should have a limited lifetime to reduce the window of opportunity for intercepted codes to be useful. OWASP recommends codes expire within 5 to 10 minutes for verification flows, though shorter windows may be appropriate for high security contexts.

Attempt limits complement lifetime controls by preventing brute force attacks on the code itself. When a user enters an incorrect code, the system should track attempts and lock the verification flow after a reasonable threshold, typically 3 to 5 failed attempts. After lockout, users should be required to request a new code rather than continue attempting against the same challenge.

• Set code expiration between 5 and 10 minutes for standard verification flows
• Limit verification attempts to 3 to 5 tries before requiring a new code
• Track attempts per challenge identifier, not per phone number alone
• Implement progressive backoff for repeated failed requests

Retry Logic and Delivery Failure Handling

When SMS delivery fails, users naturally attempt to resend the code. Poorly designed retry mechanisms can create security vulnerabilities. Specifically, rapid retry buttons without rate limiting enable automated attacks, while exposing whether a phone number is registered in your system creates enumeration risk. OWASP explicitly warns against revealing whether an account exists through authentication error messages or timing differences.

Rate limiting should apply at multiple layers. First, limit how frequently a user can request a new code from the same phone number or account. Second, apply global rate limits across your SMS delivery infrastructure to prevent abuse. Third, consider per carrier rate limits if your SMS provider exposes delivery statistics, since excessive requests to numbers on carriers with poor delivery rates may indicate issues.

The Own Auth package implements SMS OTP verification with configurable code lifetime, attempt limits, and rate limiting built into the flow. When using auth.requestSmsOtp, the package stores the generated code as a hash and enforces configured limits before returning any status to the caller. The verification endpoint auth.verifySmsOtp applies the same controls, returning appropriate statuses rather than exposing user existence through timing or error message differences.

import { createOwnAuth, defineOwnAuthConfig } from 'own-auth';

const auth = createOwnAuth(
  defineOwnAuthConfig({
    sms: {
      codeLength: 6,
      codeExpirySeconds: 300,
      maxVerificationAttempts: 5,
      rateLimit: {
        maxRequests: 3,
        windowSeconds: 60,
      },
    },
  })
);

Handling Delivery Failures Gracefully

When SMS delivery fails repeatedly, provide users with alternative verification methods rather than leaving them locked out. Email fallback, voice call delivery, or time based one time passwords (TOTP) through authenticator apps represent viable alternatives. The key principle is that delivery failure should not prevent legitimate users from completing authentication.

Security Considerations Beyond Delivery

While delivery reliability is critical, SMS OTP security extends beyond transport. NIST notes that SMS is considered a weaker authentication channel compared to cryptographic authenticators or platform bound credentials. Organizations should understand these limitations when selecting authentication factors and should implement additional controls for high value accounts.

1. Use unique per session codes rather than predictable or sequential values
2. Hash stored OTP values to prevent database compromise from exposing valid codes
3. Require re authentication before changing phone numbers or enabling SMS OTP
4. Monitor for anomalous patterns such as multiple codes sent to the same number in short succession

Phone number verification alone does not prove possession of the device, since numbers can be ported or SIM swapped through social engineering or carrier insider threats. For higher security contexts, consider requiring proof of possession through a separate channel or combining SMS OTP with a device fingerprint or behavioral signal.

Implementation Summary

Designing SMS verification around delivery and retry risk requires balancing reliability with security controls. Configure appropriate code lifetimes and attempt limits to reduce attack surface while allowing legitimate users sufficient time and attempts. Implement rate limiting at multiple levels to prevent abuse without revealing account existence. Provide fallback options when delivery consistently fails, and monitor delivery metrics to identify carrier or regional issues. By following these practices and leveraging framework provided controls, applications can maintain usable authentication flows while adhering to NIST and OWASP guidance.