Exigences de chiffrement NIS2 : ce que l'article 21 demande pour la cryptographie, et quand le chiffrement est attendu

NIS2 ne vous impose pas de tout chiffrer. L’article 21(2)(h) exige de chaque entité essentielle et importante des politiques et des procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement. La politique est obligatoire. Ce que vous chiffrez découle de votre évaluation des risques. Pour les fournisseurs de cloud, de services gérés et les autres fournisseurs numériques, le règlement d’exécution (UE) 2024/2690 précise ce que la politique doit contenir.

Ce guide couvre ce qu’exige l’article 21, le caractère obligatoire ou non du chiffrement, le règlement 2024/2690, un plan de politique, la gestion des clés, les plans post-quantiques, les télécoms, le RGPD et l’ISO 27001, ce que les règles laissent ouvert, et une liste de contrôle.

Source	Ce qu’elle dit sur la cryptographie	Qui elle lie
NIS2, art. 21(2)(h)	Politiques et procédures relatives à la cryptographie et, le cas échéant, au chiffrement	Toutes les entités essentielles et importantes
NIS2, art. 21(2)(j)	Communications vocales, vidéo et textuelles et communications d’urgence sécurisées, selon les besoins	Toutes les entités essentielles et importantes
Règlement d’exécution (UE) 2024/2690, section 9 de l’annexe	Contenu de la politique, algorithmes approuvés, gestion des clés, réexamens	Cloud, centres de données, CDN, DNS, TLD, MSP, MSSP, plateformes en ligne, prestataires de services de confiance
NIS2, considérant 98	Le chiffrement, en particulier de bout en bout, devrait être encouragé, et obligatoire si nécessaire pour les fournisseurs de télécommunications	Explique l’intention ; l’obligation figure à l’article 21
Recommandation (UE) 2024/1101 et feuille de route	Commencer la transition post-quantique d’ici fin 2026 ; infrastructures critiques d’ici fin 2030	Adressées aux États membres, pas une obligation pour les entreprises

Qu’exige NIS2 en matière de chiffrement ?

Parmi les mesures minimales, l’article 21(2)(h) cite des politiques et des procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement. Cette réserve porte sur le chiffrement, pas sur la politique. Chaque entité essentielle et importante a besoin d’une approche documentée de la cryptographie. Chiffrer ou non un système donné est une décision que cette approche doit prendre et justifier.

La cryptographie dépasse d’ailleurs le chiffrement : elle couvre aussi l’intégrité et l’authenticité, au moyen de signatures, de certificats et de fonctions de hachage. L’article 21(1) encadre la décision : les mesures tiennent compte de l’état de l’art, des normes pertinentes et du coût de mise en œuvre, en proportion de votre exposition aux risques, de votre taille, et de la probabilité et de la gravité des incidents. L’article 21(2)(j) ajoute des communications vocales, vidéo et textuelles sécurisées et des systèmes sécurisés de communication d’urgence au sein de l’entité, selon les besoins. En pratique, sécurisé signifie chiffré.

L’article 20 impose aux organes de direction d’approuver les mesures et d’en superviser la mise en œuvre, politique de cryptographie comprise. Les neuf autres mesures sont présentées dans l’article 21 de NIS2 expliqué.

Le chiffrement est-il obligatoire selon NIS2 ?

Pas de manière inconditionnelle. Le texte contraignant ne prévoit le chiffrement que le cas échéant, et ne cite aucun système, type de données ni algorithme. La confusion vient du considérant 98. Selon lui, le chiffrement, en particulier le chiffrement de bout en bout, devrait être encouragé et, si nécessaire, devrait être obligatoire pour les fournisseurs de réseaux de communications électroniques publics ou de services de communications électroniques accessibles au public. Un considérant explique la finalité du texte. L’obligation se trouve à l’article 21, qui applique la même réserve à toutes les entités, opérateurs de télécommunications compris.

Deux éléments peuvent, dans les faits, rendre le chiffrement obligatoire pour vous. D’abord, le droit national : l’article 5 permet aux États membres d’adopter des dispositions assurant un niveau plus élevé de cybersécurité, vérifiez donc la loi de transposition qui vous concerne. Ensuite, votre propre évaluation des risques : dès qu’elle identifie un risque que le chiffrement permet de traiter, ne pas chiffrer devient une décision que vous devez défendre.

Quand le chiffrement est-il approprié en pratique ?

Une approche raisonnable consiste à chiffrer par défaut et à documenter les exceptions. En pratique, il est difficile de soutenir que le chiffrement n’est pas approprié pour :

