Keyfactor Days 2027, la conferencia sobre seguridad de confianza, llega a San Diego!   Descubre lo que se avecina

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

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

Cumplimiento

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.

¿En qué consiste la preparación para la era poscuántica para un proveedor de servicios de « software »?
Se trata de la capacidad continua de detectar, clasificar y migrar la criptografía a estándares seguros frente a la computación cuántica. Para los proveedores, se centra en los procesos de firma, la emisión de certificados y los módulos validados. Se trata de una capacidad operativa, no de una actualización puntual.

¿Cuáles son los plazos clave en materia de seguridad poscuántica?
Hay dos fechas especialmente importantes. Las validaciones según la norma FIPS 140-2 pasarán a la lista histórica del CMVP el 21 de septiembre de 2026, y se espera que las nuevas adquisiciones de NSS cumplan de forma predeterminada con la norma CNSA 2.0 a partir del 1 de enero de 2027.  El NIST IR 8547, que aún es un borrador público inicial, propone su obsolescencia a partir de 2030 y su prohibición a partir de 2035. La Orden Ejecutiva 14412 establece el 31 de diciembre de 2030 como fecha límite para el establecimiento de claves y el 31 de diciembre de 2031 para las firmas digitales en los sistemas federales de alto valor y gran impacto.

¿Qué algoritmos poscuánticos ha aprobado el NIST?
El NIST aprobó tres normas en agosto de 2024: la FIPS 203 (ML-KEM) para el establecimiento de claves, la FIPS 204 (ML-DSA) para firmas y la FIPS 205 (SLH-DSA) para firmas basadas en hash.  De estos tres, la CNSA 2.0 incluye ML-KEM y ML-DSA. También aprueba LMS y XMSS de la SP 800-208 para la firma de firmware y de « software », y no aprueba SLH-DSA para ningún uso en el NSS.

¿Por qué se da prioridad a la firma de software ?
Las firmas tienen una vida útil prolongada y son difíciles de reemitir una vez implementadas. La CNSA 2.0 aprueba ML-DSA-87, así como LMS y XMSS, para la firma de firmware y de software . Las claves RSA o ECDSA de mayor tamaño no cumplen ninguno de estos requisitos. Por ello, la firma se convierte en la obligación más concreta a corto plazo.

¿En qué consiste el cuello de botella del CMVP?
La validación poscuántica se solapa con la transición habitual a la norma FIPS 140-3, lo que genera una cola muy saturada. La duración media de las validaciones ha sido de unos 18 meses, por lo que un plazo de entre 18 y 30 meses es una estimación realista. Presentar la solicitud con antelación es la mejor forma de garantizar el cumplimiento de tus plazos.

¿Qué significa «recoger ahora, descifrar más tarde» para mi producto?
Los atacantes pueden capturar datos cifrados hoy y descifrarlos cuando los ordenadores cuánticos alcancen su madurez. Si tu producto protege datos que deben permanecer confidenciales durante más de 10 o 15 años, esos datos ya están expuestos. Esperar a migrar equivale, en la práctica, a aceptar ese riesgo.

¿Cómo puedo iniciar una migración poscuántica?
Empieza por realizar un inventario criptográfico completo de todos los productos, procesos y dependencias. Clasifica los activos según su nivel de confidencialidad y su vida útil, basándote en la tabla del NIST IR 8547, y luego desarrolla la agilidad necesaria para rotarlos y renovarlos a gran escala. Evalúa a tus proveedores, ya que la criptografía heredada se convierte en un riesgo para ti.

¿Cómo contribuye Keyfactor a la preparación para la era poscuántica?
Keyfactor AgileSec se encarga del descubrimiento y la evaluación de vulnerabilidades cuánticas, EJBCA emite certificados PQC e híbridos, y Keyfactor Command automatiza el ciclo de vida a gran escala. SignServer y Signum admiten la firma a prueba de ataques cuánticos, todo ello unificado en el Trust Control Plane.