Guía del Observatorio
Criptografía poscuántica, explicada para quien tiene que decidir
Qué cambia con el riesgo cuántico y cómo priorizar la migración combinando duración de la confidencialidad, tiempo de transición e hipótesis explícitas sobre capacidad futura.
Corte propio de esta guía: 2026-07-28 (independiente de la edición del Informe). El documento declara: «Contraste documental a 03-10-2026 · Candidato para revisión del comité editorial · Fuentes primarias NIST, España y Europa». No consta en el Observatorio un registro de verificación con revisor y fecha para este documento.
Reloj de Mosca · escenarios
¿Cuánto margen tienes?
El teorema de Mosca no necesita saber cuándo llegará el ordenador cuántico: compara cuánto tiempo debe seguir siendo secreto un dato (X) más lo que tardarás en migrarlo (Y) con los años que faltan hasta el horizonte que asumes para una máquina capaz de romperlo (Z). Si X + Y supera esos años, con esas hipótesis el dato que cifras hoy seguiría necesitando protección cuando esa capacidad existiera: hay déficit de planificación. Compara escenarios para ver qué hipótesis mueve el resultado.
Margen = (Z − año de partida) − (X + Y), en años enteros. Si es negativo, hay déficit de planificación con esas hipótesis.
Año de partida: 2026 (año en curso, hora de Madrid).
- Para quién
- Quien prioriza la migración: asesoría jurídica y negocio fijan cuánto debe durar la confidencialidad (X); tecnología y proveedores, cuánto se tarda en migrar (Y); la hipótesis Z se declara y se documenta.
- Entradas
- Por escenario, dos duraciones en años enteros (X e Y) y un horizonte Z: uno de los dos hitos de planificación europeos o un año propio. Cambia una sola hipótesis entre escenarios para ver su efecto.
- Salida
- Margen o déficit de planificación de cada escenario, con sus hipótesis a la vista y la diferencia respecto del escenario A. La decisión, las hipótesis y la persona responsable se trasladan al inventario criptográfico.
Los tres escenarios iniciales son ejemplos de cálculo: no describen ninguna organización ni tienen valor predictivo. A y B solo difieren en el horizonte; B y C, en la vida útil del dato.
Comparación de escenarios
Los tres a la misma escala. La barra es X + Y; el trazo vertical, los años hasta Z; el tramo ocre, lo que sobrepasa el horizonte asumido.
- Escenario ADéficit de planificación de 9 años
Hipótesis: X 10 + Y 3 = 13 años · Z: 2030 · hito NIS, alto riesgo · 4 años desde 2026
- Escenario BDéficit de planificación de 4 años
Hipótesis: X 10 + Y 3 = 13 años · Z: 2035 · hito NIS, resto · 9 años desde 2026
Frente a A: 5 años más de margen.
- Escenario CMargen de planificación de 4 años
Hipótesis: X 2 + Y 3 = 5 años · Z: 2035 · hito NIS, resto · 9 años desde 2026
Frente a A: 13 años más de margen.
Cómo leer el resultado
- Déficit de planificación· escenarios A, B
- Con estas hipótesis, la vida útil de confidencialidad más la migración superan los años que faltan hasta el horizonte asumido. No demuestra que ningún dato esté comprometido: señala un caso que conviene situar al principio del inventario y de la priorización.
- Sin margen de planificación· ninguno
- Con estas hipótesis, confidencialidad y migración consumen exactamente el tiempo hasta el horizonte asumido. Cualquier retraso de proveedor o de certificación convierte el resultado en déficit.
- Margen de planificación· escenario C
- Con estas hipótesis queda holgura aritmética. No acredita seguridad, cumplimiento ni menor impacto, y no justifica aplazar el inventario. Contrasta exposición, autenticidad, dependencias y escenarios más adversos antes de decidir.
Hipótesis y de dónde salen
- X · Años que este dato debe seguir siendo confidencial
- Estima cuánto tiempo seguirá siendo confidencial el contenido. El plazo legal de conservación es un dato relevante, pero puede diferir de la duración del secreto o del daño potencial.
- Y · Años que tardarías en migrar ese sistema
- Incluye proveedores, certificados, firmware, pruebas, ventanas de parada y dependencias. Documenta una estimación propia y su incertidumbre.
- Z · Horizonte que asumes para la máquina
No es un dato: es una hipótesis. Puedes tomar uno de los dos hitos de planificación europeos o fijar tu propio año. 2030 y 2035 son hitos de planificación de una recomendación: objetivos de coordinación, no fechas universales de sanción ni predicciones de cuándo existirá la máquina. Elegirlos como Z equivale a planificar como si esa capacidad llegara ese año.
- 2030 · hito NIS, alto riesgo
Hoja de ruta coordinada del Grupo de Cooperación NIS (23-06-2025): casos de alto riesgo e infraestructuras críticas, antes del 31-12-2030. → Ver ficha
- 2035 · hito NIS, resto
La misma hoja de ruta recomienda completar la transición de riesgo medio antes de fin2035 y, para riesgo bajo, en la medida factible en ese horizonte. Es un objetivo de coordinación basado en riesgo, no una fecha empresarial universal de sanción. → Ver ficha
- Año propio
Hipótesis tuya. El Observatorio no estima cuándo existirá un ordenador cuántico capaz de romper la criptografía actual.
NIST IR 8547 es un borrador inicial de 12-11-2024. Sus tablas distinguen niveles y algoritmos: proponen desaconsejar después de 2030 los usos de seguridad 112 bits y desautorizar después de 2035 algoritmos de clave pública vulnerables, incluidos niveles superiores. Es una propuesta estadounidense; no establece una obligación general en España. → Ver ficha
Sección 01
El riesgo existe antes que la máquina
Una máquina cuántica suficientemente capaz afectaría a algoritmos clásicos de clave pública. Los riesgos de confidencialidad almacenada y autenticidad duradera requieren estrategias distintas.
Lo que sí cae
Algoritmo de Shor
Shor permite factorizar enteros y resolver logaritmos discretos si existe una máquina cuántica suficientemente grande y tolerante a fallos. Esto comprometería RSA y los esquemas clásicos DH/ECDH/ECDSA que sustentan muchos sistemas TLS, PKI y firmas. El alcance concreto depende de los algoritmos y protocolos del inventario; ninguna fuente aquí acredita un 100% universal de despliegue vulnerable.
- RSA
- Diffie-Hellman
- ECDH / ECDSA (curva elíptica)
Lo que aguanta
Algoritmo de Grover
Grover ofrece una aceleración cuadrática ideal de la búsqueda exhaustiva, relevante para claves simétricas y preimagen de hash. No demuestra la seguridad de todo uso de toda función hash. Parámetros adecuados de AES y funciones SHA siguen siendo parte de las defensas, con revisión del nivel requerido, implementación y protocolo.
- AES-256
- SHA-384 / SHA-512
- SHA-3
La asimetría que ordena las prioridades
Las dos cosas que protege la criptografía pública se rompen en direcciones distintas del tiempo. Entenderlo es lo que evita priorizar al revés.
Confidencialidad
Se rompe hacia atrás
El riesgo harvest now, decrypt later consiste en conservar hoy comunicaciones cifradas para intentar descifrarlas con capacidad futura. Su materialización exige captura útil, un establecimiento/protección de clave vulnerable y que la información conserve valor entonces; no alcanza automáticamente a todo tráfico pasado.
Urgencia máxima cuando el dato tiene vida larga
Autenticidad
Riesgo futuro y preservación de evidencia histórica
La ruptura de un esquema de firma podría permitir crear firmas nuevas falsas, incluso asociadas a fechas antiguas. La validación histórica necesita evidencias independientes y preservación de larga duración; verificar y archivar una vez no garantiza por sí solo autenticidad futura. Firma, sellado de tiempo, conservación y efecto probatorio requieren análisis técnico y jurídico conjunto.
Prioridad según vida útil de claves, certificados, firmware y evidencia
Harvest now, decrypt later
Capturar hoy para descifrar mañana explica por qué los datos de larga confidencialidad exigen prepararse antes de una capacidad cuántica relevante. La decisión combina esa duración, tiempo de migración y escenarios explícitos; la fecha incierta sigue influyendo en el cálculo.
Sección 02
Qué se sustituye exactamente
La criptografía poscuántica reemplaza dos piezas — el acuerdo de clave y la firma —, no el cifrado de los datos. Estos siguen viajando con criptografía simétrica.
KEM
Encapsulación de clave · establece el secreto
Un KEM establece un secreto compartido que un protocolo usa para derivar claves de cifrado simétrico. ML-KEM puede sustituir o complementar mecanismos clásicos vulnerables cuando el protocolo lo incorpora correctamente. La prioridad depende de exposición y duración de la confidencialidad.
- ML-KEMFIPS 203finalprincipal
- HQCHQC seleccionado 11-03-2025 para estandarizaciónen desarrollorespaldo por códigos
Cómo usarlo correctamente: NIST SP 800-227, Recomendaciones para mecanismos de encapsulación de clave (final, septiembre de 2025). [Registro SP 800-227: NIST SP 800-227, Recomendaciones para mecanismos de encapsulación de clave (Recommendations for Key-Encapsulation Mechanisms) (final, 18-09-2025). Revisión del comité editorial pendiente.]
Firma
Origen e integridad · prueba quién y qué
Sustituye a RSA-PSS y ECDSA. Acredita quién emitió un documento, un certificado, una actualización de firmware o una transacción, y que no se ha alterado. Es la pieza que sostiene la prueba a largo plazo.
- ML-DSAFIPS 204finalprincipal
- SLH-DSAFIPS 205finalsupuesto conservador, basado en hash
- FN-DSAFIPS 206en desarrolloFirma compacta en desarrollo; no estándar FIPS final acreditado
- LMS / XMSSSP 800-208finalCon estado; usos limitados, como firmware; gestión estricta de claves OTS
ML-DSA y SLH-DSA son estándares finales desde 13-08-2024. FN-DSA/FIPS 206 sigue en desarrollo en el registro NIST consultado; puede estudiarse, pero no describirse como estándar final de producción. SP 800-208 también normaliza LMS/XMSS con condiciones de estado y perfiles de uso limitados.
Híbrido: combinar componentes con un protocolo definido
Un diseño híbrido combina componentes clásicos y poscuánticos. Mantener seguridad si uno resiste depende de las hipótesis y propiedades del combinador, del protocolo y de su implementación. Para firmas, la política de verificación conjunta debe definirse expresamente; no toda combinación tiene la misma garantía. La arquitectura y permanencia del híbrido se deciden según riesgo y estándar aplicable.
RFC 10024 (agosto 2026, Proposed Standard) define tres grupos híbridos TLS 1.3. OpenSSL 3.5 documenta ML-KEM y esos grupos, con X25519MLKEM768 primero en la lista predeterminada. Capacidad, configuración y negociación son estados distintos: una sesión concreta solo se acredita mediante evidencia de cliente/servidor y handshake.
Fuente: RFC 10024 §§4–6; OpenSSL 3.5 SSL_CONF_cmd -groups y HISTORY; EVP_PKEY_fromdata HISTORY
Sección 03
Por qué hay varias familias y no un ganador
Cada familia descansa en un problema matemático distinto. Mantener alternativas es la forma de no quedar atrapado si una de ellas cae.
Retículos
Problemas en redes de puntos de alta dimensión
ML-KEM y ML-DSA aportan estándares finales basados en retículos. Tamaño, velocidad y adecuación se comparan por parámetros, plataforma, protocolo y pruebas; no hay un ganador universal de rendimiento.
- ML-KEM (FIPS 203)
- ML-DSA (FIPS 204)
- FN-DSA (FIPS 206, en desarrollo)
Funciones hash
Propiedades de seguridad de funciones hash y diseño del esquema
Permiten diversificar supuestos respecto de retículos. SLH-DSA es sin estado y tiene firmas grandes; LMS/XMSS exigen preservar estado de firma y evitar reutilizar claves de un solo uso.
- SLH-DSA (FIPS 205), sin estado
- LMS / XMSS (SP 800-208), con estado
Códigos correctores
Problemas de decodificación de códigos utilizados por cada esquema
HQC ofrece una base matemática diferente de ML-KEM y se seleccionó como alternativa. Una debilidad en un esquema de retículos no demuestra por sí sola la seguridad ni la ruptura de los esquemas por códigos: cada construcción requiere su análisis.
- HQC (seleccionado 2025; NIST anunció entonces previsión de estándar final 2027, todavía no tratado aquí como final)
La báscula
El precio se paga en bytes
Los tamaños pueden afectar fragmentación, certificados, memoria e interoperabilidad. Esta escala mezcla claves públicas y firmas y no mide seguridad ni rendimiento. Identifica algoritmo, parámetro y codificación antes de comparar.
- X25519 · clave pública32 B
- ECDSA P-256 · firma ES256 R||S; codificación JWS sin envoltura64 B
- FALCON-512 (antecedente de FN-DSA) · firma, referencia histórica FALCONv 1.2; no tamaño FIPS 206 final666 B
- ML-KEM-768 · clave pública de encapsulación; ciphertext 1088 bytes1184 B
- ML-DSA-65 · firma3309 B
- SLH-DSA-SHA2-128s / SLH-DSA-SHAKE-128s · firma7856 B
En los parámetros y codificaciones mostrados,7856/64=122,75: aproximadamente 123 veces. No compara todas las firmas SLH-DSA ni todas las representaciones ECDSA; es una referencia para probar protocolos y dispositivos concretos.
La reserva estratégica
Nueve candidatos avanzaron a tercera ronda el 14-05-2026. HAWK se retiró el 29-07-2026 tras una vulnerabilidad matemática; la lista conserva ese hito histórico y señala la retirada. Los candidatos restantes siguen en evaluación, sin convertir selección de ronda en estándar final.
- FAEST
- HAWK (histórico; retirado 29-07-2026)
- MAYO
- MQOM
- QR-UOV
- SDitH
- SNOVA
- SQIsign
- UOV
NIST IR 8610,14-05-2026; noticia NIST actualizada 29-07-2026; página Round 3 actualizada 28-09-2026
Sección 04
Dos carriles: quien fabrica los algoritmos y quien fabrica las obligaciones
NIST publica estándares y orientaciones técnicas estadounidenses. En España, las obligaciones nacen de normas aplicables al sujeto y caso, con requisitos contractuales o de certificación cuando correspondan. Una recomendación europea o una guía técnica no se convierte automáticamente en deber universal.
Estados Unidos · estándares técnicos
NIST · qué usar
- 29-10-2020SP 800-208Final
LMS y XMSS: firmas basadas en hash con estado
- 13-08-2024FIPS 203 · 204 · 205Final
ML-KEM, ML-DSA y SLH-DSA: el núcleo ya utilizable
- 12-11-2024IR 8547 (borrador)Borrador
Borrador inicial: calendarios distintos por nivel/algoritmo;112 bits desaconsejado después 2030 y algoritmos públicos vulnerables desautorizados después 2035. No obligación UE.
- 11-03-2025HQC seleccionadoEn desarrollo
HQC seleccionado para estandarización (IR 8545). NIST anunció en marzo 2025 previsión de final 2027; previsión de trabajo, no estándar final ni fecha legal.
- 18-09-2025NIST SP 800-227Final
Recomendaciones para mecanismos de encapsulación de clave
- 17-11-2025Aviso sobre FIPS 203Aviso
NIST identifica una cuestión que corregirá en una actualización futura. El estándar sigue siendo final y vigente
- 19-12-2025CSWP 39Final
Cripto-agilidad: estrategias y prácticas. Actualizado el 29-06-2026
- 14-05-2026IR 8610En desarrollo
Nueve firmas adicionales avanzaron a tercera ronda el 14-05-2026; HAWK retirado 29-07-2026. Proceso de evaluación, no nueve estándares finales.
- pendienteFIPS 206 · FN-DSAEn desarrollo
FN-DSA/FALCON en desarrollo como FIPS 206 según registro NIST consultado; no estándar final localizado.
Obligaciones, plazos y certificación
Europa y España · cuándo y a quién
- 11-04-2024Recomendación (UE) 2024/1101Recomendación
Hoja de ruta coordinada para la transición a criptografía poscuántica
- 27-02-2025EUCC aplicableFinal
Reglamento de Ejecución (UE) 2024/482: primer esquema europeo de certificación de ciberseguridad
- 23-06-2025Hoja de ruta del Grupo de Cooperación NISRecomendación
Objetivos recomendados: iniciar pasos antes de finalizar 2026; alto riesgo e infraestructuras críticas antes de finalizar 2030; completar riesgo medio hacia fin2035 y, para riesgo bajo, en la medida factible.
- 30-04-2026Informe de hibridación PQC del EUCCDocumento publicado
Informe técnico publicado 30-04-2026 sobre estandarización de híbridos para certificación; no obligación general de hibridar.
- 07-2026CCN-TEC 009Recomendación
CCN-TEC 009 (julio 2026) recomienda transición; CCN-STIC 221 precisa mecanismos en su ámbito. Portada STIC noviembre 2025/p.2 noviembre 2024: mantener discrepancia documental; alcance de prescripción condicionado, no universal.
- 02-06-2026EUCC Guidelines v3Aviso
ACMv 3 sigue listado como borrador tras consulta cerrada en julio 2026; ACMv 2 de 06-05-2025 continúa listado como documento aplicable. No tratar v 3 como vigente.
Dónde está la obligación, hoy
RGPD art.32, NIS 2 art.21 y DORA arts.6,8 y 9 contienen obligaciones de seguridad y gestión de riesgo dentro de sus ámbitos. Elegir medidas PQC para cumplirlas exige justificar el riesgo y estado de la técnica; la inferencia es[I], distinta de la obligación base[O]. NIS 2 requiere además comprobar su aplicación nacional. CRA entra en aplicación general el 11-12-2027, con calendario diferenciado para notificaciones art.14 desde 11-09-2026. ENS/guías CCN, certificados y contratos pueden añadir prescripciones concretas. Las fuentes citadas no fijan una fecha PQC universal para toda entidad española.
Cuidado con quien venda lo contrario: afirmar que NIS2 o DORA «ordenan migrar a PQC» es una sobreafirmación jurídica.
Sección 05
De cambiar algoritmos a operar una capacidad
La migración no termina: lo que se construye es la capacidad de volver a cambiar de algoritmo cuando haga falta. Eso es la cripto-agilidad, y es el objetivo real.
- 01
Inventariar
Propón inventario de algoritmos, claves, certificados, HSM/KMS, protocolos y dependencias. DORA art.8 exige inventarios/identificación de activos a entidades en su ámbito; un inventario criptográfico detallado desarrolla esa base y la gestión de riesgos, sin ser obligación PQC idéntica para toda organización.
- 02
Priorizar
Prioriza cada caso por duración de confidencialidad y autenticidad, exposición, impacto y tiempo/coste/dependencias de transición. Documenta hipótesis y responsable. La metodología QSFF procede del ámbito financiero y su uso fuera de él exige adaptación.
- 03
Probar en híbrido
Diseña pilotos, híbridos cuando sean adecuados, para probar interoperabilidad, tamaños, latencia, certificados y reversión. Documenta amenazas y condiciones de verificación; esta revisión no ejecuta pilotos ni demuestra un handshake.
- 04
Desplegar
Planifica por riesgo las superficies TLS, PKI, identidad, firmas, registros, código y firmware. El reloj aporta un escenario aritmético, junto con requisitos jurídicos, interoperabilidad y controles de autenticidad; no impone desplegar todas las superficies a la vez.
- 05
Operar y sustituir
Define telemetría, políticas, rotación, reversión y sustitución de algoritmos preservando seguridad y operación. CSWP 39upd 1 describe capacidades de cripto-agilidad; también requieren mantenimiento, control y nuevas pruebas con cada cambio.
Quién decide qué
Propuesta de reparto de decisiones entre asesoría, negocio, tecnología, proveedores y dirección. Debe adaptarse a responsabilidades reales y a los órganos de gobierno exigidos por cada régimen.
Cuántos años debe seguir siendo secreto un dato
- Quién
- Asesoría jurídica y negocio
- Por qué
- Valorar conservación legal, secreto, contratos, daño y exposición con tecnología. La duración del secreto puede superar o diferir de la retención.
Cuánto se tarda en migrar un sistema
- Quién
- Tecnología y proveedores
- Por qué
- Depende de hojas de ruta de terceros, ciclos de renovación de hardware y ventanas de parada.
Qué valor probatorio debe conservar un registro
- Quién
- Asesoría jurídica y responsables técnicos de validación/preservación
- Por qué
- Documentar valor y conservación de la evidencia y valorar renovación de firmas/sellos/anclajes antes de degradarse. Ninguna estrategia produce automáticamente un servicio cualificado o un efecto probatorio concreto.
Qué se migra primero y con qué presupuesto
- Quién
- Dirección
- Por qué
- Es una decisión de asignación de recursos informada por las tres anteriores, no una decisión técnica.
El caso difícil: la evidencia que dura
Para evidencia, firmas, firmware y archivos de larga vida, propone analizar validación histórica, sellado temporal, renovación y preservación antes de perder confianza en el esquema. Una verificación dual o nuevo anclaje solo ayuda bajo un diseño y evidencias adecuados; ML-DSA/SLH-DSA no garantizan por sí solos autenticidad jurídica ni servicio cualificado. El responsable jurídico y técnico debe aprobar la estrategia concreta.
Cada concepto tiene su ficha
Las fichas documentan para cada afirmación su fuente, alcance, fecha y naturaleza: obligación, recomendación, estándar, interpretación o propuesta. El enlace a una ficha no cambia esa naturaleza.
- El calendario europeo de la transición→ Hoja de ruta europea PQC
- Los estándares y su estado real→ NIST PQC (FIPS 203-206, HQC)
- Cómo priorizar por caso de uso→ Europol QSFF: priorización PQC
- Mitigaciones: híbridos, claves precompartidas y QKD→ ENISA PQC (2021)
- Mecanismos autorizados en España→ CCN: TEC 009 + STIC 221
- Certificación europea de productos→ EUCC (criptografía)
- QKD: qué resuelve y qué no→ ETSI QKD
La caja de herramientas contiene borradores de lista de comprobación PQC y cláusulas de autodeclaración para revisión. Su existencia documental no acredita adopción contractual, ensayo técnico ni aprobación jurídica. → Ir a la caja de herramientas → Plan IA360: medidas PQC en España