TLS 1.0 y 1.1 quedan fuera de Exchange Online desde julio de 2026: prepárate para evitar interrupciones en el correo

Microsoft anunció que a partir de julio de 2026 dejará de aceptar conexiones TLS 1.0 y 1.1 para clientes POP3 e IMAP4 en Exchange Online, una medida que cierra un capítulo de compatibilidad con protocolos ya obsoletos y que forma parte de un esfuerzo mayor para reducir vectores de ataque en el correo electrónico en la nube. Esto no es un cambio cosmético: las conexiones que usen TLS 1.0/1.1 simplemente fallarán, por lo que cualquier cliente o dispositivo que dependa de esas versiones dejará de poder acceder al buzón.

TLS 1.0 nació en 1999 y TLS 1.1 en 2006; durante años se han conocido debilidades y se han desarrollado mejores alternativas (TLS 1.2 y 1.3). La industria lleva tiempo moviéndose a TLS 1.2+, incluyendo compromisos públicos de fabricantes y navegadores desde 2018, y Microsoft ya documenta este paso en su comunicado técnico para Exchange Online; puedes leer los detalles en el blog oficial de Microsoft aquí: Deprecating legacy TLS and endpoints for POP and IMAP.

La buena noticia es que la mayoría de usuarios no deberían verse afectados: la mayor parte del tráfico POP/IMAP hacia Exchange Online ya usa TLS 1.2 o superior y los clientes modernos lo soportan. La mala noticia es que hay dispositivos embebidos, servicios legacy y aplicaciones personalizadas (impresoras, escáneres, cajas registradoras, software antiguo, bibliotecas OpenSSL/Curl anticuadas) que aún usan stacks viejos y podrían interrumpirse. Microsoft ha publicado orientación específica para quienes aún usan los endpoints legacy; esa guía técnica está en su documentación: Opt‑in Exchange Online endpoint for legacy TLS.

Desde el punto de vista operativo, el impacto real será la caída de sesiones TLS antiguas: los clientes obtendrán errores de conexión en lugar de entregas degradadas. Eso significa interrupción del servicio y potencial pérdida de productividad si no se actúa con tiempo. Además, mantener versiones viejas de TLS incrementa el riesgo de ataques por vulnerabilidades criptográficas y de seguridad del canal, por lo que la exclusión de esos protocolos reduce exposición a riesgos conocidos.

Si administras entornos con Exchange Online, comienza ya por identificar las dependencias. Comprueba los mensajes en el centro de administración de Microsoft y los registros de acceso para detectar clientes que usen versiones antiguas de TLS; en paralelo, revisa inventarios de dispositivos y las versiones de librerías criptográficas (por ejemplo OpenSSL). Herramientas de prueba como testssl.sh o el comando openssl s_client sirven para verificar qué versiones y suites acepta un cliente o servidor en pruebas internas. Para orientación oficial sobre configuraciones TLS seguras y recomendaciones de gobierno, la publicación de NIST es un buen punto de partida: NIST SP 800-52 Revision 2.

Las acciones concretas que conviene priorizar son claras: primero, hacer un inventario de clientes que usan POP/IMAP y detectar si dependen de TLS 1.0/1.1; segundo, actualizar sistemas operativos, clientes de correo y firmware de dispositivos para obtener soporte de TLS 1.2 o 1.3; tercero, donde sea posible, migrar clientes hacia protocolos y APIs modernos (por ejemplo MAPI sobre HTTP, EWS o Microsoft Graph con autenticación moderna) que además ofrecen mejores controles y autenticación basada en OAuth. Si tienes aplicaciones embebidas que no se pueden actualizar, planifica un reemplazo o una pasarela segura que termine TLS 1.2/1.3 para ellas y hable con Exchange con conexiones compatibles.

No dejes toda la preparación para último momento: prueba los cambios en un entorno controlado, comunica a usuarios y a proveedores de hardware con suficiente antelación, y establece un plan de contingencia para dispositivos críticos que deban seguir funcionando hasta su renovación. Documenta qué clientes migraron y conserva registros de pruebas para auditoría y soporte. Si no sabes identificar clientes legacy, pide a los proveedores que confirmen compatibilidad TLS y solicita un roadmap de actualizaciones.

Finalmente, considera este anuncio como una oportunidad para fortalecer la postura de seguridad: más allá de actualizar TLS, revisa la autenticación (evita credenciales en texto plano, adopta OAuth 2.0 cuando sea posible), fuerza cifrados fuertes y deshabilita suites y protocolos obsoletos en tu infraestructura. La transición a TLS 1.2+ no es solo cumplimiento: es reducción tangible de riesgo frente a intercepciones y ataques sobre la comunicación de correo. Si necesitas recursos técnicos para ejecutar pruebas y planificar la migración, las guías de Microsoft y NIST citadas arriba son puntos de partida fiables.