Criptografía poscuántica para webs: qué cambia en HTTPS y cómo prepararse desde ahora

La computación cuántica todavía no ha roto HTTPS ni permite descifrar de forma práctica el tráfico de una web moderna. Sin embargo, la transición criptográfica ya ha empezado. En 2024, el NIST publicó sus primeros estándares poscuánticos; en 2025, la Unión Europea presentó una hoja de ruta coordinada y, en 2026, proveedores de infraestructura como Cloudflare ya ofrecen acuerdos de claves híbridos resistentes a futuros ataques cuánticos. La criptografía poscuántica para webs ha dejado de ser una conversación puramente académica.

Esto no significa que debamos instalar mañana un «plugin cuántico» en WordPress ni sustituir por nuestra cuenta los certificados TLS. La migración afecta a varias capas: intercambio de claves, firmas digitales, certificados, SSH, copias de seguridad, software firmado, proveedores cloud y dispositivos que pueden permanecer muchos años en funcionamiento. Algunas de esas capas ya están bastante maduras; otras continúan en proceso de estandarización e implantación.

Para una empresa pequeña o un profesional web, la estrategia sensata en 2026 no es intentar implementar nuevos algoritmos manualmente, sino entender dónde está el riesgo, elegir proveedores con una hoja de ruta clara y evitar decisiones que nos dejen atrapados en sistemas criptográficos difíciles de actualizar. El objetivo de este artículo es separar la amenaza real del ruido y traducir la criptografía poscuántica a decisiones prácticas para webs y servicios digitales.

Qué amenaza exactamente un ordenador cuántico

Gran parte de la seguridad actual depende de criptografía de clave pública. Cuando abrimos una web mediante HTTPS, diferentes mecanismos permiten autenticar el servidor y establecer secretos compartidos que después protegen la sesión con cifrado simétrico. Otros sistemas utilizan criptografía asimétrica para firmar software, verificar actualizaciones, proteger conexiones SSH o demostrar la identidad de una entidad.

Los grandes ordenadores cuánticos tolerantes a fallos, si llegan a alcanzar la escala necesaria, podrían ejecutar algoritmos capaces de resolver eficientemente determinados problemas matemáticos sobre los que descansan sistemas como RSA y la criptografía de curva elíptica. El problema no afecta del mismo modo a todo el cifrado: algoritmos simétricos modernos pueden adaptarse aumentando tamaños de clave, mientras que muchos esquemas de clave pública necesitan ser sustituidos.

Por eso el programa de criptografía poscuántica del NIST lleva años seleccionando algoritmos basados en problemas matemáticos distintos. En agosto de 2024 se publicaron tres estándares principales: FIPS 203 para ML-KEM, destinado al establecimiento de claves, y FIPS 204 y FIPS 205 para firmas digitales mediante ML-DSA y SLH-DSA.

El propio NIST recomienda que las organizaciones empiecen ya a aplicar los nuevos estándares y a planificar la migración. Eso no equivale a afirmar que exista hoy un ordenador cuántico capaz de romper Internet. Significa que una transición criptográfica de esta magnitud necesita años de pruebas, despliegues, compatibilidad y renovación de productos.

El riesgo «harvest now, decrypt later» cambia el calendario

Una de las razones para actuar antes de que exista una máquina cuántica criptográficamente relevante es el denominado harvest now, decrypt later: recopilar hoy información cifrada con la esperanza de descifrarla en el futuro.

Imaginemos una organización que transmite planos industriales, historiales, propiedad intelectual o datos personales cuya confidencialidad debe mantenerse durante diez o veinte años. Un atacante puede no ser capaz de leerlos ahora, pero sí almacenar tráfico capturado. Si dentro de ese periodo aparece una capacidad cuántica suficiente y el intercambio de claves utilizado era vulnerable, parte de esa información histórica podría quedar expuesta.

Este riesgo no afecta por igual a todos los datos. Una sesión de una web informativa cuyo contenido es público tiene poco valor retrospectivo. En cambio, comunicaciones corporativas, credenciales, información sanitaria, secretos comerciales o determinadas transacciones pueden necesitar confidencialidad prolongada. Por eso las estrategias oficiales recomiendan inventariar qué información debe seguir protegida durante más tiempo.

