Calendario de CNSA 2.0: algoritmos y plazos explicados

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) es el conjunto de algoritmos poscuánticos que la NSA exige para los National Security Systems (NSS) de Estados Unidos y para los productos comerciales que se utilizan en ellos. La suite está formada por ML-KEM-1024 para el establecimiento de claves, ML-DSA-87 para las firmas de uso general, LMS y XMSS para la firma de software y firmware, AES-256 para el cifrado simétrico y SHA-384 o SHA-512 para el hash. El uso exclusivo se exige a finales de 2030 para la firma de software y firmware y para el equipamiento de red tradicional, y a finales de 2033 para navegadores y servidores web, servicios en la nube, sistemas operativos y equipamiento de nicho.

A quién se aplica CNSA 2.0

CNSA 2.0 no es una norma general de criptografía de Estados Unidos ni un estándar internacional. Rige los National Security Systems: los sistemas que tratan información clasificada o que son críticos para funciones militares y de inteligencia. Alcanza a tres grupos. En primer lugar, las organizaciones que poseen y operan esos sistemas. En segundo lugar, los integradores que los construyen. En tercer lugar, y es el grupo que con más frecuencia se ve sorprendido, los fabricantes comerciales cuyos productos se adquieren para ellos.

Las agencias federales civiles siguen una vía distinta. Sus obligaciones derivan de la Executive Order 14412 (22 de junio de 2026) y del memorando de la OMB M-26-15 (24 de junio de 2026), resumidos en nuestra página sobre la migración poscuántica federal de Estados Unidos: inventario criptográfico automatizado, planes de migración de las agencias con fecha límite el 22 de octubre de 2026, TLS 1.3 obligatorio a más tardar el 2 de enero de 2030, sistemas de alto valor con establecimiento de claves poscuántico a finales de 2030 y con firmas poscuánticas a finales de 2031, y migración completa en 2035 conforme a NSM-10. Ambas vías apuntan en la misma dirección, pero las fechas y el alcance difieren. Consulte la que se aplica al contrato que tiene delante. Los hitos fechados de la propia CNSA 2.0 se recogen en nuestra página de referencia sobre CNSA 2.0.

Este artículo es informativo y no constituye asesoramiento jurídico. Las cláusulas de adquisición de un contrato concreto siempre prevalecen sobre un resumen general.

La suite de algoritmos

CNSA 2.0 no se limita a decir «poscuántico». Nombra conjuntos de parámetros concretos, y nombra los más altos.

Tres puntos merecen atención. ML-KEM es la forma estandarizada de CRYSTALS-Kyber, publicada por el NIST como FIPS 203 el 13 de agosto de 2024 junto con FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA). Los grupos Kyber previos al estándar, como X25519Kyber768Draft00, están obsoletos y no satisfacen ningún requisito. Además, CNSA 2.0 exige los conjuntos de parámetros más altos, ML-KEM-1024 y ML-DSA-87, y no el ML-KEM-768 que los navegadores negocian hoy por defecto. Un producto que solo admite X25519MLKEM768 es poscuántico, pero no cumple CNSA 2.0. Por último, la suite remite a LMS y XMSS, definidos en SP 800-208, para firmar software y firmware. Son esquemas con estado: la clave de firma nunca debe reutilizar un índice de clave de un solo uso, por lo que la infraestructura de firma debe garantizar la persistencia del estado. SLH-DSA (FIPS 205) no tiene estado y no figura en la suite descrita anteriormente.

AES-256 y la familia SHA-2 forman parte de la suite porque el algoritmo de Shor no los rompe. El algoritmo de Grover es la razón por la que se prefiere AES-256 a AES-128 para la protección a largo plazo, y la razón por la que los tamaños de hash son de 384 bits o más.

Los plazos, categoría por categoría

CNSA 2.0 fija fechas de uso exclusivo, lo cual es más estricto que el simple soporte. Uso exclusivo significa que los algoritmos de CNSA 2.0 son los únicos que intervienen en esa función: RSA, ECDSA y ECDH desaparecen, no se limitan a quedar en segundo plano. Por tanto, el soporte debe llegar mucho antes del plazo, porque para esa fecha todo el parque tiene que estar completamente convertido.

Estas fechas proceden de las FAQ de CNSA 2.0, versión 2.1 (diciembre de 2024), y del aviso CNSA 2.0 Algorithms del 30 de mayo de 2025. El orden es deliberado. La firma va primero porque una raíz de firma tiene una vida larga: el firmware firmado hoy con una clave ECDSA puede seguir siendo verificado por dispositivos desplegados dentro de una década, y reemitir un ancla de confianza en un parque desplegado es lento. El equipamiento de red va primero porque termina los túneles cifrados de larga duración, que son el objetivo más atractivo para la estrategia «recolectar ahora, descifrar después» (harvest now, decrypt later): el tráfico grabado solo está protegido por el intercambio de claves que generó sus claves de sesión, de modo que lo capturado hoy puede convertirse en texto claro más adelante. Los navegadores, servidores, plataformas en la nube y sistemas operativos tienen hasta 2033 porque la cadena de dependencias que hay debajo de ellos (bibliotecas, módulos de seguridad hardware, autoridades de certificación, pilas de protocolos) es más profunda.