• les données en transit sur des réseaux publics, y compris les accès d’administration et à distance ;
• les ordinateurs portables et les téléphones, qui se perdent ;
• les sauvegardes, en particulier les copies conservées hors site ou chez un prestataire ;
• les stockages contenant des données personnelles, financières ou de clients ;
• les e-mails échangés avec les fournisseurs et les clients critiques.

Lorsque le chiffrement n’est pas approprié, par exemple pour un ancien automate industriel qui ne le prend pas en charge, consignez la raison, la mesure compensatoire et une date de réexamen. C’est cette trace écrite que vous présentez à une autorité.

Qu’exige le règlement 2024/2690 en matière de cryptographie ?

Le règlement d’exécution (UE) 2024/2690 s’applique aux fournisseurs de services DNS, aux registres des noms de domaine de premier niveau, aux fournisseurs de services d’informatique en nuage, de services de centres de données et de réseaux de diffusion de contenu, aux fournisseurs de services gérés, aux fournisseurs de services de sécurité gérés, aux places de marché en ligne, aux moteurs de recherche en ligne, aux plateformes de services de réseaux sociaux et aux prestataires de services de confiance. La section 9 de son annexe traduit l’article 21(2)(h) en exigences précises :

• 9.1 : une politique et des procédures en matière de cryptographie, qui garantissent une utilisation adéquate et efficace de la cryptographie, conformément à la classification des actifs et à l’évaluation des risques.
• 9.2(a) : le type, la robustesse et la qualité des mesures cryptographiques pour chaque classe d’actifs, y compris les données au repos et les données en transit.
• 9.2(b) : les protocoles, les algorithmes, la force de chiffrement, les solutions et les pratiques d’utilisation approuvés et exigés, en suivant, le cas échéant, une approche d’agilité cryptographique.
• 9.2(c) : l’approche de la gestion des clés, couvrant douze activités, de la génération à la destruction.
• 9.3 : un réexamen et, le cas échéant, une mise à jour à intervalles planifiés, compte tenu de l’état de l’art en matière de cryptographie.

Le point 6.7.2(i) ajoute que des systèmes distincts ne communiquent que par des canaux de confiance, isolés par une séparation logique, cryptographique ou physique. Si vous n’êtes pas l’un de ces fournisseurs, la section 9 reste une lecture officielle détaillée de l’article 21(2)(h), et une bonne structure pour votre propre politique. Les entités couvertes par le règlement sont présentées dans NIS2 pour l’infrastructure numérique.

Que doit contenir une politique de cryptographie NIS2 ?

Le plan ci-dessous suit la section 9 du règlement 2024/2690. C’est un modèle pratique, pas un texte juridique. Placez les tableaux d’algorithmes dans une annexe que vous pouvez mettre à jour sans faire réapprouver la politique.

POLITIQUE DE CRYPTOGRAPHIE : PLAN

1. Objet et périmètre
   - Confidentialité, intégrité et authenticité des données
   - Services, systèmes et sites couverts
2. Rôles
   - Propriétaire de la politique, dépositaires des clés,
     approbation par la direction
3. Protection par classe d'actifs
   - Classe | au repos | en transit | signature/intégrité
   - Exceptions : système, raison, mesure compensatoire,
     propriétaire, date de réexamen
4. Cryptographie approuvée (annexe, revue chaque année)
   - Protocoles et versions minimales
   - Algorithmes et longueurs de clé minimales
   - Éléments obsolètes et interdits, avec dates de retrait
   - Agilité cryptographique : comment remplacer un algorithme
5. Gestion des clés
   - Génération, certificats, distribution, stockage
   - Rotation, compromission, révocation, récupération
   - Sauvegarde, destruction, journalisation, durées de validité
6. Fournisseurs
   - Exigences minimales de chiffrement dans les contrats
   - Qui détient les clés des services hébergés et gérés
7. Preuves
   - Indicateurs de couverture, expiration des certificats,
     exceptions ouvertes
8. Réexamen
   - Intervalle planifié ; déclencheurs : incident, nouvelle
     menace, nouvelle norme, algorithme obsolète

Comment gérer les clés de chiffrement sous NIS2 ?

Le chiffrement ne vaut que ce que vaut le processus qui génère, stocke, renouvelle et détruit les clés. Le point 9.2(c) du règlement 2024/2690 énumère douze activités que l’approche couvre, le cas échéant : la génération, les certificats, la distribution, le stockage et l’accès, le changement de clés, les clés compromises, la révocation, la récupération, la sauvegarde, la destruction, la journalisation et l’audit, et les dates d’activation et de désactivation.

