Durante la Security Week 2025, lanzamos la primera puerta de enlace web segura (SWG) poscuántica nativa de la nube y solución Zero Trust del sector, un paso importante para proteger el tráfico de la red empresarial enviado desde los dispositivos de los usuarios finales a las redes públicas y privadas.
Pero esto es solo una parte de la ecuación. Para proteger realmente el futuro de las redes empresariales, es necesario un perímetro de servicio de acceso seguro (SASE) completo.
Hoy completamos la ecuación: Cloudflare One es la primera plataforma SASE que admite el cifrado poscuántico (PQ) moderno que cumple con los estándares en nuestra Secure Web Gateway, y en todos los casos de uso de Zero Trust y red de área amplia (Cloudflare WAN). Más en concreto, Cloudflare One ahora ofrece ML-KEM (mecanismo de encapsulación de claves basado en una red modular) híbrido poscuántico en todos los principales de acceso de entrada y de salida.
Para completar la ecuación, agregamos soporte para el cifrado poscuántico a nuestro Cloudflare IPsec (nuestro WAN como servicio nativo de la nube) y Cloudflare One Appliance (nuestro dispositivo Cloudflare WAN físico o virtual que establece conexiones IPsec de Cloudflare). Cloudflare IPsec utiliza el protocolo IPsec para establecer túneles encriptados desde la red de un cliente hasta la red global de Cloudflare, mientras que IP Anycast se utiliza para enrutar de forma automática ese túnel al centro de datos de Cloudflare más cercano. Cloudflare IPsec simplifica la configuración y ofrece alta disponibilidad; si un centro de datos específico deja de estar disponible, el tráfico se redirige automáticamente al centro de datos en buen estado más cercano. Cloudflare IPsec se ejecuta a la escala de nuestra red global y admite conexiones de sitio a sitio a través de una Cloudflare WAN, así como conexiones salientes a Internet.
La actualización de Cloudflare One Appliance está disponible al publico general a partir de la versión 2026.2.0 del dispositivo. La actualización de Cloudflare IPsec está en versión beta privada, y puedes solicitar acceso agregando tu nombre a nuestra lista beta cerrada.
La importancia de la criptografía poscuántica hoy
Las amenazas cuánticas no son un problema de la "próxima década". Estos son los motivos por los que nuestros clientes están priorizando hoy la criptografía poscuántica (PQC):
Se acerca la fecha límite. A fines de 2024, el Instituto Nacional de Estándares y Tecnología (NIST) envió una señal clara (de la que se han hecho eco otras agencias): la era de la criptografía clásica de clave pública está llegando a su fin. El NIST fijó una fecha límite de 2030 para depreciar RSA y Elliptic Curve Cryptography (ECC) y hacer la transición a PQC que no puede ser descifrada por computadoras cuánticas potentes. Las organizaciones que no han comenzado su migración corren el riesgo de no estar cumpliendo con la norma y ser vulnerables a medida que se acerca la fecha límite.
Históricamente, las actualizaciones han sido complicadas. Si bien 2030 puede parecer lejano, actualizar los algoritmos criptográficos es notoriamente difícil. La historia nos ha demostrado que la depreciación de la criptografía puede llevar décadas: encontramos ejemplos de MD5 que generó problemas 20 años después de que fuera desaprobada. Esta falta de agilidad criptográfica, la capacidad de intercambiar fácilmente algoritmos criptográficos, es un cuello de botella importante. Al integrar el cifrado PQ directamente en Cloudflare One, nuestra plataforma SASE, brindamos agilidad criptográfica integrada, lo que simplifica la forma en que las organizaciones ofrecen acceso remoto y conectividad de sitio a sitio.
Es posible que los datos ya estén en riesgo. Por último, "Harvest Now, Decrypt Later" es una amenaza presente y persistente, en la que los atacantes captan hoy el tráfico de red confidencial y luego lo almacenan hasta que las computadoras cuánticas sean lo suficientemente potentes como para descifrarlo. Si tus datos tienen una vida útil de más de unos pocos años (p. ej., información financiera, datos de salud, secretos de estado) ya está en riesgo a menos que esté protegido por el cifrado de la PQ .
Las dos migraciones camino hacia la seguridad cuántica: acuerdo clave y firmas digitales
La transición del tráfico de red a la criptografía poscuántica (PQC) requiere una revisión de dos primitivas criptográficas: acuerdo de clave y firmas digitales.
Migración 1: establecimiento de claves. El acuerdo de clave permite que dos partes establezcan una confidencialidad compartida a través de un canal inseguro; la confidencialidad compartida se utiliza para cifrar el tráfico de red, lo que da como resultado un cifrado poscuántico. La industria ha convergido en gran medida en ML-KEM (mecanismo de encapsulación de claves basado en una red modular) como el protocolo estándar de acuerdo de claves PQ.
ML-KEM se ha adoptado ampliamente para su uso en TLS, generalmente implementado junto con la clásica Elliptic Curve Diffie Hellman (ECDHE), donde la clave utilizada para encriptar el tráfico de red se deriva de la combinación de los resultados de los acuerdos de clave ML-KEM y ECDHE. (Esto también se conoce como “ML-KEM híbrido”). Más del 60 % del tráfico TLS generado por humanos a la red de Cloudflare está actualmente protegido con ML-KEM híbrido. La transición al ML-KEM híbrido ha sido exitosa porque:
Como ML-KEM se ejecuta en paralelo con ECDHE clásico, no disminuye la seguridad y el cumplimiento normativo en comparación con el enfoque ECDHE clásico.
Migración 2: firmas digitales. Mientras tanto, las firmas digitales y los certificados protegen la autenticidad, y evitan que los adversarios activos suplanten el servidor ante el cliente. Lamentablemente, las firmas PQ son actualmente más grandes que los algoritmos ECC clásicos, lo que ha disminuído su adopción. Por fortuna, la migración a las firmas PQ es menos urgente, porque las firmas PQ están diseñadas para detener a los adversarios activos armados con potentes computadoras cuánticas, que aún no se sabe que existan. Por lo tanto, mientras Cloudflare está contribuyendo activamente a la estandarización y la implementación de las firmas digitales PQ, la actualización actual de IPsec de Cloudflare se centra en actualizar el establecimiento de claves a ML-KEM híbrido.
La Agencia de Ciberseguridad y Seguridad de Infraestructura (CISA) de los Estados Unidos reconoció la naturaleza de estas dos migraciones en su publicación de enero de 2026, "Categorías de productos para tecnologías que utilizan estándares de criptografía poscuántica".
Para lograr un SASE totalmente protegido con cifrado poscuántico, hemos actualizado nuestros productos Cloudflare IPsec para admitir ML-KEM híbrido en el protocolo IPsec.
El recorrido de la comunidad IPsec hacia la criptografía poscuántica ha sido muy diferente al de TLS. TLS es el estándar de facto para encriptar el tráfico público de Internet en la capa 4, por ejemplo, desde un navegador hasta una red de entrega de contenido (CDN), por lo que la seguridad y la interoperabilidad de los proveedores están en la vanguardia de su diseño. Mientras tanto, IPsec es un protocolo de capa 3 que suele conectar dispositivos creados por el mismo proveedor (por ejemplo, dos enrutadores), por lo que la interoperabilidad históricamente ha sido una preocupación menor. Con esto en mente, analicemos al recorrido de IPsec hacia el futuro cuántico.
¿Claves compartidas previamente? ¿Distribución de claves cuánticas?
RFC 8784, publicado en mayo de 2020, estaba destinado a ser la actualización poscuántica de IPsec Internet Key Exchange v2 (IKEv2), que se utiliza para establecer las claves simétricas utilizadas para encriptar el tráfico de red IPsec. RFC 8784 implica el uso de claves precompartidas de larga duración (PSK) o la distribución de claves cuánticas (QKD). Ninguno de estos enfoques es muy aceptable.
RFC 8784 propone combinar una PSK con una clave derivada de Diffie Hellman Exchange (DHE), que básicamente ejecuta PSK de forma híbrida con DHE. Este enfoque protege contra los atacantes que utilizan el ataque "harvest now, decrypt later", pero no ofrece confidencialidad hacia adelante contra los adversarios cuánticos.
La confidencialidad hacia adelante es un requisito estándar de los protocolos de acuerdo de claves. Garantiza que un sistema sea seguro incluso si se filtra la clave de larga duración. El enfoque de PSK en RFC 8784 es vulnerable a un adversario que utiliza el ataque "harvest now, decrypt later", que también obtiene una copia de un PSK de larga duración, y que luego puede descifrar el tráfico en el futuro (y rompe el acuerdo de clave DHE) una vez que las computadoras cuánticas potentes estén disponibles.
Para resolver este problema de la confidencialidad hacia adelante, se puede utilizar RFC 8784 para mezclar la clave del DHE clásico con una clave recién generada derivada de un protocolo QKD.
QKD utiliza la mecánica cuántica para establecer una clave criptográfica confidencial compartida entre dos partes. Es importante destacar que para que QKD funcione, las partes deben tener hardware especializado o estar conectadas mediante una conexión física dedicada. Esta es una limitación significativa, lo que hace que QKD sea inútil para casos de uso comunes de Internet, como conectar una computadora portátil a un servidor distante a través de Wi-Fi. Estas limitaciones también son la razón por la que nunca invertimos en la implementación de QKD para Cloudflare IPsec. La Agencia de Seguridad Nacional (NSA) de los Estados Unidos, el BSI de Alemania y el Centro Nacional de Ciberseguridad del Reino Unido también han advertido contra el uso exclusivo de QKD.
RFC 9370 llegó en mayo de 2023, y específico el uso del acuerdo de clave híbrida en lugar de PSK o QKD. Pero a diferencia de TLS, que solo admite el uso de ML-KEM poscuántico en paralelo con el DHE clásico, este estándar IPsec permite utilizar hasta siete acuerdos clave diferentes para ejecutarse al mismo tiempo en paralelo con el Diffie Helman clásico. Además, no especifica los detalles sobre cuáles deberían ser estos acuerdos clave, dejando que los proveedores elijan sus algoritmos e implementaciones. Palo Alto Networks, por ejemplo, se tomó esto en serio e incorporó un soporte para más de siete conjuntos de cifrado PQC distintos en su dispositivo de seguridad de red avanzado(NGFW), la mayoría de los cuales no interoperan con otros proveedores y algunos de los cuales aún no han sido estandarizados por el NIST.
A lo largo de los años, TLS fue en la dirección opuesta, y redujo el número de conjuntos de cifrado registrados de cientos en TLS 1.2 a unos cinco en TLS 1.3. Esta filosofía de reducir la "inflación de los conjuntos de cifrado" también está en consonancia con el SP 800 52 del NIST de 2019. La justificación para reducir la "inflación de los conjuntos de cifrado" incluye:
Interoperabilidad mejorada entre proveedores y regiones.
Menor riesgo de ataques que aprovechan las degradaciones a conjuntos de cifrado débiles.
Menor riesgo de problemas de seguridad debido a errores de configuración.
Menor riesgo de fallas de implementación al reducir el tamaño de la base de código.
Esta es la razón por la que no creamos soporte para RFC 9370 desde el inicio.
Estándares que van por el buen camino
También es por eso que nos entusiasmó que la comunidad de IPsec presentara draft-ietf-ipsecme-ikev2-mlkem. Este borrador de Internet estandariza el intercambio de PQ para IPsec de la misma manera que el intercambio de claves de PQ se ha implementado ampliamente para TLS: ML-KEM híbrido. El nuevo borrador llena los vacíos en RFC 9370, y especifica cómo ejecutar el ML-KEM como el intercambio de claves adicional en paralelo con el clásico Diffie Hellman en IKEv2.
Ahora que esta especificación está disponible, hemos avanzado en la compatibilidad con IPsec poscuántica en nuestros productos de Cloudflare IPsec.
Cloudflare IPsec con criptografía poscuántica
Cloudflare IPsec es una solución Cloudflare WAN, red como servicio, que reemplaza las arquitecturas de red privadas heredadas al conectar centros de datos, sucursales y VPC en la nube a la red IP Anycast global de Cloudflare.
Con Cloudflare IPsec, la red de Cloudflare actúa como el IKEv2 de primera intervención, y espera las solicitudes de conexión de un iniciador IPsec, que es un dispositivo conector de sucursal en la red del cliente. Cloudflare IPsec admite sesiones IPsec iniciadas por conectores de sucursales que incluyen nuestro propio Cloudflare One Appliance, junto con conectores de sucursales de un conjunto diverso de proveedores, como Cisco, Juniper, Palo Alto Networks, Fortinet, Aruba y otros.
Implementamos la compatibilidad de producción ML-KEM híbrida en el IKEv2 de primera intervención de Cloudflare IPsec, como se especifica en draft-ietf-ipsecme-ikev2-mlkem. El proyecto requiere un primer intercambio de claves para ejecutarse mediante un intercambio de claves Diffie Helman clásico. La clave derivada se utiliza para encriptar un segundo intercambio de claves que se ejecuta mediante ML-KEM. Por último, las claves derivadas de los dos intercambios se mezclan y el resultado se utiliza para proteger el tráfico del plano de datos en el modo IPsec ESP (carga útil de seguridad encapsulada). El modo ESP utiliza criptografía simétrica y, por lo tanto, ya es resistente a la computación cuántica sin ninguna actualización adicional. Hemos probado nuestra implementación con el precursor IPsec en la implementación de referencia de strongswan.
Se puede observar el conjunto de cifrado utilizado en la negociación de IKEv2 mediante los registros de Cloudflare Psec.
Elegimos implementar ML-KEM híbrido en lugar de ML-KEM "puro", es decir, solo ML-KEM sin DHE ejecutándose en paralelo, por dos razones. En primer lugar, hemos utilizado ML-KEM híbrido en todos nuestros otros productos de Cloudflare, ya que este es el enfoque adoptado en toda la comunidad TLS. Y, en segundo lugar, proporciona una seguridad de precaución: ML-KEM brinda protección contra ataques cuánticos "harvest now, decrypt later", mientras que DHE proporciona un algoritmo probado y verdadero contra adversarios no cuánticos.
Una invitación a la interoperabilidad
El valor total de esta implementación solo se puede obtener a través de la interoperabilidad. Por esta razón, invitamos a otros proveedores que están desarrollando la compatibilidad con iniciadores IPsec en sus conectores de sucursal según draft-ietf-ipsecme-ikev2-mlkem a probar nuestra implementación Cloudflare IPsec. Los clientes de Cloudflare que deseen probar la interoperabilidad con conectores de sucursales de terceros mientras estamos en la versión beta cerrada pueden registrarse aquí. Planeamos implementar la disponibilidad general y desarrollar la interoperabilidad con otros proveedores a medida que comiencen a incorporarse en línea con soporte para draft-ietf-ipsecme-ikev2-mlkem.
Hardware con seguridad cuántica: Cloudflare One Appliance
Muchos de nuestros clientes compran su conector para las sucursales (hardware o virtualizado) a Cloudflare, en lugar de a un proveedor externo. Por eso, Cloudflare One Appliance, nuestro dispositivo plug-and-play que conecta tu red local a Cloudflare One, también se ha actualizado con el cifrado poscuántico.
Cloudflare One Appliance no utiliza IKEv2 para el acuerdo de claves o el establecimiento de sesiones, sino que opta por confiar en TLS. El dispositivo inicia de forma periódica un protocolo de enlace TLS con el perímetro de Cloudflare, comparte una confidencialidad simétrica sobre la conexión TLS resultante, luego inyecta esa confidencialidad simétrica en la capa ESP de Cloudflare IPsec, que luego encripta y autentica el tráfico del plano de datos de Cloudflare IPsec. Este diseño nos permitió evitar el desarrollo de la lógica del iniciador IKEv2, y hace que el conector sea más fácil de mantener utilizando nuestras bibliotecas TLS existentes.
Por lo tanto, actualizar Cloudflare One Appliance a la encriptación PQ era solo cuestión de actualizar TLS 1.2 a TLS 1.3 con ML-KEM híbrido, algo que hemos hecho muchas veces en diferentes productos en Cloudflare.
¿Cómo activo esto? ¿Y cuál es el costo?
Como siempre, esta actualización a Cloudflare IPsec no tiene costo adicional para nuestros clientes. Porque creemos que una Internet segura y privada debe ser accesible para todos, tenemos la misión de incluir PQC en todos nuestros productos, sin hardware especializado, y sin costo adicional para nuestros clientes y usuarios finales.
Los clientes que utilizan Cloudflare One Appliance obtuvieron esta actualización a PQC en la versión 2026.2.0 (publicada el 11 de febrero de 2026). La actualización se envía automáticamente (sin necesidad de que el cliente realice ninguna acción) de acuerdo con la ventana de interrupción configurada de cada dispositivo.
Para los clientes que utilizan Cloudflare IPsec con el dispositivo conector de sucursal de otro proveedor, interoperaremos con estos una vez que haya más soporte para draft-ietf-ipsecme-ikev2-mlkem. También puedes contactarnos directamente para obtener acceso a la versión beta cerrada y solicitar que interoperemos con el conector de sucursales de un proveedor específico.
Panorama completo: SASE poscuántica
La propuesta de valor de una SASE poscuántica es clara: las organizaciones pueden obtener una protección inmediata de extremo a extremo para su tráfico de red privada enviándolo a través de túneles protegidos por ML-KEM híbrido. Esto protege el tráfico de los ataques de recolección actual y descifrado posterior, incluso si las aplicaciones individuales de la red corporativa aún no se han actualizado a la criptografía poscuántica (PQC).
El diagrama anterior muestra cómo se ofrece ML-KEM híbrido poscuántico en varias configuraciones de red de Cloudflare One. Incluye los siguientes accesos:
Y los siguientes accesos:
El siguiente diagrama destaca un ejemplo de configuración de red que utiliza el acceso de Cloudflare One Client para conectar un dispositivo a un servidor detrás de un acceso de salida de Cloudflare One Appliance. El dispositivo del usuario final se conecta a la red de Cloudflare (enlace 1) mediante MASQUE con ML-KEM híbrido. Luego, el tráfico viaja a través de la red global de Cloudflare a través de TLS 1.3 con ML-KEM híbrido (enlace 2). Luego, el tráfico sale de la red de Cloudflare a través de un enlace Cloudflare IPsec poscuántico (enlace 3) que termina en Cloudflare One Appliance. Por último, se conecta a un servidor dentro del entorno del cliente. El tráfico está protegido por la criptografía poscuántica cuando viaja por la Internet pública, incluso si el propio servidor no es compatible con la criptografía poscuántica.
Por último, observamos que el tráfico de acceso a Cloudflare One y luego sale a la red pública de Internet también puede estar protegido por nuestra puerta de enlace Cloudflare Gateway poscuántica, nuestra puerta de enlace web segura (SWG). Este diagrama muestra cómo funciona la SWG:
Como se mencionó en una publicación anterior del blog, nuestra SWG ya puede admitir ML-KEM híbrido en el tráfico de SWG al servidor de origen (siempre que el origen admita ML-KEM híbrido) y en el tráfico del cliente a la SWG (si el cliente admite ML-KEM híbrido, que es el caso de la mayoría de los navegadores modernos). Es importante destacar que cualquier tráfico que acceda a la SWG a través de un dispositivo que tenga instalado Cloudflare One Client sigue estando protegido con ML-KEM híbrido, incluso si el navegador web en sí aún no es compatible con la criptografía poscuántica. Esto se debe al túnel MASQUE post-cuántico que Cloudflare One Client establece en la red global de Cloudflare. Lo mismo ocurre con el tráfico que accede a la SWG a través de un túnel IPsec poscuántico de Cloudflare.
En resumen, Cloudflare One ahora ofrece cifrado poscuántico en nuestros accesos TLS, MASQUE y Cloudflare IPsec, y para el tráfico de la red privada, y para el tráfico de salida a la Internet pública a través de nuestra SWG.
El futuro es seguro para la cuántica
Al completar la ecuación SASE poscuántica con Cloudflare IPsec y Cloudflare One Appliance, hemos ampliado el cifrado poscuántico en todos nuestros principales accesos de entrada y de salida. Elegimos intencionalmente el camino de la interoperabilidad y la simplicidad, el enfoque híbrido ML-KEM que el IETF y el NIST han defendido, en lugar de encerrar a nuestros clientes en implementaciones propietarias, "inflación de conjuntos de cifrado" o actualizaciones de hardware innecesarias.
Esta es la promesa de Cloudflare One: una plataforma SASE que no solo es más rápida y confiable que las arquitecturas heredadas a las que reemplaza, sino que también ofrece cifrado poscuántico. Ya sea que estés protegiendo el navegador de un empleado remoto o el enlace de un centro de datos de varios gigabits, ahora puedes hacerlo con la confianza de que tus datos están protegidos de ataques de recolección actual y descifrado futuro y otras amenazas futuras.
Regístrate aquí para ver una demostración completa de nuestras funciones poscuánticas en la plataforma SASE de Cloudflare One, o regístrate aquí para entrar en la lista de la versión beta cerrada de Cloudflare IPsec. Estamos orgullosos de liderar la industria en esta nueva era de la criptografía, y te invitamos a unirte a nosotros en la creación de una Internet escalable, poscuántica y compatible con los estándares.