TLS poscuántico en AWS, Google Cloud y Azure: estado en 2026

Si tu empresa corre sobre AWS, Google Cloud o Azure, parte de su tráfico ya viaja con cifrado poscuántico y otra parte no, y muchas veces la diferencia está en una configuración que nadie ha cambiado. A noviembre de 2026, los tres proveedores y Cloudflare soportan el intercambio de llaves híbrido (un algoritmo clásico combinado con ML-KEM, el estándar del NIST publicado como FIPS 203) en al menos una parte de su borde. Solo una porción viene activada por defecto, y casi toda se queda en el borde.

AWS lo dice con claridad. Su plan de migración afirma que entregará la criptografía poscuántica “como parte de nuestro modelo de responsabilidad compartida”, y su portal poscuántico agrega que actualizar la configuración de los recursos a una política TLS con PQ “le corresponde al cliente”. Este artículo resume qué hace cada proveedor por ti, qué te toca activar y cómo comprobarlo.

¿Qué tráfico de la nube ya es poscuántico por defecto?

La tabla resume los servicios principales según la documentación de cada proveedor. “El cliente debe ofrecerlo” quiere decir que el servidor está listo, pero el intercambio solo es poscuántico si tu SDK, tu librería o tu navegador también proponen ML-KEM.

AWS: listo, pero muchas veces hay que activarlo

CloudFront es lo más fácil. El 5 de septiembre de 2025 AWS anunció que el soporte poscuántico “está disponible por defecto en todas las políticas de seguridad existentes, sin configuración del cliente” para las conexiones de los usuarios. Las conexiones de CloudFront hacia tu origen aparecen en la página de preparación de AWS como “próximamente”. El 30 de octubre de 2026 AWS agregó el encabezado CloudFront-Viewer-TLS-Details, con el que puedes medir cuántos de tus usuarios se conectan de verdad con intercambio poscuántico.

Los balanceadores son donde más equipos se quedan atrás. El anuncio del 21 de noviembre de 2025 dice que hay que actualizar de forma explícita los listeners HTTPS de ALB y los listeners TLS de NLB a una política PQ-TLS. La documentación recomienda ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 (y una variante FIPS) y deja ver una trampa: un listener nuevo creado desde la consola recibe una política poscuántica, pero uno creado con la CLI, CloudFormation o CDK recibe ELBSecurityPolicy-2016-08, que no lo es. Si tu infraestructura está definida como código, revisa las plantillas. En API Gateway (API REST) pasa lo mismo, con políticas como SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09.

Los endpoints de servicio de AWS están listos del lado del servidor. KMS, ACM y Secrets Manager incorporaron ML-KEM híbrido en abril de 2025, y la página de preparación de AWS ya incluye endpoints FIPS y no FIPS, con la nota de que el cambio es transparente pero los clientes deben actualizarse. Los endpoints regionales de S3 se sumaron el 19 de noviembre de 2025. Que tus llamadas lo usen depende del SDK. Según el blog de seguridad de AWS de abril de 2026, los SDK de Rust, Go y Node.js (y Kotlin en Linux) lo hacen por defecto en versiones recientes; Python necesita OpenSSL 3.5 o posterior instalado en el servidor, y Java necesita el cliente HTTP CRT con TLS poscuántico activado. En Secrets Manager lo confirmas en CloudTrail, donde el campo tlsDetails muestra X25519MLKEM768.

Dos detalles más. En abril de 2025 AWS anunció que retiraría en 2026 la opción preliminar basada en Kyber en todos sus endpoints, a favor de ML-KEM, así que los clientes atados a versiones viejas deben actualizarse. Y su plan no pone fecha final para el resto de servicios; solo dice “en los próximos años”.

Google Cloud: activo en lo de Google, con calendario para tus balanceadores

Google es el más avanzado en sus propios endpoints. Su hoja de ruta del 11 de agosto de 2026 dice que google.com y *.googleapis.com ya implementan ML-KEM (FIPS 203) en modo híbrido, y que la meta es estar completamente preparado para la era poscuántica en 2029. Una prueba que hicimos el 8 de noviembre de 2026 contra storage.googleapis.com con un cliente OpenSSL actual negoció X25519MLKEM768.

Tus balanceadores siguen un calendario publicado. La documentación de Google describe tres etapas: al principio, desactivado salvo que lo configures como ENABLED; después de octubre de 2026, activo por defecto salvo que elijas DEFERRED; y después de octubre de 2027, activo siempre. Aplica a siete tipos de balanceador y cubre solo las conexiones entre el cliente y el balanceador, no el tramo hacia tus backends. Cuando la revisamos en noviembre de 2026, la página todavía mostraba la primera etapa como la vigente, así que configura ENABLED de forma explícita en lugar de dar por hecho que el cambio ya ocurrió.

En llaves, Google anunció el 28 de julio de 2026 la disponibilidad general de las firmas cuánticamente seguras (ML-DSA y SLH-DSA) y del encapsulamiento de llaves ML-KEM en Cloud KMS.

Microsoft Azure: Front Door ya, lo demás después

La meta general de Microsoft se adelantó este año. El 30 de junio de 2026 escribió que el objetivo es pasar sus productos y servicios a criptografía poscuántica en 2029.

