Diseño de las estrategias de transición a CNSA 2.0

El conjunto de algoritmos comerciales de seguridad nacional 2.0 ( CNSA 2.0 ) de la Agencia de Seguridad Nacional es la hoja de ruta más específica desde el punto de vista operativo que cualquier gobierno haya publicado para gestionar esta transición. Mientras que el Memorando de Seguridad Nacional 10 (NSM-10) establece el objetivo ambicioso de lograr que los sistemas de seguridad nacional sean resistentes a la computación cuántica para 2035, CNSA 2.0 traduce ese objetivo en instrucciones concretas: usar ML-KEM-1024 para el establecimiento de claves, ML-DSA-87 para firmas, admitir estos algoritmos en sus productos antes de fechas específicas y dejar de usar los antiguos por parte de otros.

Los plazos ya no están tan lejos. El primero de ellos, relativo a la firma de software y firmware, exigía que las organizaciones dieran preferencia a los algoritmos CNSA 2.0 para 2025, un hito que ya se ha superado. A partir del 1 de enero de 2027, todas las nuevas adquisiciones de Sistemas de Seguridad Nacional deberán ser compatibles con los algoritmos CNSA 2.0.

Este blog desglosa el conjunto de algoritmos CNSA 2.0, el cronograma completo de transición, los mecanismos de cumplimiento que hacen que estos plazos sean vinculantes y una estrategia práctica de cinco fases para diseñar la migración sin interrumpir sus operaciones.

Firma de código post-cuántica, definida como: firma de software y firmware con un algoritmo resistente a los ataques de una computadora cuántica, actualmente ML-DSA (FIPS 204) o el algoritmo LMS/XMSS basado en hash con estado (NIST SP 800-208), que normalmente se ejecuta junto con un algoritmo clásico durante la transición para que tanto los verificadores actuales como los que aún no se han actualizado puedan seguir validando el artefacto.

Puntos Clave

• ML-KEM (FIPS 203) y ML-DSA (FIPS 204) no son intercambiables: ML-KEM es un mecanismo de encapsulación de claves para establecer secretos compartidos, mientras que ML-DSA es un algoritmo de firma. La firma de código utiliza ML-DSA o LMS/XMSS, nunca ML-KEM.
• Las normas FIPS 203, 204 y 205 son estándares NIST definitivos desde agosto de 2024; la norma NIST SP 800-208 (LMS/XMSS) es definitiva desde 2020. Lo que aún presenta deficiencias es la compatibilidad con el ecosistema, el firmware de los módulos de seguridad de hardware (HSM), las autoridades de certificación y los verificadores de firmas.
• Un único formato de firma "compuesta" post-cuántica/clásica combinada para X.509 sigue siendo un borrador de Internet de la IETF (draft-ietf-lamps-pq-composite-sigs, que aún no es una RFC a fecha de 2026); el patrón híbrido práctico actual para la firma de código consiste en firmas separadas duales y paralelas, no en una firma compuesta.
• La compatibilidad del verificador, y no la capacidad del firmante, suele ser el verdadero cuello de botella: un artefacto puede firmarse con ML-DSA hoy en día, pero solo puede verificarse mediante plataformas que le hayan añadido soporte.
• La firma de software y firmware tiene como fecha límite más temprana la CNSA 2.0 (se recomienda y prefiere el 2025, fecha que ya ha pasado); consulte el cronograma de transición con fechas a continuación para todas las demás categorías de sistemas.

Qué es CNSA 2.0 y por qué existe

CNSA 2.0 es la guía de algoritmos criptográficos de la NSA para la protección de los Sistemas de Seguridad Nacional (NSS, por sus siglas en inglés), que incluyen sistemas clasificados y no clasificados que manejan información de seguridad nacional, mando y control militar, inteligencia y funciones relacionadas. Se anunció por primera vez el 7 de septiembre de 2022 y se actualizó a la versión 2.1 en diciembre de 2024, después de que el NIST publicara los estándares FIPS post-cuánticos definitivos en agosto de 2024.

La existencia de CNSA 2.0 se debe a una única amenaza bien conocida. Los algoritmos de clave pública que se utilizan actualmente en casi todos los sistemas, RSA y criptografía de curva elíptica ( ECC ), se basan en problemas matemáticos que las computadoras clásicas no pueden resolver en un plazo razonable. Una computadora cuántica suficientemente potente que ejecute el algoritmo de Shor puede resolver esos mismos problemas de manera eficiente, lo que hace que las firmas RSA y ECC y los intercambios de claves sean inseguros.

