Quien siga de cerca la transición a la criptografía postcuántica habrá notado que en los últimos seis meses el tema ha pasado de las recomendaciones genéricas a los calendarios con fechas, las normas técnicas aplicables y los estándares de protocolo publicados. Al mismo tiempo, una pieza que muchos esperábamos para este año, el estándar de firma FN-DSA (FIPS 206), sigue sin aparecer. En esta entrada repaso lo más relevante: normativa y pautas públicas, estándares de NIST, ETSI e IETF, la evolución de los certificados TLS y las herramientas abiertas para elaborar el inventario criptográfico.

FIPS 206 (FN-DSA): todavía no

En agosto de 2024 NIST publicó los tres primeros estándares postcuánticos: FIPS 203 (ML-KEM, mecanismo de encapsulado de claves derivado de CRYSTALS-Kyber), FIPS 204 (ML-DSA, firma basada en retículos derivada de CRYSTALS-Dilithium) y FIPS 205 (SLH-DSA, firma basada en funciones hash derivada de SPHINCS+). El cuarto, FIPS 206, debía especificar FN-DSA, la firma derivada de Falcon (de ahí el nombre: FFT over NTRU-Lattice-Based Digital Signature Algorithm), cuyo atractivo son unas firmas mucho más compactas que las de ML-DSA (en torno a 666 bytes en el nivel I frente a los 2.420 de ML-DSA-44).

A fecha de hoy FIPS 206 no se ha publicado, ni siquiera como borrador para comentarios públicos (initial public draft). En abril de 2026, Dustin Moody (NIST) indicaba en el foro PQC que el borrador seguía en la cadena de aprobación administrativa, sin fecha concreta. Y el 28 de septiembre de 2026 el equipo de FIPS 206, a través de Ray Perlner, presentó un nuevo plan sometido a discusión:

• Un único procedimiento de firma, especificado con el detalle suficiente para validarse con vectores de prueba conocidos (KAT).
• Aritmética de punto fijo en la generación de claves y en la firma (inicialmente 32.32 y 64.64), en lugar de la de punto flotante, que es la que hace de Falcon un algoritmo delicado de implementar de forma segura y reproducible.
• Las variantes optimizadas se aprobarían más adelante en publicaciones especiales (SP) separadas, con sus propios KAT y separación de dominio.

Cambiar decisiones de diseño a estas alturas sugiere que el borrador tardará todavía unos meses, y que después vendrá el periodo de comentarios y la versión final. Para quien necesite firmas postcuánticas hoy, las opciones estandarizadas siguen siendo ML-DSA (Dilithium) y SLH-DSA (SPHINCS+) y, para firmware, los esquemas con estado LMS y XMSS de la SP 800-208.

NIST sí ha movido otras piezas en 2026: el borrador de la SP 800-230 (13 de abril), con nuevos juegos de parámetros de SLH-DSA (SPHINCS+) para casos de uso con un número limitado de firmas; el borrador de la SP 800-133r3 (17 de abril) sobre generación de claves; y el paso de nueve candidatos a la tercera ronda del proceso de firmas adicionales (NIST IR 8610, mayo). El estándar del segundo KEM, HQC (Hamming Quasi-Cyclic, basado en códigos correctores de errores), seleccionado en marzo de 2025 como alternativa a ML-KEM (Kyber) basada en otro problema matemático, también está pendiente de borrador.

El calendario ya tiene fechas

La novedad más importante del año no es técnica sino de planificación: Europa, España y Estados Unidos coinciden ya en un calendario muy parecido.

Unión Europea

La hoja de ruta coordinada del Grupo de Cooperación SRI (NIS), publicada en junio de 2025, fijó tres hitos: iniciar la transición antes de finales de 2026, completar la migración de los casos de uso de riesgo alto antes de 2030 y la del resto, en la medida de lo posible, antes de 2035. En enero de 2026 la Comisión dio un paso más con la Propuesta de Directiva del Parlamento Europeo y del Consejo por la que se modifica la Directiva (UE) 2022/2555 sobre medidas de simplificación y armonización con la [Propuesta de Reglamento sobre la Ciberseguridad 2] (COM(2026) 13 final, de 20 de enero de 2026). La Directiva (UE) 2022/2555 es la Directiva SRI 2, más conocida por su sigla inglesa NIS2. Su artículo 1, apartado 5, añade al artículo 7.2 de la Directiva, que enumera las políticas que deben formar parte de la estrategia nacional de ciberseguridad, una nueva letra:

