Preparación para la era poscuántica de los proveedores de « Software »: ya se ha establecido el calendario

Durante años, el riesgo cuántico se situaba en el futuro. El mensaje para los equipos de seguridad era «algún día llegará la era cuántica», y ese «algún día» nunca llegaba a concretarse en el calendario. Eso ha cambiado. La preparación para la era poscuántica ya no es una diapositiva estratégica sobre una amenaza lejana. Se trata de un conjunto de obligaciones con plazos concretos, y para los responsables de la seguridad de la información ( software ) y los proveedores de TI, esas fechas se avecinan ahora desde dos frentes a la vez.

Hay tres hitos que lo concretan. El 21 de septiembre de 2026, el régimen de validación FIPS 140-2 dejará de estar vigente. El 1 de enero de 2027, la Agencia de Seguridad Nacional (NSA) espera que las nuevas adquisiciones del Sistema de Seguridad Nacional (NSS) cumplan de forma predeterminada con la norma CNSA 2.0. Por último, el 22 de junio de 2026, la Orden Ejecutiva 14412 fijó el 31 de diciembre de 2030 como fecha límite para el establecimiento de claves poscuánticas y el 31 de diciembre de 2031 para las firmas poscuánticas en los sistemas federales de alto valor y alto impacto, y ordenó una norma del FAR que exige a los contratistas afectados cumplir con la norma FIPS que incorpora PQC antes del 31 de diciembre de 2030. Si desarrollas, firmas o distribuyes software, ambas fechas forman parte de tu hoja de ruta. La cuestión ya no es si dar el paso, sino si empiezas antes de que los plazos te obliguen a acelerar el ritmo.

Las dos líneas temporales en las que se encuentra ahora todo proveedor de software

La migración poscuántica suele describirse como una única transición. En la práctica, los proveedores de « software » se ven abocados a dos vías con distintos responsables, distintos algoritmos y distintos plazos. Una es de carácter civil y de amplio alcance. La otra se centra en la seguridad nacional y es más agresiva. Comprender ambas es el primer paso para elaborar un plan defendible.

El ámbito civil: NIST IR 8547 y las normas definitivas

La vía civil pasa por el NIST. En agosto de 2024, el NIST ultimó sus primeras normas poscuánticas: la FIPS 203 (ML-KEM) para el establecimiento de claves, la FIPS 204 (ML-DSA) para firmas de uso general y la FIPS 205 (SLH-DSA) para firmas basadas en funciones hash. Se trata de algoritmos listos para su uso en producción, no de propuestas de investigación.

Las fechas proceden de un documento complementario. El NIST IR 8547, «Transición a los estándares de criptografía poscuántica», establece el calendario de retirada de los algoritmos de clave pública actuales. Según ese plan, los algoritmos RSA, ECDSA, EdDSA y Diffie-Hellman de campo finito y de curva elíptica con un nivel de seguridad de 112 bits quedarán obsoletos a partir de 2030, y su uso quedará prohibido en 2035. Dicho calendario se aplica de forma generalizada a los sistemas federales y a los proveedores que les prestan servicio. La Orden Ejecutiva 14412 y el Memorándum M-26-15 de la OMB recogen ahora las fechas de aplicación en el ámbito civil. El M-26-15 establece un calendario de migración en cinco fases que se extiende desde 2026 hasta 2035 y exige que los organismos elaboren planes de migración.

El eje de la seguridad nacional: CNSA 2.0

El camino de la seguridad nacional es más arduo. El Conjunto de Algoritmos Comerciales de Seguridad Nacional 2.0 (CNSA 2.0) de la NSA, publicado en su versión 2.1 en diciembre de 2024, establece plazos por categorías para el NSS. La fecha más importante para los proveedores es el 1 de enero de 2027, fecha en la que se espera que las nuevas adquisiciones de NSS cumplan de forma predeterminada con el CNSA 2.0.  La norma CNSSP 15 establece el requisito de adquisición para el 1 de enero de 2027. Los equipos y servicios que no sean compatibles con la CNSA 2.0 deberán retirarse progresivamente antes del 31 de diciembre de 2030, y el uso de los algoritmos de la CNSA 2.0 será obligatorio a partir del 31 de diciembre de 2031.

CNSA 2.0 también es más restrictivo en cuanto a lo que aprueba. Permite el uso de ML-KEM y ML-DSA, pero SLH-DSA no está aprobado para ningún uso en sistemas de seguridad nacional. La norma CNSSP 15 se ha actualizado para incorporar la CNSA 2.0; el NIAP valida los productos según los perfiles de protección publicados, y las soluciones CSfC se registran según los paquetes de capacidades de la NSA. Si vendes a organismos federales o a la base industrial de defensa, esta vía establece tus requisitos a corto plazo.

La tarea más concreta a corto plazo: tu cartera de clientes potenciales

