PQC StatusL'article 21(2)(h) de NIS2 impose aux entités essentielles et importantes de disposer de politiques et de procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement. La directive ne prescrit ni modèle, ni liste d'algorithmes, ni échéance : la qualité du document relève donc de votre responsabilité. Cet article propose un plan section par section que vous pouvez copier, associe chaque section aux preuves qu'un évaluateur demandera, et montre précisément où placer les dispositions de transition post-quantique.
Ce que l'article 21(2)(h) exige, et ce qu'il n'exige pas
La directive (EU) 2022/2555 énumère, à son article 21(2), les mesures minimales de gestion des risques en matière de cybersécurité que les entités concernées doivent prendre. Le point (h) tient en une ligne : des politiques et des procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement. Le texte est disponible sur EUR-Lex (data.europa.eu/eli/dir/2022/2555/oj). L'article 21(1) inscrit l'ensemble de ces mesures dans une logique de proportionnalité au risque encouru et de prise en compte de l'état de l'art.
Trois conséquences en découlent. Premièrement, l'obligation est documentaire et procédurale : il vous faut une politique écrite et les procédures qui l'appliquent, et non une suite cryptographique particulière. Deuxièmement, puisque la directive ne nomme aucun algorithme ni aucune longueur de clé, c'est la politique elle-même qui doit porter cette liste et préciser comment elle évolue dans le temps. Troisièmement, la formule « le cas échéant » signifie que la décision de ne pas chiffrer un élément doit être une décision documentée et fondée sur le risque, et non une omission. Notre page de référence sur l'article 21(2)(h) de NIS2 rassemble le texte et les jalons associés.
Cet article est fourni à titre d'information et ne constitue pas un conseil juridique. Votre loi nationale de transposition, votre secteur et votre autorité compétente déterminent ce qui est suffisant en pratique.
Le plan de politique à copier
La structure ci-dessous est un plan de travail, pas une exigence légale. Elle est ordonnée de sorte qu'un lecteur partant de la section 1 aboutisse à une décision sur les algorithmes approuvés dès la section 5, et que chaque section suivante produise un livrable qu'un évaluateur peut examiner. Une politique de huit à quinze pages, avec les paramètres techniques dans une annexe révisable sans réapprouver l'ensemble du document, suffit généralement.
| # | Section | Contenu |
|---|---|---|
| 1 | Objet et base juridique | Le document met en œuvre l'article 21(2)(h) de NIS2 tel que transposé en droit national, et liste tout autre régime applicable (DORA, PCI DSS, Cyber Resilience Act, règles sectorielles). |
| 2 | Périmètre | Entités, filiales, environnements (production, test, cloud, OT), classes de données et services tiers couverts. Exclusions nommées et leur justification. |
| 3 | Rôles et responsabilités | Qui est propriétaire de la politique, qui approuve les changements d'algorithmes, qui approuve les dérogations, qui assure les fonctions de dépositaire de clés, et l'implication de l'organe de direction attendue par NIS2. |
| 4 | Risques et classification des données | Comment la durée de confidentialité est attribuée à chaque classe de données. C'est cette donnée d'entrée qui détermine quels systèmes migrent en premier. |
| 5 | Algorithmes et paramètres approuvés | La liste autorisée avec les paramètres minimaux, par cas d'usage : données en transit, données au repos, signatures, hachage, dérivation de clés, génération de nombres aléatoires. |
| 6 | Algorithmes obsolètes et interdits | Ce qui ne peut plus être déployé, ce qui reste toléré uniquement pour la vérification de l'existant, et la date de retrait de chacun. |
| 7 | Référentiels de protocoles et de configuration | Version minimale de TLS, ordre des groupes et des suites cryptographiques, accord de clé SSH, paramètres VPN et bases de données. Un référentiel par famille de plateformes. |
| 8 | Gestion des clés | Génération, distribution, stockage, rotation, séquestre, archivage et destruction, avec les exigences matérielles pour chaque classe de clés. |
| 9 | Gestion des certificats | Autorité émettrice, durée de validité maximale, automatisation du renouvellement, révocation, et registre des certificats avec leurs propriétaires. |
| 10 | Inventaire cryptographique | Ce qui est inventorié (algorithme, paramètres, bibliothèque et version, système, propriétaire, classe de données), comment l'inventaire est collecté et à quelle fréquence il est actualisé. |
| 11 | Agilité cryptographique et transition post-quantique | Les conditions de déclenchement, la séquence de migration et les dates cibles. Voir la section suivante. |
| 12 | Exigences fournisseurs et achats | Clauses exigées des éditeurs et des fournisseurs cloud : divulgation des algorithmes utilisés, prise en charge de l'échange de clés hybride, notification des changements cryptographiques. |
| 13 | Dérogations | Format de demande, niveau d'acceptation du risque requis, mesures compensatoires, date d'expiration obligatoire, registre central. |
| 14 | Surveillance, tests et revue | Fréquence des analyses externes et internes, détection des dérives de configuration, et cycle de revue de la politique elle-même. |
| 15 | Gestion des incidents cryptographiques | Conduite à tenir en cas de compromission de clé, d'émission erronée de certificat ou de publication d'une attaque pratique contre un algorithme approuvé, y compris les liens avec le processus de notification des incidents NIS2. |
Section 5 : ce que la liste approuvée doit contenir
Citez les standards finaux et indiquez les paramètres. Pour l'encapsulation de clés, ML-KEM est normalisé dans la FIPS 203 du NIST, publiée comme standard final le 13 août 2024, aux côtés de ML-DSA dans la FIPS 204 et de SLH-DSA dans la FIPS 205 (csrc.nist.gov/pubs/fips/203/final). Pour la protection symétrique, AES-256 est à privilégier pour les données à longue durée de vie : les algorithmes symétriques et les fonctions de hachage ne sont pas cassés par l'algorithme de Shor, et c'est l'algorithme de Grover qui justifie le choix d'une taille de clé plus grande. Si vous opérez en Allemagne, la BSI TR-02102-1 (version 2026-01, publiée le 23 janvier 2026) est une directive technique qui recommande l'accord de clé hybride post-quantique et un RSA d'au moins 3000 bits, et ne recommande l'accord de clé classique seul que jusqu'à fin 2031, ou fin 2030 pour les besoins de protection très élevés. Les lignes directrices de ce type sont des recommandations, et non des obligations, sauf si votre droit national ou un contrat les rend contraignantes.
Section 6 : ce qu'il faut interdire explicitement
RC4 est interdit dans TLS par la RFC 7465. MD5 et SHA-1 sont obsolètes pour les signatures. DSA n'est plus approuvé pour la génération de signatures selon la FIPS 186-5 et ne peut servir qu'à vérifier des signatures existantes. Les groupes TLS Kyber antérieurs à la normalisation, comme X25519Kyber768Draft00 au codepoint 0x6399, sont obsolètes et devraient être retirés au profit des groupes ML-KEM enregistrés. Associez une date de retrait à chaque ligne, faute de quoi la section devient une liste de vœux.
Section 11 : les dispositions de transition post-quantique
NIS2 ne mentionne pas la cryptographie post-quantique. La raison de l'inclure malgré tout est le scénario « récolter maintenant, déchiffrer plus tard » (harvest now, decrypt later) : le trafic enregistré aujourd'hui n'est protégé que par l'échange de clés qui l'a négocié, de sorte qu'une session capturée maintenant pourrait être déchiffrée ultérieurement si cet échange de clés est vulnérable au quantique. C'est pourquoi l'échange de clés hybride passe en premier et pourquoi les signatures et les certificats peuvent migrer ensuite. Notez que COM(2026) 13, publiée le 20 janvier 2026, est une proposition de la Commission visant à modifier NIS2 afin que les stratégies nationales comprennent une politique de transition post-quantique. Il s'agit d'une proposition, elle n'a pas été adoptée, et elle porte sur les stratégies des États membres plutôt que d'imposer une obligation directe aux entités (EUR-Lex CELEX 52026PC0013).
Inscrivez quatre éléments dans cette section. Premièrement : l'exigence d'inventaire, actualisé selon une fréquence définie, car on ne peut pas migrer ce que l'on ne sait pas lister. Deuxièmement : la séquence, l'échange de clés avant les signatures, les services exposés à l'extérieur avant les services internes, les données à longue durée de confidentialité en premier. Troisièmement : les dates de référence sur lesquelles vous choisissez de vous aligner, qualifiées pour ce qu'elles sont. La feuille de route de mise en œuvre coordonnée de l'UE (Coordinated Implementation Roadmap 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 à risque moyen d'ici fin 2035, les cas à faible risque l'étant dans la mesure du possible (notre synthèse et la fiche de la bibliothèque de la Commission). NIST IR 8547 reste un projet initial soumis à consultation publique, publié le 12 novembre 2024 : il 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. Citez-le en tant que projet. Quatrièmement : la clause d'agilité, c'est-à-dire les conditions techniques et contractuelles permettant de changer d'algorithme sans repenser le système.
Le référentiel à placer en annexe est court. Groupe hybride en premier, repli classique conservé, testé en préproduction avant la production :
# 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 enregistré par l'IANA à 0x11EC (4588), SecP256r1MLKEM768 à 0x11EB (4587) et SecP384r1MLKEM1024 à 0x11ED (4589) ; le registre IANA des paramètres TLS fait foi (iana.org). La RFC 10024 (août 2026) spécifie l'accord de clé hybride post-quantique et traditionnel pour TLS 1.3. Les versions actuelles de Chrome, Edge et Firefox proposent déjà X25519MLKEM768 par défaut, si bien que son activation est normalement invisible pour les utilisateurs. Côté SSH, OpenSSH 10.0 (9 avril 2025) a fait de mlkem768x25519-sha256 l'accord de clé par défaut, et OpenSSH 10.1 (6 octobre 2025) affiche un avertissement lorsqu'une connexion négocie un accord de clé non post-quantique.
De la clause de politique à la preuve
Un évaluateur lit la politique, puis demande la preuve de son application. Définir le livrable dès la rédaction coûte moins cher que de le reconstituer plus tard. La colonne de droite ci-dessous reflète notre interprétation des bonnes pratiques, et non une exigence littérale de l'article 21(2)(h).
| Clause de la politique | Preuve à conserver |
|---|---|
| Algorithmes et paramètres approuvés | Politique signée avec historique des versions et trace de l'approbation de la dernière modification. |
| Inventaire cryptographique | Export daté de l'inventaire avec le propriétaire système de chaque entrée. Un CBOM (cryptographic bill of materials, nomenclature cryptographique) est un moyen pratique de le produire, comme expliqué dans notre note sur ce qu'est un CBOM. |
| Référentiels de protocoles | Enregistrements de gestion de configuration et résultats d'analyses externes pour chaque point de terminaison public. |
| Gestion des clés et des certificats | Registre des clés, journaux de rotation et registre des certificats avec dates d'expiration et propriétaires. |
| Dérogations | Registre des dérogations avec acceptation du risque, mesure compensatoire et date d'expiration. |
| Fréquence de revue | Compte rendu de la dernière revue et liste des modifications qui en résultent. |
| Transition post-quantique | Plan de migration avec responsables et dates cibles, et rapport d'avancement correspondant. |
NIS2 ne fixe aucune fréquence de revue. Si vous relevez également de PCI DSS v4.0.1, l'exigence 12.3.3 impose que les suites cryptographiques et les protocoles utilisés soient documentés et revus au moins tous les 12 mois, y compris une stratégie documentée face à l'évolution anticipée des vulnérabilités cryptographiques, obligatoire depuis le 31 mars 2025. Adopter une périodicité de douze mois pour l'ensemble de la politique constitue un référentiel unique défendable. Les entités financières devraient aligner ce même document sur DORA : l'article 6 du règlement délégué (EU) 2024/1774 de la Commission exige une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions de mise à jour ou de changement de technologie cryptographique en fonction des évolutions de la cryptanalyse, et l'article 7 exige une gestion des clés sur l'ensemble de leur cycle de vie ainsi qu'un registre des certificats pour les actifs TIC soutenant des fonctions critiques ou importantes. Notre analyse de la politique de chiffrement DORA au titre de l'article 6 détaille ces formulations plus prescriptives, et un seul document peut satisfaire les deux régimes si la section périmètre est explicite.
Transpositions nationales et écueils à éviter
NIS2 est une directive : elle produit ses effets par le biais du droit national. Les lois de transposition, les orientations des autorités nationales et les actes d'exécution peuvent ajouter des précisions : une structure de politique imposée, des référentiels nationaux nommément cités, des fréquences de revue ou des formats de notification spécifiques. Ces précisions varient selon l'État membre et le secteur ; consultez donc les orientations publiées par votre autorité nationale avant de figer le document. Ne considérez pas le minimum de la directive comme votre plafond.
Quatre faiblesses fréquentes méritent d'être signalées. Une politique qui liste des algorithmes sans dates de retrait n'est pas auditable. Une politique sans processus de dérogation pousse les équipes vers une non-conformité silencieuse. Une politique qui nomme un produit d'éditeur au lieu d'une famille d'algorithmes devient caduque à la migration suivante. Enfin, une politique qui revendique une préparation post-quantique sans inventaire ne peut pas montrer quels systèmes sont concernés. Veillez aussi à la justesse des nuances dans le document : un projet de standard reste un projet, et une recommandation d'une agence nationale n'est pas une obligation, sauf si votre périmètre en fait une. L'ANSSI, par exemple, indique que l'hybridation est obligatoire dans son périmètre réglementé (qualification de produits, domaine de la défense, SAIV et SIIV), tandis que ses recommandations post-quantiques plus générales ne constituent pas encore des obligations réglementaires ailleurs.
Étape suivante : mesurer ce que votre politique affirme
La section 7 du plan est la seule partie de la politique qu'un tiers peut vérifier de l'extérieur : vérifiez-la donc vous-même d'abord. Analysez votre domaine avec PQC Status pour voir les versions de TLS, les suites cryptographiques, la prise en charge des groupes hybrides ML-KEM et la chaîne de certificats que vos points de terminaison publics négocient réellement, puis joignez le résultat à l'annexe des référentiels comme preuve datée pour cette clause. Une analyse ne décrit que la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité. Exécutez-la sur chaque nom d'hôte public, consignez les écarts dans le registre des dérogations avec une date d'expiration, et la section post-quantique de votre politique cesse d'être une simple intention.