La CNBV volvió a permitir el SMS como factor de autenticación, y 4 de 10 bancos mexicanos fallan en proteger su correo contra suplantación: lo que debe blindarse en la app misma

Desde el 2 de septiembre de 2026, los bancos mexicanos pueden volver a enviar códigos por SMS para autenticar ciertas operaciones digitales. Dos semanas después de que esa reforma entró en vigor, el 16 de septiembre, Proofpoint publicó que 42% de las principales instituciones financieras del país tiene huecos en la protección de su correo electrónico contra suplantación de identidad. Si tu empresa opera una app que mueve dinero (banco, fintech, aseguradora, marketplace con pagos), esto no es una nota de banca: es una señal de que el cumplimiento mínimo no es lo mismo que una aplicación endurecida.

Qué cambió realmente en la regulación

La Comisión Nacional Bancaria y de Valores publicó en el Diario Oficial de la Federación del 1 de septiembre de 2026 una resolución que modifica los artículos 319 Bis 2, 319 Bis 3 y 319 Bis 5 de las Disposiciones de carácter general aplicables a las instituciones de crédito. La reforma, vigente desde el 2 de septiembre, agrega el número de teléfono móvil como canal autorizado para entregar el Factor de Autenticación de Categoría 3, junto con el correo electrónico y la mensajería instantánea cifrada que ya estaban permitidos.

El alcance es acotado: aplica a servicios financieros digitales operados por comisionistas de base tecnológica (fintechs que operan cuentas de nivel 2, créditos de hasta 3,000 UDI, pagos de bienes y servicios, y movimientos de productos financieros contratados a través de ellas). No es una autorización general para toda la banca ni para cualquier monto. Tampoco es que el SMS "se prohibió" antes: la reforma lo reincorpora como opción, después de un periodo en que solo correo y mensajería cifrada estaban habilitados para ese factor.

El propio análisis que acompañó la reforma reconoce el riesgo: SMS depende de una infraestructura de telecomunicaciones diseñada hace décadas, es vulnerable a SIM swapping (transferir el número a otra tarjeta SIM mediante ingeniería social) y a smishing, y un código que llega por SMS puede mostrarse en la pantalla bloqueada del teléfono. La propia CNBV recomendó que las instituciones que usen SMS sumen "controles adicionales en monitoreo de fraude, protección del canal móvil y gestión de identidad". Es decir: la autoridad habilitó el canal y, en el mismo movimiento, dijo que no basta con habilitarlo.

Los números que sí están confirmados

Dos estudios independientes, publicados el mismo mes, dibujan el contexto en el que llega esta reforma.

Proofpoint analizó el correo electrónico de 54 instituciones financieras mexicanas usando DMARC, el estándar que autentica al remitente de un correo antes de que llegue al destinatario. El hallazgo: 91% tiene algún nivel de DMARC configurado, pero solo 58% (31 de las 54) usa la política más estricta, "Reject", que descarta directamente los correos que no pasan la verificación. Doce instituciones se quedan en "Quarantine" (los manda a spam, no los bloquea) y seis en "Monitor" (solo observan, no actúan). Cinco no tienen DMARC configurado. Es importante no confundir esto: el 42% no describe apps con código vulnerable, describe bancos que dejan la puerta de la suplantación por correo medio abierta, lo cual facilita el phishing que después empuja al usuario a instalar apps falsas o abrir enlaces maliciosos.

En paralelo, la Condusef reportó que las reclamaciones por cargos y transferencias no reconocidas subieron 18.1% interanual entre enero y julio de 2026: 42,791 casos contra 36,222 en el mismo periodo de 2025. Los consumos no reconocidos crecieron 27.7% y las transferencias electrónicas no autorizadas, 16.5%. De las reclamaciones ya resueltas a julio, 48% terminó a favor del usuario de la banca; 52% no.

Ninguno de estos dos estudios mide directamente la seguridad del código de las apps bancarias (fijación de certificados, resistencia a ingeniería inversa, detección de manipulación). Lo que sí muestran es el entorno: el canal de entrada (correo, SMS) tiene huecos conocidos, y el fraude que llega después de ese canal ya está creciendo de forma medible. Esa es la brecha que la aplicación misma tiene que cerrar, porque ni la CNBV ni Condusef la cierran por ti.

Por qué el MTU no resuelve esto

Desde octubre de 2025 existe otro control, distinto y complementario: el Monto de Transferencia Único (MTU), obligatorio desde enero de 2026. Cada usuario define un tope por operación (si no lo configura, aplica un default de 1,500 UDI, aproximadamente 12,800 pesos) para transferencias SPEI, CoDi o DiMo. Si una operación supera ese tope, el banco la bloquea o exige autenticación adicional.