Para los proveedores de « software », el requisito de firma es la obligación más concreta a corto plazo. Las firmas de firmware y de « software » tienen una larga vida útil, son difíciles de reemitir sobre el terreno y son precisamente lo que un atacante querría falsificar. Eso las convierte en el primer ámbito práctico en el que la preparación para la era poscuántica se hace realidad.

La firma también requiere compatibilidad con nuevos algoritmos, no solo claves más largas. CNSA 2.0 especifica esquemas basados en hash con estado, LMS o XMSS tal y como se definen en la norma NIST SP 800-208, para la firma de « software » y de firmware. Estos se diferencian del ML-DSA de uso general y conllevan sus propios requisitos de gestión de estado. Un proceso de firma basado únicamente en claves RSA o ECDSA más largas no cumple con esta obligación. Se necesitan los algoritmos adecuados resistentes a la computación cuántica, implementados correctamente.

El cuello de botella del CMVP: dos barras, una cola

Detrás del problema del algoritmo se esconde un problema logístico. La validación poscuántica no llega a una pista desierta. Se solapa con la transición habitual de FIPS 140-2 a FIPS 140-3, por lo que una única cola de validación, ya de por sí saturada, tiene ahora que superar dos obstáculos al mismo tiempo.

Los cálculos de plazos son implacables. Las validaciones según la norma FIPS 140-3 han durado una media de unos 18 meses, y la lista de espera ha aumentado desde entonces, por lo que un plazo de entre 18 y 30 meses es un margen de planificación realista. A fecha de agosto de 2026, los módulos de PQC se encuentran en la lista de espera del CMVP, y varios proveedores tienen previsto obtener los certificados a partir de finales de 2026.

La expiración de la norma FIPS 140-2 aumenta la presión. El 21 de septiembre de 2026, los certificados FIPS 140-2 que sigan activos pasarán a formar parte de la lista histórica del CMVP. Las implementaciones existentes podrán seguir funcionando, pero las agencias federales no deberán incluir módulos históricos en nuevas contrataciones. A menudo, una misma solicitud debe cumplir ambos requisitos, por lo que entrar pronto en la cola es más importante de lo que parece.

Recoge ahora, descifra después: por qué esperar ya es una decisión en sí misma

El argumento más sólido para actuar ahora no tiene nada que ver con la fecha en que estará disponible un ordenador cuántico operativo. Se trata del problema de «recoger ahora, descifrar más tarde». Un adversario puede capturar hoy mismo el tráfico cifrado y almacenarlo, para luego descifrarlo una vez que exista un ordenador cuántico con capacidad criptográfica.

Esto replantea el plazo en función de la sensibilidad de los datos, y no de hardware. Si tu producto protege información que debe permanecer confidencial durante más de 10 o 15 años, se puede considerar que esos datos ya están expuestos. Esperar no es una postura neutral. Es una decisión de aceptar esa exposición, y es algo que tus clientes te pedirán cada vez más que justifiques.

Lo que realmente requiere una migración controlada

Una migración gestionada se reduce a cuatro capacidades que un proveedor de software debe poner en marcha. Responder a cada pregunta sobre el grado de preparación requiere un control operativo, no un proyecto puntual. A continuación se detalla lo que exige cada una de ellas.

Elaborar un inventario criptográfico completo

No se puede migrar lo que no se ve. Un inventario completo permite detectar todos los certificados, claves, algoritmos y bibliotecas presentes en tus productos, procesos de compilación y entornos en la nube. Es fundamental que incluya las dependencias heredadas open-source , ya que la criptografía que no has escrito tú sigue siendo criptografía que distribuyes.

Clasificar los activos vulnerables a los ataques cuánticos según su sensibilidad y su vida útil

No todos los activos tienen la misma urgencia. Una vez identificados, los activos vulnerables a los ataques cuánticos deben clasificarse según el calendario de obsolescencia de la norma NIST IR 8547 y en función del tiempo que deben conservarse sus datos o su fiabilidad. Esa clasificación convierte una lista simple en un orden de migración prioritario.

Facilita la gestión ágil de certificados y claves a escala de flota

La migración no es un cambio único. Es necesario poder rotar, reemitir y generar nuevas claves a gran escala, además de poder emitir certificados compatibles con PQC y certificados híbridos para una transición por fases. La agilidad criptográfica es lo que te permite avanzar sin interrumpir la producción y, posteriormente, seguir avanzando a medida que evolucionan los estándares.

Evaluar la situación de los proveedores y las dependencias

Tu vulnerabilidad no se limita a tu propio código. Es importante evaluar la situación de los proveedores y las dependencias en materia de PQC, ya que la criptografía heredada se convierte en tu vulnerabilidad en el momento en que la incorporas. Un proveedor que ignora su cadena de suministro hereda todas las debilidades que esta presente.

Cómo Keyfactor ayudarte Keyfactor

Estas cuatro capacidades se corresponden directamente con la plataforma « Keyfactor », por lo que las cuestiones de preparación mencionadas anteriormente se convierten en controles operativos en lugar de riesgos pendientes.