«k) para la transición hacia una criptografía postcuántica, teniendo en cuenta los calendarios de transición y los requisitos pertinentes establecidos en los actos jurídicos y políticas de la Unión aplicables.»

El considerando 8 explica el porqué: la posibilidad de ataques basados en «recopilar ahora para descifrar más adelante», «que probablemente ya están teniendo lugar», los riesgos futuros de falsificación de firmas mediante ataques cuánticos y la retirada progresiva de los algoritmos de clave pública actuales «hacen aún más urgente iniciar acciones de migración a la criptografía poscuántica». Pide que esas políticas incluyan herramientas para evaluar la exposición de los activos criptográficos, un plan de migración y pruebas de implantación, que fomenten soluciones europeas verificadas y sometidas a evaluación formal, y que se ajusten a la hoja de ruta del Grupo de Cooperación SRI, «logrando así la migración a la criptografía poscuántica de aquí a 2030 para los casos de uso crítico y de aquí a 2035 para los casos de uso de nivel medio y bajo». Es todavía una propuesta, sujeta al procedimiento legislativo ordinario, pero convierte la hoja de ruta en una obligación de los Estados.

En el ámbito de la certificación de productos, ENISA y el subgrupo de criptografía del ECCG sometieron a consulta pública, hasta finales de julio de 2026, la versión 3 de los Agreed Cryptographic Mechanisms del esquema europeo EUCC, la referencia de mecanismos criptográficos aceptados para productos certificados.

España

En julio de 2026 el Centro Criptológico Nacional publicó la guía de buenas prácticas CCN-TEC 009 (BP/37) «Recomendaciones para una transición postcuántica segura», que traslada el calendario europeo a nuestro contexto:

• 31 de diciembre de 2026: estrategia y gobernanza definidas, inventario criptográfico, clasificación de casos de uso y pilotos en marcha para los sistemas de riesgo alto y medio.
• 31 de diciembre de 2030: migración completada en los sistemas de riesgo alto.
• 31 de diciembre de 2035: migración completada en los de riesgo medio y, en lo posible, en los de riesgo bajo.

La guía recomienda soluciones híbridas al menos en las primeras etapas: en el establecimiento de claves, combinar al menos dos mecanismos (intercambio clásico, intercambio postcuántico o claves precompartidas) mediante una función de derivación; en firmas, hibridar las basadas en retículos (ML-DSA y FN-DSA), mientras que las basadas en hash (XMSS y SLH-DSA) no lo requieren. Entre los KEM cita ML-KEM, HQC y FrodoKEM, que considera la opción más conservadora. Insiste en la criptoagilidad como criterio de diseño, en el gobierno del programa (comité, oficina PQC, equipos técnicos) y en su alineamiento con el ENS, NIS2, DORA y el RGPD, y recuerda el teorema de Mosca para estimar el margen disponible: si el tiempo que deben protegerse los datos más el tiempo de migración supera el plazo hasta que exista un ordenador cuántico relevante, el problema ya está aquí. Para elegir productos remite a la guía CCN-STIC 221 de mecanismos autorizados y al apartado Quantum Resistant del catálogo CPSTIC.

En septiembre, el secretario de Estado de Telecomunicaciones e Infraestructuras Digitales, Antonio Hernando, anunció en el encuentro de AMETIC en Santander que el Gobierno elaborará un inventario de sistemas, empezando por la Administración General del Estado, y un calendario de migración que situaría el inicio de la transición de los sistemas más críticos en 2030-2031. Por ahora no hay real decreto ni orden ministerial: es un anuncio de plan, que conviene seguir.

Estados Unidos

La orden ejecutiva 14412, Securing the Nation Against Advanced Cryptographic Attacks, de 22 de junio de 2026, endurece los plazos federales: criptografía postcuántica para el establecimiento de claves en los activos de alto valor y sistemas de alto impacto antes del 31 de diciembre de 2030, y para las firmas antes del 31 de diciembre de 2031. El memorando OMB M-26-15 que la acompaña pide además un inventario criptográfico automatizado que alimente un CBOM central. En el sector privado, Google anunció el 25 de marzo su objetivo de estar preparada en 2029, con ML-DSA incorporado a Android 17 para el arranque verificado y la atestación.

