La política de cifrado DORA según el artículo 6 del RTS

El artículo 6 del Reglamento Delegado (UE) 2024/1774 de la Comisión, las normas técnicas de regulación (RTS) sobre gestión del riesgo de TIC en el marco de DORA, exige que la entidad financiera disponga de una política de cifrado y controles criptográficos, y esa política debe contener disposiciones para actualizar o cambiar la tecnología criptográfica en función de la evolución del criptoanálisis. El texto no menciona ningún algoritmo ni fija ningún plazo poscuántico. A continuación separamos el requisito literal de nuestra opinión sobre cómo redactar el documento y aportar evidencias. TIC significa tecnologías de la información y la comunicación. Esto es información, no asesoramiento jurídico.

Lo que exige literalmente el artículo 6

El RTS es vinculante para las entidades financieras incluidas en su ámbito, y el artículo 6 es su artículo sobre cifrado. Exige una política documentada de cifrado y controles criptográficos, adoptada como parte de las políticas de seguridad de las TIC y basada en los resultados de la clasificación de datos y de la evaluación del riesgo de TIC. La política aborda la protección de los datos en los estados en que la entidad realmente los tiene: en reposo, en tránsito y, cuando proceda y sea técnicamente viable, en uso. Cuando el cifrado de datos en uso no sea viable, se espera que la entidad trate los datos en un entorno protegido o aplique otras medidas y deje constancia de esa elección. El artículo remite a las prácticas de referencia y a normas reconocidas, no a una lista fija de algoritmos. Y contiene la cláusula más relevante para el trabajo poscuántico: la política debe incluir disposiciones para actualizar o cambiar la tecnología criptográfica a medida que evoluciona el criptoanálisis. El texto auténtico está en EUR-Lex, y nuestro resumen fechado está en la página sobre el RTS de DORA. Compruebe siempre la numeración de los apartados con el texto consolidado antes de citarla en una respuesta de auditoría.

El artículo 7 es la disposición complementaria: la gestión de claves criptográficas durante todo su ciclo de vida (generación, renovación, almacenamiento, archivo, recuperación, destrucción) y un registro de certificados y de dispositivos que almacenan certificados, al menos para los activos de TIC que sustentan funciones esenciales o importantes. Lea ambos artículos conjuntamente. La mayor parte de las evidencias que un evaluador solicita en virtud del artículo 6 se encuentra en los inventarios y registros que el artículo 7 le obliga a mantener.

Lo que el artículo 6 no dice

No menciona ML-KEM (mecanismo de encapsulación de claves basado en retículos modulares, normalizado por NIST como FIPS 203 el 13 de agosto de 2024), no hace referencia al intercambio de claves híbrido y no establece ninguna fecha de migración. Esas señales proceden de otros documentos, cada uno con su propio estatus. NIST IR 8547 es un borrador inicial público (12 de noviembre de 2024, todavía en borrador) que propone declarar obsoletos los algoritmos vulnerables a la computación cuántica con seguridad de 112 bits después de 2030 y prohibir todos los algoritmos de clave pública vulnerables a la computación cuántica después de 2035. La Hoja de ruta de implementación coordinada de la UE 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 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 la de riesgo medio para finales de 2035. NIS2 Art. 21(2)(h) exige por separado políticas y procedimientos sobre el uso de la criptografía y, cuando proceda, del cifrado. Las entidades sujetas a ambos marcos deberían redactar una única política y mapearla dos veces, en lugar de mantener dos documentos.

Estructura sección por sección

La estructura siguiente es nuestra interpretación, no una plantilla publicada por un regulador. Está organizada para que cada sección responda a una pregunta que probablemente plantee un evaluador, y para que la parte volátil (los algoritmos) figure en un anexo que pueda versionar sin reabrir toda la política.

1. Finalidad, ámbito y gobernanza. Qué entidades, sistemas y terceros quedan cubiertos, quién aprueba la política, quién es su responsable y con qué periodicidad se revisa.
2. Definiciones y funciones. Custodio de claves, arquitecto criptográfico, propietario del activo, propietario del certificado. Defina cada sigla una sola vez.
3. Vínculo con la clasificación de datos. Para cada nivel de clasificación, la protección exigida en cada estado de los datos. Esto es lo que hace que la política esté basada en el riesgo y no sea genérica.
4. Algoritmos, longitudes de clave y protocolos aprobados (Anexo A). Una tabla versionada con tres columnas: preferente, aceptable, prohibido. Cite la norma en la que se basa cada entrada.
5. Datos en reposo. Discos, bases de datos, almacenamiento de objetos, copias de seguridad, archivos, equipos de usuario. Indique el mecanismo y quién verifica la cobertura.
6. Datos en tránsito. Versión mínima de TLS, conjuntos de cifrado y grupos de intercambio de claves aprobados, tráfico interno entre servicios, transferencia de ficheros, correo electrónico, administración remota.
7. Datos en uso. Dónde se aplica y, donde no, el entorno protegido u otras medidas utilizadas en su lugar, con la justificación documentada.
8. Claves y certificados. Remita al artículo 7: reglas del ciclo de vida, uso de módulos de seguridad de hardware y de servicios de gestión de claves, periodos de rotación, el registro de certificados y sus alertas de caducidad.
9. Inventario criptográfico y proveedores. Cómo se elabora y actualiza el inventario, y qué exige a los proveedores terceros de servicios de TIC.
10. Cambio de tecnología criptográfica (Anexo B). La cláusula de agilidad, descrita en la sección siguiente.
11. Excepciones y sistemas heredados. Un registro de excepciones temporales, cada una con un control compensatorio, un responsable y una fecha de finalización.
12. Evidencias e informes. Qué artefacto acredita qué cláusula, quién lo elabora y con qué frecuencia.