Esto genera dos riesgos distintos. El primero es prospectivo: una vez que exista una computadora cuántica criptográficamente relevante ( CRQC ), cualquier sistema que aún dependa de RSA o ECC será inmediatamente vulnerable. El segundo es actual: los adversarios están capturando y archivando datos cifrados y comunicaciones firmadas hoy mismo, con la intención de descifrarlos o falsificarlos una vez que una CRQC esté disponible. Esta es la amenaza de "recolectar ahora, descifrar después", lo que significa que los datos con requisitos de confidencialidad que se extienden más allá del período de disponibilidad de la CRQC ya están en riesgo, independientemente de la solidez del cifrado actual.

CNSA 2.0 reemplaza al conjunto de algoritmos CNSA 1.0 anterior , que se basaba en RSA, ECDH, ECDSA y AES. CNSA 2.0 conserva las primitivas simétricas y de hash que siguen siendo resistentes a la computación cuántica y reemplaza los algoritmos de clave pública vulnerables a la computación cuántica con alternativas post-cuánticas estandarizadas por el NIST.

Conjunto de algoritmos CNSA 2.0

CNSA 2.0 especifica algoritmos exactos y, fundamentalmente, conjuntos de parámetros precisos para cada caso de uso. Una de las características distintivas de este conjunto de herramientas es que solo exige los niveles de seguridad más altos del NIST . Los conjuntos de parámetros inferiores, aunque el NIST los estandarizó y aprobó para uso general, no están permitidos en los Sistemas de Seguridad Nacional.

Función	Algoritmo CNSA 2.0	Estándar	Notas
Establecimiento clave	ML-KEM-1024	FIP 203	Anteriormente CRYSTALS-Kyber; Nivel de seguridad NIST 5 únicamente. ML-KEM-512 y ML-KEM-768 no están aprobados para NSS.
Firmas digitales (general)	ML-DSA-87	FIP 204	Anteriormente CRYSTALS-Dilithium; solo el conjunto de parámetros más alto. ML-DSA-44 y ML-DSA-65 no están permitidos para NSS. Se utiliza para todas las firmas, incluyendo software y firmware.
Firma de software y firmware	LMS o XMSS	SP 800-208 del NIST	Firmas basadas en hash con estado. La NSA recomienda LMS con SHA-256/192. ML-DSA-87 también está aprobado para este caso de uso.
Cifrado simétrico	AES-256	FIP 197	Conservado de CNSA 1.0; resistente a ataques cuánticos con una longitud de clave de 256 bits.
Hashing	SHA-384 o SHA-512	FIPS 180-4	CNSA 2.0 añadió SHA-512 como opción aprobada junto con SHA-384.

Estado de los estándares: ¿Qué es definitivo y qué aún está en desarrollo?

No todo lo que se etiqueta como “postcuántico” se encuentra en la misma etapa de madurez, y confundir un estándar de algoritmo finalizado con una característica del ecosistema en desarrollo es uno de los errores de planificación más comunes. Es útil separar el estándar del algoritmo de la infraestructura circundante que debe ponerse al día.

Parámetro	Estado	Desde / Notas
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	Estándares NIST finales	Publicado agosto 13, 2024
NIST SP 800-208 (LMS, XMSS)	Recomendación final del NIST	Publicado Octubre 2020
Firmas post-cuánticas/clásicas compuestas (individuales, combinadas) para X.509	Borrador de Internet de la IETF, aún no es una RFC.	borrador-ietf-lamps-pq-composite-sigs, revisado activamente hasta 2026; no construya sistemas de producción asumiendo aún un formato de cableado estable.
Compatibilidad del firmware HSM con FIPS 203/204/205 y SP 800-208.	Desigual, específico del proveedor y del modelo.	Los principales proveedores lanzaron soporte inicial en las versiones de firmware de 2025 a 2026; confirme por modelo, no dé nada por sentado.
Compatibilidad con autoridades de certificación públicas para la firma de código en perfiles de certificados ML-DSA/LMS.	Limitado y aún en desarrollo	Verifique con su CA antes de dar por sentado que existe un certificado de firma de código PQC de confianza pública disponible hoy.
Verificadores de firmas de sistemas operativos y plataformas (por ejemplo, verificación al estilo Authenticode)	En gran medida, aún no reconoce las firmas PQC.	Por eso, la firma doble y paralela es el modelo práctico actual, y no un sustituto de la firma clásica.