La guía conjunta de CISA, NSA y NIST sobre preparación cuántica insiste precisamente en crear un inventario de los sistemas que utilizan criptografía vulnerable y relacionarlo con la criticidad y la vida útil de los datos. No se trata de cambiar algoritmos a ciegas, sino de saber dónde están nuestras dependencias.

ML-KEM, ML-DSA y SLH-DSA: los nombres que empiezan a importar

ML-KEM para establecer secretos

FIPS 203 define ML-KEM, un mecanismo de encapsulación de claves basado en retículas. Su función es permitir que dos partes establezcan un secreto compartido a través de un canal público. Ese secreto puede utilizarse después con criptografía simétrica para cifrar comunicaciones.

ML-KEM se deriva del algoritmo CRYSTALS-Kyber seleccionado durante el proceso del NIST. El estándar contiene tres conjuntos de parámetros —ML-KEM-512, ML-KEM-768 y ML-KEM-1024— con diferentes equilibrios entre seguridad y rendimiento. En despliegues web actuales aparece con frecuencia ML-KEM-768 dentro de mecanismos híbridos.

ML-DSA y SLH-DSA para firmas

Las firmas digitales resuelven otro problema: verificar autenticidad e integridad. FIPS 204 estandariza ML-DSA, basado en CRYSTALS-Dilithium, mientras que FIPS 205 define SLH-DSA, basado en SPHINCS+. Tener familias diferentes aporta diversidad criptográfica y evita depender de una única construcción matemática.

La transición de firmas es especialmente importante porque afecta a certificados, PKI, software firmado, firmware y raíces de confianza. Es también una parte más compleja de desplegar de extremo a extremo que el simple acuerdo de claves de una conexión TLS.

Por qué se están usando sistemas híbridos

Durante una transición de esta escala no resulta prudente abandonar de golpe los algoritmos clásicos que llevan años analizados. Por eso una estrategia habitual consiste en combinar un mecanismo tradicional y otro poscuántico.

En TLS 1.3, uno de los grupos híbridos que está ganando protagonismo combina X25519 con ML-KEM-768. La idea es que el secreto de la conexión dependa de ambos componentes. Si la parte clásica fuese vulnerable en el futuro pero ML-KEM continuase siendo segura, la confidencialidad seguiría protegida; si apareciese un problema inesperado en el componente poscuántico, el mecanismo tradicional seguiría aportando defensa frente a atacantes convencionales.

El IETF trabaja en la estandarización de estos mecanismos. En julio de 2026 se publicó una nueva revisión del borrador ML-KEM Post-Quantum Key Agreement for TLS 1.3. Es importante llamarlo por su nombre correcto: sigue siendo un Internet-Draft y, por tanto, un documento de trabajo, no un RFC definitivo.

Los esquemas híbridos son una transición, no necesariamente el estado final de toda la infraestructura. Su valor reside en permitir despliegues graduales sin exigir que cada cliente, servidor, certificado y dispositivo cambie simultáneamente.

Qué está ocurriendo ya en la web real

La criptografía poscuántica no es únicamente una futura especificación. Algunos grandes proveedores ya utilizan acuerdos de claves híbridos en producción. Cloudflare, por ejemplo, documenta soporte para X25519MLKEM768 y está ampliando el uso de firmas ML-DSA en determinados productos. Su documentación de criptografía poscuántica en SSL/TLS, actualizada en julio de 2026, explica que uno de los objetivos es reducir precisamente el riesgo de captura hoy y descifrado posterior.

Eso no significa que una web detrás de un CDN pueda anunciarse automáticamente como «100 % poscuántica». Una conexión HTTPS incluye varias piezas. El acuerdo de claves puede ser híbrido y resistente frente a un futuro adversario cuántico, mientras que la autenticación del certificado siga utilizando una firma clásica. También puede existir protección poscuántica entre navegador y edge, pero no entre el edge y el servidor de origen.

Cloudflare ya permite en determinados escenarios utilizar X25519MLKEM768 entre su red y el servidor de origen, además de opciones relacionadas con firmas ML-DSA. Aun así, la disponibilidad depende de productos, software y configuración concreta. La lección importante es que debemos hablar de qué tramo y qué función criptográfica están protegidos, en vez de aplicar una etiqueta global a todo el sitio.

Europa ya ha fijado una dirección de migración

