NIS2 · Conformité

NIS2 article 21 et cryptographie : les preuves que les auditeurs demanderont vraiment

Publié le 7 octobre 2026 · 7 min de lecture · Par Ali Korsi Une seule ligne de l’article 21 devient une politique complète, un cycle de vie de gestion des clés et un cycle de revue dès que l’on lit les règles d’exécution.

Read in English

L’article 21, paragraphe 2, point h), de la directive NIS2 (UE) 2022/2555 est l’une des obligations les plus courtes du texte. Les entités essentielles et importantes doivent disposer de « des politiques et des procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement ». C’est la phrase entière.

Il est tentant d’y voir une case déjà cochée : nous utilisons TLS, nos bases de données sont chiffrées, c’est réglé. Cette lecture ne résiste ni au règlement d’exécution (UE) 2024/2690 de la Commission, ni à une autorité de contrôle qui vous demande de montrer la politique en action.

Ce que dit réellement la directive

Trois dispositions doivent être lues ensemble :

Article 21(1) : il impose des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, en tenant compte de l’état des connaissances (l’« état de l’art ») et, le cas échéant, des normes européennes et internationales pertinentes, ainsi que du coût de mise en œuvre.
Article 21(2)(h) : il inscrit les politiques de cryptographie et de chiffrement parmi les mesures minimales.
Article 20(1) : il impose aux organes de direction d’approuver les mesures de l’article 21 et d’en superviser la mise en œuvre, et les rend responsables des violations. L’article 20(2) impose aux membres des organes de direction de suivre une formation en cybersécurité.

« État de l’art » est l’expression à souligner. Elle rend l’obligation dynamique : une politique adéquate au moment de sa rédaction peut devenir non conforme à mesure que le domaine évolue, sans qu’une seule ligne de la politique ait changé.

Ce qu’ajoute le règlement d’exécution 2024/2690

Le règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 précise les exigences techniques et méthodologiques des mesures de l’article 21 pour un groupe d’entités déterminé : fournisseurs de services DNS, registres de noms de domaine de premier niveau, fournisseurs de services d’informatique en nuage, fournisseurs de services de centres de données, fournisseurs de réseaux de diffusion de contenu, fournisseurs de services gérés, fournisseurs de services de sécurité gérés, fournisseurs de places de marché en ligne, de moteurs de recherche en ligne et de plateformes de services de réseaux sociaux, ainsi que prestataires de services de confiance.

La section 9 de son annexe porte sur la cryptographie. En résumé :

9.1 — établir, mettre en œuvre et appliquer une politique et des procédures relatives à la cryptographie, afin que celle-ci offre une protection adéquate et efficace.
9.2(a) — conformément à votre classification des actifs, définir le type, la robustesse et la qualité des mesures cryptographiques requises, y compris pour les données au repos et en transit.
9.2(b) — sur cette base, définir les protocoles, algorithmes, niveaux de robustesse du chiffrement, solutions cryptographiques et pratiques d’utilisation approuvés et requis, en suivant, le cas échéant, une approche de crypto-agilité.
9.2(c) — définir votre approche de la gestion des clés : génération des clés, émission et obtention des certificats de clé publique, distribution et activation, stockage et accès, changement ou mise à jour des clés, traitement des clés compromises, révocation, récupération, sauvegarde et archivage, destruction, journalisation et audit des activités de gestion des clés, et dates d’activation et de désactivation.
9.3 — réexaminer et, le cas échéant, mettre à jour la politique et les procédures à intervalles planifiés, en tenant compte de l’état de l’art en matière de cryptographie.

Si vous ne faites pas partie des types d’entités énumérés, le règlement ne vous lie pas directement ; la transposition nationale et votre autorité compétente en fixent le détail. En pratique, la section 9 est la définition la plus précise de ce qu’est « une politique cryptographique » dans tout le droit de l’UE, et nous nous attendons à ce que les auditeurs d’autres secteurs s’en servent comme point de référence. Les orientations techniques de mise en œuvre de l’ENISA (Technical Implementation Guidance, juin 2025) ajoutent des exemples concrets de preuves pour chaque exigence.