Cronograma de transición

CNSA 2.0 define dos hitos para cada categoría de sistema: una fecha de “compatibilidad y preferencia”, a partir de la cual los sistemas deben ser capaces de usar los algoritmos de CNSA 2.0 y deberían utilizarlos por defecto, y una fecha de “uso exclusivo”, a partir de la cual ya no se permiten los algoritmos de CNSA 1.0. El cronograma está escalonado deliberadamente, dando prioridad a las categorías que son más difíciles de actualizar después de la implementación.

Categoría del sistema	Apoyar y preferir	Uso exclusivo
Firma de software y firmware	2025 (aprobado)	2030
Equipos de red (VPN, enrutadores)	2026	2030
Sistemas operativos	2027	2033
Navegadores web, servidores, servicios en la nube	2025 (aprobado)	2033
Equipos especializados y heredados	Actualizar o reemplazar para 2033	2033
Todos los NSS (transición completa)	Hasta proximo aviso	2035 (según NSM-10)

¿Por qué la firma de software y firmware conlleva el plazo más temprano?

No es casualidad que la firma de software y firmware tenga el plazo de "compatibilidad y preferencia" más temprano de todo el cronograma de CNSA 2.0. Existe una razón arquitectónica específica: las raíces de confianza del firmware son los componentes más difíciles de actualizar después de que se implementa un dispositivo.

Durante la fabricación de un dispositivo, las claves de verificación de su firmware suelen estar integradas en el hardware, a veces fusionadas con el propio chipset de forma que no se puedan modificar posteriormente. Si dichas claves se basan en un algoritmo vulnerable a la computación cuántica, el dispositivo presenta esa vulnerabilidad durante toda su vida útil. En el caso de dispositivos con una vida útil de décadas, como hardware militar, controladores industriales y sistemas embebidos, una clave de firma elegida hoy podría seguir en uso mucho después de que se prevea la existencia de una clave de verificación de confiabilidad de la computación (CRQC).

Esto genera un riesgo adicional específico para el firmware. Un atacante que logre recuperar la clave de firma, ya sea a partir del tráfico de firma archivado o descifrando directamente el algoritmo con un CRQC, podría firmar un firmware malicioso que todos los dispositivos implementados aceptarían como legítimo. Dado que el firmware se encuentra por debajo del sistema operativo y de todos los controles de seguridad a nivel de software, una firma de firmware falsificada es uno de los ataques más peligrosos posibles.

Por este motivo, la NSA ha instado a los proveedores a adoptar LMS y XMSS de inmediato desde la recomendación original de 2022, mucho antes de la transición general. Las firmas basadas en hash con estado, como LMS y XMSS, son bien conocidas, conservadoras en sus supuestos de seguridad y resistentes a la computación cuántica. Son especialmente adecuadas para el caso de uso del firmware, donde la operación de firma es poco frecuente y controlada, lo que reduce la complejidad operativa de la gestión de claves con estado.

Para las organizaciones que desarrollan productos que incluyen firmware, la implicación práctica es que la infraestructura de firma es lo primero que se debe migrar. El dispositivo que se distribuye hoy con firma clásica es el que portará esa vulnerabilidad en la década de 2030 y más allá. Para conocer los formatos específicos que una plataforma de firma debe cubrir en toda esa flota de dispositivos, consulte « Hemos contabilizado todos los formatos que CodeSign Secure puede firmar »; para saber cómo la elección del algoritmo se relaciona con la procedencia de la compilación, consulte « Fortalecimiento de la seguridad de la cadena de suministro con SLSA Nivel 3 y firma de código».

Patrones de firma híbridos y paralelos

El término "firma híbrida" se usa de forma imprecisa, y la distinción entre sus dos significados reales es importante para lo que se puede implementar hoy en día.

Actualmente , la firma dual, paralela y separada es el patrón práctico disponible: el artefacto se firma dos veces, una con un algoritmo clásico (RSA o ECDSA) y otra con un algoritmo post-cuántico (ML-DSA o LMS). Ambas firmas se transportan con el artefacto como bloques de firma separados e independientes. Un verificador que solo entiende el algoritmo clásico comprueba esa firma e ignora la que no reconoce; un verificador actualizado para entender la firma post-cuántica puede comprobar ambas. Ninguna firma depende de la otra, razón por la cual este patrón funciona con el panorama actual de verificadores mixtos y parcialmente actualizados.