ETSI TS 119 312: los prestadores de servicios de confianza ya tienen reglas

Para los prestadores cualificados de servicios de confianza la publicación más relevante del semestre es la ETSI TS 119 312 V2.1.1 (junio de 2026), Cryptographic Suites, la especificación que establece qué algoritmos y longitudes de clave son adecuados para firmas, sellos y certificados en el ecosistema eIDAS. La versión 2 supone un cambio de enfoque:

• Incorpora ML-DSA (Dilithium; parámetros 44, 65 y 87) y SLH-DSA (SPHINCS+) como algoritmos recomendados, y LMS y XMSS de forma condicionada a una gestión estricta del estado.
• Define un marco de firmas híbridas (cláusula 6.4), con combinaciones recomendadas como RSA-PSS de 3.000 bits o más con ML-DSA-65.
• Fija fechas de fin concretas: los certificados con claves RSA de menos de 3.000 bits no deberían emitirse después del 31 de diciembre de 2026, y su validez no debería ir más allá de 2028.
• Exige protección postcuántica (híbrida o por sustitución) cuando la validez de lo protegido se extienda más allá de 2030, tanto para RSA como para ECDSA.

No incluye todavía FN-DSA (Falcon), por la razón ya explicada, ni ML-KEM (Kyber), que no es un algoritmo de firma. Y remite el calendario detallado de migración a un documento específico de ETSI que aún está en elaboración.

En España, el abandono de RSA-2048 por los prestadores no es solo una recomendación técnica: tiene mandato del organismo supervisor. La Subdirección General para la Sociedad Digital, de la Secretaría de Estado de Digitalización e Inteligencia Artificial, publicó en octubre de 2025 la Nota sobre la migración del algoritmo RSA, dirigida a los prestadores cualificados y no cualificados que usan RSA. Les exige cumplir el Anexo 1 de la guía CCN-STIC 807 del Centro Criptológico Nacional, según el cual a partir del 1 de enero de 2027 los certificados RSA que se sigan emitiendo deberán usar módulos de al menos 3.000 bits. Los prestadores cualificados que tengan jerarquías con claves más cortas deben generar otras nuevas y acreditarlo con un informe técnico de un organismo de evaluación de la conformidad que incluya, como mínimo, la evidencia de la ceremonia de generación de claves (o con el informe de su auditoría, si se realiza antes del 31 de diciembre de 2026). Ya lo comenté en «Actualización urgente para las administraciones públicas en relación con las firmas electrónicas», porque las Administraciones deben adaptar sus sedes y plataformas de firma para aceptar los nuevos certificados.

Norma europea y supervisor nacional coinciden, por tanto: 2026 es el último año para emitir certificados RSA-2048, y quien firme o selle documentos que deban conservar su valor más allá de 2030 debe planificar ya la hibridación con algoritmos postcuánticos.

En otro ámbito, ETSI ha publicado el informe técnico TR 104 171 (versión 1.1.1, de marzo de 2026, difundido en septiembre) con pautas de implementación para generadores cuánticos de números aleatorios (QRNG), que introduce el concepto de «confianza cero en la entropía».

En la parte de cifrado, la que protege frente a la recolección de tráfico para descifrarlo en el futuro, el IETF ha cerrado este año los documentos que faltaban:

TLS: el intercambio de claves postcuántico ya es estándar

• RFC 9954 (julio de 2026), de carácter informativo, define la construcción general del intercambio de claves híbrido en TLS 1.3: se combinan un algoritmo clásico y uno postcuántico y el secreto resultante es seguro mientras lo sea cualquiera de los dos.
• RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 (agosto de 2026), en vía de estándar, la concreta en tres grupos: X25519MLKEM768, el único marcado como recomendado en el registro de IANA y el que ya negocian por defecto los principales navegadores, y SecP256r1MLKEM768 y SecP384r1MLKEM1024, pensados para entornos cuyas normas exigen curvas NIST.
• El borrador de ML-KEM sin componente clásico en TLS fue aprobado por el IESG en septiembre, está en la cola del RFC Editor y se publicará como RFC informativa; en el registro de IANA figura como no recomendado, frente al híbrido.