Pourquoi « nous utilisons TLS » n’est pas une politique

Relisez le point 9.2. Il vous demande de lier la robustesse cryptographique à la classification des actifs, de nommer les algorithmes et protocoles approuvés, et de gérer les clés sur tout leur cycle de vie. Une affirmation telle que « tout le trafic est chiffré en TLS 1.2 ou supérieur » ne répond à aucune de ces questions. Elle ne dit rien :

des algorithmes d’échange de clés et de signature réellement négociés ;
des clés RSA et à courbes elliptiques intégrées dans le code, les bibliothèques et les certificats ;
du propriétaire de chaque clé, de sa date d’expiration et de la façon dont elle est révoquée ;
de la rapidité avec laquelle vous pourriez remplacer un algorithme s’il était déprécié demain.

Une politique qui nomme des algorithmes approuvés ne vaut que par votre capacité à prouver que ce qui tourne en production y est conforme. C’est là que la plupart des organisations butent.

Ce que les auditeurs et les autorités peuvent demander

Pour les entités essentielles, l’article 32(2) confère aux autorités compétentes des pouvoirs qui incluent des audits de sécurité réguliers et ciblés, des scans de sécurité, des demandes de politiques de cybersécurité documentées et des demandes de preuves de la mise en œuvre des politiques de cybersécurité. Les entités importantes font l’objet d’une supervision ex post au titre de l’article 33, généralement après des preuves ou des indices de non-conformité. Dans les deux cas, la question passe de « avez-vous une politique ? » à « montrez-moi qu’elle est appliquée ».

Correspondance pratique entre exigences et preuves :

Exigence	Preuves attendues par un auditeur	Ce qu’apporte un inventaire / CBOM
9.1 La politique existe et est appliquée	Politique approuvée et versionnée ; preuve de sa couverture sur l’ensemble des systèmes	Un inventaire montre où la cryptographie est utilisée, de sorte que la couverture est démontrée plutôt qu’affirmée
9.2(a) Robustesse adaptée à la classification des actifs	Lien entre classification des données et contrôles cryptographiques	Chaque actif cryptographique est rattaché à un emplacement et à un système, et peut donc être relié aux données qu’il protège
9.2(b) Algorithmes et protocoles approuvés	Liste approuvée, plus les écarts constatés et suivis	Algorithmes, tailles de clés et configurations TLS découverts, comparés à la liste approuvée
9.2(b) Crypto-agilité	Preuve que vous savez localiser et remplacer des algorithmes	Un CBOM recense chaque instance à modifier, condition préalable à l’agilité
9.2(c) Cycle de vie de la gestion des clés	Registre des certificats et des clés, suivi des expirations, traces des révocations	Certificats X.509 analysés avec émetteur, type de clé, taille et dates de validité
9.3 Revue au regard de l’état de l’art	Revues datées, journal des modifications, justification des décisions	Des scans répétés fournissent une référence datée et montrent ce qui a changé entre deux revues
Art. 20 Supervision par la direction	Procès-verbaux du conseil approuvant les mesures ; reporting à la direction	Une synthèse des risques que l’organe de direction peut lire, approuver et consigner au procès-verbal

Rien de tout cela ne remplace les outils de gestion des clés ni la documentation des processus. Mais c’est l’inventaire qui transforme une politique, simple déclaration d’intention, en quelque chose de mesurable. Nous traitons le recoupement avec les règles du secteur financier dans DORA article 9 et l’inventaire cryptographique (en anglais).

La place de la cryptographie post-quantique