Las firmas compuestas , una única firma criptográfica que combina matemáticamente un algoritmo clásico y uno post-cuántico en un solo valor, representan un enfoque diferente y más integrado, y aún no constituyen un estándar finalizado para su uso en X.509. La especificación pertinente, draft-ietf-lamps-pq-composite-sigs, sigue siendo un borrador de Internet de la IETF a fecha de 2026, aún en revisión, y no una RFC. Desarrollar herramientas de producción con un formato de transmisión incompleto conlleva el riesgo de tener que volver a firmar o emitir certificados una vez que el formato se estabilice. En lo que respecta a la firma de código, las firmas paralelas duales son la opción de menor riesgo actualmente; vale la pena seguir de cerca las firmas compuestas, pero aún no es recomendable depender de ellas.

Dependencias de migración

La migración a la firma CNSA 2.0 tiene un orden de dependencia real, y comenzar fuera de secuencia es una forma común de arruinar un proyecto piloto con un problema que nunca tuvo que ver con la firma en absoluto.

1. Es necesario confirmar y, si es preciso, actualizar primero el firmware o el hardware del HSM para el algoritmo de destino (ML-DSA, LMS o XMSS); no se pueden generar ni utilizar claves que el HSM no admita.
2. A continuación, se aborda la compatibilidad con la autoridad de certificación y el perfil de certificado, si el caso de uso requiere un certificado (la firma del firmware LMS/XMSS suele utilizar claves públicas integradas). Confirme que su CA puede emitir un certificado que codifique el algoritmo que pretende utilizar antes de darlo por sentado.
3. Debe existir una cadena de herramientas de firma y compatibilidad con la integración CI/CD; el proceso debe poder invocar el nuevo algoritmo a través de su plataforma de firma o API de HSM.
4. La compatibilidad con el verificador y la plataforma se comprueba al final, pero conceptualmente debería evaluarse primero: si los sistemas que comprobarán la firma no pueden reconocer el nuevo algoritmo, la doble firma no es opcional, es la única manera de que el artefacto siga siendo utilizable.
5. Solo cuando se confirmen los cuatro elementos tendrá sentido realizar un despliegue piloto; consulte las fases de la arquitectura de transición a continuación.

Compatibilidad de verificación

Esta es la limitación que la mayoría de los planes de transición subestiman. Un artefacto puede firmarse correctamente con ML-DSA o LMS hoy en día, pero esa firma solo es útil si algo en el otro extremo puede verificarla. La verificación Authenticode a nivel de sistema operativo convencional no reconoce de forma nativa las firmas post-cuánticas; la firma clásica en un artefacto con doble firma es lo que la mayoría de los verificadores implementados comprobarán en el futuro cercano. Las herramientas de verificación internas o personalizadas que usted controla pueden actualizarse para comprobar explícitamente la firma post-cuántica, razón por la cual la doble firma hoy sirve a dos públicos diferentes a la vez: los verificadores externos, sin modificaciones, obtienen la firma clásica que ya entienden, y los sistemas de verificación internos o prospectivos pueden validar adicionalmente la firma post-cuántica para una garantía genuina de resistencia cuántica. Confirme, en lugar de asumir, a qué categoría pertenece cada uno de sus verificadores reales antes de considerar un proyecto piloto como representativo de la producción.

Arquitectura de transición

La migración a CNSA 2.0 no es un proyecto único con un final definido. Se trata de un programa plurianual que abarca el inventario criptográfico, la infraestructura, las operaciones de firma y la gobernanza. La siguiente estrategia de cinco fases proporciona una ruta estructurada que las organizaciones pueden adaptar a su escala y plazos.

Fase 1: Descubrimiento criptográfico e inventario

No se puede migrar la criptografía sin haberla identificado. La primera y más fundamental fase consiste en crear un inventario completo de todos los lugares donde se utiliza la criptografía clásica en la organización: cada certificado, cada clave de firma, cada punto final TLS y cada dependencia criptográfica integrada en el software y el hardware.

