Cryptographie et chiffrement (Article 21 NIS2) — Politiques, gestion des clés et transition post-quantique

Ce que dit l'article 21 §2 — texte de la mesure et intention

L'article 21 de la directive NIS2 exige des entités régulées la mise en place de « politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement ». Cette obligation dépasse la simple activation d'un protocole de chiffrement par défaut : elle impose une gouvernance documentée, un choix raisonné des mécanismes cryptographiques, et la traçabilité du cycle de vie des clés.

L'intention du législateur européen est triple : garantir la confidentialité des données en transit et au repos, assurer l'intégrité et l'authenticité des échanges, et organiser la résilience face à l'obsolescence des algorithmes. La transition post-quantique durera plus d'une dizaine d'années et impactera l'intégralité de l'écosystème numérique. Pour l'ANSSI, la cryptographie représente à la fois un contrôle critique et une dette technique à anticiper dès aujourd'hui, notamment au regard de la menace quantique.

Référentiels et standards qui s'articulent

ISO 27001:2022 Annex A 8.24 – Use of Cryptography

La norme ISO 27001:2022 Annex A 8.24 impose la définition et la mise en œuvre de règles pour l'usage efficace de la cryptographie, y compris la gestion des clés cryptographiques. La conformité exige la mise en place d'une politique sur la cryptographie, un processus efficace de gestion des clés et la détermination du type de technique cryptographique applicable à la classification des données de l'actif informationnel.

Le contrôle 8.24 consolide les deux anciens contrôles 10.1.1 et 10.1.2 de la version 2013 et place la gestion des clés au cœur du dispositif.

IEC 62443 pour les OT

Les environnements de production industrielle (secteurs énergie, eau, transports) doivent appliquer la norme IEC 62443-3-3 qui spécifie les exigences de sécurité système, y compris le chiffrement des communications et la gestion des clés pour les systèmes de contrôle industriels (ICS/SCADA). La crypto-agilité y est particulièrement critique, compte tenu des cycles de vie matériels de 15 à 30 ans.

Mise en œuvre opérationnelle — étapes concrètes pour une entité régulée

Étape 1 – Inventaire cryptographique complet

Les organisations doivent inventorier où elles ont de la cryptographie dans leur environnement, ce qui n'est pas facile car la cryptographie est tellement intégrée dans les applications que la plupart des utilisateurs ne la voient même plus.

Recensez :

Chiffrement au repos : bases de données (TDE), disques (BitLocker, LUKS), sauvegardes, archives, systèmes de fichiers chiffrés
Chiffrement en transit : TLS/SSL (serveurs web, API), VPN (IPsec, OpenVPN, WireGuard), messagerie (S/MIME, PGP), tunnels inter-sites
Signatures et PKI : certificats serveurs, certificats d'authentification utilisateurs, tokens HSM, signature de code, horodatage
Mécanismes embarqués : firmware, TPM, Secure Boot, SGX, chiffrement matériel dans les SAN ou appliances

Documentez pour chaque usage : algorithme, longueur de clé, mode opératoire, lieu de stockage des clés, date de déploiement, propriétaire fonctionnel, durée de vie prévue, références produits/bibliothèques.

Étape 2 – Analyse de risques et classification

Croisez l'inventaire avec la classification des actifs informationnels définie dans votre analyse de risques sécurité SI. Identifiez les flux et données critiques qui justifient un niveau de sécurité cryptographique renforcé (secret médical, secret défense, données bancaires, propriété intellectuelle sensible).

Appliquez une grille de décision :

Confidentialité requise → chiffrement au repos (AES-256) + en transit (TLS 1.3)
Intégrité seule → hachage SHA-256 minimum, HMAC
Authenticité → signatures numériques (RSA ≥ 2048 bits ou ECDSA P-256)
Non-répudiation → PKI avec horodatage qualifié RGS 2 ou 3 étoiles

Étape 3 – Formalisation d'une politique cryptographique

Rédigez une Politique d'usage de la cryptographie (ou intégrez un chapitre dédié dans la Politique de Sécurité des Systèmes d'Information). ISO 27001:2022 Annex A 8.24 exige une politique documentée pour les contrôles cryptographiques.

Contenu minimal attendu par un auditeur :

