NIS2 article 21(2)(h) : ce que les auditeurs acceptent comme preuve cryptographique

L’article 21(2)(h) de NIS2 exige « des politiques et des procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement ».

C’est tout le texte. Aucun algorithme, aucune longueur de clé, aucune version de protocole. Les équipes qui préparent un audit demandent légitimement ce que cela signifie en pratique, et la réponse vient de deux endroits : la formule « état de l’art » de l’article 21(1) lui-même, et ce que les autorités de supervision ont effectivement réclamé.

Le défaut d’audit récurrent porte sur la preuve, pas sur la sécurité

Le constat le plus fréquent dans les évaluations NIS2 de 2026 n’est pas un contrôle manquant. C’est un contrôle qui existe sans rien pour l’attester.

Un document de politique affirmant « nous utilisons un chiffrement conforme aux standards du marché » n’est pas une preuve. Il décrit une intention. Un auditeur cherche quelque chose qui démontre l’état du système à une date donnée, et idéalement quelque chose qu’il peut reproduire.

C’est pourquoi la mesure externe est devenue le chemin de moindre résistance pour la partie transport : elle produit une observation datée de ce que vos systèmes ont réellement négocié, ce qu’aucun document de politique ne peut faire.

À quoi ressemble la preuve au niveau transport

Pour la partie observable de l’extérieur de 21(2)(h), un dossier de preuves défendable contient les éléments suivants, chacun horodaté et accompagné de l’observation brute plutôt que d’un verdict.

Les versions de protocole proposées. TLS 1.2 au minimum, TLS 1.3 pris en charge. TLS 1.0 et 1.1 doivent être refusés, pas seulement dépriorisés. La preuve est une tentative de handshake contre chaque version et son résultat.

Les suites cryptographiques négociées. La suite réellement choisie, avec confidentialité persistante. Une liste de ce que votre fichier de configuration autorise est une preuve plus faible que ce que le serveur a fait quand on l’a sollicité.

Les propriétés du certificat. Émetteur, algorithme et taille de clé, algorithme de signature, fenêtre de validité, et de plus en plus la durée de vie émise face au plafond du CA/Browser Forum. Les auditeurs commencent à demander comment le renouvellement est effectué, car un processus manuel est un constat de résilience autant que de cryptographie.

HSTS. Présence, max-age, includeSubDomains, et appartenance à la liste de préchargement. Sans HSTS, la première requête d’une session est déclassable, ce qui sape tout le reste de cette liste.

Le transport du courrier. Si MTA-STS impose du TLS authentifié pour le courrier entrant. C’est là que la plupart des éditeurs ont un vrai trou, parce que l’authentification de l’expéditeur est confondue avec le chiffrement du transport.

L’accord de clés. Si l’échange de clés hybride post-quantique est proposé. Pas encore une exigence, de plus en plus une question, et directement rattaché à la formule « état de l’art ».

Ce que « état de l’art » veut dire, et ne veut pas dire

L’article 21(1) exige des mesures proportionnées au risque, en tenant compte de l’état de l’art et du coût de mise en œuvre.

Deux conséquences méritent d’être énoncées précisément.

Ce n’est pas une obligation de déployer le mécanisme le plus récent disponible. Le coût de mise en œuvre est explicitement un facteur, et la proportionnalité est inscrite dans le texte.

C’est en revanche une obligation de savoir où vous vous situez par rapport à la pratique courante et d’avoir tranché. Un auditeur qui interroge l’échange de clés post-quantique en 2026 n’attend généralement pas qu’il soit déployé. Il vérifie que vous avez une réponse, car « nous n’y avions pas pensé » et « nous l’avons évalué, voici notre position et notre calendrier » sont deux postures différentes sous une norme qui invoque l’état de l’art.

Écrire la décision, y compris la décision de ne pas agir et son motif, est la preuve la moins coûteuse de tout ce domaine.

Ce que cet article ne couvre pas

La partie observable de l’extérieur n’est pas tout 21(2)(h). Le chiffrement au repos, la gestion des clés, le traitement des secrets et le chiffrement entre services internes sont dans le périmètre et ne se mesurent pas depuis l’extérieur.

Être clair sur cette frontière compte au moment de présenter les preuves. Un éditeur qui soumet un scan externe comme s’il couvrait toute la clause s’expose à une correction. Un éditeur qui le soumet comme « la partie transport externe, mesurée à cette date, les contrôles internes étant documentés séparément » est plus facile à évaluer et donne une impression de maîtrise.

Voir ce qu’un scan externe peut et ne peut pas prouver pour situer cette limite.

Le mappage des autres référentiels

Si vous maintenez un seul jeu de preuves pour plusieurs référentiels, les contrôles de la couche transport tombent à des endroits prévisibles :

Référentiel	Contrôle
NIS2	Article 21(2)(h), les éléments réseau relevant de 21(2)(e)
ISO/IEC 27001:2022	A.8.24 usage de la cryptographie, A.8.20 sécurité des réseaux
DORA	Article 9 protection, article 7 systèmes et outils TIC
BSI IT-Grundschutz	La directive technique applicable, TR-03108 pour le courrier

Produire une mesure et la mapper quatre fois demande nettement moins de travail que quatre évaluations, et c’est l’argument principal pour traiter la couche externe avec un outil qui émet le mappage plutôt qu’avec un tableur.

Une séquence pratique

1. Mesurez ce que vous présentez aujourd’hui à l’extérieur. On n’écrit pas une politique sur une configuration qu’on n’a pas observée.
2. Corrigez tout ce qui échoue à une référence actuelle : TLS sous 1.2, HSTS absent, certificats émis hors du plafond en vigueur.
3. Rédigez la politique pour décrire ce qui est désormais vrai, avec les décisions et leur justification.
4. Remesurez selon un rythme défini et conservez les sorties datées. Un instantané unique prouve un moment ; une série prouve un processus, et c’est le processus qui intéresse réellement l’article 21.

En résumé

21(2)(h) ne nomme aucun algorithme, donc la preuve l’emporte sur l’affirmation.

Des mesures externes datées des versions de protocole, des suites, des certificats, de HSTS et du transport e-mail couvrent la partie observable. Documentez la partie interne séparément, et écrivez les décisions que vous avez prises sur ce que vous ne déployez pas encore.