CBOM Secure de Encryption Consulting ayudará a su organización a crear un inventario de cada activo criptográfico, incluyendo el algoritmo y el conjunto de parámetros utilizados, su ubicación, las dependencias, su propietario y su posible reemplazo. Las dependencias criptográficas suelen estar ocultas en lugares difíciles de detectar: ​​bibliotecas de terceros, configuraciones de módulos de seguridad de hardware, aplicaciones heredadas y productos de proveedores cuya arquitectura interna no es visible.

Fase 2: Priorización y evaluación de riesgos

Con un inventario completo, la siguiente fase consiste en priorizar qué migrar primero según el riesgo y el plazo. El cronograma de CNSA 2.0 establece la estructura de plazos, pero las organizaciones deben añadir su propia evaluación de riesgos.

Los activos de máxima prioridad son aquellos que combinan una fecha límite temprana de CNSA 2.0 con una exposición prolongada. Las claves de firma de firmware para dispositivos con una vida útil de varias décadas encabezan esta lista: tienen la fecha límite más temprana y el período de exposición más largo. A continuación, se encuentran los datos y las firmas que protegen información con requisitos de confidencialidad o integridad a largo plazo, debido a la amenaza de "recolectar ahora, descifrar después". Los activos de menor prioridad son aquellos con ciclos de vida cortos y fechas límite posteriores, donde esperar a que haya herramientas más maduras conlleva poco riesgo.

Fase 3: Preparación de la infraestructura y las herramientas

La fase 3 prepara la infraestructura que soportará las operaciones de CNSA 2.0. La cuestión central para la mayoría de las organizaciones es la preparación de los HSM . CNSA 2.0 exige que las claves estén protegidas en hardware validado, y la mayoría de los HSM antiguos necesitan actualizaciones de firmware para ser compatibles con ML-KEM, ML-DSA, LMS y XMSS.

Para cada HSM del entorno, las organizaciones deben confirmar con el proveedor si el firmware actual admite las operaciones de generación, almacenamiento y firma de claves CNSA 2.0; si se puede actualizar el firmware para añadir compatibilidad o si es necesario reemplazar el hardware; y cuál es la fecha de lanzamiento prevista para el firmware compatible con FIPS 203, 204 y 205. Los principales proveedores, como Thales Luna, Entrust nShield y Utimaco, han estado distribuyendo compatibilidad con CNSA 2.0 en las actualizaciones de firmware de 2025 y 2026, pero la compatibilidad varía según el modelo específico y debe verificarse en lugar de darse por sentada.

Esta fase también incluye la validación de que las cadenas de herramientas de firma, las canalizaciones de CI/CD , las autoridades de certificación y los sistemas de verificación pueden producir y validar firmas CNSA 2.0.

Lista de verificación de preparación para HSM

• Confirmación, para cada modelo, de si el firmware actual admite la generación y firma de claves ML-DSA y/o LMS/XMSS, y no solo una declaración general del proveedor sobre su hoja de ruta.
• Se determinó si una actualización de firmware agrega compatibilidad o si se requiere un reemplazo de hardware, y se obtuvo una fecha objetivo específica del proveedor.
• Se verificó el rendimiento del HSM con los nuevos algoritmos; las claves y firmas más grandes pueden modificar el rendimiento de maneras que conviene medir antes de comprometerse con un cronograma de implementación.
• Se ha confirmado la gestión de estado consistente ante fallos específicamente para LMS/XMSS, ya que un estado de firma perdido o revertido puede comprometer la clave por completo.
• Se ha comprobado que la plataforma de firma o el complemento CI/CD que se encuentra delante del HSM se haya actualizado para utilizar el nuevo algoritmo, y no solo que el propio HSM lo admita.

Fase 4: Despliegue híbrido y programa piloto

Durante la transición, se recomienda un despliegue híbrido en lugar de una sustitución completa inmediata. La firma híbrida y el intercambio de claves híbrido aplican en paralelo un algoritmo clásico y un algoritmo CNSA 2.0, de modo que los sistemas capaces de verificación post-cuántica obtienen protección resistente a la computación cuántica, mientras que los sistemas heredados que aún no se han migrado siguen funcionando.