El MTU es un control de negocio: limita cuánto dinero puede moverse en una sola operación. No es un control de la aplicación: no evita que un atacante clone el canal de comunicación con el servidor, extraiga las llaves criptográficas de la app en un dispositivo con jailbreak, o inyecte código en un binario sin protección de manipulación. Un atacante con control del dispositivo puede automatizar varias operaciones por debajo del MTU, o esperar a que la víctima lo eleve. El MTU reduce el daño de una sola transacción fraudulenta; no reduce la probabilidad de que el fraude ocurra desde dentro de la app. Son capas distintas y las dos hacen falta, pero una no sustituye a la otra. Sobre el otro lado de esta ecuación (el movimiento de dinero entre apps vía SPEI) ya escribimos cuando Banxico fijó su propio plazo en la Circular 9/2026 de Banxico: tu app mueve dinero entre usuarios por SPEI, y el 14 de diciembre es la fecha límite.

Qué revisar en tu propia aplicación

Si tu empresa opera una app transaccional, el cumplimiento regulatorio (MTU activo, DMARC en Reject, Categoría 3 funcionando) es el piso, no el techo. Antes de dar por cerrado el tema, hay cinco preguntas concretas que vale la pena llevar a tu equipo de TI o a tu proveedor:

1. ¿La app verifica el certificado del servidor más allá de la cadena de confianza del sistema operativo? Sin fijación de certificados (certificate pinning), un atacante en la misma red Wi-Fi puede interceptar el tráfico con un certificado falso y leer o modificar lo que la app envía, incluyendo el código de autenticación.
2. ¿La app detecta si corre en un dispositivo con root o jailbreak, y qué hace si lo detecta? Detectar no basta: hay que decidir si bloquea la operación, la limita o solo la reporta.
3. ¿El binario tiene protección contra ingeniería inversa? Un APK o IPA sin ofuscación ni verificación de integridad se puede descompilar, modificar y redistribuir como una versión falsa, justo el vector de malware que Proofpoint menciona junto a sus hallazgos de correo.
4. ¿Dónde vive el código de autenticación una vez que llega al teléfono? Si las notificaciones muestran el contenido completo en la pantalla bloqueada, cualquier persona con el teléfono en la mano (o malware con acceso a notificaciones) lo puede leer sin desbloquear nada.
5. ¿Cuándo fue la última vez que alguien hizo un análisis dinámico de la app, no solo una revisión de código? El análisis estático encuentra errores en el código; el dinámico encuentra qué pasa cuando la app corre en un entorno hostil, que es exactamente el escenario que importa aquí.

El marco de referencia para ordenar estas preguntas es OWASP MASVS, específicamente los controles de MASVS-NETWORK (fijación de certificados) y MASVS-RESILIENCE (anti-manipulación, detección de root/jailbreak, anti-debugging). Para una app que mueve dinero, el nivel de referencia suele ser MASVS-L2, que exige las cinco capas de arriba, no solo una.

Dónde esta lógica no aplica

No toda empresa con presencia móvil necesita este nivel de endurecimiento. Si tu app es informativa, de catálogo, o no mueve dinero ni datos financieros del usuario, invertir en fijación de certificados o resistencia a ingeniería inversa es gastar presupuesto en un riesgo que no tienes. La inversión se justifica cuando la app autentica operaciones, almacena credenciales o mueve fondos, no antes.

Tampoco conviene leer esta reforma como una señal de que el SMS es, en sí mismo, la causa del fraude. El SMS es un canal más débil que una app de autenticación o una llave física, pero sigue siendo mejor que no tener segundo factor en absoluto. El error no está en que la CNBV lo haya vuelto a permitir: está en que una empresa use ese permiso regulatorio como excusa para no revisar el resto del aplicativo. Y, al revés, blindar la app no vuelve innecesario vigilar el canal de entrada: una app perfectamente endurecida sigue siendo vulnerable si el correo que la acompaña no tiene DMARC en Reject, porque ahí es donde empieza buena parte del fraude que termina reportado ante Condusef.

Si tu aplicación todavía no ha pasado por una revisión de este tipo, una auditoría de seguridad de aplicaciones móviles es el punto de partida antes de la próxima auditoría regulatoria, no después.

Lo que vale la pena preguntarse no es si tu app cumple con la CNBV, sino si resistiría un intento real de manipulación en un dispositivo que ya no controlas. Si no tienes esa respuesta, adaptamos ese endurecimiento a tu aplicación actual, sin rehacerla desde cero.

Fuentes

• La CNBV flexibiliza la autenticación bancaria y vuelve a apostar por una tecnología vulnerable como el SMS
• 42% de los bancos en México tienen fallas de seguridad: levantan una alerta urgente por robo de datos en apps (Expansión)
• Quejas por cargos y transferencias no reconocidas suben 18.1%: Condusef
• CNBV flexibiliza autenticación en servicios bancarios digitales operados por comisionistas tecnológicos
• Qué es el MTU y por qué tu banco podría bloquear transferencias
• OWASP MASVS: Mobile Application Security Verification Standard