La politique de chiffrement DORA au titre de l'article 6 du RTS

L'article 6 du règlement délégué (UE) 2024/1774 de la Commission, qui contient les normes techniques de réglementation (RTS) relatives à la gestion du risque lié aux TIC au titre de DORA, impose à une entité financière de disposer d'une politique de chiffrement et de contrôles cryptographiques. Cette politique doit comporter des dispositions permettant de mettre à jour ou de changer la technologie cryptographique en fonction de l'évolution de la cryptanalyse. Le texte ne cite aucun algorithme et ne fixe aucune échéance post-quantique. La suite distingue l'exigence littérale de notre point de vue sur la manière de rédiger le document et d'en apporter la preuve. TIC désigne les technologies de l'information et de la communication. Ce contenu est fourni à titre d'information et ne constitue pas un conseil juridique.

Ce que l'article 6 exige littéralement

Le RTS est contraignant pour les entités financières entrant dans son champ d'application, et l'article 6 en est l'article consacré au chiffrement. Il demande une politique documentée de chiffrement et de contrôles cryptographiques, adoptée dans le cadre des politiques de sécurité des TIC et fondée sur les résultats de la classification des données et de l'évaluation des risques liés aux TIC. La politique traite de la protection des données dans les états que l'entité rencontre réellement : au repos, en transit et, lorsque c'est pertinent et techniquement faisable, en cours d'utilisation. Lorsque le chiffrement des données en cours d'utilisation n'est pas faisable, l'entité est censée traiter les données dans un environnement protégé ou appliquer d'autres mesures, et consigner ce choix. L'article renvoie aux pratiques de référence et aux normes reconnues plutôt qu'à une liste figée d'algorithmes. Et il comporte la clause la plus importante pour les travaux post-quantiques : la politique doit inclure des dispositions permettant de mettre à jour ou de changer la technologie cryptographique à mesure que la cryptanalyse évolue. Le texte faisant foi est disponible sur EUR-Lex, et notre synthèse datée figure sur la page consacrée au RTS DORA. Vérifiez toujours la numérotation des paragraphes dans le texte consolidé avant de la citer dans une réponse d'audit.

L'article 7 en est la disposition complémentaire : la gestion des clés cryptographiques sur l'ensemble de leur cycle de vie (génération, renouvellement, stockage, archivage, récupération, destruction) et un registre des certificats et des dispositifs qui les stockent, au moins pour les actifs TIC soutenant des fonctions critiques ou importantes. Lisez les deux articles ensemble. La plupart des preuves qu'un évaluateur demande au titre de l'article 6 se trouvent dans les inventaires et registres que l'article 7 vous oblige à tenir.

Ce que l'article 6 ne dit pas

Il ne cite pas ML-KEM (mécanisme d'encapsulation de clé fondé sur les réseaux euclidiens modulaires, normalisé par le NIST sous la référence FIPS 203 le 13 août 2024), il ne mentionne pas l'échange de clés hybride et il ne fixe aucune date de migration. Ces signaux proviennent d'autres documents, chacun ayant son propre statut. NIST IR 8547 est un projet initial soumis à consultation publique (12 novembre 2024, toujours à l'état de projet) qui propose de déprécier les algorithmes vulnérables au quantique offrant une sécurité de 112 bits après 2030 et d'interdire tous les algorithmes à clé publique vulnérables au quantique après 2035. La feuille de route coordonnée de mise en œuvre de l'UE v1.1 (publiée le 23 juin 2025) est une orientation coordonnée destinée aux États membres, et non un règlement contraignant pour les entreprises : elle fixe des premières étapes comprenant un inventaire cryptographique et des feuilles de route nationales d'ici fin 2026, la migration des cas d'usage à haut risque d'ici fin 2030 et celle des cas à risque moyen d'ici fin 2035. L'article 21(2)(h) de NIS2 demande par ailleurs des politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement. Les entités soumises aux deux textes ont intérêt à rédiger une seule politique et à la mettre en correspondance deux fois, plutôt qu'à maintenir deux documents.

Un plan section par section

La structure ci-dessous est notre interprétation, et non un modèle publié par un régulateur. Elle est organisée de sorte que chaque section réponde à une question qu'un évaluateur posera vraisemblablement, et que la partie volatile (les algorithmes) figure dans une annexe que vous pouvez versionner sans rouvrir l'ensemble de la politique.

1. Objet, périmètre et gouvernance. Entités, systèmes et tiers couverts, instance qui approuve la politique, responsable de la politique, fréquence de revue.
2. Définitions et rôles. Dépositaire de clés, architecte cryptographique, propriétaire d'actif, propriétaire de certificat. Définissez chaque acronyme une seule fois.
3. Lien avec la classification des données. Pour chaque niveau de classification, la protection requise dans chaque état des données. C'est ce qui rend la politique fondée sur les risques plutôt que générique.
4. Algorithmes, longueurs de clé et protocoles approuvés (annexe A). Un tableau versionné à trois colonnes : préféré, acceptable, interdit. Citez la norme qui fonde chaque entrée.
5. Données au repos. Disques, bases de données, stockage objet, sauvegardes, archives, postes de travail. Indiquez le mécanisme et qui vérifie la couverture.
6. Données en transit. Version minimale de TLS, suites de chiffrement et groupes d'échange de clés approuvés, trafic interne de service à service, transfert de fichiers, messagerie, administration à distance.
7. Données en cours d'utilisation. Les cas où cela s'applique et, lorsque ce n'est pas le cas, l'environnement protégé ou les autres mesures utilisées à la place, avec la justification consignée.
8. Clés et certificats. Renvoi à l'article 7 : règles de cycle de vie, utilisation des modules matériels de sécurité et du service de gestion des clés, périodes de rotation, registre des certificats et alertes d'expiration associées.
9. Inventaire cryptographique et fournisseurs. Comment l'inventaire est constitué et actualisé, et ce que vous exigez des prestataires tiers de services TIC.
10. Changement de technologie cryptographique (annexe B). La clause d'agilité, décrite dans la section suivante.
11. Exceptions et existant. Un registre d'exceptions limitées dans le temps, chacune assortie d'un contrôle compensatoire, d'un responsable et d'une date de fin.
12. Preuves et reporting. Quel artefact prouve quelle clause, qui le produit et à quelle fréquence.