Objectifs : confidentialité, intégrité, authenticité, non-répudiation, conformité légale
Périmètre : SI métier, SI OT, cloud public/privé, postes de travail, dispositifs IoT/mobiles
Algorithmes autorisés : AES-256, RSA ≥ 2048, ECDSA P-256/P-384, SHA-256/SHA-3
Algorithmes interdits : DES, 3DES (après 2023), MD5, SHA-1, RC4, RSA < 2048 bits
Protocoles imposés : TLS 1.2 minimum (TLS 1.3 recommandé), SSH v2, IPsec avec IKEv2
Gestion du cycle de vie des clés : génération (HSM, KMS cloud), stockage (jamais en clair dans le code source ou fichiers de configuration), distribution (canal sécurisé), rotation annuelle minimum, révocation, destruction sécurisée
Modalités d'homologation pour toute nouvelle solution intégrant de la cryptographie
Propriétaires : RSSI responsable de la politique, DSI responsable de l'implémentation, responsables métiers pour l'analyse de risques fonctionnelle
Revue annuelle obligatoire de la politique

Étape 4 – Implémentation technique et migration

Priorisez les actions par niveau de risque :

Niveau critique (à traiter sous 6 mois) :

Désactivation de TLS 1.0/1.1, SSL 3.0
Remplacement de SHA-1 dans les certificats (migration vers SHA-256)
Mise à niveau de clés RSA < 2048 bits
Chiffrement des bases contenant des données personnelles sensibles (RGPD art. 32)

Niveau élevé (6–18 mois) :

Déploiement de la rotation automatique des clés (KMS Azure Key Vault, AWS KMS, HashiCorp Vault)
Migration des VPN IPsec vers IKEv2 avec Perfect Forward Secrecy (PFS)
Audit des bibliothèques cryptographiques tierces (OpenSSL, BouncyCastle) – évitez le développement maison
Mise en place de l'authentification mutuelle TLS (mTLS) pour les API critiques

Niveau modéré (18–36 mois) :

Préparation à la cryptographie post-quantique : tests de compatibilité hybride (algorithmes classiques + PQC)
Mise en œuvre de la crypto-agilité : capacité à changer rapidement d'algorithme sans refonte applicative
Formation des équipes DevOps/SecOps

Les organisations doivent mettre en œuvre des infrastructures à clés publiques (PKI) et des solutions de gestion du cycle de vie des certificats (CLM) capables de crypto-agilité, recommandée par le NIST et l'ANSSI, qui est la capacité d'un système d'information à changer rapidement et sans rupture ses mécanismes cryptographiques.

Étape 5 – Traçabilité et supervision

Loguez tous les événements de gestion des clés (génération, distribution, rotation, révocation, destruction). Intégrez ces logs dans votre SIEM. Mettez en place des alertes sur :

Expiration imminente de certificats (30 jours)
Tentative d'usage d'un algorithme banni
Accès aux clés maîtresses en dehors des procédures nominales
Échec de validation de signature

Documentez chaque changement dans un registre cryptographique (format tableur ou CMDB) : date, système impacté, ancien algorithme/clé, nouvel algorithme/clé, responsable, ticket de changement.

Prestataires ANSSI à mobiliser pour cette mesure

PASSI / PASSI-LPM — audit d'implémentation cryptographique

Un Prestataire d'Audit de la Sécurité des Systèmes d'Information qualifié ANSSI réalise un audit de configuration cryptographique :

Validation de la conformité des algorithmes déployés au guide ANSSI et aux politiques internes
Test de solidité des générateurs de nombres aléatoires (PRNG)
Vérification de l'absence de clés faibles, réutilisées ou exposées (scan de dépôts Git, fichiers de config)
Audit de code des implémentations cryptographiques custom (recherche de failles type padding oracle, timing attacks)
Revue de la gestion des clés dans les solutions HSM/KMS

Pour les entités OIV, un PASSI-LPM est obligatoire pour les audits de sécurité des systèmes sensibles intégrant des mécanismes cryptographiques critiques.

PRIS — réponse aux incidents cryptographiques

Un Prestataire de Réponse aux Incidents de Sécurité intervient en cas de compromission suspectée ou avérée :