Es decir, las orientaciones del IETF coinciden con las del CCN: híbrido primero. Activar X25519MLKEM768 en servidores, balanceadores y CDN es hoy una de las acciones con mejor relación entre coste y beneficio.

La autenticación: certificados más cortos y Merkle Tree Certificates

La autenticación postcuántica es más difícil por una cuestión de tamaño. Una firma ML-DSA-44 (Dilithium) ocupa unos 2.420 bytes, frente a los 64 de ECDSA P-256; con las varias firmas y claves públicas que viajan en un handshake TLS (certificado, cadena, transparencia), la sustitución directa llevaría el handshake por encima de los 10 KB, con un impacto apreciable en la latencia. ML-DSA ya está definido para certificados X.509 en el RFC 9881 (octubre de 2025), pero su despliegue masivo en la web es otra cosa.

Por eso cobra interés el trabajo del grupo IETF PLANTS sobre los Merkle Tree Certificates (MTC): la autoridad de certificación emite los certificados en lotes, firma una sola vez la raíz del árbol de Merkle y los navegadores reciben esas firmas por separado, de modo que en el handshake solo viaja una prueba de inclusión. Let’s Encrypt anunció en junio que tendrá un entorno de pruebas con MTC a finales de 2026 y uno de producción en 2027, y Cloudflare y Chrome están experimentando con el mismo esquema.

En paralelo avanza la reducción de la duración de los certificados TLS acordada en el CA/Browser Forum (votación SC-081v3, abril de 2025): desde el 15 de marzo de 2026 el máximo es de 200 días, que bajará a 100 días en marzo de 2027 y a 47 días en marzo de 2029. La justificación principal es reducir la dependencia de una revocación que no funciona bien y la vigencia de datos de validación obsoletos, pero hay un argumento que interesa especialmente aquí: la criptoagilidad. Una organización que renueva sus certificados cada pocas semanas de forma automatizada (con ACME) puede cambiar de algoritmo, de clave o de autoridad de certificación en un ciclo de renovación; una que gestiona certificados de un año a mano, no. La renovación frecuente es, en la práctica, el ensayo general de la migración postcuántica.

El primer paso: inventario y CBOM con herramientas abiertas

Todas las guías coinciden en que el primer paso es saber qué criptografía se usa, dónde y para proteger qué información durante cuánto tiempo. El formato que se está imponiendo para documentarlo es el CBOM (Cryptography Bill of Materials), incorporado al estándar CycloneDX en su versión 1.6 (abril de 2024), que describe algoritmos, claves, certificados, protocolos y bibliotecas de un sistema y sus dependencias.

Entre las herramientas abiertas destaca CBOMkit, ahora bajo el paraguas de la Post-Quantum Cryptography Alliance de la Linux Foundation, que incluye un visor, un generador de CBOM y un plugin para SonarQube (sonar-cryptography) que detecta el uso de criptografía en el código fuente. En 2026 ha añadido soporte para Go, además de Java y Python, y está migrando su salida a CycloneDX 1.7. Un CBOM generado a partir del código, combinado con el inventario de certificados y configuraciones TLS de la infraestructura, es exactamente lo que piden tanto la guía del CCN como el memorando M-26-15.

Qué hacer ahora

Con lo publicado en estos meses, la lista de tareas para una entidad grande queda bastante definida:

1. Gobierno: nombrar responsables y aprobar un plan con presupuesto antes de que termine 2026, como pide el CCN.
2. Inventario y CBOM: descubrir la criptografía de aplicaciones, infraestructura y proveedores, y clasificar los casos de uso por riesgo y por tiempo de vida de la información.
3. Quick wins: activar el intercambio de claves híbrido X25519MLKEM768 en TLS y automatizar la renovación de certificados.
4. Firmas de larga duración: revisar qué documentos, sellos y evidencias deben conservar su valor más allá de 2030 y planificar firmas híbridas conforme a la ETSI TS 119 312.
5. Proveedores: incluir la criptoagilidad y la hoja de ruta postcuántica en los requisitos de compra.
6. Formación: preparar a los equipos técnicos y de cumplimiento, porque la migración será larga y afectará a casi todos los sistemas.

Cómo puede ayudar EADTrust