La disposition de changement : l'agilité cryptographique par écrit

Une clause indiquant que l'entité surveillera les évolutions cryptographiques ne constitue pas une preuve. Une clause qu'un évaluateur peut tester nomme le déclencheur, le responsable, l'inventaire sur lequel elle s'applique et le délai d'action. Cinq éléments suffisent.

• Sources de déclenchement. Les documents et flux nommés que vous suivez : normes et projets du NIST, BSI TR-02102-1 (une directive technique dont la version de janvier 2026 recommande l'accord de clé post-quantique hybride et ne recommande l'accord de clé classique seul que jusqu'à fin 2031, fin 2030 pour les besoins de protection très élevés), publications de l'ANSSI (ses recommandations post-quantiques ne sont pas encore des obligations réglementaires en dehors de son périmètre réglementé), avis de fin de support des fournisseurs et résultats de cryptanalyse publiés.
• Un responsable de la décision. Un rôle unique habilité à modifier l'annexe A, un comité qui approuve la modification et un enregistrement de la date, de la justification et du document source.
• Un inventaire avec des responsables. On ne peut pas changer ce que l'on ne sait pas lister. Une nomenclature cryptographique (CBOM) est un moyen pratique de le produire, et il s'agit là de notre interprétation plutôt que d'une exigence du texte.
• Des classes d'actifs avec des dates cibles. Regroupez les actifs selon leur exposition et la durée pendant laquelle leurs données doivent rester confidentielles, puis attribuez une date cible à chaque groupe plutôt qu'une date unique à l'ensemble du parc.
• Une règle de déploiement sûr. Les nouveaux algorithmes sont activés aux côtés d'une solution de repli classique, testés en préproduction, et seulement ensuite promus.

Pourquoi commencer par l'échange de clés : le trafic enregistré n'est protégé que par l'échange de clés qui a établi la session, de sorte que le trafic capturé aujourd'hui pourra être déchiffré plus tard si cet échange est vulnérable au quantique. Les signatures et les certificats peuvent migrer ensuite, car une signature vérifiée aujourd'hui ne devient pas falsifiable rétroactivement. C'est la raison mesurée pour laquelle l'échange de clés hybride, par exemple X25519MLKEM768 (codepoint IANA 0x11EC), constitue la première étape concrète pour une entité financière. Les groupes Kyber antérieurs à la norme, tels que X25519Kyber768Draft00 (0x6399), sont obsolètes et devraient être classés comme interdits dans l'annexe A. OpenSSL 3.5 ou une version ultérieure est nécessaire pour disposer des groupes ML-KEM dans 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.

De l'exigence à la preuve

La colonne de gauche paraphrase l'exigence. La colonne du milieu présente notre interprétation des preuves qui y répondent, et non une liste publiée par une quelconque autorité.

Vérifiez l'affirmation sur le transit avant qu'un évaluateur ne le fasse

Les énoncés de politique relatifs aux données en transit sont les plus faciles à vérifier et les plus faciles à mal formuler, car un répartiteur de charge, un réseau de diffusion de contenu ou un hôte virtuel ancien peut contredire discrètement le socle défini. Commencez par une vérification en lecture seule, avec OpenSSL 3.5 ou une version ultérieure :

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

Exécutez-la sur chaque nom d'hôte public de votre registre, pas seulement sur le site principal. Si votre parc relève également de PCI DSS, le même inventaire alimente l'exigence 12.3.3, obligatoire depuis le 31 mars 2025, qui demande des suites de chiffrement et des protocoles documentés et revus au moins tous les 12 mois, comme le décrit notre note sur l'inventaire cryptographique PCI DSS. Un inventaire, deux mises en correspondance.

Quatre écueils

• Inscrire des échéances dans la politique comme si le RTS les fixait. Citez les calendriers externes comme déclencheurs de revue et expliquez leur statut, puisque les orientations et les projets ne sont pas des obligations.
• Une politique sans inventaire derrière elle. La disposition de changement est invérifiable sans une liste des actifs, de leur cryptographie et de leurs responsables.
• Considérer une analyse externe comme une attestation. Une analyse décrit la configuration visible de l'extérieur d'un point de terminaison donné à un instant donné. Ce n'est ni une certification ni une attestation de conformité.
• Figer la liste des algorithmes dans le corps de la politique. Conservez-la dans une annexe dotée de son propre numéro de version, afin qu'une évolution de la cryptanalyse n'impose pas un cycle complet d'approbation de la politique.

Prochaine étape

Commencez par les preuves que vous pouvez réunir dès aujourd'hui : listez vos points de terminaison publics, consignez l'échange de clés négocié par chacun d'eux et joignez ce résultat à la section de votre politique consacrée aux données en transit. Vous pouvez analyser votre domaine avec PQC Status gratuitement pour voir les versions de TLS, les suites de chiffrement, la prise en charge de ML-KEM hybride et la chaîne de certificats que perçoit un observateur externe, puis vous appuyer sur les écarts constatés pour fixer des dates cibles par classe d'actifs dans l'annexe B. Renouvelez l'analyse après chaque changement afin que le journal des déclencheurs contienne des preuves datées avant et après.