La fecha de 2030 no es la fecha de llegada de los ordenadores cuánticos
Durante años, la criptografía funcionó en silencio bajo la mayor parte de las conversaciones de seguridad corporativa. RSA y ECDSA vivían en páginas que la mayoría de los administradores nunca leerían; el handshake TLS era un detalle técnico que se olvidaba en cuanto se establecía la conexión. En 2024 eso cambió. NIST finalizó los primeros estándares de criptografía post-cuántica (PQC) y el contador para que la infraestructura corporativa complete la transición antes de 2030 empezó a correr.
El Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) de la NSA fija 2030 como el año objetivo para la transición de los sistemas de seguridad nacional de EE. UU. a la criptografía post-cuántica. Este calendario se trata como una fecha límite práctica del sector. Los fabricantes que suministran a clientes de seguridad nacional están obligados a cumplirlo. Los clientes corporativos siguen los mismos estándares; porque sus auditores, reguladores y grandes contrapartes los siguen.
Pero aquí hay un malentendido común: la fecha límite de 2030 no significa "el año en que llegan los ordenadores cuánticos".
Las estimaciones de los expertos sobre cuándo existirá un ordenador cuántico criptográficamente relevante varían desde finales de la década de 2030 hasta "nunca"; depende del analista. La fecha límite de 2030 tiene que ver con el tiempo de preparación. Migrar la PKI global, cada endpoint TLS, cada autoridad de certificación, cada dispositivo embebido que trae RSA hardcodeado, lleva más de una década. Hay que empezar mucho antes de que la amenaza sea operativa; de lo contrario, en el momento de necesidad la transición no estará completa.
Añada a esto la amenaza "recolectar ahora, descifrar después" (harvest now, decrypt later — HNDL). Un adversario que registre su tráfico cifrado en 2026 puede descifrar el registro años después, cuando disponga de capacidad cuántica. Si el dato debe seguir siendo secreto después de 2030 — secretos comerciales, comunicaciones de M&A, documentos legales sellados, PII de clientes con largas ventanas de retención — la protección post-cuántica se necesita ahora. La fecha límite se aplica a la vida útil de confidencialidad de los datos; no a la fecha de llegada del ordenador cuántico.
La transición a PQC en cifras
ML-KEM, ML-DSA y ML-SLH; publicados como FIPS 203, 204, 205
NIST CSRCAño objetivo de la NSA para los sistemas de seguridad nacional de EE. UU.
NSA CNSA 2.0Qué finalizó NIST en 2024
Tras un proceso de selección de varios años que comenzó en 2016, NIST finalizó los primeros estándares de criptografía post-cuántica en agosto de 2024. Surgieron tres algoritmos; cada uno cubre una primitiva criptográfica distinta de las que proporcionan los algoritmos clásicos de clave pública. Los tres son basados en lattice o basados en hash — las familias que NIST seleccionó tras eliminar a los demás candidatos.
ML-KEM (FIPS 203)
Module-Lattice-Based Key Encapsulation Mechanism, antes Kyber. El estándar para el intercambio de claves — el paso en el que TLS establece un secreto compartido por un canal público. Sustituye al intercambio de claves basado en RSA, usado desde los años 90, y a ECDH. ML-KEM-768 añade unos 1,1 KB al handshake; X25519 eran unos 100 bytes. El coste de CPU puede competir con RSA-2048.
ML-DSA (FIPS 204)
Module-Lattice-Based Digital Signature Algorithm, antes Dilithium. El estándar para las firmas digitales; se usa en certificados, firma de código, autenticación y todo contexto en el que el receptor deba verificar la identidad del emisor. Sustituye a RSA y ECDSA. Las firmas ML-DSA-65 son de unos 3,3 KB; ECDSA, unos 70 bytes. El rendimiento de firma es comparable al de ECDSA.
ML-SLH (FIPS 205)
Stateless Hash-Based Signature Algorithm, antes SPHINCS+. Un esquema de firma alternativo con concesiones distintas. Produce firmas más lentas y más grandes que ML-DSA; pero es basado en hash — su seguridad se apoya en supuestos más fáciles de defender que los problemas de lattice subyacentes a ML-DSA. La mayoría de los despliegues usarán ML-DSA por rendimiento; ML-SLH se reservará para la firma de archivo a largo plazo, donde los supuestos conservadores son más críticos.
Capacidades que deben cumplir los ADC corporativos
Los controladores de entrega de aplicaciones corporativos — balanceadores de carga, WAF, terminadores SSL, sistemas GTM — se sitúan en el límite de terminación TLS. Esa posición convierte el soporte de PQC en una puerta para la transición más amplia: si el ADC no habla PQC, nada de lo que tenga detrás puede hacerlo.
ML-KEM en el intercambio de claves de TLS 1.3
El ADC debe aceptar y poder negociar ML-KEM como algoritmo de intercambio de claves en el handshake de TLS 1.3. La mayoría de los despliegues elegirán el modo híbrido — ML-KEM combinado con X25519 o P-256 — por lo que también es necesario el soporte de grupos híbridos.
ML-DSA para las firmas de certificados
Los certificados que el ADC presenta a los clientes y los certificados que valida de los servicios upstream — ambos requieren soporte de ML-DSA. La validación de la cadena de certificados, el OCSP stapling y la verificación de SCT deben todos conocer ML-DSA.
Mayor capacidad de payload de handshake
ML-KEM-768 añade unos 1,1 KB al handshake; las firmas ML-DSA-65 son de unos 3,3 KB. El ADC debe manejar paquetes de handshake mayores; esto es directamente relevante para la configuración de MTU, el presupuesto de la tasa de conexiones y el ajuste fino de la mitigación de DDoS.
Herramientas del ciclo de vida de certificados
Las herramientas de gestión de certificados actuales asumen tamaños clásicos de clave y firma. Los certificados PQC son mayores; los flujos de trabajo ACME, los almacenes de certificados y las integraciones con HSM requieren actualizaciones para manejar el nuevo perfil de tamaño.
Modo híbrido por defecto
Los despliegues de PQC puro son aún tempranos; los algoritmos son más recientes y su historial de criptoanálisis es limitado. El modo híbrido (clásico y PQC en el mismo handshake) es la vía conservadora: si uno de los dos componentes es seguro, la conexión es segura. El modo híbrido debería planificarse por defecto al menos hasta 2028.
Margen de rendimiento
El coste de CPU de ML-KEM puede competir con RSA-2048; la firma de ML-DSA es comparable a ECDSA. El impacto práctico en el rendimiento es pequeño, pero no nulo. La planificación de capacidad debe tener en cuenta un coste de CPU de handshake TLS algo mayor durante la transición híbrida.
Los despliegues de PQC puro dependen de una única familia de algoritmos nueva para la confidencialidad. Si un futuro resultado de criptoanálisis debilita ML-KEM, toda conexión que use únicamente ML-KEM se vuelve vulnerable de forma retroactiva. El modo híbrido — la combinación de ML-KEM con X25519 o P-256 — deriva el secreto de sesión de ambos; si uno de los algoritmos resiste, la conexión es segura. El coste es el tamaño del handshake híbrido (el mayor de las dos aportaciones). El beneficio es una defensa en profundidad frente a futuras debilidades desconocidas en cualquiera de las dos familias. Los principales navegadores (Chrome, Firefox) y las bibliotecas TLS desplegaron el modo híbrido a lo largo de 2024-2026; el IETF estandarizó los identificadores de grupos híbridos. Para los despliegues corporativos, el híbrido debería ser el valor por defecto al menos hasta 2028.
Calendario operativo para la transición corporativa
Ahora (2026): inventaríe las superficies criptográficas
Liste cada endpoint TLS, relación con autoridad de certificación, flujo de trabajo de firma de código y flujo de datos de confidencialidad a largo plazo. Sin inventario no puede planificarse el alcance de la transición. La mayoría de las organizaciones descubren superficies que habían olvidado — servicios internos, clientes antiguos, dispositivos embebidos, integraciones B2B.
Ahora (2026): habilite PQC en el TLS de cara al público
En los ADC que lo soporten, habilite el modo híbrido de ML-KEM en los endpoints TLS de cara al público. El cambio es conservador: el modo híbrido vuelve a la seguridad clásica si la PQC se debilita más adelante. El tráfico real de producción obtiene el beneficio de inmediato.
2026-2027: piloto de certificados ML-DSA
Empiece a emitir certificados firmados con ML-DSA para cargas de trabajo no críticas, con el fin de validar las herramientas de gestión de certificados, la monitorización y los procedimientos operativos. Las rutas de código de validación de la cadena de certificados se ejercitan antes de soportar carga para los servicios críticos.
2027-2028: amplíe a los servicios internos
Amplíe el TLS híbrido y los certificados ML-DSA al tráfico interno este-oeste. Los servicios internos toleran mejor los problemas de compatibilidad durante el piloto; los problemas de compatibilidad de la cola larga afloran antes de hacerse de cara al público.
2028-2029: limpieza de la cola larga
Aborde los dispositivos embebidos, las integraciones antiguas y las API de cara a partners que carecen de soporte de PQC. Algunos fabricantes requieren presión; algunos sistemas antiguos requieren sustitución. La cola larga es donde realmente se consume el presupuesto de tiempo de la transición.
2030: PQC operativa
Todas las nuevas conexiones TLS usan híbrido o PQC puro. Las conexiones solo clásicas son una excepción explícita y requieren un calendario documentado de fin de vida. La transición ya no es un proyecto, sino una operación — la agilidad criptográfica continua es la nueva normalidad.
¿Qué significa esto para las decisiones de producto ADC en 2026?
Las decisiones de infraestructura corporativa tomadas en 2026 perduran durante toda la ventana de transición a PQC. Un ADC elegido hoy que carezca de soporte de PQC es una sustitución obligada antes de 2030 — un coste que el comprador no planificó. Las consecuencias prácticas para la evaluación de fabricantes se agrupan en tres apartados.
Primero, el soporte de PQC debe comprobarse como una capacidad fundamental; no como un elemento de la hoja de ruta. "Soportaremos ML-KEM en nuestra versión de 2027" y "ML-KEM está en nuestra versión actual" no son lo mismo. La transición híbrida requiere validación real de producción; y eso exige que la función esté disponible ahora.
Segundo, el estado de validación FIPS 140-3 de las implementaciones de PQC es importante para los sectores regulados — gobierno, defensa, banca. La validación va por detrás de la adopción; por eso debe incluirse en los calendarios de compra.
Tercero, la historia operativa puede ser más importante que la criptográfica: cómo maneja el ADC los flujos de trabajo de gestión de certificados con los tamaños de PQC, cómo afina el mayor presupuesto de handshake, cómo informa de las distribuciones de sesiones PQC vs. clásicas. Las matemáticas están resueltas; las operaciones aún se están resolviendo en todo el sector.
El posicionamiento de tecnología moderna de TR7 incluye el soporte de ML-KEM y ML-DSA en las versiones actuales; no como una puerta de característica futura. La elección de arquitectura que lo hace posible es la misma que hace posibles HTTP/3 y las actualizaciones sin interrupción: TR7 se construyó desde un punto de partida limpio; no se reparcheó sobre una arquitectura anterior a estos requisitos. Para las organizaciones que miden la preparación para PQC como parte de las evaluaciones de fabricantes en 2026, esta postura desde cero es una entrada que facilita la decisión.
Referencias y fuentes
Agosto de 2024 — publicación de FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (ML-SLH) tras un proceso de selección de varios años. https://csrc.nist.gov/projects/post-quantum-cryptography
El Commercial National Security Algorithm Suite 2.0 fija 2030 como año objetivo para la transición de los sistemas de seguridad nacional de EE. UU. a la criptografía post-cuántica. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
Especificación completa de ML-KEM (Kyber), incluidos los conjuntos de parámetros, los tamaños de texto cifrado y las propiedades de seguridad. https://csrc.nist.gov/pubs/fips/203/final
Especificación completa de ML-DSA (Dilithium), incluidos los tamaños de firma, la verificación y el análisis de seguridad. https://csrc.nist.gov/pubs/fips/204/final
Borrador de Internet que define los identificadores de grupos de intercambio de claves post-cuántico híbrido para TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Listo para lo siguiente, incluido 2030
El ADC corporativo de TR7 soporta ML-KEM y ML-DSA en las versiones actuales — incluidos los modos TLS híbridos que combinan algoritmos clásicos y post-cuánticos. HTTP/3, QUIC, las actualizaciones sin interrupción y la criptografía post-cuántica forman parte del mismo compromiso arquitectónico: construir para lo siguiente en lugar de parchear lo antiguo.
Descubra la tecnología moderna de TR7