Por qué importa a los proveedores fuera de Estados Unidos

Tres razones, ninguna de ellas teórica.

• Las cláusulas de adquisición viajan. Los requisitos de CNSA 2.0 se incorporan a los contratos y a las solicitudes de propuestas. Un proveedor de componentes situado dos o tres niveles por debajo en una cadena de suministro de defensa los hereda a través de su cliente, no a través de su propio regulador.
• Los conjuntos de parámetros altos son una decisión de producto, no una opción de configuración. ML-KEM-1024 y ML-DSA-87 modifican el tamaño de las claves y las firmas, el tamaño de los handshakes, el tamaño de las imágenes de firmware y los requisitos de los módulos de seguridad hardware. Una hoja de ruta que se detiene en ML-KEM-768 necesitará una segunda pasada.
• Los requisitos europeos no son idénticos. La ANSSI hace obligatoria la hibridación dentro de su ámbito regulado (cualificación de productos, procedimientos relacionados con la defensa, operadores de importancia vital) e indica que sus demás recomendaciones poscuánticas aún no son obligaciones reglamentarias. BSI TR-02102-1 (versión 2026-01) es una directriz técnica que recomienda el acuerdo de claves poscuántico híbrido y considera aceptable el acuerdo de claves clásico usado en solitario solo hasta finales de 2031, o hasta finales de 2030 para necesidades de protección muy elevadas. Un producto que se vende en ambos mercados debe poder negociar un grupo híbrido y un conjunto de parámetros de CNSA 2.0, lo que es un argumento a favor de la cripto-agilidad en el código en lugar de una única elección fijada en el código.

Si necesita ver todos los plazos oficiales en paralelo, nuestra visión general de los plazos de migración poscuántica compara CNSA 2.0 con la hoja de ruta de la UE, las fechas del NCSC del Reino Unido y la vía federal de Estados Unidos.

Qué comprobar este trimestre

Empiece en modo de solo lectura, en un entorno de preproducción, y mantenga una alternativa clásica hasta que se acerque el plazo que le corresponde.

Confirme qué grupos puede ofrecer realmente su pila TLS. Los grupos ML-KEM requieren OpenSSL 3.5 o posterior:

openssl version
openssl list -tls-groups

Busque MLKEM1024 y SecP384r1MLKEM1024, además del ampliamente desplegado X25519MLKEM768. Los codepoints de la IANA se publican en el registro de parámetros TLS, y el propio mecanismo híbrido se especifica en el RFC 10024 (agosto de 2026).

A continuación, pruebe qué negociará un servidor, un grupo cada vez, contra un host de preproducción:

openssl s_client -connect staging.example.com:443 -groups MLKEM1024 </dev/null 2>&1 | grep -i -E "negotiated|group"
openssl s_client -connect staging.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i -E "negotiated|group"

En cuanto a la firma, genere un par de claves ML-DSA-87 de prueba y mida el efecto de las firmas más grandes en el tamaño de sus artefactos, en su canal de actualizaciones y en sus rutas de código de verificación:

openssl genpkey -algorithm ML-DSA-87 -out mldsa87-test.key

Mantenga la clave de prueba fuera de cualquier almacén de confianza de producción. El trabajo más difícil es organizativo: inventariar cada raíz de firma y su caducidad, identificar los módulos de seguridad hardware que deben admitir ML-DSA-87 o la firma basada en hash con estado, y planificar la gestión del estado que exigen LMS y XMSS. Nuestra guía para migrar la firma de código a ML-DSA describe la secuencia, incluida la doble firma durante la transición.

Siguiente paso: medir lo que presenta hoy

Los plazos de CNSA 2.0 se refieren a lo que sus productos y servicios negocian realmente, no a lo que promete su hoja de ruta. Empiece por la capa visible desde el exterior: analice su dominio con PQC Status para ver qué grupos de intercambio de claves, versiones de TLS y algoritmos de certificado ofrecen ahora mismo sus endpoints. Utilice el resultado como primera línea de una lista de brechas: endpoints sin ningún grupo ML-KEM, endpoints que solo ofrecen ML-KEM-768 cuando un contrato CNSA 2.0 requerirá ML-KEM-1024, y cadenas de certificados todavía firmadas con RSA o ECDSA. Un análisis describe una configuración TLS visible desde el exterior. No es una certificación ni una atestación de cumplimiento, así que compleméntelo con su inventario interno de claves de firma, imágenes de firmware y bibliotecas embebidas.