Migration vers la cryptographie post-quantique avec ISO 27001

Le bourdonnement du projecteur est le seul bruit dans la salle du conseil. Sarah, la RSSI, vient de terminer son point trimestriel sur les risques lorsque le directeur général brandit l’impression d’un article de la presse financière. Le titre est sans détour : « Le compte à rebours quantique : vos données sont-elles déjà obsolètes ? »
« Sarah », dit-il, moins accusateur que réellement inquiet, « nous avons dépensé des millions dans le chiffrement. Nous sommes conformes. Nous sommes sécurisés. Cet article affirme qu’un ordinateur quantique suffisamment puissant pourrait tout casser. Sommes-nous exposés ? Qu’en est-il des données que nous chiffrons et stockons aujourd’hui ? Est-ce une bombe à retardement ? »
Cette conversation quitte désormais les conférences de sécurité pour entrer dans les comités exécutifs. La question n’est plus de savoir si l’informatique quantique intéresse les chercheurs. Elle est de savoir si les choix cryptographiques actuels pourront protéger les obligations métier de demain.
Pour de nombreuses organisations, la réponse honnête est inconfortable. Le chiffrement est partout : passerelles TLS, VPN, portails clients, jetons d’identité, sauvegardes de bases de données, applications mobiles, plateformes de paiement, S/MIME, SSH, intégrations API, environnements SaaS, modules matériels de sécurité, services cloud de gestion des clés, signature de micrologiciels, signature de code et contrats numériques.
C’est précisément le problème. La cryptographie est partout, mais sa responsabilité est souvent nulle part.
La migration vers la cryptographie post-quantique ne concerne pas seulement un futur ordinateur quantique pertinent pour la cryptanalyse. Elle concerne aussi le risque actuel de type « collecter maintenant, déchiffrer plus tard », dans lequel des adversaires capturent aujourd’hui des données chiffrées et attendent que des capacités futures rendent leur déchiffrement réalisable. Si votre organisation conserve des données à caractère personnel, des dossiers de santé, des données financières réglementées, des secrets d’affaires, des communications juridiques, des données d’infrastructures nationales, des micrologiciels produits ou de la propriété intellectuelle à longue durée de vie, le risque existe déjà sur l’ensemble du cycle de vie.
Un plan de migration cryptographique adapté au risque quantique n’est pas un projet conduit dans l’urgence. C’est un programme structuré de gouvernance, d’inventaire, de gestion des fournisseurs, d’architecture, de tests et d’audit. La question pratique pour les RSSI est simple :
Comment construire un plan de migration post-quantique crédible pour la direction générale, exploitable par les ingénieurs et défendable devant les auditeurs ?
La réponse consiste à ancrer les travaux dans ISO/IEC 27001:2022, à interpréter les contrôles au moyen d’ISO/IEC 27002:2022, à utiliser les normes de cryptographie post-quantique de NIST comme boussole technique et à créer un modèle unique d’éléments probants couvrant les obligations ISO 27001, NIST, COBIT 2019, GDPR, DORA et NIS2.
Pourquoi la cryptographie post-quantique relève du SMSI
Une erreur fréquente consiste à confier la migration post-quantique uniquement aux ingénieurs cryptographes. Ils sont indispensables, mais ils ne peuvent pas résoudre seuls la question de gouvernance.
La migration post-quantique touche à la gestion des actifs, à la classification des données, à la gestion des fournisseurs, à l’architecture sécurisée, à la gestion des clés, au développement applicatif, à la sécurité cloud, à la réponse aux incidents, à la continuité d’activité, au risque juridique, à la responsabilité réglementaire et aux éléments probants d’audit. Ce sont des sujets de SMSI.
ISO/IEC 27001:2022 fournit le cadre de gouvernance. La norme exige que l’organisation comprenne son contexte, les parties intéressées, les risques, les objectifs, les responsabilités, les compétences, les informations documentées, la planification opérationnelle, l’évaluation de la performance, l’audit interne, la revue de direction et l’amélioration continue. ISO/IEC 27002:2022 fournit ensuite l’interprétation des contrôles, notamment autour de 8.24 Use of cryptography, 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 8.25 Secure development life cycle, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities et 5.30 ICT readiness for business continuity.
Chez Clarysec, c’est pourquoi la préparation au post-quantique est traitée comme une transformation pilotée par le SMSI, et non comme un remplacement isolé d’algorithmes.
Comme l’indique le Zenith Blueprint : feuille de route en 30 étapes pour les auditeurs de Clarysec, phase 2, étape 8, « Cadrage des actifs, des dépendances et des éléments probants » :
« Un contrôle ne peut être considéré comme fiable tant que l’organisation ne peut pas démontrer où il s’applique, qui en est propriétaire, quels éléments probants l’étayent et quel risque il réduit. »
Cette phrase est particulièrement importante pour la cryptographie post-quantique. Avant de remplacer des algorithmes, vous devez savoir où ils sont utilisés.
Le Zenith Controls : guide de correspondance inter-conformité de Clarysec présente la cryptographie comme une chaîne d’éléments probants connectée, et non comme un simple paramètre technique :
« L’assurance cryptographique est auditée tout au long du cycle de vie de l’information : identification, classification, utilisation approuvée, protection des clés, surveillance opérationnelle, dépendance fournisseur, gestion des exceptions et conservation des éléments probants. »
Cette vision du cycle de vie évite l’échec le plus courant : se demander uniquement « Utilisons-nous des algorithmes sûrs face au quantique ? ». Les meilleures questions sont les suivantes :
- Quels systèmes doivent migrer en premier vers le post-quantique ?
- Quelles données ont une durée de confidentialité supérieure à l’horizon de risque quantique ?
- Quels fournisseurs contrôlent notre chiffrement, nos signatures, nos certificats ou notre gestion des clés ?
- Quelles applications sont crypto-agiles et lesquelles sont codées en dur ?
- Quels contrôles compensatoires existent tant que la migration n’est pas achevée ?
- Quels éléments probants démontreront que les décisions étaient fondées sur les risques et ont été revues ?
De la menace quantique au risque métier auditable
Un plan post-quantique utile commence par des scénarios de risque. Évitez les formulations vagues telles que « l’informatique quantique pourrait casser le chiffrement ». Créez plutôt des enregistrements de risque auditables reliant l’impact métier, la menace, la vulnérabilité, les actifs affectés, les contrôles actuels, le risque résiduel et les actions de traitement des risques.
Par exemple :
« Des documents d’identité clients chiffrés et conservés pendant sept ans pourraient devenir vulnérables à un déchiffrement futur si des sauvegardes sont exfiltrées aujourd’hui et si la cryptographie à clé publique actuelle devient cassable à l’avenir. »
Ce scénario renvoie à la conservation des données, au chiffrement des sauvegardes, à la gestion des clés, au contrôle d’accès, à l’hébergement fournisseur, à la surveillance et à la priorité de migration.
Autre exemple :
« La signature de micrologiciels pour des objets connectés repose sur des schémas de signature qui pourraient ne plus rester fiables pendant tout le cycle de vie attendu des équipements. »
Ce scénario renvoie à la sécurité produit, aux mécanismes de mise à jour sécurisée, aux capacités HSM, à la sécurité des clients, à l’assurance de conception fournisseur et à la résilience opérationnelle à long terme.
Troisième exemple :
« Des communications juridiques archivées et chiffrées aujourd’hui pourraient nécessiter une confidentialité supérieure à quinze ans, créant une exposition de type collecter maintenant, déchiffrer plus tard. »
Ce scénario renvoie à la classification, à la conservation, à la protection cryptographique, au gel légal, aux communications sécurisées et à l’acceptation du risque par la direction.
Le risque ne se limite pas à un futur « Q-Day ». Il comprend trois préoccupations liées :
- Collecter maintenant, déchiffrer plus tard : des adversaires collectent aujourd’hui des données chiffrées en vue d’un déchiffrement futur.
- Compromission des signatures numériques : des attaques futures sapent la confiance dans les mises à jour logicielles, les jetons d’identité, les documents juridiques, les micrologiciels et les transactions financières.
- Défaillance de concentration cryptographique : une vaste catégorie de produits, protocoles, bibliothèques ou fournisseurs devient obsolète au même moment.
La politique d’entreprise Clarysec Cryptography and key management policy, clause 5.1, formule ainsi l’exigence de gouvernance :
« Les contrôles cryptographiques doivent être sélectionnés, mis en œuvre, revus et retirés en fonction de la classification de l’information, de la durée de protection requise, des normes cryptographiques approuvées, de la propriété des clés et des décisions documentées de traitement des risques. »
Cette clause est essentielle, car la durée de protection devient un facteur de priorisation. Des données de session éphémères et des dossiers médicaux à long terme n’exposent pas l’organisation au même risque quantique. Une clé de signature de code qui fonde la confiance d’un appareil pendant quinze ans présente un profil de risque différent d’un certificat de test interne à courte durée de vie.
La même famille de politiques, mentionnée dans les supports Clarysec comme la Politique relative aux contrôles cryptographiques, peut également formaliser les attentes de revue avec une formulation telle que :
Clause 5.4 : normes relatives aux algorithmes et aux longueurs de clés
« Tous les algorithmes cryptographiques et toutes les longueurs de clés utilisés dans l’organisation doivent être sélectionnés à partir d’une liste approuvée tenue à jour par l’équipe de sécurité de l’information. Cette liste doit être revue chaque année au regard des bonnes pratiques du secteur et des orientations des organismes nationaux de cybersécurité, par exemple NIST et ENISA, en portant une attention particulière au développement des normes cryptographiques post-quantiques. Une feuille de route de migration des systèmes qui utilisent des algorithmes vulnérables aux attaques fondées sur le quantique doit être tenue à jour dans le cadre de l’inventaire des actifs cryptographiques. »
Cela n’exige pas une adoption précoce non maîtrisée. Cela exige de la veille, de la planification, une revue et des éléments probants.
Utiliser les normes PQC de NIST comme boussole technique
Les travaux de NIST sur la cryptographie post-quantique donnent aux organisations une orientation technique crédible. NIST a normalisé ML-KEM pour l’établissement de clés, ML-DSA pour les signatures numériques et SLH-DSA pour les signatures sans état fondées sur le hachage. Ces normes donnent aux fournisseurs et aux architectes une base pour les feuilles de route et les conceptions pilotes.
Pour les RSSI, l’objectif n’est pas de mémoriser les détails des algorithmes. L’objectif est de créer une trajectoire de migration capable d’intégrer les choix cryptographiques approuvés sans perturber les services métier, les engagements de conformité ou la traçabilité d’audit.
Un plan de migration aligné sur NIST doit comprendre quatre axes :
- Découverte : identifier où existe la cryptographie à clé publique vulnérable.
- Priorisation : classer les systèmes selon la sensibilité des données, la durée de protection, l’exposition, l’impact sur l’intégrité et la criticité métier.
- Architecture de transition : définir où les mécanismes hybrides, crypto-agiles ou post-quantiques seront testés et adoptés.
- Assurance : produire les éléments probants montrant que les décisions, exceptions, dépendances fournisseurs, tests et risques résiduels sont maîtrisés.
La crypto-agilité mérite une attention particulière. Un système crypto-agile peut changer d’algorithmes, de tailles de clés, de bibliothèques, de certificats et de protocoles sans refonte majeure. À l’ère post-quantique, la crypto-agilité n’est pas un luxe. C’est une exigence de résilience.
Si une API de paiement contient des bibliothèques cryptographiques codées en dur et n’a pas de propriétaire documenté, elle n’est pas crypto-agile. Si une application mobile épingle des certificats sans chemin de mise à jour maîtrisé, la migration peut devenir coûteuse. Si un objet connecté a une durée de vie terrain de quinze ans et ne peut pas prendre en charge des signatures plus volumineuses ou des mises à jour sécurisées de micrologiciels, le risque devient stratégique.
Construire l’inventaire cryptographique avant de choisir la trajectoire de migration
La plupart des organisations ne disposent pas d’un inventaire cryptographique complet. Elles peuvent avoir un inventaire de certificats, une feuille de calcul de gestion des clés, des enregistrements HSM, une liste KMS cloud ou des entrées CMDB. Rarement disposent-elles d’une vue unique de leurs dépendances cryptographiques.
Un plan de migration vers la cryptographie post-quantique nécessite une nomenclature cryptographique, ou CBOM. Elle n’a pas besoin d’être parfaite dès le premier jour. Elle doit en revanche être structurée, placée sous responsabilité et améliorée en continu.
Au minimum, collectez les champs suivants :
| Champ d’inventaire | Pourquoi il est important pour la migration post-quantique |
|---|---|
| Service métier | Priorise la migration selon l’impact métier |
| Propriétaire de l’actif | Attribue la responsabilité et l’autorité de décision |
| Classification des données | Identifie les exigences de confidentialité et d’intégrité |
| Durée de protection | Met en évidence l’exposition de type collecter maintenant, déchiffrer plus tard |
| Fonction cryptographique | Distingue le chiffrement, l’échange de clés, les signatures, le hachage et les certificats |
| Algorithme et protocole | Identifie où des mécanismes à clé publique vulnérables sont utilisés |
| Bibliothèque ou mise en œuvre | Met en évidence les dépendances logicielles et les contraintes de mise à jour |
| Emplacement des clés | Indique si les clés se trouvent dans un HSM, un KMS cloud, un logiciel, un terminal ou une plateforme fournisseur |
| Dépendance fournisseur | Révèle où la migration dépend de tiers |
| Complexité de migration | Soutient le séquencement, les tests et la planification budgétaire |
| Source des éléments probants | Rend l’inventaire auditable |
Un inventaire initial peut ressembler à ceci :
| ID de l’actif | Nom de l’actif | Propriétaire | Criticité métier | Usage cryptographique | Emplacement | Vulnérabilité PQC | Priorité de migration |
|---|---|---|---|---|---|---|---|
| APP-042 | API de facturation client | Technologies financières | Élevée | Signatures RSA-2048, TLS, chiffrement AES-256 | AWS eu-west-1 | Élevée pour la confiance dépendante de RSA | 1 |
| NET-007 | VPN d’accès à distance | Infrastructure informatique | Élevée | Authentification ECDSA, IKEv2 | Sur site et périphérie cloud | Élevée pour l’authentification dépendante d’ECC | 1 |
| DB-011 | Dossiers patients archivés | Conformité | Élevée avec conservation de 30 ans | Chiffrement de base de données AES-256 | Base de données sur site | Plus faible pour le chiffrement symétrique, élevée si les clés sont échangées ou enveloppées avec des méthodes à clé publique vulnérables | 2 |
| CODE-001 | Signature de code CI/CD | DevOps | Impact élevé sur l’intégrité | Signature de code RSA-4096 | HSM et pipeline de build | Élevée pour la confiance à long terme dans les signatures | 1 |
Ce tableau montre immédiatement pourquoi l’inventaire compte. AES-256 ne présente pas le même type de risque quantique que RSA ou ECC, mais des dossiers patients archivés peuvent encore dépendre d’un enveloppement de clés vulnérable, de certificats, de systèmes d’identité ou de canaux de transfert de sauvegarde. La signature de code ne protège pas nécessairement la confidentialité, mais elle protège l’intégrité logicielle et la confiance.
Dans Zenith Controls, la cryptographie est mise en correspondance avec des normes de soutien qui ajoutent de la profondeur. ISO/IEC 27005 soutient la gestion des risques de sécurité de l’information et aide à traduire l’incertitude quantique en scénarios de risque structurés. ISO/IEC 27017 soutient les contrôles de sécurité propres au cloud, ce qui est essentiel lorsque des services cryptographiques sont fournis par KMS cloud, TLS managé, chiffrement SaaS ou certificats de plateforme. ISO/IEC 27018 est pertinente lorsque des données à caractère personnel sont traitées dans des services cloud publics. ISO 22301 est pertinente lorsque la défaillance cryptographique pourrait affecter la continuité de services critiques. ISO/IEC 27036 soutient la sécurité des relations fournisseurs, essentielle lorsque des fournisseurs gèrent pour votre compte le chiffrement, les signatures, les certificats ou les communications sécurisées.
La leçon est simple : vous ne pouvez pas migrer ce que vous ne trouvez pas.
Prioriser selon la sensibilité, la durée, l’exposition et la difficulté de migration
Une fois la CBOM en place, la priorisation devient fondée sur les éléments probants. Le meilleur point de départ est un petit nombre de systèmes critiques, et non un exercice de perfection à l’échelle de l’entreprise.
Imaginez une société de services financiers disposant de trois systèmes à forte valeur :
- un coffre-fort documentaire client conservant des pièces d’identité pendant dix ans ;
- une passerelle API B2B prenant en charge les transactions partenaires ;
- une plateforme de signature de code pour les mises à jour de logiciels de bureau.
À l’aide de Zenith Blueprint, phase 2, étape 8, l’équipe extrait les actifs de la CMDB, les certificats de la plateforme de gestion des certificats, les clés du HSM et du KMS cloud, les classes de données du registre de protection de la vie privée et les dépendances fournisseurs des enregistrements d’achats.
Elle attribue ensuite une cotation aux systèmes :
| Système | Sensibilité des données | Durée de protection | Exposition externe | Dépendance fournisseur | Priorité de migration |
|---|---|---|---|---|---|
| Coffre-fort documentaire client | Très élevée | Longue | Moyenne | KMS cloud et fournisseur de stockage | Critique |
| Passerelle API B2B | Élevée | Courte à moyenne | Très élevée | Fournisseur de gestion d’API | Élevée |
| Plateforme de signature de code | Impact très élevé sur l’intégrité | Confiance appareil à long terme | Moyenne | HSM et outils de pipeline de build | Critique |
Le coffre-fort documentaire client devient prioritaire en raison de la durée de confidentialité. La plateforme de signature de code devient prioritaire parce que la confiance dans les signatures affecte l’intégrité logicielle et la sécurité des clients. La passerelle API est hautement prioritaire en raison de son exposition externe, mais les données qu’elle conserve peuvent avoir une durée de confidentialité plus courte.
Le registre des risques doit ensuite relier chaque scénario au traitement et aux éléments probants :
| Scénario de risque | Contrôle actuel | Décision de traitement | Éléments probants requis |
|---|---|---|---|
| Des enregistrements clients à longue durée de vie pourraient être exposés à un déchiffrement futur | Chiffrement des données au repos, contrôle d’accès, KMS cloud | Évaluer la feuille de route du chiffrement de stockage, renforcer la séparation des clés, revoir la cryptographie des transferts de sauvegarde | CBOM, feuille de route fournisseur, décision d’architecture, enregistrement de traitement des risques |
| La confiance dans les mises à jour logicielles pourrait être affaiblie par une compromission future des signatures | HSM de signature de code, approbation des versions | Évaluer la préparation aux signatures post-quantiques, la stratégie d’horodatage et le cycle de vie des signatures | Inventaire des signatures, rapport de capacités HSM, procédure de développement sécurisé |
| La cryptographie de l’API partenaire pourrait être difficile à changer rapidement | Certificats TLS, configuration de la passerelle API | Mettre en œuvre des tests de crypto-agilité et une revue de la feuille de route fournisseur | Scan TLS, configuration de référence, attestation fournisseur |
La politique d’entreprise Clarysec Secure development policy, clause 6.4, apporte l’angle de la chaîne de livraison logicielle :
« Les revues de conception de sécurité doivent évaluer les dépendances cryptographiques, le cycle de vie des bibliothèques, l’agilité algorithmique, la gestion des secrets, les mécanismes de mise à jour et les composants contrôlés par des fournisseurs avant toute approbation de production. »
Cette clause transforme la préparation post-quantique en exigence d’ingénierie. Elle évite que des équipes déploient de nouveaux systèmes impossibles à migrer ultérieurement.
Suivre une feuille de route de 12 mois compréhensible par les auditeurs
Pour de nombreuses organisations, la migration post-quantique prendra des années. La première année doit faire passer l’organisation de l’incertitude à une migration gouvernée.
| Mois | Chantier | Résultat | Éléments probants |
|---|---|---|---|
| 1 | Mandat de la direction générale | Périmètre validé au niveau du conseil, appétence au risque et trajectoire de financement | Comptes rendus du comité de pilotage, charte approuvée |
| 1 à 2 | Découverte cryptographique | CBOM initiale couvrant les services critiques | Export d’inventaire, liens CMDB, attestations des propriétaires de systèmes |
| 2 à 3 | Revue des données et de la durée de protection | Liste priorisée des données sensibles à longue durée de vie et des actifs à fort impact sur l’intégrité | Registre de classification, calendrier de conservation, enregistrements de risques |
| 3 à 4 | Revue des dépendances fournisseurs | Feuille de route fournisseur et analyse des écarts contractuels | Questionnaires fournisseurs, clauses contractuelles, exceptions de risque |
| 4 à 6 | Évaluation de l’architecture et de la crypto-agilité | Schémas d’architecture cible et contraintes de migration | Enregistrements de revue d’architecture, décisions de conception |
| 6 à 8 | Mise en œuvre pilote | Test hybride ou post-quantique dans un environnement sélectionné à faible risque | Résultats des tests, plan de retour arrière, constats de performance |
| 8 à 10 | Mise à jour des politiques et procédures | Règles mises à jour sur la cryptographie, la gestion des clés, les fournisseurs, le développement sécurisé et les actifs | Politiques approuvées, enregistrements de formation |
| 10 à 12 | Préparation à l’audit | Audit interne, revue de direction et actualisation du plan de traitement | Rapport d’audit, actions correctives, plan de traitement des risques mis à jour |
Dans Zenith Blueprint, phase 3, étape 14, « Conception et propriété du traitement des risques », la feuille de route met en garde contre les intentions de sécurité non financées :
« Un plan de traitement sans propriétaire, attente en matière d’éléments probants, trajectoire budgétaire et date de revue n’est pas un plan. C’est un risque non résolu avec une meilleure mise en forme. »
C’est exactement ainsi que les programmes post-quantiques échouent. Ils produisent des supports de sensibilisation, mais pas de backlog de remédiation attribué. Ils discutent d’algorithmes, mais ne mettent pas à jour les contrats fournisseurs. Ils documentent le risque, mais ne testent pas les schémas de migration.
Une feuille de route crédible crée des enregistrements de décision, des propriétaires, des dépendances, des attentes en matière d’éléments probants, des budgets et des dates de revue.
Intégrer tôt les fournisseurs au programme
De nombreuses dépendances cryptographiques sont externalisées. Les fournisseurs cloud terminent TLS. Les plateformes SaaS chiffrent les enregistrements. Les fournisseurs d’identité signent les jetons. Les prestataires de paiement gèrent les certificats. Les fournisseurs de matériel contrôlent la signature des micrologiciels. Les prestataires de services managés exploitent des VPN et des passerelles de sécurité.
Même si votre équipe interne est prête, votre migration peut être bloquée par les capacités des fournisseurs.
La politique d’entreprise Clarysec Third-party and supplier security policy, clause 5.6, précise :
« Les fournisseurs qui fournissent des services pertinents pour la sécurité doivent divulguer les dépendances significatives, les responsabilités cryptographiques, les éléments probants d’assurance, les processus de gestion des vulnérabilités et les évolutions de feuille de route susceptibles d’affecter le niveau de risque de l’organisation. »
Pour la préparation post-quantique, interrogez les fournisseurs critiques :
- Quels algorithmes, protocoles, certificats et services de gestion des clés protègent nos données ou transactions ?
- Tenez-vous à jour un inventaire cryptographique ou une CBOM ?
- Quelle est votre feuille de route post-quantique alignée sur NIST ?
- Prendrez-vous en charge l’échange de clés hybride, les signatures post-quantiques ou l’établissement de clés résistantes au quantique ?
- Comment les changements concernant les certificats, jetons, signatures et mécanismes de chiffrement seront-ils communiqués ?
- Quelles actions seront requises de la part du client ?
- Quels environnements de test seront disponibles ?
- Comment la performance, l’interopérabilité et le retour arrière seront-ils traités ?
- Les responsabilités cryptographiques sont-elles définies dans le contrat ou dans le modèle de responsabilité partagée ?
- Quelles options de sortie ou de portabilité existent si votre feuille de route ne satisfait pas nos exigences de risque ?
Les réponses des fournisseurs doivent alimenter le registre des risques. Des réponses faibles ne signifient pas toujours un remplacement immédiat, mais elles imposent un traitement. Vous pouvez devoir mettre en place des contrôles compensatoires, modifier des contrats, ajouter des clauses de notification, planifier la sortie, renforcer la surveillance ou revoir la stratégie d’approvisionnement.
C’est particulièrement important au regard des attentes de résilience opérationnelle de type DORA et NIS2. DORA met l’accent sur la gestion des risques liés aux TIC et la gestion des risques liés aux tiers TIC, y compris la supervision des dépendances critiques. NIS2 Article 21 exige des mesures de gestion des risques de sécurité techniques, opérationnelles et organisationnelles appropriées et proportionnées, y compris la sécurité de la chaîne d’approvisionnement, la gestion des incidents, la continuité d’activité et la cryptographie le cas échéant. GDPR Article 32 exige une sécurité adaptée au risque, incluant la confidentialité, l’intégrité, la disponibilité, la résilience et la capacité à assurer la protection continue des données à caractère personnel.
Le langage réglementaire diffère, mais la logique de contrôle est constante : connaître ses dépendances, gérer le risque, conserver les éléments probants et agir avant que la résilience soit compromise.
Cartographie inter-conformité : un plan de migration, plusieurs obligations
Un solide plan de migration vers la cryptographie post-quantique doit éviter de créer des dossiers de preuves séparés pour chaque référentiel. Les mêmes éléments probants de base peuvent soutenir plusieurs obligations s’ils sont correctement structurés.
Zenith Controls cartographie la thématique cryptographique entre ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA et NIS2 en se concentrant sur l’objectif du contrôle plutôt que sur l’intitulé utilisé par chaque référentiel.
| Référentiel | Comment le plan post-quantique soutient la conformité |
|---|---|
| ISO/IEC 27001:2022 | Montre la sélection des contrôles fondée sur les risques, les informations documentées, l’audit interne, la revue de direction et l’amélioration continue |
| ISO/IEC 27002:2022 | Soutient l’interprétation des contrôles pour 8.24 Use of cryptography, l’inventaire des actifs, la classification, la sécurité des fournisseurs, les services cloud, le développement sécurisé, la surveillance et la continuité |
| Normes PQC de NIST | Fournit l’orientation technique pour la transition vers des algorithmes post-quantiques approuvés et la planification cryptographique |
| NIST Cybersecurity Framework 2.0 | Relie les activités de migration aux résultats Govern, Identify, Protect, Detect, Respond et Recover |
| COBIT 2019 | Aligne le risque cryptographique sur les objectifs de gouvernance et de management tels que APO12 Managed Risk, APO13 Managed Security, APO10 Managed Vendors, DSS05 Managed Security Services et MEA03 Managed Compliance |
| GDPR | Soutient les attentes de l’Article 32 en matière de sécurité appropriée, de confidentialité, d’intégrité, de résilience et de responsabilité pour le traitement des données à caractère personnel |
| DORA | Soutient la gestion des risques liés aux TIC, la gestion des risques liés aux tiers TIC, les tests de résilience, la préparation aux incidents et la supervision par l’organe de direction |
| NIS2 | Soutient les mesures de gestion des risques de sécurité de l’Article 21, la sécurité de la chaîne d’approvisionnement, la gestion des incidents, la continuité d’activité et la responsabilité de gouvernance |
La réutilisation des éléments probants est la clé. Un inventaire cryptographique soutient la gestion des actifs ISO, les résultats Identify de NIST, la visibilité des actifs TIC exigée par DORA, la gestion des risques NIS2 et la responsabilité GDPR. Les questionnaires fournisseurs soutiennent les contrôles fournisseurs ISO, le risque tiers TIC DORA, la sécurité de la chaîne d’approvisionnement NIS2 et la gouvernance des fournisseurs COBIT. Les résultats des tests de migration soutiennent les changements sécurisés, les tests de résilience, la préparation à l’audit et la revue de direction.
Ce que demanderont les auditeurs
La cryptographie post-quantique reste un sujet d’audit émergent, mais les auditeurs disposent déjà de suffisamment d’attentes de contrôle pour poser des questions difficiles.
Un auditeur ISO/IEC 27001:2022 commencera généralement par le risque. Il demandera si le risque cryptographique lié au quantique est identifié, apprécié, traité, surveillé et revu dans le SMSI. Il attendra des éléments probants montrant que les contrôles cryptographiques sont sélectionnés sur la base du risque métier et que les responsabilités sont définies.
Un évaluateur orienté NIST peut se concentrer sur la visibilité des actifs, les mécanismes de protection, le risque lié à la chaîne d’approvisionnement, la gestion des vulnérabilités et les résultats de gouvernance. Il peut demander si l’organisation a identifié les systèmes utilisant une cryptographie à clé publique vulnérable et si la planification de la migration est alignée sur l’orientation de NIST.
Un auditeur COBIT ou ISACA posera souvent des questions de gouvernance. Qui est responsable ? Comment le conseil reçoit-il les rapports ? Les investissements sont-ils priorisés ? Les dépendances fournisseurs sont-elles gérées ? Les bénéfices, les risques et les ressources sont-ils équilibrés ?
Un auditeur protection des données peut chercher à savoir si le chiffrement et la gestion des clés restent adaptés à la sensibilité et à la durée de conservation des données à caractère personnel.
Un examinateur axé sur DORA ou NIS2 examinera la résilience, la concentration des tiers TIC, la continuité opérationnelle et la préparation aux incidents.
| Angle d’audit | Questions probables | Éléments probants à préparer |
|---|---|---|
| ISO/IEC 27001:2022 | Le risque post-quantique est-il intégré au processus de gestion des risques du SMSI ? Les contrôles cryptographiques sont-ils sélectionnés et revus ? | Registre des risques, plan de traitement, Déclaration d’applicabilité, approbations de politiques, résultats d’audit interne |
| NIST | L’organisation a-t-elle inventorié les usages cryptographiques et planifié la migration vers des approches approuvées ? | CBOM, décisions d’architecture, résultats pilotes, backlog de migration |
| COBIT 2019 | La transition cryptographique est-elle gouvernée, financée et surveillée ? | Rapports au conseil, comptes rendus de gouvernance, KPI, tableaux de bord des risques fournisseurs |
| GDPR | La protection cryptographique reste-t-elle appropriée au regard de la sensibilité et de la conservation des données à caractère personnel ? | Classification des données, références DPIA, calendrier de conservation, conception du chiffrement |
| DORA | Les dépendances TIC et fournisseurs sont-elles comprises et résilientes ? | Registre des actifs TIC, attestations fournisseurs, éléments probants de tests, plans de sortie |
| NIS2 | Les mesures de gestion des risques de sécurité et de chaîne d’approvisionnement sont-elles efficaces ? | Revues fournisseurs, procédures d’incident, plans de continuité, enregistrements de traitement des risques |
Zenith Controls recommande de traiter la préparation à l’audit comme un cheminement d’éléments probants. N’attendez pas que les auditeurs demandent des captures d’écran et des feuilles de calcul. Construisez un espace de travail GRC qui relie chaque risque cryptographique à son propriétaire, aux actifs affectés, aux fournisseurs, aux décisions, aux tests, aux exceptions et aux dates de revue.
Mettre à jour les politiques pour rendre le programme opérationnel
La plupart des politiques de cryptographie ont été rédigées pour des exigences traditionnelles de confidentialité et d’intégrité. La migration post-quantique impose des ajouts ciblés.
Votre politique de cryptographie et de gestion des clés doit couvrir les normes approuvées, la fréquence de revue, la classification des données, la durée de protection, l’agilité algorithmique, la génération des clés, le stockage des clés, la rotation des clés, la destruction, la propriété, le cycle de vie des certificats, la responsabilité HSM, la responsabilité KMS cloud, l’approbation des exceptions, la cryptographie contrôlée par les fournisseurs et la surveillance de la transition post-quantique.
Votre politique de développement sécurisé doit couvrir l’approbation des bibliothèques cryptographiques, l’interdiction des algorithmes codés en dur sans revue, le suivi des dépendances, les mécanismes de mise à jour sécurisée, les tests de performance pour des clés ou signatures plus volumineuses, la rétrocompatibilité, le retour arrière et la modélisation des menaces pour les produits à longue durée de vie.
Votre politique de sécurité des fournisseurs doit couvrir la transparence cryptographique, les demandes de feuille de route post-quantique, les obligations contractuelles de notification, la responsabilité partagée pour le chiffrement et la gestion des clés, la planification de sortie et la portabilité.
Votre procédure de gestion des actifs doit couvrir les champs d’inventaire cryptographique, la propriété, les sources d’éléments probants, la fréquence de revue et l’intégration avec la CMDB, l’inventaire cloud, la gestion des certificats, les enregistrements HSM et les référentiels de code.
C’est là que la bibliothèque de politiques Clarysec aide les organisations à accélérer. Plutôt que de partir d’une page blanche, les équipes peuvent adapter des clauses de politiques en procédures, registres, questionnaires et éléments probants d’audit.
Éviter les erreurs les plus fréquentes de migration post-quantique
Les erreurs les plus dangereuses sont généralement des défaillances de gouvernance, et non des défaillances techniques.
Commencer par les algorithmes au lieu des actifs. Si vous ne savez pas où la cryptographie est utilisée, le choix d’algorithmes ne vous aidera pas.
Ignorer la durée de vie des données. Des données transactionnelles à courte durée de vie et des archives sensibles à longue durée de vie n’exposent pas l’organisation au même risque.
Traiter les fournisseurs comme une phase ultérieure. De nombreux contrôles cryptographiques sont gérés par des fournisseurs. Si les fournisseurs ne sont pas intégrés tôt, votre plan peut être irréaliste.
Oublier les signatures. La planification post-quantique ne concerne pas seulement le chiffrement. Les signatures numériques, la signature de code, les certificats, les jetons d’identité, les mises à jour de micrologiciels et la signature de documents nécessitent une attention particulière.
Supposer que les fournisseurs cloud résolvent tout. Les plateformes cloud joueront un rôle majeur, mais la responsabilité reste partagée. Vous devez toujours savoir quels services, configurations, clés, régions et intégrations sont concernés.
Ne pas créer d’éléments probants d’audit. Un plan de migration qui ne peut pas être étayé par des éléments probants ne satisfera ni la direction, ni les régulateurs, ni les clients, ni les auditeurs.
Sauter les tests de performance et d’interopérabilité. Les algorithmes post-quantiques peuvent affecter la taille des charges utiles, le comportement des handshakes, la latence, le stockage, les contraintes embarquées et la compatibilité.
Indicateurs que le RSSI doit présenter au conseil
Le reporting au conseil doit être suffisamment simple pour être compris et suffisamment précis pour déclencher l’action. Évitez les débats approfondis sur les algorithmes. Concentrez-vous sur l’exposition, les progrès, les décisions et le risque résiduel.
| Indicateur | Signification pour le conseil |
|---|---|
| Pourcentage de services critiques disposant d’un inventaire cryptographique achevé | Montre la visibilité |
| Pourcentage de données sensibles à longue durée de vie mises en correspondance avec des contrôles cryptographiques | Montre la préparation face au risque collecter maintenant, déchiffrer plus tard |
| Nombre de fournisseurs critiques ayant fourni une feuille de route post-quantique | Montre la préparation des tiers |
| Nombre d’exceptions cryptographiques à haut risque | Montre l’exposition non maîtrisée |
| Pourcentage d’applications critiques évaluées pour la crypto-agilité | Montre la faisabilité de la migration |
| État d’achèvement du pilote | Montre les progrès concrets |
| Actions de traitement ouvertes en retard | Montre le risque d’exécution |
| Tendance du risque résiduel | Montre si le programme réduit l’exposition |
Un message utile au conseil pourrait être formulé ainsi :
« Nous avons achevé la découverte cryptographique pour 72 % des services critiques. Deux systèmes présentent une exposition critique de confidentialité à longue durée de vie, et trois fournisseurs n’ont pas encore fourni de feuille de route post-quantique. Nous avons lancé un projet de préparation à la signature de code et une revue des dépendances KMS cloud. Aucun remplacement d’urgence n’est recommandé aujourd’hui, mais l’incertitude fournisseur reste le principal risque résiduel. »
C’est le langage du cyber-risque gouverné.
Liste de contrôle pratique pour démarrer cette semaine
Vous n’avez pas besoin d’attendre une certitude parfaite. Commencez par des actions qui améliorent immédiatement la visibilité et la gouvernance.
- Désigner un responsable de la cryptographie post-quantique.
- Ajouter le risque cryptographique lié au quantique au registre des risques du SMSI.
- Identifier les dix principaux services qui traitent des données sensibles à longue durée de vie ou présentent un impact élevé sur l’intégrité.
- Construire une CBOM minimale viable pour ces services.
- Demander aux fournisseurs critiques leur feuille de route post-quantique.
- Revoir les politiques de cryptographie, de développement sécurisé, de fournisseurs et d’actifs.
- Identifier les systèmes comportant des algorithmes codés en dur, des bibliothèques obsolètes, une rotation manuelle des certificats ou une propriété insuffisamment définie.
- Sélectionner un pilote à faible risque pour tester la crypto-agilité.
- Définir les indicateurs destinés au conseil et la fréquence de reporting.
- Planifier un audit interne centré sur la gouvernance de la cryptographie et les éléments probants.
Le mouvement le plus important consiste à transformer l’incertitude en travaux gérés. Le risque quantique est peut-être tourné vers l’avenir, mais la dette cryptographique existe aujourd’hui.
Prochaines étapes avec Clarysec
La migration post-quantique sera l’une des transitions de sécurité les plus complexes de la prochaine décennie, car elle touche à l’identité, au chiffrement, aux signatures, aux fournisseurs, au cloud, aux logiciels, aux équipements, aux archives et aux éléments probants d’audit. Les organisations qui commencent par la gouvernance et l’inventaire avanceront plus vite que celles qui attendent un cycle de remplacement de dernière minute.
Clarysec peut vous aider à construire un plan de migration cryptographique adapté au risque quantique au moyen de :
- Zenith Blueprint : feuille de route en 30 étapes pour les auditeurs pour une mise en œuvre par phases et la préparation à l’audit
- Zenith Controls : guide de correspondance inter-conformité pour la cartographie ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA et NIS2
- Politique de cryptographie et de gestion des clés pour des règles cryptographiques prêtes pour la gouvernance
- Politique de sécurité des tiers et des fournisseurs pour les exigences de feuille de route fournisseur et d’assurance
- Politique de développement sécurisé pour les pratiques d’ingénierie crypto-agiles
Le meilleur moment pour commencer la planification post-quantique est avant qu’un régulateur, un auditeur, un client ou un membre du conseil ne demande des éléments probants. Commencez par l’inventaire, reliez-le au risque et construisez la trajectoire de migration, une décision maîtrisée à la fois.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


