PQC StatusEl artículo 21(2)(h) de NIS2 exige a las entidades esenciales e importantes disponer de políticas y procedimientos relativos a la utilización de la criptografía y, en su caso, del cifrado. La directiva no prescribe ninguna plantilla, ninguna lista de algoritmos ni ningún plazo, por lo que la calidad del documento depende de usted. Este artículo ofrece un esquema sección por sección que puede copiar, relaciona cada sección con la evidencia que solicitará un evaluador y muestra exactamente dónde deben ubicarse las disposiciones de transición poscuántica.
Qué exige el artículo 21(2)(h), y qué no exige
La Directiva (UE) 2022/2555 enumera, en su artículo 21(2), las medidas mínimas de gestión de riesgos de ciberseguridad que deben adoptar las entidades incluidas en su ámbito. La letra (h) consta de una sola línea: políticas y procedimientos relativos a la utilización de la criptografía y, en su caso, del cifrado. El texto está disponible en EUR-Lex (data.europa.eu/eli/dir/2022/2555/oj). El artículo 21(1) plantea todas estas medidas como proporcionadas al riesgo existente y basadas en el estado de la técnica.
De ello se derivan tres consecuencias. En primer lugar, la obligación es documental y procedimental: necesita una política escrita y los procedimientos que la aplican, no un conjunto de cifrado concreto. En segundo lugar, como la directiva no menciona ningún algoritmo ni ninguna longitud de clave, es la propia política la que debe contener esa lista e indicar cómo evoluciona con el tiempo. En tercer lugar, la expresión «en su caso» significa que la decisión de no cifrar algo debe ser una decisión documentada y basada en el riesgo, no una omisión. Nuestra página de referencia sobre el artículo 21(2)(h) de NIS2 reúne el texto y los hitos relacionados.
Este artículo tiene carácter informativo y no constituye asesoramiento jurídico. Su ley nacional de transposición, su sector y su autoridad competente determinan qué resulta suficiente en la práctica.
El esquema de política que puede copiar
La estructura siguiente es un esquema de trabajo, no un requisito legal. Está ordenada de modo que un lector que empiece por la sección 1 pueda llegar a una decisión sobre algoritmos aprobados en la sección 5, y de modo que cada sección posterior genere un artefacto que un evaluador pueda inspeccionar. Una política de ocho a quince páginas, con los parámetros técnicos en un anexo que pueda revisar sin volver a aprobar todo el documento, suele ser suficiente.
| # | Sección | Qué establece |
|---|---|---|
| 1 | Finalidad y base jurídica | Que el documento aplica el artículo 21(2)(h) de NIS2 tal como se ha transpuesto a nivel nacional, y enumera cualquier otro régimen aplicable (DORA, PCI DSS, Cyber Resilience Act, normativa sectorial). |
| 2 | Ámbito | Entidades, filiales, entornos (producción, pruebas, nube, OT), clases de datos y servicios de terceros cubiertos. Exclusiones explícitas y su justificación. |
| 3 | Funciones y responsabilidades | Quién es responsable de la política, quién aprueba los cambios de algoritmos, quién aprueba las excepciones, quién desempeña las funciones de custodio de claves, y la implicación del órgano de dirección que espera NIS2. |
| 4 | Riesgo y clasificación de datos | Cómo se asigna la duración de la confidencialidad a cada clase de datos. Este es el dato que determina qué sistemas migran primero. |
| 5 | Algoritmos y parámetros aprobados | La lista autorizada con parámetros mínimos, por caso de uso: datos en tránsito, datos en reposo, firmas, funciones hash, derivación de claves, generación de números aleatorios. |
| 6 | Algoritmos obsoletos y prohibidos | Qué ya no puede desplegarse, qué se tolera únicamente para la verificación de elementos heredados, y la fecha de retirada de cada uno. |
| 7 | Líneas base de protocolos y configuración | Versión mínima de TLS, orden de grupos y conjuntos de cifrado, acuerdo de claves SSH, parámetros de VPN y bases de datos. Una línea base por familia de plataformas. |
| 8 | Gestión de claves | Generación, distribución, almacenamiento, rotación, custodia, archivo y destrucción, con los requisitos de hardware para cada clase de clave. |
| 9 | Gestión de certificados | Autoridad emisora, validez máxima, automatización de la renovación, revocación, y un registro de certificados con sus responsables. |
| 10 | Inventario criptográfico | Qué se inventaría (algoritmo, parámetros, biblioteca y versión, sistema, responsable, clase de datos), cómo se recopila y con qué frecuencia se actualiza. |
| 11 | Agilidad criptográfica y transición poscuántica | Las condiciones desencadenantes, la secuencia de migración y las fechas objetivo. Véase la sección siguiente. |
| 12 | Requisitos para proveedores y contratación | Cláusulas exigidas a los proveedores y a los proveedores de nube: divulgación de los algoritmos en uso, compatibilidad con el intercambio de claves híbrido, notificación de cambios criptográficos. |
| 13 | Excepciones | Formato de la solicitud, nivel de aceptación del riesgo requerido, controles compensatorios, fecha de caducidad obligatoria, registro centralizado. |
| 14 | Supervisión, pruebas y revisión | Frecuencia de los escaneos externos e internos, detección de desviaciones de configuración, y el ciclo de revisión de la propia política. |
| 15 | Gestión de incidentes criptográficos | Qué hacer ante el compromiso de una clave, la emisión indebida de un certificado o la publicación de un ataque práctico contra un algoritmo aprobado, incluidos los vínculos con el proceso de notificación de incidentes de NIS2. |
Sección 5: qué debe contener la lista aprobada
Cite normas definitivas e indique los parámetros. Para el encapsulado de claves, ML-KEM está normalizado en NIST FIPS 203, publicado como norma definitiva el 13 de agosto de 2024, junto con ML-DSA en FIPS 204 y SLH-DSA en FIPS 205 (csrc.nist.gov/pubs/fips/203/final). Para la protección simétrica, se prefiere AES-256 para los datos de larga duración: los algoritmos simétricos y las funciones hash no quedan rotos por el algoritmo de Shor, y el algoritmo de Grover es el motivo por el que se elige el tamaño de clave mayor. Si opera en Alemania, BSI TR-02102-1 (versión 2026-01, publicada el 23 de enero de 2026) es una directriz técnica que recomienda el acuerdo de claves poscuántico híbrido y RSA de al menos 3000 bits, y recomienda el acuerdo de claves clásico por sí solo únicamente hasta finales de 2031, o hasta finales de 2030 para necesidades de protección muy elevadas. Las directrices de este tipo son recomendaciones, no obligaciones, salvo que su legislación nacional o un contrato las hagan vinculantes.
Sección 6: qué prohibir explícitamente
RC4 está prohibido en TLS por el RFC 7465. MD5 y SHA-1 están obsoletos para firmas. DSA ya no está aprobado para la generación de firmas según FIPS 186-5 y solo puede utilizarse para verificar firmas heredadas. Los grupos TLS Kyber previos a la norma, como X25519Kyber768Draft00 en el codepoint 0x6399, están obsoletos y deberían retirarse en favor de los grupos ML-KEM registrados. Añada una fecha de retirada a cada línea; de lo contrario, la sección se convierte en una lista de deseos.
Sección 11: las disposiciones de transición poscuántica
NIS2 no menciona la criptografía poscuántica. El motivo para incluirla de todos modos es el riesgo de «capturar ahora, descifrar después»: el tráfico registrado hoy solo está protegido por el intercambio de claves que lo negoció, por lo que una sesión capturada ahora podría descifrarse más adelante si el intercambio de claves es vulnerable a la computación cuántica. Por eso el intercambio de claves híbrido va primero y las firmas y los certificados pueden migrar después. Tenga en cuenta que COM(2026) 13, publicada el 20 de enero de 2026, es una propuesta de la Comisión para modificar NIS2 de modo que las estrategias nacionales incluyan una política de transición poscuántica. Se trata de una propuesta, no ha sido adoptada y se dirige a las estrategias de los Estados miembros en lugar de imponer una obligación directa a las entidades (EUR-Lex CELEX 52026PC0013).
Incluya cuatro elementos en esta sección. Uno: el requisito de inventario, actualizado con una frecuencia establecida, ya que no se puede migrar lo que no se puede enumerar. Dos: la secuencia, primero el intercambio de claves y después las firmas, primero los servicios expuestos externamente y después los internos, primero los datos de confidencialidad prolongada. Tres: las fechas de referencia con las que decide alinearse, indicando claramente su naturaleza. La EU Coordinated Implementation Roadmap v1.1 (publicada el 23 de junio de 2025) es una orientación coordinada para los Estados miembros, no un reglamento vinculante para las empresas: establece unos primeros pasos que incluyen un inventario criptográfico y hojas de ruta nacionales para finales de 2026, la migración de los casos de uso de alto riesgo para finales de 2030 y de los de riesgo medio para finales de 2035, y los de bajo riesgo en la medida de lo posible (nuestro resumen y la entrada de la biblioteca de la Comisión). NIST IR 8547 sigue siendo un borrador público inicial, publicado el 12 de noviembre de 2024: propone declarar obsoletos los algoritmos vulnerables a la computación cuántica con 112 bits de seguridad a partir de 2030 y prohibir todos los algoritmos de clave pública vulnerables a la computación cuántica a partir de 2035. Cítelo como borrador. Cuatro: la cláusula de agilidad, es decir, las condiciones técnicas y contractuales en las que puede cambiar de algoritmo sin rediseñar el sistema.
La línea base que corresponde al anexo es breve. Grupo híbrido primero, alternativa clásica mantenida, probado en preproducción antes de pasar a producción:
# OpenSSL 3.5 or later is required for the ML-KEM TLS groups
# openssl.cnf, ssl_conf section: hybrid first, classical fallback retained
Groups = X25519MLKEM768:SecP256r1MLKEM768:X25519:P-256X25519MLKEM768 está registrado por la IANA en 0x11EC (4588), SecP256r1MLKEM768 en 0x11EB (4587) y SecP384r1MLKEM1024 en 0x11ED (4589); el registro de parámetros TLS de la IANA es la fuente de referencia (iana.org). El RFC 10024 (agosto de 2026) especifica el acuerdo de claves híbrido poscuántico y tradicional para TLS 1.3. Las versiones actuales de Chrome, Edge y Firefox ya ofrecen X25519MLKEM768 por defecto, por lo que habilitarlo suele ser invisible para los usuarios. En lo que respecta a SSH, OpenSSH 10.0 (9 de abril de 2025) convirtió mlkem768x25519-sha256 en el acuerdo de claves predeterminado, y OpenSSH 10.1 (6 de octubre de 2025) emite una advertencia cuando una conexión negocia un acuerdo de claves no poscuántico.
De la cláusula de la política a la evidencia
Un evaluador lee la política y después solicita pruebas de que se aplica. Decidir el artefacto en el momento de redactarla resulta más económico que reconstruirlo más tarde. La columna de la derecha refleja nuestra interpretación de las buenas prácticas, no un requisito literal del artículo 21(2)(h).
| Cláusula de la política | Evidencia que conservar |
|---|---|
| Algoritmos y parámetros aprobados | Política firmada con historial de versiones y el registro de aprobación del último cambio. |
| Inventario criptográfico | Exportación fechada del inventario con el responsable del sistema en cada entrada. Un CBOM (lista de materiales criptográficos) es una forma práctica de generarlo, tal como se describe en nuestra nota sobre qué es un CBOM. |
| Líneas base de protocolos | Registros de gestión de la configuración y resultados de escaneos externos por cada punto de acceso público. |
| Gestión de claves y certificados | Registro de claves, registros de rotación y un registro de certificados con fechas de caducidad y responsables. |
| Excepciones | Registro de excepciones con aceptación del riesgo, control compensatorio y fecha de caducidad. |
| Frecuencia de revisión | Acta de la última revisión y la lista de cambios resultante. |
| Transición poscuántica | Plan de migración con responsables y fechas objetivo, y un informe de avance respecto a dicho plan. |
NIS2 no fija ninguna frecuencia de revisión. Si también está sujeto a PCI DSS v4.0.1, el requisito 12.3.3 exige que los conjuntos de cifrado y los protocolos en uso estén documentados y se revisen al menos cada 12 meses, incluida una estrategia documentada ante los cambios previstos en las vulnerabilidades criptográficas, obligatoria desde el 31 de marzo de 2025. Adoptar una frecuencia de doce meses para toda la política constituye una línea base única defendible. Las entidades financieras deberían alinear el mismo documento con DORA: el artículo 6 del Reglamento Delegado (UE) 2024/1774 de la Comisión exige una política de cifrado y controles criptográficos que incluya disposiciones para actualizar o cambiar la tecnología criptográfica en función de los avances del criptoanálisis, y el artículo 7 exige la gestión de claves durante todo su ciclo de vida, así como un registro de certificados para los activos de TIC que respaldan funciones críticas o importantes. Nuestro análisis de la política de cifrado de DORA conforme al artículo 6 aborda la redacción más prescriptiva, y un único documento puede satisfacer ambos regímenes si la sección de ámbito es explícita.
Transposiciones nacionales y qué evitar
NIS2 es una directiva, por lo que surte efecto a través del derecho nacional. Las leyes de transposición, las orientaciones de las autoridades nacionales y los actos de ejecución pueden añadir detalles: una estructura de política obligatoria, directrices nacionales de referencia concretas, frecuencias de revisión específicas o formatos de notificación. Estos detalles varían según el Estado miembro y el sector, así que consulte las orientaciones publicadas por su autoridad nacional antes de cerrar el documento. No dé por hecho que el mínimo de la directiva es su techo.
Conviene señalar cuatro debilidades frecuentes. Una política que enumera algoritmos pero no fechas de retirada no puede auditarse. Una política sin proceso de excepciones empuja a los equipos a un incumplimiento silencioso. Una política que cita un producto de un proveedor en lugar de una familia de algoritmos deja de funcionar en la siguiente migración. Y una política que declara estar preparada para la era poscuántica sin un inventario no puede demostrar qué sistemas están afectados. Mantenga también la precisión de los matices en el documento: un borrador de norma es un borrador, y una recomendación de una agencia nacional no es una obligación salvo que su ámbito la convierta en tal. La ANSSI, por ejemplo, establece que la hibridación es obligatoria dentro de su ámbito regulado (cualificación de productos, ámbito relacionado con la defensa, SAIV y SIIV), mientras que sus recomendaciones poscuánticas más generales todavía no son obligaciones regulatorias en otros ámbitos.
Siguiente paso: mida lo que declara su política
La sección 7 del esquema es la única parte de la política que un tercero puede verificar desde el exterior, así que verifíquela usted primero. Escanee su dominio con PQC Status para ver las versiones de TLS, los conjuntos de cifrado, la compatibilidad con grupos ML-KEM híbridos y la cadena de certificados que negocian realmente sus puntos de acceso públicos, y adjunte el resultado al anexo de líneas base como evidencia fechada de esa cláusula. Un escaneo describe únicamente la configuración TLS visible desde el exterior: no es una certificación ni una atestación de cumplimiento. Ejecútelo en cada nombre de host público, registre las carencias en el registro de excepciones con una fecha de caducidad, y la sección poscuántica de su política dejará de ser una mera aspiración.