En EADTrust llevamos tiempo trabajando en esta transición. Nuestras jerarquías de certificación ya combinan RSA de 4.096 y 8.192 bits con curva elíptica ECC de 256 y 384 bits, precisamente para tener margen de criptoagilidad (por eso la nota del supervisor sobre RSA no nos ha afectado), y acompañamos a otras organizaciones en el mismo camino:

• Formación en computación cuántica y criptografía postcuántica, in company y en abierto. Impartimos el curso de computación cuántica y criptografía postcuántica y lo adaptamos a cada organización, de forma presencial, en línea o híbrida, para que los equipos entiendan qué cambia, por qué y cómo abordarlo. Además, una vez al año celebramos una edición en abierto, presencial, que tendrá lugar cada año en torno al 14 de abril, Día Mundial de la Cuántica. La edición de 2026, con la metodología ENSAR y los modelos del IQC Kit, que permiten «tocar» los conceptos que se explican, se celebró los días 22 y 23 de abril (más información en «Evento formativo sobre computación cuántica y criptografía postcuántica en abril de 2026, con la metodología ENSAR»). Puede consultar el resto de nuestra oferta formativa en la página de cursos EADTrust.
• Acompañamiento profesional en la migración de sistemas criptográficos de entidades grandes: inventario y CBOM, análisis de riesgos y priorización, hoja de ruta alineada con el calendario europeo y la guía del CCN, diseño de soluciones híbridas y adaptación de infraestructuras de clave pública. Ya estamos trabajando en estos aspectos con dos grandes clientes.

Si su organización necesita empezar o acelerar su transición postcuántica, puede contactar con nosotros:

• Web: www.eadtrust.eu
• Correo electrónico: info@eadtrust.com
• Teléfonos: 902 365 612 y 91 716 05 55

Referencias

Fuentes originales

• NIST: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA)
• NIST pqc-forum: FIPS 206 Status Update y New plan for FN-DSA (28 de septiembre de 2026)
• NIST: SP 800-230 (borrador), SP 800-133 Rev. 3 (borrador), nueve candidatos a la tercera ronda de firmas adicionales (IR 8610) y selección de HQC
• NIS Cooperation Group: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (junio de 2025)
• Comisión Europea: COM(2026) 13 final, Propuesta de Directiva por la que se modifica la Directiva (UE) 2022/2555 sobre medidas de simplificación y armonización con la [Propuesta de Reglamento sobre la Ciberseguridad 2] (EUR-Lex; versión en inglés; documento del Consejo 5627/26)
• ENISA: consulta pública del borrador de Agreed Cryptographic Mechanisms
• Centro Criptológico Nacional: CCN-TEC 009 (BP/37) Recomendaciones para una transición postcuántica segura (julio de 2026)
• Ministerio para la Transformación Digital y de la Función Pública: Nota sobre la migración del algoritmo RSA (octubre de 2025)
• Casa Blanca: Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks (PDF) y OMB M-26-15, Execution of the Migration to Post-Quantum Cryptography
• Google: Quantum frontiers may be closer than they appear (25 de marzo de 2026)
• ETSI: TS 119 312 V2.1.1 (2026-06) Cryptographic Suites y TR 104 171 V1.1.1 (2026-03)
• IETF: RFC 9954 Hybrid Key Exchange in TLS 1.3, RFC 10024 Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3, draft-ietf-tls-mlkem, RFC 9881 ML-DSA in X.509 Certificates y draft-ietf-plants-merkle-tree-certs
• Let’s Encrypt: A Post-Quantum Future for Let’s Encrypt
• CA/Browser Forum: Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• OWASP CycloneDX: CycloneDX v1.6 released; PQCA: CBOMkit, sonar-cryptography y CBOMkit Now Supports Go

Resúmenes y artículos de terceros

• NIST locks FN-DSA to fixed-point math for FIPS 206
• España prepara un calendario de migración a criptografía postcuántica (AMETIC, septiembre de 2026)
• The EU Just Proposed Including Post-Quantum Cryptography (PQC) in NIS2
• EO 14412: Hard 2030 and 2031 Federal PQC Deadlines
• Google sets 2029 deadline for quantum-safe encryption
• ETSI Publishes Guidance for Secure Quantum Random Number Generators
• RFC 10024: Hybrid ML-KEM TLS 1.3 Standard Finalized
• Sectigo: certificados TLS de 47 días
• Actualización urgente para las administraciones públicas en relación con las firmas electrónicas (inza.blog)