Criterios
Edición 04-10-2026 · corte 27-07-2026 · revisión jurídica de las fichas por el comité editorial no acreditada
Vista agregada de los enunciados clasificados del Informe y del marco normativo cartografiado: qué dice cada fuente, con qué naturaleza jurídica, en qué estado se encuentra, qué fechas la condicionan y dónde verificarla. Los totales agrupan criterios O/I/S/R/P y no equivalen a obligaciones.
- Fichas
- 29
- Criterios visibles
- 16
- Fecha de corte
- 27-07-2026
- O Obligación normativa expresa
- I Interpretación jurídica basada en riesgo
- S Estándar técnico
- R Recomendación no vinculante
- P Propuesta de política o buena práctica
El filtro por sector muestra las fichas que cita cada guía sectorial. Es una asociación editorial y orientativa: no determina que una norma se aplique a todas las entidades del sector.
Se muestran 5 de 29 fichas y 16 criterios.
Fichas que cita la guía «Administraciones públicas». Ver la guía sectorial →
RGPD Reglamento (UE) 2016/679 — Reglamento General de Protección de Datos
Protección de datos · reglamento · https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Los responsables y encargados deben aplicar medidas técnicas y organizativas apropiadas para garantizar una seguridad adecuada al riesgo, incluida la protección frente al tratamiento no autorizado o ilícito y frente a pérdida, destrucción o daño accidental, mediante medidas como confidencialidad, integridad, disponibilidad, resiliencia, seudonimización, cifrado y procesos periódicos de verificación cuando proceda. En contexto cuántico, esta obligación no se traduce automáticamente en un mandato universal de criptografía poscuántica, sino en un análisis de seguridad conforme al riesgo, al estado de la técnica, a los costes, a la naturaleza, al alcance, al contexto y a los fines del tratamiento. El fundamento se encuentra en los artículos 5.1.f y 32 RGPD. (responsable, encargado)
- La transición progresiva a criptografía poscuántica debe formularse como medida interpretativa de gestión del riesgo HNDL, priorizable cuando la criticidad de los datos, su vida útil de confidencialidad, la exposición criptográfica y el estado de la técnica lo justifiquen. El RGPD no impone, por sí mismo, una obligación automática y universal de migración PQC para todo responsable o encargado. (responsable, encargado)
- El responsable debe aplicar protección de datos desde el diseño y por defecto al determinar los medios del tratamiento y durante el propio tratamiento. En sistemas con exposición criptográfica relevante, esa obligación puede justificar inventario criptográfico, cripto-agilidad, minimización y controles de seguridad si resultan proporcionados al riesgo, pero esas medidas concretas deben mantenerse como desarrollo interpretativo y no como requisito uniforme para todos los tratamientos. El fundamento de diseño y defecto se encuentra en el artículo 25 RGPD. (responsable)
- La evaluación de impacto relativa a la protección de datos debe realizarse antes del tratamiento cuando sea probable que un tipo de tratamiento, en particular con nuevas tecnologías, entrañe un alto riesgo para los derechos y libertades de las personas físicas. El uso de tecnología cuántica o de técnicas de machine learning cuántico no activa por sí solo la EIPD si no concurre la probabilidad de alto riesgo exigida por el artículo 35 RGPD. (responsable)
- La reidentificación de datos anonimizados mediante técnicas cuánticas debe describirse como hipótesis técnica que exige evaluación con evidencia y con los medios razonablemente utilizables, y no como capacidad general demostrada ni como consecuencia jurídica automática. Se mantiene la distinción entre datos anónimos fuera de los principios de protección de datos y datos seudonimizados o reidentificables que siguen pudiendo vincularse a una persona física mediante información adicional. (responsable)
Fuentes oficiales
Capítulo del Informe: §4.3, §3.1, §5.5 · Fecha de ficha: 27-07-2026
NIS2 Directiva (UE) 2022/2555 — Seguridad de las redes y sistemas de información
Ciberseguridad y resiliencia · directiva · https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- Las entidades esenciales e importantes comprendidas en NIS2 deben adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos de ciberseguridad, incluidas políticas sobre criptografía y, cuando proceda, cifrado, sin que ello convierta ninguna tecnología concreta en obligación universal. (entidades esenciales e importantes)
- La migración a criptografía poscuántica o a soluciones híbridas puede formar parte de las medidas exigibles bajo NIS2 cuando el análisis de riesgo, la vida útil de los datos, el estado de la técnica y la criticidad del servicio lo justifiquen, pero NIS2 no impone literalmente PQC a toda entidad ni a todo sistema. (entidades incluidas)
- Las entidades incluidas deben gestionar la seguridad de la cadena de suministro respecto de proveedores directos, incluidos proveedores de computación, componentes o servicios cuánticos cuando soporten redes y sistemas relevantes, con alcance condicionado por actividad, tamaño, sector, establecimiento, excepciones y norma nacional aplicable. (entidades incluidas)
- Las entidades incluidas notificarán incidentes significativos conforme al art. 23.4 NIS2: alerta temprana sin demora indebida y a más tardar24h, notificación a más tardar72h desde conocimiento y actualización/informe intermedio a solicitud. El informe final se presenta a más tardar un mes tras la notificación; si el incidente continúa, informe de situación y final en un mes desde haberlo gestionado. Para incidentes significativos de prestadores de servicios de confianza que afecten a sus servicios, la notificación de la letra b) se adelanta a24h. Estos relojes se distinguen del aviso contractual del proveedor al cliente. (entidades incluidas)
Fuentes oficiales
Capítulo del Informe: §4.2.1, §6.1 · Fecha de ficha: 27-07-2026
eIDAS2 Reglamento (UE) 2024/1183 — Marco europeo de identidad digital
Identidad digital y servicios de confianza · reglamento · https://eur-lex.europa.eu/eli/reg/2024/1183/oj
- Los prestadores cualificados de servicios de confianza deben gestionar los riesgos aplicables, incluido el riesgo criptográfico, y mantener los requisitos de seguridad y cualificación correspondientes a los servicios que prestan. El artículo 20 eIDAS exige auditoría a su propio coste al menos cada 24 meses por un organismo de evaluación de la conformidad. Además, el artículo 6.11 de 2025/2162 exige que los sistemas de evaluación prevean al menos una evaluación de vigilancia anual por servicio cualificado evaluado. La acreditación corresponde al organismo evaluador, conforme al artículo 2; no debe confundirse con la cualificación del prestador. El prestador remite el informe al organismo de supervisión en tres días laborables tras recibirlo (artículo 20.1); la gestión de riesgos se ancla en el artículo 24.2.f bis y en los requisitos del servicio. Los cambios criptográficos significativos y los planes de cese se rigen por el Reglamento de Ejecución (UE) 2025/2530, en su ámbito propio. (QTSP)
- La conservación, resellado y migración criptográfica deben presentarse como medidas para preservar la verificabilidad a largo plazo de firmas, sellos y evidencias, sin afirmar invalidez retroactiva de una firma válida ni imponer un algoritmo PQC único e inmediato. El Reglamento de Ejecución (UE) 2025/1946 confirma que los servicios cualificados de conservación de firmas electrónicas cualificadas y sellos electrónicos cualificados garantizan a largo plazo integridad, autenticidad, prueba de existencia y accesibilidad de las pruebas de conservación, dentro de ese ámbito específico. La medida concreta se selecciona según riesgo, periodo de retención, perfil y conformidad del servicio, en el ámbito de los artículos 34 y 40 eIDAS. La conservación preserva la fiabilidad existente y no crea cualificación retroactiva. (QTSP, partes que confían)
- La cripto-agilidad y la preparación poscuántica de la Cartera Europea de Identidad Digital deben conservarse como interpretación prudente de seguridad por diseño, protección de datos y resiliencia, según el riesgo y las normas y especificaciones aplicables. No implica una obligación inmediata de implementar un algoritmo poscuántico único. La eventual obligación relativa a declaraciones electrónicas de atributos se analiza separadamente para su propio servicio y destinatario. El Reglamento de Ejecución (UE) 2026/1735 se analiza en el ámbito de los emisores de declaraciones de atributos y fuentes auténticas que regula; su artículo 2 difiere únicamente el artículo 1.3 al 1 de enero de 2027 y no difiere automáticamente todo el anexo I. El Reglamento de Ejecución (UE) 2026/2099 establece identificación y autenticación para intercambio transfronterizo a través de MiSalud@UE. Publicado 22.09.2026, vigor 12.10.2026 y aplicación general 26.03.2027; art. 3.2 exige notificar conjuntos nacionales de atributos a más tardar el 26.03.2028 y arts. 3.3/5.2 aplican 26.03.2029 para emisión a petición y aceptación de atributos mediante cartera EUDI, tanto en solicitudes presenciales como en línea. Art. 4.2 exige nivel al menos sustancial en solicitudes en línea y alto desde 26.03.2030; art. 6.3 exige al menos sustancial para profesionales y alto desde 26.03.2032. No impone PQC universal, una nueva categoría de servicio cualificado ni una fecha general de migración EUDI. (emisores y proveedores de la cartera)
Fuentes oficiales
Capítulo del Informe: §4.5, §2.4 · Fecha de ficha: 27-07-2026
Hoja de ruta europea PQC Recomendación (UE) 2024/1101 + hoja de ruta coordinada del Grupo de Cooperación NIS
Política pública y hojas de ruta · recomendacion · https://eur-lex.europa.eu/eli/reco/2024/1101/oj
- Iniciar inventarios criptográficos, gobernanza y planificación de la migración alineados con los hitos 2026/2030/2035 (Estados miembros; empresas por derivación de riesgo)
- Como propuesta contractual propia, solicitar a proveedores de infraestructura cuántica o poscuántica un plan y evidencias de transición adaptados al riesgo y al sistema, tomando como referencias institucionales 2026/2030 y el horizonte 2035 para completar riesgo medio y, para riesgo bajo, en la medida de lo posible. Una autodeclaración, si se pacta, debe precisar alcance, hitos, prueba y revisión; no es certificación ni obligación universal impuesta por los hitos NIS. (compradores públicos y privados)
Fechas clave
- 11-04-2024Recomendación (UE) 2024/1101 sobre la transición coordinada a PQC
- 23-06-2025Hoja de ruta coordinada del Grupo de Cooperación NIS; los Estados miembros deberían iniciar la transición antes de finalizar 2026
- dic 2030Horizonte para casos de alto riesgo e infraestructuras críticas — objetivo de coordinación, no fecha universal de sanción
- dic 2035Referencia 2035: completar riesgo medio y, para riesgo bajo, en la medida de lo posible según CCN-TEC 009 §6; descarga íntegra de hoja de ruta/FAQ europea pendiente.
Fuentes oficiales
- Recomendación (UE) 2024/1101 + hoja de ruta coordinada del Grupo de Cooperación NIS
- Comisión, transiciónPQC
- Comisión, hoja de ruta coordinadaPQC
- Comisión, Surveyfeedback /FAQ
- Resumen de la hoja de ruta del Grupo de Cooperación NIS (Quantum Policy Forum)
- CCN-TEC 009: transición postcuántica segura (binomio nacional)
- BOCG223: Informe Ponencia154/000007, recomendación gradual/híbrida, §V.1
- ENISA, PQC: Current State and Quantum Mitigation (mitigaciones: híbridos y PSK)
- Europol/QSFF: metodología de priorización de la migración (matriz riesgo × tiempo)
Capítulo del Informe: §5.7 (tabla de hitos), §3.2, §7.2 · Fecha de ficha: 27-07-2026
CCN: TEC 009 + STIC 221 CCN-TEC 009 «Recomendaciones para una transición postcuántica segura» y guía CCN-STIC 221 «Mecanismos criptográficos autorizados por el CCN»
Estándares técnicos · guía técnica nacional · https://www.ccn.cni.es/eu/docman/documentos-publicos/boletines-pytec/495-ccn-tec-009-recomendaciones-transicion-postcuantica-segura/file
- Planificar la transición postcuántica conforme al CCN-TEC 009 (inventario criptográfico, priorización, esquemas híbridos) (administraciones públicas y proveedores del sector público)
- Emplear mecanismos criptográficos autorizados del CCN en sistemas del ámbito ENS cuando la medida y el nivel aplicables lo exijan, identificando versión/prescripción CCN-STIC 221; por ejemplo [mp.com.2.r1.1] para protección de comunicaciones de confidencialidad MEDIA/ALTA. No extrapolar a todo sistema o contrato privado. (responsables de seguridad)
Fechas clave
- 13-03-2023Nota de actualización de la guía CCN-STIC 221 (con revisiones posteriores)
- nov 2025Portada del PDF público CCN-STIC 221 localizado; p. 2 conserva edición noviembre de 2024. Discrepancia de versión pendiente de aclaración.
- 05-06-2026Publicación de ISO/IEC 18033-2:2006/Amd 2:2026 (FrodoKEM), etapa 60.60pendiente de revisión editorial P1-12
- jul 2026Publicación del CCN-TEC 009 (programa PYTEC), también disponible en inglés
Fuentes oficiales
Capítulo del Informe: pendiente de anclar (fuente incorporada en jul-2026) · Fecha de ficha: 27-07-2026
Herramientas asociadas
El Manual QT-QMS es un modelo de referencia no certificable. Las cláusulas tipo son borradores orientativos sujetos a adaptación jurídica caso a caso; no son un clausulado listo para firma ni sustituyen asesoramiento legal. [Naturaleza registrada: QT-QMS: modelo de referencia beta no certificable; no es norma técnica, esquema de certificación ni presunción de cumplimiento.]
Cláusulas contractuales patrón (orientativas)
- 1. Seguridad criptográfica poscuántica y cripto-agilidad
- 2. Uso ético y limitación de finalidad
- 3. Protección de datos y confidencialidad cuántica
- 4. Auditorías, transparencia y cooperación regulatoria
- 5. Exportación, PI y soberanía tecnológica
- 6. Ciberresiliencia y cadena de suministro (CRA)
- 7. Portabilidad y cambio de proveedor (Ley de Datos)
- 8. Prestación de servicios TIC a entidades financieras (DORA)
- 9. Autodeclaración de conformidad con la hoja de ruta NIS de transición PQC
- 10. Adhesión a un código de buenas prácticas cuánticas voluntario
Checklist PQC
- 1. Nombrar equipo PQC con patrocinio de dirección, líder CISO o Crypto Officer, equipo multidisciplinar y mandato documentado.
- 2. Inventariar criptografía vulnerable, incluyendo RSA, Diffie-Hellman, ECC, IoT, VPN, tarjetas, PKI, firmas de firmware y escaneo TLS automatizado, sin registrar secretos ni claves.
- 3. Clasificar y priorizar por vida útil de confidencialidad, exposición HNDL, impacto y tiempo de migración, con prioridad para secretos de más de cinco a diez años y sistemas de alto riesgo. Las bandas internas crítico <2 años, medio 3–5 y bajo >5 son propuestas P, no plazos legales ni equivalencia automática con los horizontes CCN. No basta que un dato sea público o efímero para descartar riesgo de autenticidad, integridad o disponibilidad.
- 4. Seleccionar familias, función y parámetros por caso de uso: ML-KEM para establecimiento de secreto y ML-DSA o SLH-DSA para firma, según estándar final y guías aplicables; valorar construcción híbrida estandarizada y pruebas. Distinguir algoritmo, protocolo, módulo validado y servicio completo. No tratar FALCON/FIPS 206 en desarrollo como estándar final ni a HQC seleccionado como FIPS final. Conservar versión, modelo de amenaza, interoperabilidad, límites y prescripción ENS concreta. En un pliego público describir prestaciones verificables, equivalencias y prueba admisible cuando proceda.
- 5. Inventariar y actualizar PKI, HSM, bibliotecas, dependencias y SBOM con versiones soportadas y política de parches. La referencia OpenSSL 3.x+ es insuficiente: OpenSSL 3.5 incorpora ML-KEM, ML-DSA y SLH-DSA; comprobar rama, versión, proveedor criptográfico, parámetros, soporte y configuración efectivos. Las pruebas deben acreditar negociación y conexión interoperable, además de autenticación y firmas/certificados que correspondan; tener la biblioteca o un KEM híbrido no prueba que todo el canal sea poscuántico. FIPS 140-3 es validación de módulo/configuración y entorno concretos, distinta de FIPS 203–205; comprobar certificado y alcance cuando el régimen o contrato lo requiera, sin afirmarlo para todo módulo PQC ni imponerlo universalmente. En pliegos, justificar requisitos y alternativas conforme a LCSP y ENS aplicable.
- 6. Ejecutar pilotos en entorno controlado, con compatibilidad hacia atrás, métricas de rendimiento, interoperabilidad, coste operativo, reversión y criterios de parada.
- 7. Formar y comunicar internamente a TI, desarrollo, compras, dirección, jurídico y privacidad; en entidades financieras DORA, incluir al proveedor tercero TIC en formación cuando proceda conforme al art. 30.2.i.
- 8. Migrar por fases con opción de rollback, documentación de cada cambio, control de versiones y evidencia que permita auditoría posterior.
- 9. Monitorizar continuamente latencias, errores, compatibilidad, degradación, incidencias y sistemas inviables, con reevaluación formal del riesgo.
- 10. Cerrar cada caso con evaluación final de eslabones débiles, políticas actualizadas, evidencia trazable ante DORA cuando aplique y proceso de mejora continua. No se declara cierre sin eslabones débiles a partir de una checklist; registrar alcance, ensayos, resultados, limitaciones y aceptación reales.
- 11. Puntuar cada caso de uso con matriz de riesgo cuántico y tiempo de migración, considerando vida útil del dato, exposición, severidad, disponibilidad de solución, coste y dependencias externas. QSFF/Europol y G7 son referencias sectoriales de priorización R; no metodología legal obligatoria para todo sector ni fecha nueva de migración.
- 12. Catalogar mecanismos y prácticas vulnerables o mal gestionados con evidencia: protocolos obsoletos según versión/configuración, claves o credenciales embebidas, gestión manual sin control de ciclo de vida y certificados wildcard con exposición relevante. No prohibir universalmente todo certificado manual o wildcard por su etiqueta. Documentar riesgo, excepciones justificadas, responsable, remediación proporcional, fecha y medida de efectividad; las prohibiciones derivarán de norma, política aprobada o contrato identificados. Evitar almacenar secretos en el inventario.
- 13. Cuando sea pertinente EUCC, contrastar mecanismos con la versión ENISA designada aplicable: la página consultada mantiene ACM v2 de 06-05-2025. La v3 de 02-06-2026 es borrador cuya consulta terminó en julio; no se invita a participar ni se presenta como versión final. Separar el informe ENISA de hibridación PQC publicado 30-04-2026 como referencia técnica complementaria, sin convertirlo en certificación de una implementación ni obligación PQC universal. Registrar versión, productos y ámbito que efectivamente se evalúan.