La fase 4 pone esto en práctica mediante implementaciones piloto. Se comienza con una línea de productos o sistema controlado y de bajo riesgo, se implementa la firma híbrida o el intercambio de claves híbrido y se valida que los artefactos y las conexiones funcionen correctamente en toda la infraestructura de verificación con la que se encontrarán. Aquí es donde surgen los casos límite: herramientas de verificación que aún no comprenden las firmas CNSA 2.0, impactos en el rendimiento derivados de tamaños de clave y firma mayores, y problemas de integración en el proceso de firma. Resolver estos problemas en una fase piloto es mucho menos costoso que descubrirlos en producción.

Fase 5: Migración completa y desmantelamiento de sistemas heredados

La fase final extiende el enfoque validado a todo el entorno y retira progresivamente la criptografía clásica. A medida que la infraestructura de verificación madura y la compatibilidad con CNSA 2.0 se generaliza en todos los sistemas de la organización, el componente clásico de las implementaciones híbridas puede dejar de utilizarse según los plazos de "uso exclusivo" establecidos en el cronograma de CNSA 2.0.

Esta fase también incluye el desmantelamiento o la sustitución de los equipos especializados y obsoletos que no se pueden migrar in situ, lo cual, según CNSA 2.0, se abordará para 2033. Estos suelen ser los cambios que requieren más recursos y deben planificarse con suficiente antelación a la fecha límite.

Pruebas y validación

Más allá del programa piloto descrito en la Fase 4, algunas comprobaciones específicas merecen una cobertura de prueba explícita antes de que cualquier artefacto con doble firma se distribuya de forma generalizada:

• Verifique el artefacto con cada verificador con el que se encontrará realmente en producción, no solo con el utilizado durante el desarrollo, ya que no se garantiza que el comportamiento del verificador ante una firma adicional no reconocida sea idéntico en todas las plataformas.
• Medir el impacto del tamaño de las claves y firmas post-cuánticas más grandes en el tamaño de los artefactos, el tiempo de descarga y cualquier canal de distribución con restricciones de tamaño (en particular, los mecanismos de actualización integrados).
• Confirme la compatibilidad de la marca de tiempo; una marca de tiempo confiable debe seguir siendo válida y verificable independientemente del algoritmo de firma al que esté asociada.
• Si el volumen de lanzamientos es elevado, realice pruebas de carga para evaluar el rendimiento de la firma digital con el nuevo algoritmo, ya que ML-DSA y LMS/XMSS tienen características de rendimiento diferentes a las de RSA o ECDSA.

Rollback

Debido a que la firma dual paralela agrega una segunda firma independiente en lugar de reemplazar la primera, la reversión durante las etapas piloto y de implementación inicial tiene un riesgo relativamente bajo: si la firma post-cuántica agregada causa una falla de verificación inesperada en algún punto del campo, la firma clásica sigue presente y válida, y la solución es dejar de adjuntar la segunda firma para ese flujo de artefactos mientras se resuelve la incompatibilidad, no volver a emitir ni revocar nada. La situación es diferente una vez que un entorno alcanza su fecha de "uso exclusivo" y la firma clásica se ha eliminado; en ese momento, la reversión significa volver a habilitar la firma dual temporalmente mientras se corrige la brecha de verificación subyacente, lo que es una razón más para no retirar completamente la firma clásica hasta que se haya confirmado la cobertura de verificación en todos los consumidores del artefacto, no hasta que se dé por sentada.

Cómo puede ayudar la consultoría de cifrado

La transición a CNSA 2.0 abarca el descubrimiento criptográfico, la preparación de la infraestructura, las operaciones de firma y la gobernanza a largo plazo. La cartera de productos y los servicios de consultoría de Encryption Consulting están diseñados para brindar soporte a las organizaciones en cada fase de este proceso.

Servicios de Asesoramiento PQC : Nuestros Servicios de Asesoramiento Criptográfico Post-Cuántico proporcionan la base estratégica para una migración a CNSA 2.0. Ayudamos a las organizaciones a evaluar su postura criptográfica actual, a elaborar la hoja de ruta de migración alineada con el cronograma de CNSA 2.0, a priorizar los activos según el riesgo y la fecha límite, y a diseñar la arquitectura cripto-ágil que facilita tanto esta transición como las futuras.

CBOM Secure : La primera fase de cualquier migración a CNSA 2.0 es el descubrimiento, y no se puede migrar lo que no se ve. CBOM Secure realiza un descubrimiento criptográfico continuo en todo el entorno, creando un inventario completo y actualizado de certificados, claves y dependencias criptográficas necesarias para la migración. Identifica con precisión qué activos utilizan algoritmos vulnerables a ataques cuánticos y deben someterse a la transición a CNSA 2.0, transformando la fase fundamental de descubrimiento, que antes era manual y propensa a errores, en un proceso automatizado y repetible.