Para una web profesional en España, la hoja de ruta europea es especialmente relevante. En junio de 2025, los Estados miembros, con apoyo de la Comisión, publicaron una hoja de ruta coordinada para la transición a criptografía poscuántica.

La Comisión comunicó que los Estados miembros deberían comenzar la transición a finales de 2026 y que la protección de infraestructuras críticas debería migrar lo antes posible, con el objetivo de hacerlo no más tarde de finales de 2030. Esos hitos están orientados principalmente a administraciones, infraestructuras y sectores estratégicos, no significan que cada pyme deba reemplazar sus certificados antes de esas fechas.

Lo relevante para cualquier empresa es la señal: la transición ya forma parte de la planificación institucional europea. Los productos cloud, sistemas operativos, navegadores, librerías, dispositivos de red y proveedores de certificados evolucionarán condicionados por ese calendario.

Qué significa todo esto para una web WordPress

En una instalación WordPress habitual, la mayor parte de la criptografía de transporte no la implementa WordPress. HTTPS depende del servidor web, de OpenSSL u otra biblioteca TLS, del proveedor de alojamiento, del proxy o CDN y del navegador del visitante. Por eso instalar un plugin de WordPress no convierte por sí mismo una conexión en resistente a ataques cuánticos.

Esto es una buena noticia. Para la mayoría de profesionales y pequeñas empresas, la migración llegará principalmente a través de actualizaciones de infraestructura y proveedores. El NCSC británico indica que, en muchas pymes, los proveedores entregarán PQC como parte de sus actualizaciones normales.

La responsabilidad del propietario de la web es diferente: mantener software actualizado, evitar infraestructuras obsoletas y escoger proveedores capaces de evolucionar. Es una extensión de las prácticas que ya explicamos en cómo mantener una página web segura.

Una web utiliza criptografía en más sitios que HTTPS

Reducir el problema al certificado del dominio sería quedarse corto. En un proyecto web pueden existir dependencias criptográficas en numerosos puntos:

• conexiones HTTPS entre usuario, CDN y servidor;
• SSH y SFTP para administración y despliegue;
• firmas de paquetes, plugins, temas y actualizaciones;
• copias de seguridad cifradas y almacenamiento cloud;
• API externas y webhooks;
• VPN y accesos de administración;
• correo electrónico y certificados de cliente;
• gestores de secretos, HSM y servicios de claves;
• autenticación y recuperación de cuentas.

Por eso la migración poscuántica se relaciona con una idea cada vez más importante: la agilidad criptográfica. Un sistema ágil no está atado rígidamente a un único algoritmo, proveedor o formato de clave. Puede sustituir componentes criptográficos sin rehacer toda la aplicación.

Ese principio también encaja con el artículo sobre passkeys y autenticación resistente al phishing. Las passkeys solucionan problemas de autenticación actuales, especialmente phishing y reutilización de contraseñas, pero no son una respuesta completa a la transición poscuántica. WebAuthn y los autenticadores también dependen de algoritmos y ecosistemas que deberán evolucionar cuando corresponda.

Qué debería hacer una empresa en 2026

1. No implementar criptografía propia

El primer paso es evitar el error más peligroso: descargar una implementación experimental y sustituir algoritmos por cuenta propia. La criptografía es un área donde una solución técnicamente sofisticada puede ser insegura por detalles mínimos. El NCSC recomienda que, salvo organizaciones con especialistas específicos, la migración se apoye en implementaciones y bibliotecas confiables.

2. Preguntar a proveedores por su hoja de ruta

Hosting, CDN, correo, VPN, copias de seguridad, identidad y servicios cloud deberían poder explicar cómo planean soportar estándares poscuánticos. No es necesario exigir que todo esté migrado hoy, pero sí distinguir entre un proveedor que tiene un plan y otro que ignora completamente la transición.

3. Identificar datos con confidencialidad prolongada

No toda información necesita seguir siendo secreta durante diez años. Conviene identificar qué datos sí lo requieren y priorizar los servicios que los transportan o almacenan. Ahí el riesgo de captura hoy y descifrado futuro es más relevante.

4. Mantener TLS y software modernos

La compatibilidad poscuántica llegará antes a plataformas actualizadas. Servidores antiguos, sistemas operativos sin soporte o appliances que no pueden renovar bibliotecas criptográficas acabarán convirtiéndose en obstáculos. La mejor preparación consiste muchas veces en eliminar deuda técnica.