• Inventario criptográfico y evaluación de vulnerabilidades. Keyfactor AgileSec detecta los activos criptográficos en productos, procesos de compilación e infraestructura en la nube, y facilita la evaluación de vulnerabilidades cuánticas para que puedas establecer prioridades.
• Emisión de certificados compatibles con PQC e híbridos. EJBCA Emite certificados utilizando algoritmos PQC normalizados por el NIST, incluidos certificados híbridos que admiten una migración por etapas.
• Agilidad criptográfica a escala de flota. Keyfactor Command Automatiza la gestión del ciclo de vida de los certificados y las claves, de modo que la rotación y la generación de nuevas claves se adaptan a la escala sin necesidad de intervención manual en cada terminal.
• Firma a prueba de la computación cuántica. Keyfactor SignServer y Keyfactor Signum es compatible con la firma de software y de firmware, incluidos los esquemas LMS y XMSS que exige CNSA 2.0.

En conjunto, estos productos conforman el «Trust Control Plane» de Keyfactor: un único sistema de registro que supervisa, analiza, aprovisiona, coordina y gestiona los activos criptográficos. En lugar de tener que buscar certificados en herramientas inconexas, los equipos de seguridad gestionan la confianza como una operación única y continua. Eso es precisamente lo que requiere, en realidad, el seguimiento de la validación según la norma FIPS 140-3 de los algoritmos de PQC, así como de todo lo demás en estos plazos.

La preparación para la era poscuántica es un programa, no un proyecto

Los dos plazos son fijos, pero el trabajo que hay detrás no termina cuando pasa una fecha. Los estándares evolucionarán, se añadirán y retirarán algoritmos, y tu huella criptográfica seguirá cambiando. La preparación para la era poscuántica es una capacidad operativa que se mantiene de forma continua, no un hito que se tacha de la lista.

Lo más sensato es empezar ya con las dos tareas que más tiempo llevan. Elabora tu inventario criptográfico para saber qué es lo que vas a migrar y envía tus módulos a la cola de validación con antelación, para que el cuello de botella del CMVP no determine tu fecha de entrega. Los proveedores que se adelanten a los plazos los tratarán como algo rutinario. Los que esperen, los afrontarán como emergencias.

¿Estás listo para saber cuál es tu situación? Solicitar una demo para hacer un inventario de tus sistemas criptográficos y trazar tu camino hacia la seguridad cuántica.

¿Tienes dudas sobre la preparación para la era poscuántica? Tenemos las respuestas.

What is post-quantum readiness for a software vendor?
It is the ongoing ability to discover, classify, and migrate cryptography to quantum-safe standards. For vendors, it centers on signing pipelines, certificate issuance, and validated modules. It is an operating capability, not a one-time upgrade.

When are the key post-quantum deadlines?
Two dates matter most. FIPS 140-2 validations move to the CMVP Historical list on September 21, 2026, and new NSS acquisitions are expected to be CNSA 2.0-compliant by default from January 1, 2027.  NIST IR 8547, still an initial public draft, proposes deprecation after 2030 and disallowance after 2035. EO 14412 sets December 31, 2030 for key establishment and December 31, 2031 for digital signatures on federal high-value and high-impact systems.

Which post-quantum algorithms did NIST finalize?
NIST finalized three standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) for hash-based signatures.  Of those three, CNSA 2.0 includes ML-KEM and ML-DSA. It also approves LMS and XMSS from SP 800-208 for firmware and software signing, and does not approve SLH-DSA for any use in NSS.

Why is software signing the first priority?
Signatures have long lifetimes and are hard to re-issue once deployed.  CNSA 2.0 approves ML-DSA-87 as well as LMS and XMSS for firmware and software signing. Larger RSA or ECDSA keys satisfy none of these. That makes signing the most concrete near-term obligation.

What is the CMVP bottleneck?
Post-quantum validation overlaps with the ordinary FIPS 140-3 transition, creating one crowded queue. Validations have averaged roughly 18 months, so 18 to 30 months is a realistic planning range. Submitting early is the main way to protect your timeline.

What does harvest-now-decrypt-later mean for my product?
Attackers can capture encrypted data today and decrypt it once quantum computers mature. If your product protects data that must stay confidential beyond 10 to 15 years, that data is already exposed. Waiting to migrate is effectively accepting that risk.

How do I start a post-quantum migration?
Begin with a complete cryptographic inventory across products, pipelines, and dependencies. Classify assets by sensitivity and lifespan against the NIST IR 8547 schedule, then build agility to rotate and reissue at scale. Assess your suppliers, since inherited cryptography becomes your exposure.

How does Keyfactor support post-quantum readiness?
Keyfactor AgileSec handles discovery and quantum-vulnerability assessment, EJBCA issues PQC and hybrid certificates, and Keyfactor Command automates lifecycle at scale. SignServer and Signum support quantum-safe signing, all unified in the Trust Control Plane.