NIS2 ne mentionne pas l’informatique quantique. Elle n’en a pas besoin. L’article 21(1) rattache les mesures à l’état des connaissances, et la section 9.3 impose des revues au regard de l’état de l’art en matière de cryptographie. En août 2024, le NIST a publié ses premiers standards post-quantiques, FIPS 203, 204 et 205. En juin 2025, les États membres de l’UE, avec l’appui de la Commission, ont publié une feuille de route coordonnée de mise en œuvre pour la transition vers la cryptographie post-quantique, dont les premières étapes prévoient des inventaires cryptographiques d’ici fin 2026 et la migration des cas d’usage à haut risque d’ici fin 2030.

Il serait difficile de soutenir, lors d’une revue en 2026 ou 2027, que l’état de l’art en matière de cryptographie n’inclut pas un plan pour les algorithmes vulnérables au quantique. Cela ne signifie pas que tout doit être migré maintenant. Cela signifie en revanche que la politique doit reconnaître le problème, identifier où la cryptographie RSA et à courbes elliptiques est utilisée, et donner la priorité aux données à longue durée de confidentialité, exposées dès aujourd’hui aux attaques « harvest now, decrypt later » (en anglais). Pour le détail, voir notre article sur la feuille de route post-quantique de l’UE et la crypto-agilité expliquée.

La responsabilité de l’organe de direction

L’article 20 explique pourquoi ce sujet relève de l’ordre du jour du conseil, et pas seulement de l’équipe sécurité. Les organes de direction approuvent les mesures et peuvent être tenus responsables des violations. Pour les entités essentielles, l’article 32(5) permet en outre aux autorités, en dernier recours et sous réserve de garanties procédurales, de demander l’interdiction temporaire, pour une personne exerçant des responsabilités dirigeantes au niveau de directeur général ou de représentant légal, d’exercer des fonctions de direction. L’article 34 fixe des amendes administratives maximales d’au moins 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour les entités essentielles, et de 7 millions d’euros ou 1,4 % pour les entités importantes, le montant le plus élevé étant retenu.

Un conseil ne peut pas approuver de manière éclairée une politique cryptographique qu’il n’a aucun moyen de vérifier. Donnez-lui un inventaire daté, une synthèse des risques et un plan de migration, et l’approbation prend tout son sens.

Un point de départ pragmatique

Inventorier la cryptographie dans le code, les certificats et les endpoints en production.
Comparer ce que vous trouvez avec votre liste d’algorithmes approuvés et consigner les écarts.
Prioriser selon la sensibilité des données et l’exposition au risque quantique.
Rendre compte à l’organe de direction et consigner l’approbation au procès-verbal.
Recommencer à intervalles planifiés, en conservant les résultats datés comme preuves.

Vous ne savez pas où vous en êtes ? L’auto-évaluation gratuite de maturité post-quantique (deux minutes, en anglais) ou notre checklist pour les RSSI sont de bons premiers pas.

CRYPTAGION est conçu pour constituer cette piste de preuves. L’outil effectue une analyse statique du code Python, JS/TS, Java, Go et C/C++, analyse les certificats X.509 et scanne les endpoints TLS en production, puis produit un CBOM CycloneDX 1.6 et un score de risque quantique de 0 à 100 par actif tenant compte de l’exposition HNDL. Le rapport PDF destiné au conseil met en correspondance les constats avec DORA, NIS2, le Cyber Resilience Act de l’UE et FIPS 203/204/205, avec une feuille de route de migration en quatre vagues. Il se déploie sur site ou en environnement isolé (air-gapped) : votre code ne quitte jamais votre périmètre. Pour en savoir plus sur notre approche, consultez notre page inventaire cryptographique (en anglais).

Sources

Transformez votre politique cryptographique en preuves d’audit

CRYPTAGION produit l’inventaire cryptographique daté, le CBOM et le rapport prêt pour le conseil que les revues NIS2 et les autorités de contrôle demandent à voir.

Réserver un appel de découverte gratuit →

← Toutes les ressources · Accueil