5. Separar confidencialidad de autenticación

Cuando un proveedor anuncie «PQC», hay que preguntar qué protege exactamente. ¿Acuerdo de claves? ¿Firmas? ¿Cliente a CDN? ¿CDN a origen? ¿SSH? ¿Código firmado? Esa precisión evita una falsa sensación de seguridad.

6. Documentar dependencias

Una lista básica de proveedores, protocolos, certificados, claves, sistemas de backup y accesos administrativos ya constituye un buen comienzo. Las organizaciones grandes necesitarán inventarios criptográficos mucho más rigurosos; una pequeña empresa puede empezar identificando los componentes críticos que no controla directamente.

Qué no cambia con la criptografía poscuántica

La llegada de nuevos algoritmos no elimina la mayoría de amenazas actuales. Un sitio puede utilizar un intercambio de claves resistente a futuros ordenadores cuánticos y seguir siendo vulnerable a una contraseña robada, un plugin desactualizado, una inyección SQL o una sesión secuestrada.

De hecho, la mayoría de incidentes que afectan hoy a webs pequeñas no requieren romper criptografía. Los atacantes aprovechan credenciales, ingeniería social, configuraciones incorrectas y software vulnerable. El artículo sobre cómo los ciberdelincuentes utilizan inteligencia artificial muestra precisamente que la automatización puede amplificar amenazas existentes sin necesidad de romper TLS.

PQC debe incorporarse como una nueva capa dentro de la seguridad, no sustituir MFA, passkeys, actualizaciones, backups, privilegio mínimo, monitorización o una arquitectura web razonable.

Qué ocurre con certificados y firmas digitales

La parte de autenticación es uno de los grandes retos de la transición. En HTTPS, el certificado permite demostrar que estamos hablando con el servidor correcto. Las firmas poscuánticas tienen tamaños y características diferentes de las actuales, lo que afecta a certificados, cadenas de confianza, protocolos y dispositivos.

Por eso veremos probablemente una transición más gradual que en el acuerdo de claves. Cloudflare ya está desplegando ML-DSA en partes de su infraestructura, pero el ecosistema global de PKI pública necesita compatibilidad entre autoridades de certificación, navegadores, servidores, hardware y estándares.

La situación puede resultar confusa porque una conexión híbrida protege la confidencialidad futura sin que la cadena de certificados sea todavía poscuántica. No es una contradicción: confidencialidad y autenticación son propiedades distintas y pueden migrarse en momentos diferentes.

El calendario no depende de adivinar cuándo llegará un ordenador cuántico

Nadie puede afirmar con rigor la fecha exacta en que existirá una máquina capaz de comprometer RSA o ECC a escala práctica. Las estimaciones tecnológicas cambian y existen enormes retos de ingeniería, corrección de errores y escalado.

Las agencias de seguridad no están basando sus planes en acertar una fecha. El NCSC propone completar el descubrimiento y plan inicial antes de 2028, realizar las migraciones de mayor prioridad antes de 2031 y trabajar hacia una migración completa en 2035. El razonamiento es operativo: cambiar la criptografía de millones de sistemas requiere muchos años aunque el riesgo cuántico tarde en materializarse.

Europa utiliza un calendario diferente y más específico para sus infraestructuras críticas. Eso demuestra que no existe una única fecha global de migración, pero sí un consenso creciente en algo esencial: esperar hasta que aparezca una amenaza práctica sería demasiado tarde para empezar.

¿Debes buscar ya un hosting «post-cuántico»?

No convertiría esa etiqueta en el principal criterio para contratar un hosting en 2026. Rendimiento, copias de seguridad, aislamiento, actualizaciones, soporte, TLS moderno y capacidad de respuesta ante incidentes siguen teniendo un impacto mucho más inmediato.

Sí resulta razonable valorar positivamente que el proveedor utilice una infraestructura actual, permita un CDN con soporte PQC, documente sus dependencias criptográficas y tenga una estrategia de actualización. En proyectos que manejan información de larga confidencialidad, la pregunta merece mucha más importancia.

También conviene evitar afirmaciones comerciales absolutas. Una empresa puede ofrecer intercambio de claves poscuántico y seguir dependiendo de firmas clásicas en otra parte de la cadena. La seguridad real se entiende revisando arquitectura y alcance, no leyendo una insignia.

