Presupuesto de latencia para OTP por SMS: cómo definir expiración y objetivos sin depender de la media
Aprenda a descomponer, medir y gobernar la latencia de un OTP por SMS con percentiles, segmentación y señales funcionales, sin confundir aceptación, DLR y uso real del código.
Qué problema resuelve un presupuesto de latencia en un flujo OTP por SMS
Un presupuesto de latencia OTP SMS convierte una expectativa imprecisa —«el código debe llegar rápido»— en un modelo operativo medible. Su función es separar las etapas del recorrido, asignar responsables, elegir señales observables y decidir cuánto tiempo permanece válido un código sin basarse en una entrega media global.
En un flujo de autenticación fuera de banda, el verificador genera un secreto temporal, lo envía por un canal secundario como SMS y la persona usuaria lo devuelve por el canal primario. Por tanto, el recorrido relevante no acaba cuando una plataforma acepta la solicitud de envío ni necesariamente cuando llega un informe de entrega: termina cuando el verificador acepta una presentación válida del OTP.
El presupuesto sirve para tomar decisiones de producto y operación: definir una expiración razonable, establecer cuándo mostrar la opción de reenvío, detectar degradación por destino o ruta y evitar atribuir a la red móvil una demora originada en la aplicación o en una cola interna.
- Defina el resultado funcional como la validación exitosa del OTP, no sólo como el envío del mensaje.
- Modele las etapas por separado antes de fijar cualquier objetivo de tiempo.
- Mida por segmentos operativos; un valor global puede ocultar degradaciones concentradas.
- Mantenga la seguridad como restricción del diseño: el código debe ser temporal y aceptarse una sola vez.
Por qué la latencia media no sirve para fijar la expiración de un código
La media responde mal a una pregunta de producto crítica: cuánto tiempo necesitan la gran mayoría de usuarios legítimos para completar el flujo. Un conjunto de entregas rápidas puede reducir la media aunque exista una cola significativa de experiencias lentas. Si la expiración se fija con esa media, los casos de cola expiran de forma recurrente aunque el indicador agregado parezca saludable.
La expiración tampoco representa únicamente el transporte del SMS. Debe cubrir el tiempo desde la creación del secreto hasta su introducción y validación, incluidos el procesamiento interno, la transmisión, la posible demora de red, la disponibilidad del terminal y el tiempo de la persona usuaria para leer e introducir el código.
NIST indica que, en OTP basados en tiempo, la vida útil debe considerar la deriva de reloj esperada, una tolerancia para el retardo de red y el tiempo de introducción por el usuario. Este principio evita diseñar una expiración con una única medida de latencia de proveedor o ruta.
- No use la media como criterio principal de expiración ni como único SLO.
- Observe percentiles altos de tiempo hasta la validación, junto con tasas de éxito y expiración.
- Analice ventanas temporales comparables, no sólo agregados históricos.
- Diferencie entre un retraso de transporte y una validación tardía causada por la interacción de la persona usuaria.
Definiciones operativas y marcas de tiempo mínimas
Antes de medir, defina cada evento con precisión y registre su marca temporal. Las definiciones ambiguas generan comparaciones inválidas entre equipos, proveedores o destinos. Use un identificador de correlación interno para el intento de autenticación y un identificador de mensaje para el envío, manteniendo los datos de correlación no sensibles.
Una secuencia práctica parte de la creación del OTP y de su asociación con la transacción de autenticación. Después registra la solicitud al canal de envío, la aceptación de esa solicitud por API o SMPP, los eventos de encolado y envío disponibles, cualquier DLR recibido y, finalmente, la validación correcta o fallida del código.
La aceptación por API o SMPP sólo acredita que el proveedor recibió correctamente el comando o solicitud. No acredita que el SMS haya llegado al dispositivo. De igual forma, un DLR es una señal asíncrona cuyo significado depende del informe recibido y de la cadena de entrega; debe conservarse como evidencia operativa, sin tratarlo como prueba de lectura ni como reloj definitivo de entrega.
- t0: creación del OTP y apertura de su periodo de validez.
- t1: solicitud de envío emitida por la aplicación.
- t2: aceptación por API o SMPP y asignación del identificador de mensaje, si existe.
- t3: eventos de envío o de cambio de estado disponibles en la plataforma.
- t4: recepción del DLR y, cuando se facilite, las marcas temporales e intentos contenidos en el propio informe.
- t5: presentación y validación exitosa del OTP, o registro de expiración, fallo o abandono.
Qué partes controla cada actor
El emisor controla el diseño de la experiencia, la generación del código, la creación de la solicitud, el comportamiento de la aplicación, sus propias colas, las reglas de expiración, los límites de intento y la instrumentación. También puede elegir la conectividad disponible, definir políticas por destino y actuar sobre rutas conforme a sus acuerdos y controles operativos.
El proveedor de mensajería y los intermediarios controlan partes de la aceptación, el tratamiento y la entrega hacia las redes conectadas, según la arquitectura y los acuerdos aplicables. La red móvil controla elementos del encaminamiento y de la entrega reportada dentro de su dominio. El terminal, la cobertura disponible, el estado del dispositivo y la conducta de la persona usuaria quedan fuera del control directo del emisor.
Esta separación debe reflejarse en el diagnóstico. Si sube el tiempo entre creación y aceptación, investigue primero la aplicación o la conectividad de salida. Si la aceptación se mantiene estable pero cambia la distribución de DLR o validaciones para un destino, investigue el segmento afectado sin concluir que un único evento prueba la causa.
- Aplicación: generación, almacenamiento seguro, expiración, UI, solicitud y validación.
- Conectividad de envío: aceptación, respuesta técnica e identificadores de mensaje.
- Ruta y red móvil: tratamiento de entrega y señales de estado que puedan ser reportadas.
- Terminal y usuario: disponibilidad práctica del código, lectura e introducción.
- Verificador: decisión final de aceptar o rechazar el OTP presentado.
Cómo construir un presupuesto de latencia por etapas
Construya el presupuesto desde el resultado que importa: una validación válida antes de expirar. Empiece reuniendo eventos de intentos reales de autenticación, con correlación entre el intento, el mensaje y el resultado de verificación. Excluya de la definición los eventos que no puedan vincularse de forma fiable, pero cuantifique esa falta de correlación como una limitación de observabilidad.
Calcule distribuciones para cada intervalo: creación a solicitud, solicitud a aceptación, aceptación a cualquier señal posterior disponible y creación a validación exitosa. Mantenga por separado los intentos validados, los expirados, los abandonados, los fallidos y aquellos en los que el código fue incorrecto. Mezclarlos en una sola serie oculta problemas de seguridad, UX y entrega.
El presupuesto final no es una promesa de que todos los mensajes se completarán dentro de un tiempo fijo. Es una política: una ventana de validez acompañada de límites de reenvío, controles de intentos, alternativas de autenticación cuando proceda y umbrales de operación por segmento.
- 1. Defina el evento de inicio: normalmente la creación del OTP.
- 2. Defina el evento funcional de fin: validación exitosa por el verificador.
- 3. Registre intervalos intermedios con marcas temporales distinguibles.
- 4. Clasifique el desenlace de todos los intentos.
- 5. Calcule percentiles por segmento y ventana temporal.
- 6. Fije la expiración considerando transporte, interacción humana y requisitos de seguridad.
- 7. Revise la política tras cambios de ruta, producto, conectividad o comportamiento de tráfico.
Percentiles, ventanas temporales y segmentación por destino
Use percentiles para describir la distribución, no sólo un punto central. Los percentiles de tiempos hasta validación ayudan a observar la experiencia de la parte más lenta de los usuarios que completan el flujo. Deben leerse junto con la proporción de intentos que expiran, la tasa de validación y el volumen, porque un percentil calculado sobre pocas observaciones puede ser inestable.
Segmente al menos por destino. Cuando los datos y el volumen lo permitan, añada dimensiones útiles para operar: ruta, remitente, tipo de número, tipo de tráfico, versión de la aplicación o política de riesgo. No mezcle segmentos que tienen comportamientos diferentes y después espere que un único umbral global explique la causa de una desviación.
Compare cada segmento con su propia línea base en ventanas temporales coherentes. Una ventana demasiado corta reacciona a ruido; una excesivamente larga puede retrasar la detección. Establezca además un volumen mínimo de observaciones antes de tomar decisiones automatizadas o escalar una alerta.
- Mida el tiempo de creación a validación como métrica funcional principal.
- Mida creación a aceptación para aislar demoras internas o de conectividad.
- Conserve DLR y sus marcas como telemetría complementaria, no como sustituto de la validación.
- Analice porcentaje de expiraciones, reenvíos, intentos fallidos y validaciones exitosas junto con los tiempos.
- Exija suficiente volumen antes de comparar percentiles entre segmentos.
Expiración, reenvío, límites de solicitud y prevención de duplicados
La ventana de expiración debe ser suficientemente amplia para cubrir la experiencia legítima prevista, pero no debe convertirse en una sustitución de controles de seguridad. Para autenticación fuera de banda cubierta por NIST, la transacción debe completarse dentro de 10 minutos y un secreto dado sólo puede aceptarse una vez durante su periodo de validez. Aplique siempre los requisitos regulatorios, contractuales y de riesgo que correspondan a su caso de uso.
El reenvío no debe crear una tormenta de mensajes ni ampliar indefinidamente la superficie de ataque. Antes de emitir otro SMS, compruebe si existe un OTP vigente asociado a la misma transacción y decida explícitamente si se reutiliza, se invalida y sustituye, o se limita la solicitud. La política debe ser consistente para que no haya varios códigos ambiguos activos sin una regla clara de validación.
Para secretos cortos, limite efectivamente los intentos fallidos consecutivos. La emisión de un secreto nuevo no debe reiniciar el contador de fallos. Puede usar esperas progresivas y señales de riesgo para endurecer el flujo cuando aparezcan patrones anómalos, manteniendo alternativas de autenticación cuando el riesgo, la cobertura o la accesibilidad lo requieran.
- Mantenga un único estado autoritativo por transacción de autenticación.
- Haga que cada OTP sea de uso único.
- Defina una política explícita sobre qué ocurre con el OTP anterior tras un reenvío.
- Limite solicitudes de reenvío por cuenta, sesión, destino y señales de riesgo pertinentes.
- No reinicie los límites de intentos fallidos al emitir un código nuevo.
- Ofrezca alternativas de autenticación cuando SMS/PSTN no sea adecuado o no esté disponible.
Qué puede indicar un DLR y qué no puede demostrar
Un DLR puede aportar información operativa útil: estado reportado, intentos de entrega y, según la interfaz, marcas temporales del intento y de la recepción del informe. Es valioso para investigar tendencias y para separar una respuesta técnica inicial de un estado de entrega comunicado posteriormente.
Sin embargo, el DLR no demuestra por sí solo que la persona usuaria haya leído, comprendido o introducido el código. Tampoco debe utilizarse como el reloj para decidir de forma inmediata que existe un retraso de entrega. Los recibos o eventos generados por operadores pueden llegar tarde; la documentación de AWS advierte que pueden recibirse hasta 72 horas después y que no deben emplearse para determinar un retraso de entrega saliente.
La validación exitosa del OTP es una señal funcional más fuerte: demuestra que el código llegó a estar disponible para la persona usuaria y fue presentado al verificador. Aun así, no convierte el DLR en irrelevante; ambas señales responden a preguntas distintas y deben conservarse separadas.
- Aceptación de envío: el comando o solicitud fue recibido correctamente.
- DLR: resultado de entrega reportado de forma asíncrona, con incertidumbre de tiempo y alcance.
- Validación exitosa: evidencia funcional de que el código fue presentado correctamente al verificador.
- Ausencia de DLR: no debe interpretarse automáticamente como ausencia de entrega.
- DLR Delivered: no prueba lectura ni introducción correcta del código.
Preguntas frecuentes
¿Qué métrica debe guiar la expiración de un OTP por SMS?
La referencia más útil es la distribución del tiempo desde la creación del OTP hasta su validación exitosa, segmentada por destino y otras dimensiones operativas relevantes. Debe complementarse con tasas de expiración, reenvío y fallo, no con una media de entrega aislada.
¿La aceptación por API o SMPP significa que el SMS llegó al teléfono?
No. Indica que el comando o solicitud fue recibido correctamente por el sistema que lo acepta. No demuestra recepción en el dispositivo de destino.
¿Un DLR Delivered prueba que el usuario recibió y leyó el OTP?
No. Un DLR representa un resultado de entrega reportado y puede ser útil como señal operativa, pero no prueba lectura, comprensión ni introducción del código. La validación exitosa es la señal funcional más fuerte.
¿Cuánto debe durar un OTP enviado por SMS?
No existe una duración universal que pueda deducirse de una media de entrega. Defínala a partir de la distribución de tiempos hasta validación, el tiempo de interacción esperado, el riesgo y los requisitos aplicables. Para la autenticación fuera de banda cubierta por NIST, la transacción debe completarse dentro de 10 minutos.
¿Debe generar un código nuevo cada vez que el usuario solicita un reenvío?
Debe existir una política explícita. Si se genera uno nuevo, defina qué ocurre con el anterior para evitar ambigüedad y no reinicie los controles de intentos fallidos. También conviene limitar las solicitudes de reenvío y aplicar esperas o medidas adaptativas cuando corresponda.
¿Cómo detectar degradación de una ruta OTP?
Compare percentiles de tiempo hasta validación, tasas de expiración, reenvíos y señales de entrega contra una línea base propia, segmentando por destino, ruta, remitente u otras dimensiones disponibles. Exija volumen suficiente y una desviación sostenida antes de atribuir un pico aislado a un problema de ruta.
Fuentes consultadas
- 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