El cambio visible para los clientes de Azure es reciente. El 6 de noviembre de 2026 Microsoft anunció que en Azure Front Door el TLS 1.3 híbrido poscuántico queda activado por defecto, sin acción del cliente, con los grupos X25519MLKEM768 y SecP256r1MLKEM768. Protege el tramo entre el cliente y Front Door; el tramo de Front Door a tu origen todavía no.

En tus propios servidores Windows el soporte existe, pero apagado. La publicación de Microsoft del 14 de julio de 2026 dice que el TLS híbrido con ML-KEM ya está disponible de forma general en Windows 11 y Windows Server 2025, pero que los grupos poscuánticos no vienen activados por defecto. La misma publicación muestra cómo activarlos con PowerShell: Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0.

Las API de administración y de servicios de Azure van atrás. En un análisis publicado el 28 de mayo de 2026, Wiz escribió que no logró encontrar ningún servidor de API de Azure con este soporte, mientras que todos los de Google Cloud lo tenían. El mismo informe encontró intercambio poscuántico en apenas el 13% de los servidores de API de AWS en esa fecha, antes de una parte del despliegue de AWS en 2026. Nuestra prueba del 8 de noviembre contra management.azure.com todavía negoció un grupo clásico de curva elíptica.

Cloudflare: el más avanzado, incluidos los orígenes

Cloudflare informó el 23 de junio de 2026 que “más de dos tercios del tráfico de navegadores hacia la red de Cloudflare está protegido con cifrado poscuántico”. Desde el 21 de julio de 2026, su intercambio automático de llaves con los orígenes está activo en todas las zonas existentes y por defecto en las nuevas, y prefiere X25519MLKEM768 cuando el origen lo soporta. El límite está en tus servidores: Cloudflare escribió el 8 de septiembre de 2026 que la proporción de orígenes con soporte poscuántico pasó del 0,5% al 12,8%.

Por qué tus clientes y servidores deciden el resultado

Un intercambio híbrido solo ocurre cuando los dos extremos lo proponen, así que las librerías de tu plataforma pesan tanto como la nube.

• OpenSSL 3.5, publicado el 8 de abril de 2025, incorporó ML-KEM, ML-DSA y SLH-DSA y cambió los grupos que ofrece por defecto en TLS para incluir X25519MLKEM768 y X25519. Los servidores y los entornos, como Python, enlazados a versiones anteriores de OpenSSL siguen siendo clásicos.
• Go 1.24 activó ML-KEM híbrido por defecto cuando la aplicación no fija sus propias curvas.
• Java recibe el intercambio híbrido para TLS 1.3 con la JEP 527, incluida en JDK 27 en septiembre de 2026. Las aplicaciones en JDK anteriores no lo tienen en la librería estándar.
• Windows lo tiene en SChannel, pero desactivado, como vimos.

En la infraestructura típica de una empresa latinoamericana, con servicios Java en JDK viejos, servidores Windows y equipos locales detrás del borde de la nube, es ahí donde la mayoría de conexiones sigue siendo clásica.

¿Cómo compruebas si una conexión es poscuántica?

Cuatro revisiones cubren casi todos los casos:

1. OpenSSL 3.5 o posterior. Ejecuta openssl s_client -connect ejemplo.com:443 -servername ejemplo.com -tls1_3 -groups X25519MLKEM768. Si la salida incluye Negotiated TLS1.3 group: X25519MLKEM768, el servidor soporta el intercambio híbrido.
2. Navegador. En Chrome o Edge, abre las herramientas de desarrollo y el panel Security, que describe la conexión y su intercambio de llaves.
3. Registros del proveedor. El campo tlsDetails de CloudTrail para llamadas a la API de AWS, los registros de conexión del ALB y el encabezado de CloudFront para tus propios endpoints.
4. Tu inventario. Anota el resultado por endpoint, para que la próxima auditoría arranque con datos y no con suposiciones.

Qué hacer este trimestre

1. Lista todos los puntos de entrada expuestos a internet (CDN, balanceadores, API gateways) con su política TLS.
2. Pasa los balanceadores y API Gateway de AWS a políticas PQ, configura las políticas SSL de Google Cloud en ENABLED y confirma que los valores por defecto de Front Door y CloudFront te aplican.
3. Corrige los valores por defecto de tu infraestructura como código para que ningún listener nuevo nazca con ELBSecurityPolicy-2016-08.
4. Actualiza los clientes: OpenSSL 3.5 o posterior en los servidores, SDK de AWS al día, Go 1.24 o posterior, y un plan para los servicios en Java y Windows.
5. Mapea lo que está detrás del borde: orígenes, llamadas entre servicios, bases de datos, VPN y conexiones con aliados como pasarelas de pago y API de finanzas abiertas. Por ahí viajan los datos que la táctica de cosechar ahora, descifrar después pone en riesgo.
6. Pregúntales a tus proveedores de SaaS y de pagos cuándo van a ofrecer intercambio híbrido en sus endpoints.

Esta es la primera capa de la migración, y la más barata. Los certificados y las firmas vienen después y toman más tiempo, como contamos en qué es la criptografía poscuántica, y la lista de endpoints que armes aquí es el comienzo de tu inventario criptográfico. Si quieres una mirada externa sobre cómo está tu tráfico en la nube y en tus centros de datos, la evaluación de preparación cuántica lo cubre, y la migración a criptografía poscuántica lo lleva de las configuraciones a las firmas. Si trabajas en un banco o una fintech con API de finanzas abiertas, revisa también nuestra página de banca y finanzas.