En pratique, trois lacunes sont fréquentes :

1. Des clés stockées à côté des données qu’elles protègent, dans la même base de données, le même dépôt ou le même fichier de configuration.
2. Aucune procédure en cas de clé compromise, si bien que la première est improvisée pendant un incident.
3. Des certificats sans propriétaire, découverts lorsqu’ils expirent et qu’un service s’arrête.

Un service managé de gestion des clés ou un module matériel de sécurité (HSM) règle le stockage et la journalisation. Il ne règle pas la question de la responsabilité. Chaque clé et chaque certificat doivent avoir un propriétaire nommément désigné et, pour les services hébergés, la politique doit préciser qui détient les clés : vous ou le prestataire.

NIS2 impose-t-elle la cryptographie post-quantique ?

Non. Les dispositions de NIS2 et du règlement 2024/2690 relatives à la cryptographie ne contiennent aucune exigence post-quantique. Le plan de l’UE figure dans deux documents adressés aux États membres :

• La recommandation (UE) 2024/1101 de la Commission du 11 avril 2024 relative à une feuille de route pour la mise en œuvre coordonnée de la transition vers la cryptographie post-quantique.
• La feuille de route coordonnée publiée par les États membres avec la Commission le 23 juin 2025, élaborée au sein du groupe de coopération NIS. Dans son annonce, la Commission indique que tous les États membres devraient commencer la transition vers la cryptographie post-quantique d’ici la fin de 2026, et que les infrastructures critiques devraient basculer dès que possible, au plus tard d’ici la fin de 2030.

Le lien avec NIS2 est indirect : le règlement 2024/2690 demande, le cas échéant, une agilité cryptographique et des réexamens au regard de l’état de l’art. En pratique, commencez par inventorier où vous dépendez de la cryptographie à clé publique (TLS, VPN, SSH, signature de code) et quels fournisseurs la contrôlent. Les données qui doivent rester confidentielles pendant des années passent en premier, car un trafic enregistré aujourd’hui pourrait être déchiffré plus tard.

Qu’implique NIS2 pour le chiffrement dans les télécoms ?

Les fournisseurs de réseaux de communications électroniques publics et de services de communications électroniques accessibles au public entrent dans le champ quelle que soit leur taille (article 2(2)(a)). Ceux qui sont des moyennes entreprises ou des entreprises plus grandes sont des entités essentielles (article 3(1)) ; ceux qui sont des petites entreprises ou des microentreprises sont des entités importantes, sauf s’ils sont identifiés comme entités essentielles. La compétence revient à l’État membre dans lequel ils fournissent leurs services (article 26).

L’article 43 a supprimé, à compter du 18 octobre 2024, les règles de sécurité des télécommunications des articles 40 et 41 du code des communications électroniques européen (directive (UE) 2018/1972). Le considérant 95 indique que les lignes directrices nationales adoptées en vertu de ces articles devraient être prises en compte, le cas échéant. Les points propres aux télécoms en matière de chiffrement figurent dans les considérants :

• Considérant 98 : le chiffrement, en particulier de bout en bout, devrait être encouragé, aux côtés de concepts de sécurité centrés sur les données tels que la cartographie, la segmentation, le marquage et la gestion des accès. Si nécessaire, il devrait être obligatoire, conformément aux principes de sécurité et de respect de la vie privée par défaut et dès la conception. Il devrait être concilié avec les pouvoirs des États membres en matière de sécurité publique et d’enquêtes pénales, mais cela ne devrait pas affaiblir le chiffrement de bout en bout.
• Considérant 99 : les normes de routage sécurisé devraient être encouragées.
• Considérant 104 : les fournisseurs devraient mettre en œuvre la sécurité dès la conception et par défaut, et informer leurs clients des cybermenaces importantes et des mesures qu’ils peuvent prendre, par exemple en utilisant des types spécifiques de logiciels ou des technologies de chiffrement.

L’article 2(6) ajoute que NIS2 est sans préjudice de la responsabilité des États membres en matière de sécurité nationale et de leur pouvoir de maintenir l’ordre public. Lue avec le considérant 98, NIS2 laisse en place les règles nationales d’accès légal, et ne demande pas aux opérateurs d’affaiblir le chiffrement de bout en bout pour y répondre.

L’article 23(2) est contraignant : le cas échéant, les entités indiquent aux destinataires de leurs services potentiellement affectés par une cybermenace importante les mesures qu’ils peuvent prendre. Orienter les clients vers un canal chiffré peut répondre exactement à cela. Les opérateurs répercutent aussi des exigences de chiffrement sur leurs fournisseurs par voie contractuelle, comme décrit dans NIS2 pour les fournisseurs des télécoms.