CodeSign Secure : Dado que la firma de software y firmware tiene como fecha límite la primera para la implementación de CNSA 2.0, muchas organizaciones deben priorizar la infraestructura de firma. CodeSign Secure admite los algoritmos de firma de CNSA 2.0 en producción: ML-DSA con los niveles de parámetros requeridos y LMS para la firma de firmware, todo ello respaldado por HSM validados por FIPS de Thales, Entrust, Utimaco y Securosys. La plataforma también garantiza la protección de claves, el control de acceso basado en roles y el registro de auditoría que exige la gobernanza de firmas de NSS.

Conclusión

CNSA 2.0 representa la hoja de ruta para la migración post-cuántica más concreta y específica desde el punto de vista operativo que haya publicado un gobierno. Especifica algoritmos exactos, conjuntos de parámetros exactos y fechas exactas, y respalda esas fechas con mecanismos de control que convierten el cumplimiento en una condición para la validación, la certificación y la adquisición.

Las organizaciones que logren superar esta transición con éxito serán aquellas que la aborden como un programa estructurado a largo plazo: descubriendo su inventario criptográfico, priorizando según el riesgo y el plazo, preparando su infraestructura, implementando enfoques híbridos durante la transición y desarrollando la criptoagilidad para que el próximo cambio criptográfico sea mucho menos problemático que este. La infraestructura de firma, con su plazo de entrega temprano y su amplio período de exposición, es el punto de partida idóneo.

En Encryption Consulting, nuestros servicios de consultoría y nuestra cartera de productos, desde CBOM Secure para el descubrimiento hasta CodeSign Secure para la firma CNSA 2.0, están diseñados para acompañarle en todo el proceso, desde el inventario inicial hasta el desmantelamiento final. Si su organización está evaluando su preparación para CNSA 2.0, estaremos encantados de ayudarle a diseñar la estrategia a seguir.

Preguntas frecuentes

¿ML-KEM es lo mismo que ML-DSA?

No. ML-KEM (FIPS 203) es un mecanismo de encapsulación de claves que se utiliza para establecer un secreto compartido para el cifrado; ML-DSA (FIPS 204) es un algoritmo de firma digital. Resuelven problemas diferentes y no son intercambiables. La firma de código utiliza ML-DSA o LMS/XMSS, basado en funciones hash con estado, nunca ML-KEM.

¿Cuál es la diferencia entre las firmas post-cuánticas híbridas y compuestas?

El término híbrido, tal como se practica hoy en día, se refiere a firmas duales, independientes y paralelas, una clásica y otra post-cuántica, asociadas al mismo artefacto. El término compuesto se refiere a un único valor de firma que combina matemáticamente ambos algoritmos; la especificación IETF pertinente para firmas ML-DSA compuestas sigue siendo un borrador de Internet, no una RFC finalizada, a fecha de 2026.

¿Pueden los verificadores de firmas actuales comprobar una firma ML-DSA o LMS hoy en día?

Depende totalmente del verificador específico. La verificación Authenticode a nivel de sistema operativo convencional aún no reconoce en gran medida las firmas post-cuánticas, por lo que la firma dual, que consiste en mantener la firma clásica junto con la nueva, es el enfoque práctico en lugar de reemplazarla por completo.

¿Qué módulos de seguridad de hardware (HSM) son compatibles con los algoritmos CNSA 2.0 actualmente?

Los principales proveedores, como Thales Luna, Entrust nShield y Utimaco, incluyeron compatibilidad con CNSA 2.0 en sus actualizaciones de firmware de 2025 y 2026, pero la compatibilidad varía según el modelo. Confirme la compatibilidad actual del firmware directamente con el proveedor para su modelo HSM específico, en lugar de asumir que la compatibilidad es general para toda la suite.

¿Qué ocurre si un artefacto con doble firma no supera la verificación en algún punto del proceso?

Dado que la firma clásica sigue presente e independiente, el artefacto generalmente conserva su validez para los verificadores que solo comprueban dicha firma. La solución consiste en pausar la adición de la firma post-cuántica para ese flujo de artefactos mientras se diagnostica la incompatibilidad específica, no en revocar ni volver a emitir nada.