Clé privée divulguée (serveur compromis, vol de token HSM)
Certificat frauduleusement émis (attaque sur l'autorité de certification)
Détection d'usage d'algorithmes obsolètes par un attaquant (downgrade attack)
Révocation d'urgence de certificats et regénération
Analyse forensique des journaux cryptographiques pour identifier l'origine de la faille

PDIS — détection de mauvaises pratiques cryptographiques

Un Prestataire de Détection des Incidents de Sécurité surveille en continu les flux réseau et logs applicatifs pour repérer :

Négociation de suites cryptographiques faibles (DES, RC4) malgré leur interdiction
Connexions TLS avec certificats auto-signés non autorisés
Usage de protocoles en clair (HTTP, FTP, Telnet) sur des segments sensibles
Émission de certificats avec durée de validité non conforme (> 398 jours pour TLS depuis septembre 2020)

PACS — accompagnement stratégique et politique cryptographique

Un Prestataire d'Accompagnement et de Conseil en Sécurité peut :

Rédiger ou réviser la politique cryptographique pour l'aligner sur NIS2 et ISO 27001:2022 A.8.24
Conduire l'inventaire cryptographique initial (cartographie des usages)
Définir une roadmap de migration post-quantique sur 3–5 ans
Former les équipes techniques (DSI, DevOps) aux bonnes pratiques ANSSI
Accompagner la démarche d'homologation RGS pour les entités publiques

Qualification SecNumCloud pour hébergement

Si vous stockez vos clés ou vos données chiffrées chez un cloud provider, vérifiez que celui-ci dispose de la qualification SecNumCloud. Ce label ANSSI garantit notamment :

Localisation des données en France ou UE
Chiffrement au repos et en transit avec algorithmes conformes
Gestion des clés de chiffrement maîtrisée (pas d'accès par le prestataire sans accord explicite)
Traçabilité des opérations cryptographiques

Outils techniques recommandés

Gestion centralisée des clés (KMS)

Azure Key Vault / AWS KMS / Google Cloud KMS : pour les organisations en cloud hybride, offrent rotation automatique, HSM managé (FIPS 140-2 niveau 3), logs d'accès intégrés
HashiCorp Vault : solution on-premise ou cloud-agnostique, supporte secrets dynamiques, chiffrement as a service, intégration Kubernetes
Thales CipherTrust Manager (anciennement Vormetric) : orchestration centralisée pour datacenters et clouds multiples, conformité ANSSI/RGS

HSM (Hardware Security Module)

Thales Luna HSM : qualifié ANSSI, utilisé par les OIV et secteurs financiers
Utimaco CryptoServer : certification EAL4+, support des algorithmes post-quantiques
nCipher nShield : modulaire, supporte PKI à très fort volume

Bibliothèques et implémentations

Privilégiez toujours des bibliothèques auditées et maintenues : OpenSSL 3.x (support PQC expérimental), LibreSSL, BouncyCastle (Java/.NET), libsodium (chiffrement moderne simplifié), cryptography (Python).

Selon Veracode, la mauvaise implémentation des protocoles de sécurité est la deuxième cause de failles, les applications web et mobiles étant les plus touchées. Évitez le développement cryptographique interne sauf si vous disposez d'une équipe spécialisée avec revue de code par un tiers qualifié.

Scan et audit automatisés

SSL Labs (Qualys) : test de configuration TLS publique (score A requis)
testssl.sh : script open-source d'audit des configurations TLS/SSL
cryptosense Analyzer : détection automatique d'usage de crypto faible dans le code Java/.NET
CipherScan (Mozilla) : audit des suites cryptographiques activées côté serveur

Solutions EDR/XDR avec visibilité cryptographique

Les EDR modernes (CrowdStrike, Microsoft Defender for Endpoint, SentinelOne) peuvent détecter :

Tentatives de chiffrement massif (indicateur ransomware)
Accès anormal aux secrets (coffres-forts de mots de passe, clés SSH)
Usage de bibliothèques cryptographiques obsolètes dans les processus

Cas d'incidents documentés — où l'absence/défaillance de cette mesure a aggravé l'impact

Heartbleed (2014) : faille OpenSSL

La vulnérabilité CVE-2014-0160 dans OpenSSL a exposé les clés privées de millions de serveurs TLS. Les organisations sans rotation régulière des certificats et sans inventaire cryptographique ont dû procéder à une révocation et regénération d'urgence, paralysant des infrastructures pendant plusieurs jours. Celles ayant un plan de gestion de clés documenté et des procédures de rotation automatisées ont pu migrer en quelques heures.

SolarWinds Orion (2020) : certificats compromis

Les attaquants ont signé le code malveillant avec un certificat légitime volé. Les entités victimes sans surveillance de l'usage des certificats de signature de code (monitoring des accès au HSM, traçabilité des demandes) n'ont détecté l'anomalie qu'après plusieurs mois. Une politique stricte de contrôle d'accès aux clés privées et un log centralisé des signatures auraient permis une alerte précoce.

Exploitation d'algorithmes faibles (MD5, SHA-1)

Des failles ont été découvertes dans les fonctions de hachage MD5 et SHA-1, permettant aux attaquants de falsifier des signatures numériques et de contourner les contrôles de sécurité. Le portefeuille Parity Multisig (2017) a permis le vol de 153 037 ETH en raison d'une erreur dans la vérification des signatures ; le groupe Lazarus (2020) a exploité des faiblesses de validation de signature pour voler 12,5 millions de dollars sur plusieurs protocoles DeFi.

Ces attaques illustrent le coût de l'obsolescence cryptographique non traitée. Une politique claire avec interdiction formelle de MD5/SHA-1 et contrôles techniques (rejet au niveau firewall applicatif, Web Application Firewall) auraient bloqué ces vecteurs.

Ransomware et chiffrement sans PKI robuste

De nombreuses attaques ransomware en 2023–2025 ont tiré parti de la mauvaise gestion des sauvegardes chiffrées : clés de chiffrement stockées sur le même réseau que les sauvegardes, absence de chiffrement ou usage de mots de passe faibles. Le chiffrement de données par ransomware a reculé de 9 points en 2024, grâce à la généralisation des sauvegardes sécurisées, des plans de reprise d'activité et des outils de détection comportementale. Les organisations ayant déployé un chiffrement des sauvegardes avec clés externalisées (offline ou dans un coffre-fort cloud distinct) ont pu restaurer leurs systèmes sans payer de rançon.

Attaque ANTS France (avril 2026) : absence de chiffrement des données

L'attaque contre l'Agence Nationale des Titres Sécurisés a exposé les données de près de 12 millions de particuliers. L'attaquant aurait exploité une faille Idor (Insecure Direct Object Reference), permettant d'accéder aux données d'autres utilisateurs en modifiant simplement un identifiant dans les requêtes, sans qu'aucun contrôle d'autorisation ni chiffrement côté serveur ne soit effectué. Un chiffrement applicatif des données sensibles (tokenisation, chiffrement au niveau colonne) aurait limité l'exfiltration.

Sanctions et risques en cas de non-conformité

Sanctions administratives NIS2

L'article 34 de la directive NIS2 prévoit des amendes administratives jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial (selon le montant le plus élevé) pour les entités essentielles, et jusqu'à 7 millions d'euros ou 1,4 % du CA pour les entités importantes, en cas de manquement grave aux mesures de gestion des risques de cybersécurité, incluant explicitement l'absence ou l'insuffisance de politiques cryptographiques.

La loi française de transposition (décret ReCyF publié le 17 mars 2026) aligne les plafonds de sanction sur ces montants et habilite l'ANSSI à vérifier, lors d'inspections ou d'audits post-incident, la conformité des mécanismes cryptographiques déployés.

Risques RGPD connexes

Une absence de chiffrement des données personnelles sensibles peut constituer un manquement à l'obligation de sécurité prévue à l'article 32 du RGPD. Selon les données ouvertes de la CNIL, le nombre de notifications de violations de données est passé de 4 669 en 2023 à 5 630 en 2024 (+20,6 %), puis a atteint 6 929 sur les neuf premiers mois de 2025. En cas de fuite de données non chiffrées, la CNIL peut prononcer une amende allant jusqu'à 20 millions d'euros ou 4 % du CA annuel mondial, cumulable avec les sanctions NIS2.

Perte de confiance et coûts opérationnels

Au-delà des sanctions, une cryptographie défaillante entraîne :

Suspension d'activité : impossibilité de signer numériquement des contrats, d'établir des connexions sécurisées avec des partenaires (banques, administrations)
Coût de remédiations d'urgence : révocation et réémission de milliers de certificats (coût moyen estimé : 150–300 € par certificat selon la classe RGS), migration applicative forcée
Atteinte réputationnelle : les clients B2B et les donneurs d'ordres (OIV, grands comptes) exigent désormais dans leurs audits tiers la preuve de politiques cryptographiques conformes

Responsabilité pénale en cas de négligence avérée

L'absence de mesures cryptographiques de base (chiffrement des données de santé, secrets industriels) peut, en cas d'incident, engager la responsabilité pénale des dirigeants pour mise en danger de la vie d'autrui (données médicales) ou atteinte au secret des affaires.

En synthèse : la mesure « Cryptographie et chiffrement » n'est pas un simple point de conformité technique, mais un pilier stratégique de la résilience numérique. Elle impose une gouvernance claire, un inventaire exhaustif, le recours à des standards robustes (ANSSI, ISO 27001:2022 A.8.24, RGS, NIST PQC) et une capacité d'adaptation rapide (crypto-agilité). Les entités régulées NIS2 doivent anticiper dès 2026 la transition post-quantique, s'appuyer sur des prestataires qualifiés (PASSI, PRIS, PACS) et maintenir une traçabilité rigoureuse du cycle de vie des clés pour répondre aux exigences d'audit et prévenir les incidents majeurs.