Qué puede pasar durante los próximos años

En 2026 estamos en una fase intermedia. Los estándares básicos del NIST existen, implementaciones reales están apareciendo y el IETF continúa trabajando en la integración de ML-KEM en protocolos como TLS. Al mismo tiempo, el NIST sigue evaluando algoritmos adicionales de firma para aumentar diversidad y cubrir distintos casos de uso.

Durante los próximos años veremos más soporte en bibliotecas TLS, navegadores, VPN, SSH, HSM, sistemas operativos y autoridades de certificación. Parte de la transición será prácticamente invisible para el usuario: una actualización del navegador o del CDN puede modificar el intercambio criptográfico sin cambiar la interfaz de la web.

Otras migraciones serán más difíciles. Hardware con ciclos de vida largos, dispositivos IoT, sistemas industriales, PKI complejas y software firmado durante décadas necesitan planificación específica. De ahí que las estrategias oficiales insistan tanto en inventario y agilidad criptográfica.

Conclusión

La criptografía poscuántica no responde a una emergencia en la que el HTTPS actual haya dejado de funcionar. Responde a una transición que debe completarse antes de que los algoritmos de clave pública vulnerables puedan ser atacados por ordenadores cuánticos suficientemente grandes.

Para una web convencional, la mayor parte del cambio llegará a través de navegadores, CDN, servidores, bibliotecas y proveedores. Ya existen acuerdos de claves híbridos en producción, mientras que firmas, certificados y otras piezas del ecosistema siguen evolucionando. Esa diferencia explica por qué debemos evitar expresiones simplistas como «mi web ya es cuánticamente segura».

La preparación útil en 2026 es bastante menos espectacular: mantener la infraestructura al día, conocer qué proveedores gestionan nuestra criptografía, identificar información que necesita confidencialidad prolongada y diseñar sistemas capaces de cambiar de algoritmo sin reconstruirse desde cero. En seguridad, anticiparse rara vez significa instalar más cosas; muchas veces significa tomar hoy decisiones que no nos bloqueen mañana.

Si estás planificando una nueva web o renovando una infraestructura existente, una arquitectura sencilla, actualizable y bien documentada aporta más resiliencia que cualquier etiqueta tecnológica aislada. Esa base facilitará también la transición criptográfica cuando los proveedores y estándares alcancen cada nueva etapa.

Preguntas frecuentes

¿Puede un ordenador cuántico romper HTTPS hoy?

No existe actualmente evidencia pública de un ordenador cuántico capaz de romper a escala práctica la criptografía de clave pública utilizada ampliamente en Internet. La migración se está preparando ahora porque desplegar nuevos estándares en toda la infraestructura puede llevar muchos años y porque determinados datos capturados hoy podrían seguir siendo sensibles en el futuro.

¿Necesito un plugin poscuántico para WordPress?

No. En una instalación WordPress normal, HTTPS depende principalmente del navegador, servidor, biblioteca TLS, hosting, proxy o CDN. La transición poscuántica debe llegar mediante implementaciones fiables en esas capas, no mediante criptografía desarrollada dentro de un plugin.

¿Qué diferencia hay entre ML-KEM y ML-DSA?

ML-KEM, estandarizado en FIPS 203, sirve para establecer un secreto compartido que después puede utilizarse para cifrar comunicaciones. ML-DSA, definido en FIPS 204, es un algoritmo de firma digital destinado a autenticar e identificar modificaciones.

¿Una conexión X25519MLKEM768 ya es totalmente poscuántica?

Protege el acuerdo de claves mediante un esquema híbrido que combina un mecanismo clásico con ML-KEM, pero eso no implica que todas las demás piezas de la conexión sean poscuánticas. La autenticación del certificado, el tramo hacia el servidor de origen u otros componentes pueden seguir utilizando criptografía tradicional.

Fuentes y referencias

Este artículo se ha elaborado a partir de los estándares y documentación del NIST, la hoja de ruta de la Comisión Europea, las recomendaciones del NCSC, documentación técnica de Cloudflare y trabajos en curso del IETF. Las fechas de migración son objetivos institucionales y las especificaciones que continúan como Internet-Draft pueden cambiar antes de convertirse en estándares definitivos.