Comment le chiffrement NIS2 recoupe-t-il le RGPD et l’ISO 27001 ?

L’article 32(1)(a) du RGPD cite la pseudonymisation et le chiffrement des données à caractère personnel comme mesure de sécurité, selon les besoins. En vertu de l’article 34(3)(a), vous n’êtes pas tenu d’informer les personnes concernées d’une violation si des mesures telles que le chiffrement ont rendu les données incompréhensibles pour toute personne non autorisée. Un chiffrement que vous pouvez prouver change ce qui se passe après une violation. Une seule politique sert les deux textes : voir NIS2 et le RGPD.

L’ISO/IEC 27001:2022 couvre le même terrain avec la mesure 8.24 de l’annexe A, utilisation de la cryptographie. Si vous exploitez un SMSI, la politique existe probablement ; vérifiez qu’elle traite la gestion des clés avec le niveau de détail décrit à la section 9. Le reste de l’annexe A, classé selon le travail qu’il demande, se trouve dans les mesures de l’annexe A regroupées selon le travail réel.

Que laisse ouvert NIS2 en matière de chiffrement ?

Les règles de NIS2 et du règlement 2024/2690 sur la cryptographie ne citent aucun algorithme, aucune longueur de clé ni aucune version de protocole. L’article 25 demande aux États membres d’encourager le recours aux normes sans imposer ni privilégier une technologie particulière, et l’état de l’art évolue. C’est vous qui choisissez, et l’autorité vérifie que votre choix est appliqué : elle peut demander des preuves de la mise en œuvre des politiques, pas seulement les politiques elles-mêmes (articles 32 et 33).

Une politique qui indique « TLS 1.2 ou supérieur » est facile à écrire. La question de l’audit est de savoir si c’est vrai aujourd’hui : quels services exposés acceptent encore d’anciens protocoles, quels volumes et quelles sauvegardes ne sont pas chiffrés, quels certificats expirent le mois prochain, quelles clés n’ont pas été renouvelées à temps. Les réponses se trouvent dans les services de gestion des clés, la gestion des terminaux, les inventaires de certificats et les scanners. Collectées à la main une fois par an, elles sont périmées dès leur arrivée.

Combler l’écart, c’est lire l’état du chiffrement directement dans les systèmes, en continu, avec une personne qui examine les exceptions au regard de la politique. C’est ainsi que fonctionne la plateforme CloudSoul : une plateforme automatisée, avec une expertise humaine dans la boucle. Un audit de sécurité au regard de l’article 21 montre où en est votre couverture de chiffrement aujourd’hui, et le programme complet est présenté sur la page conformité NIS2.

Liste de contrôle du chiffrement NIS2

• Approuvez une politique de cryptographie couvrant la confidentialité, l’intégrité et l’authenticité.
• Classez les données et fixez le chiffrement au repos et en transit pour chaque classe.
• Tenez une annexe des algorithmes approuvés, avec les éléments obsolètes et leurs dates de retrait.
• Consignez chaque exception avec une raison, une mesure compensatoire et une date de réexamen.
• Nommez un propriétaire pour chaque clé et chaque certificat, et rédigez la procédure en cas de clé compromise.
• Intégrez les exigences de chiffrement et la détention des clés dans les contrats des fournisseurs critiques.
• Inventoriez où vous dépendez de la cryptographie à clé publique, en prévision de la transition post-quantique.
• Mesurez la couverture du chiffrement et rendez-en compte à la direction à intervalles planifiés.

Sources

• Directive (UE) 2022/2555 (NIS2), articles 2, 3, 5, 20, 21, 23, 25, 26, 32, 33 et 43, considérants 95, 98, 99 et 104, EUR-Lex.
• Règlement d’exécution (UE) 2024/2690 de la Commission, annexe, points 6.7.2 et 9, EUR-Lex.
• Directive (UE) 2018/1972 (code des communications électroniques européen), EUR-Lex.
• Recommandation (UE) 2024/1101 de la Commission du 11 avril 2024 relative à une feuille de route pour la mise en œuvre coordonnée de la transition vers la cryptographie post-quantique, EUR-Lex.
• A Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, 23 juin 2025, Commission européenne.
• Commission européenne, « EU reinforces its cybersecurity with post-quantum cryptography », 23 juin 2025, Commission européenne.
• Règlement (UE) 2016/679 (RGPD), articles 32 et 34, EUR-Lex.
• ISO/IEC 27001:2022, mesure 8.24 de l’annexe A, ISO.

Questions fréquentes