La disposición de cambio: la agilidad criptográfica por escrito

Una cláusula que afirma que la entidad supervisará la evolución criptográfica no constituye una evidencia. Una cláusula que un evaluador puede comprobar identifica el desencadenante, el responsable, el inventario sobre el que actúa y el plazo de actuación. Bastan cinco elementos.

• Fuentes de desencadenantes. Documentos y fuentes concretos que usted sigue: normas y borradores de NIST, BSI TR-02102-1 (una directriz técnica cuya versión de enero de 2026 recomienda el acuerdo de claves poscuántico híbrido y recomienda el acuerdo de claves clásico por sí solo únicamente hasta finales de 2031, finales de 2030 para necesidades de protección muy elevadas), las publicaciones de ANSSI (sus recomendaciones poscuánticas aún no son obligaciones normativas fuera de su ámbito regulado), los avisos de fin de soporte de los proveedores y los resultados criptoanalíticos publicados.
• Un responsable de la decisión. Una única función facultada para modificar el Anexo A, con un comité que lo aprueba y un registro de la fecha, la justificación y el documento de origen.
• Un inventario con responsables. No se puede cambiar lo que no se puede enumerar. Una lista de materiales criptográficos (CBOM) es una forma práctica de elaborarlo; se trata de nuestra interpretación, no de un requisito del texto.
• Clases de activos con fechas objetivo. Agrupe los activos por exposición y por el tiempo durante el cual sus datos deben seguir siendo confidenciales, y asigne a cada grupo una fecha objetivo en lugar de una única fecha para todo el parque.
• Una regla de despliegue seguro. Los nuevos algoritmos se activan junto con una alternativa clásica, se prueban en preproducción y solo entonces se promueven.

Por qué empezar por el intercambio de claves: el tráfico grabado solo está protegido por el intercambio de claves que estableció la sesión, por lo que el tráfico capturado hoy puede descifrarse más adelante si ese intercambio es vulnerable a la computación cuántica. Las firmas y los certificados pueden migrar después, porque una firma verificada hoy no se vuelve falsificable de forma retroactiva. Esa es la razón sensata por la que el intercambio de claves híbrido, por ejemplo X25519MLKEM768 (codepoint IANA 0x11EC), es el primer paso concreto para una entidad financiera. Los grupos Kyber anteriores a la norma, como X25519Kyber768Draft00 (0x6399), están obsoletos y deberían figurar como prohibidos en el Anexo A. Se requiere OpenSSL 3.5 o posterior para los grupos ML-KEM en OpenSSL.

Section 10. Changing cryptographic technology

10.1 Annex A (approved algorithms) is reviewed at least every 12 months and on any
     of these triggers: a new or withdrawn standard, an update to a national
     technical guideline we track, a published cryptanalytic result, a supplier
     end-of-support notice, or a change in the classification of data we protect.
10.2 The CISO owns Annex A. Changes are approved by the ICT risk committee and
     recorded with a date, a rationale and the source document.
10.3 Each asset class in Annex B has a named owner and a target date for migration
     to the algorithms marked preferred in Annex A.
10.4 Where an asset cannot meet its target date, the owner records a time-limited
     exception with a compensating control and an end date.
10.5 A new algorithm is deployed with a classical fallback, validated in staging,
     and promoted only after a documented interoperability test.

Del requisito a la evidencia

La columna de la izquierda parafrasea el requisito. La columna central es nuestra interpretación de las evidencias que lo satisfacen, no una lista publicada por ninguna autoridad.

Verifique lo que afirma sobre el tránsito antes que el evaluador

Las afirmaciones de la política sobre los datos en tránsito son las más fáciles de comprobar y las más fáciles de equivocar, porque un balanceador de carga, una red de distribución de contenidos o un host virtual heredado pueden contradecir discretamente la configuración de referencia. Empiece con una verificación de solo lectura, con OpenSSL 3.5 o posterior:

openssl s_client -connect www.example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"

Ejecútelo contra cada nombre de host público de su registro, no solo contra el sitio principal. Si su parque también está sujeto a PCI DSS, el mismo inventario alimenta el requisito 12.3.3, obligatorio desde el 31 de marzo de 2025, que exige conjuntos de cifrado y protocolos documentados y revisados al menos cada 12 meses, como se describe en nuestra nota sobre el inventario criptográfico de PCI DSS. Un inventario, dos mapeos.

Cuatro errores habituales

• Incluir plazos en la política como si los fijara el RTS. Cite los calendarios externos como desencadenantes de revisión y explique su estatus, ya que las orientaciones y los borradores no son obligaciones.
• Una política sin inventario que la respalde. La disposición de cambio no es verificable sin una lista de activos, su criptografía y sus responsables.
• Tratar un escaneo externo como una certificación. Un escaneo describe la configuración visible desde el exterior de un punto de acceso concreto en un momento dado. No es una certificación ni una declaración de cumplimiento.
• Congelar la lista de algoritmos en el cuerpo de la política. Manténgala en un anexo con su propio número de versión, para que un avance del criptoanálisis no requiera un ciclo completo de aprobación de la política.

Siguiente paso

Empiece por las evidencias que puede reunir hoy: enumere sus puntos de acceso públicos, registre qué intercambio de claves negocia cada uno y adjunte ese resultado a la sección de datos en tránsito de su política. Puede escanear su dominio con PQC Status de forma gratuita para ver las versiones de TLS, los conjuntos de cifrado, la compatibilidad con ML-KEM híbrido y la cadena de certificados que percibe un observador externo, y después utilizar las carencias detectadas para fijar fechas objetivo por clase de activos en el Anexo B. Repita el escaneo después de cada cambio para que el registro de desencadenantes contenga evidencias fechadas del antes y el después.