La cadena de suministro de software se basa en la confianza, y cada binario firmado depende de una premisa fundamental: que los algoritmos criptográficos que protegen esas firmas, específicamente RSA y ECDSA, no pueden ser vulnerados por ningún atacante con los recursos informáticos disponibles. Pero esa premisa ya no es infalible.
La aparición de las computadoras cuánticas criptográficamente relevantes (CRQC) introduce un riesgo sistémico para todos los esquemas de firma digital en producción actualmente. El NIST finalizó sus primeros estándares criptográficos postcuánticos en agosto de 2024 e instó explícitamente a los administradores de sistemas a comenzar la integración de inmediato. Los reguladores y los líderes tecnológicos están avanzando al unísono, desde el mandato CNSA 2.0 de la NSA que exige la adopción de ML-DSA para los sistemas de seguridad nacional, hasta el objetivo de Google y Cloudflare de lograr la adopción total de PQC en toda su infraestructura para 2029.
La cuestión ya no es si las organizaciones necesitan adaptar su infraestructura de firma de código a algoritmos post-cuánticos, sino si completarán esa transición antes de que un CRQC haga que la demora tenga consecuencias.
Analizaremos el panorama de algoritmos PQC, los desafíos específicos de implementación para la firma de código, las estrategias de arquitectura y la hoja de ruta de migración por fases que ofrece a los equipos de la cadena de suministro de software un camino claro hacia adelante, sin tiempo de inactividad operativa. Para obtener información sobre el sellado de tiempo, la preparación para HSM y los mecanismos de verificación a largo plazo que determinan si una firma aplicada hoy seguirá siendo válida dentro de veinte años, consulte nuestro documento PQC para la firma de código: protección de software y firmware de larga duración.
Estrategia de firma de código PQC, definida como: un plan priorizado y por fases para trasladar la infraestructura de firma de una cadena de suministro de software a algoritmos resistentes a la computación cuántica, ML-DSA, SLH-DSA o FN-DSA, elegidos en función de la carga de trabajo en lugar de por defecto, implementados junto con las firmas clásicas durante la transición y secuenciados de manera que los cambios en la raíz de confianza se produzcan antes que en los sistemas dependientes, en lugar de después.
Puntos Clave
- FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) son estándares NIST definitivos desde agosto de 2024. FN-DSA (FIPS 206) sigue siendo un borrador público inicial, cuya finalización está prevista para finales de 2026 o principios de 2027, y aún no es un estándar publicado.
- La elección del algoritmo depende de la carga de trabajo: ML-DSA para la firma de CI/CD de alto volumen, donde generalmente ofrece un rendimiento competitivo o superior al de RSA en las pruebas comparativas publicadas; SLH-DSA para anclajes de confianza de larga duración, donde su perfil conservador y más lento es aceptable; y FN-DSA (una vez finalizado) para dispositivos IoT/integrados con recursos limitados.
- La firma híbrida (clásica más PQC, aplicada en paralelo) es el patrón práctico actual porque la compatibilidad de los verificadores con las firmas PQC aún es desigual en todo el ecosistema; este es el mismo enfoque de doble firma que se detalla específicamente para CI/CD en nuestro documento sobre la arquitectura SLSA de nivel 3.
- Esta página es la capa de priorización y estrategia de arquitectura para la cadena de suministro de software general. Para el cronograma de transición específico de CNSA 2.0 y la migración en cinco fases, consulte Diseño de las estrategias de transición a CNSA 2.0Para elegir específicamente entre esquemas de firma basados en hash, consulte Comparación de SLH-DSA, LMS y XMSS.
- No se puede migrar lo que no se puede inventariar; el 34 % de las empresas citan la falta de visibilidad criptográfica centralizada como una barrera principal para la preparación de PQC.
Por qué la firma de código de PQC no puede esperar
Cuando la mayoría de las organizaciones piensan en la amenaza cuántica, la conciben como un problema futuro. Pero para las cadenas de suministro de software , las mejoras algorítmicas están reduciendo los requisitos de cúbits necesarios para descifrar RSA-2048. En 2019, se estimaba que romper RSA-2048 requeriría aproximadamente 20 millones de cúbits, pero para 2025, las arquitecturas más recientes que utilizan códigos de verificación de paridad cuántica de baja densidad (QLDPC) han reducido esa estimación a aproximadamente 100 000 cúbits, lo que supone una reducción de 20 veces impulsada exclusivamente por la innovación algorítmica, no por el hardware, en menos de seis años.
A diferencia de las comunicaciones encriptadas, donde la confidencialidad se rige por el principio de "recopilación inmediata, descifrado posterior", el software firmado conlleva un riesgo diferente: " Confianza inmediata, falsificación posterior ". Un instalador firmado, una imagen de firmware, un paquete de actualización de software: estos elementos permanecen en circulación durante años o décadas. Si se implementa una vulnerabilidad CRQC y se vulneran los algoritmos de firma clásicos, un atacante puede falsificar retroactivamente firmas en elementos maliciosos que resulten indistinguibles del software legítimo firmado históricamente. El riesgo no se manifiesta con la llegada de una vulnerabilidad CRQC, sino durante toda la vida útil de cada elemento firmado clásicamente que aún esté en producción en ese momento.
El informe de enero de 2026 del Citi Institute , titulado "Amenaza cuántica: La carrera por la seguridad del billón de dólares ha comenzado", estima una probabilidad de entre el 19 % y el 34 % de que una computadora cuántica rompa el estándar RSA-2048 para 2034, con aproximadamente 20 mil millones de dispositivos IoT activos en todo el mundo actualmente expuestos a la amenaza cuántica durante su vida útil. Para los equipos de software que gestionan productos con una vida útil de varios años, la transición a la firma de código PQC ya no representa una ventaja para los pioneros. Se trata de una medida de mitigación de riesgos en la cadena de suministro que debe implementarse de inmediato.
Algoritmos PQC del NIST para la firma de código
El NIST finalizó sus tres primeros estándares criptográficos post-cuánticos el 13 de agosto de 2024, con vigencia inmediata para su uso por parte del gobierno federal de EE. UU. y como referencia global para su adopción por la industria. Para las firmas digitales, que constituyen la base de la firma de código, hay tres algoritmos disponibles o próximos a su finalización.
Elegir el algoritmo adecuado es una decisión arquitectónica crucial que afecta a todo, desde el rendimiento del pipeline de CI/CD hasta la longevidad de la raíz de confianza. A continuación, se muestra una comparación de los algoritmos de firma del NIST para aplicaciones de firma de código:
| Algoritmo | Estándar | Principio básico | Tamaño de la firma | Throughput | El más adecuado para |
|---|---|---|---|---|---|
| ML-DSA (CRISTALES-Dilitio) | FIPS 204 (Finalizado) | Estructura reticular (Módulo-LWE) | 2–3 KB | En general, son competitivos o más rápidos que los esquemas clásicos en las pruebas comparativas publicadas. | Firma general de paquetes, DevOps, cadena de suministro de CI/CD |
| SLH-DSA (SPHINCS+) | FIPS 205 (Finalizado) | Hash sin estado (SHA-2/SHAKE) | 8–50 KB | Considerablemente menor; gastos generales significativos | Archivo a largo plazo, pilares de confianza de misión crítica |
| FN-DSA (HALCÓN) | FIPS 206 (Borrador público inicial; se espera la versión final para finales de 2026 o principios de 2027) | Red compacta (basada en NTRU) | 0.6–1.2 KB | Rápido (optimizado para dispositivos con recursos limitados) | Firmware para IoT, sistemas embebidos, hardware con recursos limitados |
Desafíos de implementación
Los algoritmos de firma de código PQC están estandarizados y las pruebas de seguridad son sólidas. Representa un desafío operativo y de infraestructura. Sin embargo, hay algunos aspectos que requieren una planificación explícita:
Inflación del tamaño de la firma y la llave
El cambio más visible al pasar de los algoritmos clásicos a los algoritmos PQC es el aumento significativo en el tamaño de las claves y las firmas.
| Componente | RSA-3072 (Clásico) | ML-DSA-65 (PQC) |
|---|---|---|
| clave pública | ~384 bytes | ~1,952 bytes |
| clave privada | ~384 bytes | ~4,032 bytes |
| Firma | ~384 bytes | ~3,309 bytes |
Tomando como referencia una firma ECDSA P-256 sin procesar de 64 bytes, una firma ML-DSA-65 (3,309 bytes) es aproximadamente 52 veces mayor. Esta proporción se aplica específicamente a la representación sin procesar de 64 bytes; las firmas ECDSA codificadas en el mundo real (DER) suelen ser algo mayores de 64 bytes, por lo que esta comparación debe interpretarse como una ilustración de la magnitud del aumento, en lugar de un multiplicador universal para las firmas ECDSA en general. Para los sistemas de firma de alto volumen que procesan miles de artefactos al día, este aumento de tamaño afecta a los requisitos de almacenamiento, a los tiempos de transferencia de red para los artefactos firmados y a la capacidad de cualquier sistema que gestione, valide o almacene en caché las firmas.
Estos impactos se pueden gestionar con una planificación arquitectónica adecuada. El hash del lado del cliente garantiza que solo los hashes, y no los binarios completos del artefacto, atraviesen la infraestructura de firma, y la aceleración por hardware en los modernos módulos de seguridad de hardware (HSM) reduce la sobrecarga computacional.
Brecha de HSM heredada
Las organizaciones deben verificar la hoja de ruta PQC de su modelo HSM específico y planificar las actualizaciones de firmware correspondientes. La mayoría de los HSM antiguos con certificación FIPS 140-2 carecen de soporte nativo para los estándares NIST PQC. Las organizaciones que utilicen firmware HSM antiguo deberán actualizar a un firmware compatible con FIPS 140-3 y PQC, o bien implementar un enfoque de "doble pila" durante el período de transición, donde la firma clásica continúe en los HSM existentes mientras que la firma PQC se ejecute en hardware actualizado o nuevo.
La certificación FIPS 140-3 para el firmware HSM con soporte PQC está progresando, y Entrust , Thales , Securosys y Utimaco ya han lanzado o anunciado actualizaciones de firmware compatibles con PQC.
Diferencias de rendimiento
Los tres algoritmos de firma PQC del NIST presentan características de rendimiento significativamente diferentes, aunque las cifras exactas varían considerablemente según el conjunto de parámetros, el tamaño de la clave RSA utilizado como referencia, si se mide la firma o la verificación, la biblioteca de software y la arquitectura de la CPU, la implementación de HSM, la aceleración por hardware y si se utiliza el pre-hashing de mensajes. Considere cualquier porcentaje de rendimiento específico, incluidas las caracterizaciones generales que se detallan a continuación, como ilustrativo y no como aplicable a diferentes entornos; realice pruebas comparativas con su propia biblioteca, hardware y conjunto de parámetros antes de basarse en una cifra.
- En general, ML-DSA ofrece un rendimiento competitivo con RSA clásico, e incluso superior en muchos análisis comparativos publicados. para operaciones de firma, debido a su eficiente diseño basado en celosía.
- SLH-DSA es sustancialmente más lento que RSA clásico. En la mayoría de las configuraciones, a menudo por uno o dos órdenes de magnitud, lo que lo convierte en una opción poco adecuada como algoritmo de firma principal en flujos de trabajo de alto volumen.
Esta diferencia de rendimiento es crucial para la selección del algoritmo. Elegir SLH-DSA para una canalización de CI/CD que firma cientos de artefactos por ciclo de compilación conlleva el riesgo de crear un cuello de botella en el rendimiento que anula el propósito de una canalización automatizada. ML-DSA suele ser la mejor opción para contextos de firma donde el rendimiento es un factor crítico; SLH-DSA se reserva generalmente para casos de uso de anclaje de confianza de larga duración, donde su perfil de seguridad conservador justifica el costo en términos de rendimiento.
Cuello de botella de validación
Todos los sistemas operativos, navegadores, herramientas de seguridad y plataformas de instalación de software que validan firmas en artefactos firmados deben actualizarse para reconocer y validar las firmas PQC. Esto representa un desafío de sincronización del ecosistema que se extenderá durante varios años. Una organización que comience a firmar con ML-DSA hoy producirá artefactos cuyas firmas PQC no podrán ser verificadas por sistemas que aún no se hayan actualizado. Precisamente por ello, la firma híbrida, que aplica tanto una firma clásica como una PQC a cada artefacto, es la arquitectura adecuada para el período de transición.
Según un estudio, el 48 % de las empresas afirma no estar preparada para las amenazas cuánticas , mientras que el 34 % señala la falta de visibilidad centralizada de sus activos criptográficos como principal obstáculo para la preparación ante la computación cuántica probabilística (PQC) . No se puede migrar lo que no se puede inventariar.
El paso fundamental para cualquier programa de migración de PQC es un análisis criptográfico exhaustivo que identifique cada certificado, cada clave y cada operación de firma en todo el proceso de compilación, firma y distribución. Encryption Consulting ofrece CBOM Secure para ayudarle a mantener un inventario de todos los objetos criptográficos de su entorno. Sin este inventario, los planes de migración de PQC se basan en información incompleta.
Firma híbrida: Firmas duales, no un formato compuesto.
Conviene precisar el significado de «híbrido», ya que se utiliza de forma imprecisa. El enfoque práctico actual consiste en firmas duales paralelas: el artefacto contiene una firma clásica y una firma PQC como dos bloques de firma independientes. Un verificador no actualizado comprueba la firma clásica e ignora la que no reconoce; un verificador actualizado puede comprobar ambas. Un único formato de firma «compuesta» combinado para certificados X.509 sigue siendo un borrador de la IETF, no un estándar finalizado, a fecha de 2026, por lo que desarrollar herramientas de producción basadas en él es prematuro. La firma dual es la opción de menor riesgo por ahora.
Dependencias de migración: El orden de compilación
El marco de prioridades que se muestra a continuación indica qué es lo más importante; este es el orden técnico en el que deben suceder realmente esos elementos.
- Confirme que el firmware del HSM sea compatible con el algoritmo específico (ML-DSA, SLH-DSA o FN-DSA posterior) que pretende utilizar; esto debe verificarse para cada modelo, no debe asumirse a partir de la hoja de ruta general de PQC del proveedor.
- Actualizar la infraestructura de las autoridades de certificación raíz e intermedias, ya que constituyen el ancla de confianza para todo lo que se firma posteriormente y deben implementarse antes que los sistemas dependientes.
- Integre la firma PQC en el proceso de CI/CD como un paso de firma adicional y paralelo, no como un reemplazo, para que la firma clásica continúe sin interrupciones.
- Confirme qué verificadores posteriores (almacenes de confianza del sistema operativo, administradores de paquetes, puertas de despliegue internas) pueden comprobar la nueva firma y trate a los que no puedan como si aún dependieran de la firma clásica.
- Pruebe primero una línea de productos controlada y de menor riesgo antes de ampliarla, y solo retire la firma clásica una vez que se confirme, y no se dé por sentada, la cobertura del verificador en todos sus canales de distribución reales.
Pruebas
Antes de ampliar la implementación más allá de un proyecto piloto, realice pruebas con todos los verificadores que el artefacto encontrará en producción, no solo con el utilizado en desarrollo, ya que no se garantiza la coherencia en el manejo de firmas no reconocidas en todas las plataformas. Mida el impacto del tamaño de las firmas PQC en el tamaño del artefacto y el tiempo de transferencia para cualquier canal de distribución con ancho de banda limitado, y realice pruebas de carga del rendimiento de firma con el algoritmo y el volumen reales, especialmente si se incluye SLH-DSA, dado su rendimiento sustancialmente menor en comparación con ML-DSA.
Rollback
Dado que la firma dual añade una segunda firma independiente en lugar de reemplazar la primera, la reversión durante una prueba piloto conlleva un riesgo bajo: si la firma PQC provoca un fallo de verificación inesperado en algún punto del sistema, la firma clásica sigue siendo válida y la solución consiste en pausar la adición de la segunda firma para ese flujo de artefactos mientras se diagnostica la incompatibilidad. La situación que requiere verdadera precaución es la de eliminar por completo la firma clásica; esto solo debe hacerse después de confirmar la cobertura del verificador, ya que revertir esa decisión a posteriori implica volver a habilitar la firma dual en lugar de un simple cambio de configuración.
Hoja de ruta desactualizada
| Milestone | Fecha |
|---|---|
| Las normas FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) se han finalizado. | 13 de agosto de 2024 |
| Se prevé la finalización de FIPS 206 (FN-DSA). | Finales de 2026 o principios de 2027 (aún en borrador) |
| Fecha de soporte y preferencia de CNSA 2.0 para la firma de software/firmware | 2025 (ya pasó) |
| Fecha de uso exclusivo de CNSA 2.0 para la firma de software/firmware | 2030 |
| Google y Cloudflare buscan la adopción total de PQC en toda su infraestructura. | 2029 |
| Transición completa al NSS (según NSM-10) | 2035 |
Priorización estratégica
Las organizaciones que intenten abordar simultáneamente todos los aspectos de la transición a PQC tendrán dificultades para dar seguimiento y priorizar las tareas. El marco que se presenta a continuación, basado directamente en el perfil de riesgo de la cadena de suministro, clasifica las acciones según su urgencia e importancia.
Implementar ahora: Importante y urgente
- Actualización de la raíz y del intermedio autoridades de certificación (CA) a algoritmos compatibles con PQC, ya que la infraestructura de CA es el ancla de confianza para todo lo que viene después y debe avanzar primero.
- Resolver Cosechar ahora, descifrar más tarde (HNDL) riesgos para artefactos firmados de alto valor al volver a firmar software de larga duración con firmas híbridas antes de que se abra la ventana de amenaza.
- Abordar las implicaciones en el rendimiento y la latencia que conllevan los tamaños mayores de claves y firmas PQC antes de que afecten al rendimiento del flujo de trabajo de producción.
- Validar la arquitectura de firma híbrida para comprobar su compatibilidad con versiones anteriores frente a su infraestructura real de distribución y verificación antes de cualquier implementación en producción.
Planificación estratégica: importante pero menos urgente
- Desarrollar y probar esquemas de firma híbrida en casos de uso representativos dentro de su ecosistema de software específico.
- Seleccionar algoritmos PQC para cada línea de productos y caso de uso de firma en función de los requisitos de rendimiento, las limitaciones del dispositivo y las necesidades de longevidad de la firma.
- Diseñar una arquitectura de criptoagilidad que permita a la infraestructura de firma intercambiar algoritmos y rotar claves sin necesidad de reconstruir completamente el sistema cada vez.
- Mapear la compatibilidad de la cadena de suministro de terceros para comprender qué socios posteriores, plataformas de distribución y herramientas de verificación están preparados para consumir software firmado por PQC.
Tareas tácticas: urgentes pero con enfoque operativo.
- Gestionar el aumento del volumen de certificados que se produce con la rotación de claves durante la migración.
- Responder a los requisitos de presentación de informes de cumplimiento para consultas regulatorias.
- Integración de la firma PQC en los flujos de trabajo de CI/CD junto con las herramientas heredadas durante la transición.
Monitoreo: Menos urgente y menos importante ahora
- Análisis posterior a la implementación de la estabilidad del algoritmo PQC a lo largo del tiempo.
- Migración de PQC para sistemas heredados no críticos.
- Seguimiento de los futuros avances de los proveedores en materia de ataques cuánticos.
Cómo ayuda CodeSign Secure de Encryption Consulting
CodeSign Secure es la plataforma de gestión de firmas de código empresariales de Encryption Consulting, y está diseñada específicamente para dar soporte a la migración a la firma de código PQC en cada fase de la hoja de ruta mencionada anteriormente.
Soporte para algoritmos PQC
CodeSign Secure v3.02 admite la firma de nivel de producción con todos los algoritmos PQC principales de NIST como una firma separable para los procesos de firma y verificación:
- ML-DSA (FIPS 204) en los tres niveles de seguridad (ML-DSA-44, ML-DSA-65 y ML-DSA-87) para paquetes generales y oleoductos de la cadena de suministro
- SLH-DSA (FIPS 205) para firmas de archivo a largo plazo y aplicaciones de anclaje de confianza de misión crítica
- LMS (NIST SP 800-208) para aplicaciones de firma de firmware e IoT donde se prefiere la resistencia cuántica basada en hash y con estado.
Gestión de claves con respaldo HSM para claves PQC
CodeSign Secure almacena todas las claves de firma privadas, tanto clásicas como PQC, dentro de módulos de seguridad de hardware con certificación FIPS 140-2 Nivel 3. La plataforma se integra con Entrust nCipher, Thales Luna, Securosys, Utimaco, así como con HSM en la nube de AWS y Azure, todos los cuales han lanzado o anunciado compatibilidad con ML-DSA y SLH-DSA en su firmware compatible con PQC.
Integración de canalización de CI/CD
CodeSign Secure se integra de forma nativa con Azure DevOps, Jenkins, GitLab CI, TeamCity y otras plataformas de canalización importantes, admitiendo tanto la invocación mediante API como mediante línea de comandos. Las operaciones de firma PQC se pueden configurar como etapas controladas y sujetas a políticas en las canalizaciones de lanzamiento, sin diferencias con los flujos de trabajo de firma clásicos existentes desde la perspectiva del desarrollador.
Control de acceso granular y registro de auditoría
El control de acceso basado en roles de CodeSign Secure determina quién puede solicitar operaciones de firma PQC, qué artefactos se pueden firmar con qué algoritmo y certificado, y qué pasos de aprobación se requieren. Cada evento de firma, incluyendo el algoritmo utilizado, el certificado, el hash del artefacto, la marca de tiempo y la identidad del aprobador, se registra de forma inmutable.
Análisis de vulnerabilidades de software
CodeSign Secure incluye el análisis de vulnerabilidades de software previo a la firma y la verificación hash previa y posterior como parte del flujo de trabajo de firma. Antes de aplicar una firma PQC, la plataforma puede validar que el artefacto que se firma ha superado los criterios de revisión de seguridad definidos, lo que garantiza que la firma resistente a la computación cuántica se aplique a un artefacto seguro y no solo a uno protegido criptográficamente.
Preguntas frecuentes
¿Qué algoritmo de firma PQC debo usar para la firma de código CI/CD?
ML-DSA (FIPS 204). En la mayoría de las pruebas de rendimiento publicadas, ofrece un desempeño competitivo o superior al de RSA clásico, lo que lo hace adecuado para flujos de trabajo de alto volumen. Sin embargo, el rendimiento exacto depende de la biblioteca, el hardware y el conjunto de parámetros específicos. El rendimiento de SLH-DSA es considerablemente menor, a menudo en un orden de magnitud o más, lo que lo hace poco apropiado para la firma rutinaria en tiempo de compilación; es mejor reservarlo para anclas de confianza de larga duración.
¿Está FN-DSA listo para usarse hoy en día?
Todavía no. FN-DSA (FIPS 206) sigue siendo un borrador público inicial a fecha de 2026, y se espera que se finalice a finales de 2026 o principios de 2027. Téngalo en cuenta, pero no cree dependencias de producción basadas en él antes de que sea un estándar publicado.
¿Necesito reemplazar las firmas clásicas de inmediato?
No, y no deberías. La firma dual y paralela, que consiste en una firma clásica y una firma PQC en el mismo artefacto, es el enfoque práctico mientras el soporte de los verificadores para las firmas PQC en todo el ecosistema aún sea desigual.
¿Cuál es el mayor obstáculo que las organizaciones subestiman?
Compatibilidad del verificador. Un artefacto puede firmarse correctamente con ML-DSA hoy en día, pero esa firma solo es útil para los sistemas que se han actualizado para reconocerla; se trata de un problema de sincronización del ecosistema que lleva varios años, no de un problema de firma.
¿Por dónde empiezo si aún no he inventariado mi infraestructura de firmas?
Con el descubrimiento criptográfico: un inventario completo de cada certificado, clave y operación de firma a lo largo del proceso de compilación, firma y distribución. Los planes de migración elaborados sin este inventario parten de información incompleta.
Conclusión
La transición post-cuántica para la firma de código no es un evento aislado. Se trata de una evolución arquitectónica que se extiende a lo largo de varios años y que requiere una planificación minuciosa, una ejecución por fases y una infraestructura capaz de gestionar simultáneamente operaciones de firma clásicas y resistentes a la computación cuántica durante el período de transición.
Las normativas vigentes, como los plazos de 2030 y 2035 del NIST, los requisitos de adopción de ML-DSA de la CNSA 2.0 y los hitos de migración del NCSC del Reino Unido, establecen expectativas concretas que las organizaciones de los sectores público y privado ya están trabajando para cumplir. Además, la amenaza de "Confiar ahora, forjar después" implica que cada artefacto firmado digitalmente con una larga vida útil de distribución acumula hoy un riesgo que se materializará cuando llegue un CRQC.
En Encryption Consulting, creamos CodeSign Secure para que la transición a PQC sea viable hoy mismo, con soporte para ML-DSA y SLH-DSA con firmas separables, y los controles de infraestructura que requieren los programas de cumplimiento y gobernanza.
