Constituer un inventaire cryptographique : données à relever, méthodes de découverte comparées, certificats, CBOM, priorisation et plan sur 90 jours.
Un inventaire cryptographique est un registre tenu à jour de tous les endroits où votre organisation utilise la cryptographie : quels algorithmes, tailles de clés, certificats, clés, bibliothèques et protocoles sont utilisés, sur quels systèmes, pour protéger quelles données, et sous la responsabilité de qui. Il se construit par la découverte cryptographique (analyse des réseaux, des hôtes, des magasins de clés, des gestionnaires de clés, du code et des sources de certificats) et constitue la première étape de tout programme de migration post-quantique, car on ne peut pas remplacer RSA ou ECC là où l'on ignore qu'ils sont utilisés.
La plupart des organisations pensent déjà savoir où se trouve leur cryptographie : les répartiteurs de charge, la PKI, le HSM. La découverte montre généralement le contraire. Des certificats dorment dans des keystores Java sans propriétaire, des applications figent des bibliothèques qui négocient d'anciennes suites de chiffrement, des clés de KMS cloud ont été créées par des équipes qui ont depuis changé de poste, et des appliances de fournisseurs embarquent une cryptographie qu'aucun scanner ne voit. Les régulateurs l'ont remarqué : le gouvernement fédéral américain exige un inventaire cryptographique priorisé depuis 2023, et les autorités de surveillance européennes et suisses l'attendent désormais dans le cadre de la gestion du risque quantique.
Ce guide explique quoi inventorier, compare les méthodes de découverte et leurs angles morts, traite spécifiquement de la découverte des certificats, montre comment un inventaire devient un CBOM et se termine par un plan à 90 jours que vous pouvez lancer dès ce trimestre.
Le problème métier est simple à énoncer. Un ordinateur quantique cryptographiquement pertinent casserait les algorithmes à clé publique (RSA, ECDH, ECDSA) qui protègent l'échange de clés et les signatures presque partout. Les remplacer est un programme d'ingénierie de plusieurs années, et les données enregistrées aujourd'hui peuvent être déchiffrées plus tard. Vous ne pouvez ni budgéter, ni séquencer, ni démontrer ce programme sans savoir où ces algorithmes sont utilisés. C'est pourquoi les principaux cadres publics placent l'inventaire en premier.
Le mémorandum de l'OMB M-23-02, « Migrating to Post-Quantum Cryptography » (18 novembre 2022) demande aux agences fédérales de soumettre à l'ONCD et à la CISA, au plus tard le 4 mai 2023 puis chaque année jusqu'en 2035, un inventaire priorisé des systèmes d'information et des actifs contenant des systèmes cryptographiques vulnérables à un CRQC. Le périmètre se concentre sur les systèmes à fort impact, les High Value Assets, les systèmes dont les données devraient rester sensibles pour la mission en 2035 et le contrôle d'accès fondé sur une PKI. Pour chaque système, les agences doivent notamment consigner l'algorithme cryptographique utilisé, le service qu'il fournit, la longueur de clé, l'éditeur du logiciel, le système d'exploitation et sa version, le modèle d'hébergement et la durée pendant laquelle les données doivent être protégées (« time to live »).
Cette liste de champs constitue un bon modèle pour toute organisation, réglementée ou non. Le mémo considère aussi qu'un système cryptographique est « activement utilisé » s'il peut être employé, même uniquement pour des clients anciens, ce qui correspond exactement au type de configuration de repli que la découverte fait apparaître. Notre aperçu de la réglementation post-quantique américaine couvre le calendrier fédéral plus large.
La fiche conjointe « Quantum-Readiness: Migration to Post-Quantum Cryptography » (CISA, NSA, NIST, août 2023) invite les organisations à commencer par des « activités proactives de découverte cryptographique » et à utiliser des outils de découverte pour trouver les algorithmes vulnérables au quantique à trois endroits :
Elle ajoute deux points importants pour le cadrage. Les outils de découverte peuvent ne pas voir la cryptographie embarquée dans les produits : il faut donc demander aux fournisseurs la liste de la cryptographie embarquée. Et l'inventaire doit être corrélé avec les inventaires existants d'actifs, d'identités (ICAM/IdAM), d'EDR et de CDM, et indiquer pendant combien de temps les jeux de données les plus sensibles doivent être protégés.
Le projet « Migration to Post-Quantum Cryptography » du National Cybersecurity Center of Excellence du NIST est documenté dans la NIST SP 1800-38. Le volume B, « Quantum Readiness: Cryptographic Discovery », décrit un plan de tests fonctionnels pour les outils de découverte, une approche de la découverte que la plupart des organisations peuvent lancer dès maintenant et une architecture de laboratoire intégrant les outils de découverte fournis par les contributeurs. Les dernières versions que nous avons pu vérifier sur csrc.nist.gov sont des projets préliminaires (volume A d'avril 2023 ; volumes B et C de décembre 2023) : considérez-la donc comme un guide pratique plutôt que comme une norme définitive.
En Suisse, la communication FINMA 05/2026 attend des établissements surveillés qu'ils tiennent un inventaire cryptographique mis à jour en continu et une feuille de route PQC approuvée par le conseil d'administration ; voir notre guide de la feuille de route post-quantique FINMA 05/2026. Pour les entités financières et les entités essentielles de l'UE, voir les exigences de chiffrement de DORA et les exigences de crypto-agilité de NIS2.
Un inventaire cryptographique utile n'est pas une liste de certificats. Il couvre tous les types d'actifs qui portent ou exécutent de la cryptographie, et consigne suffisamment de contexte pour prendre une décision de migration.
| Type d'actif | Où il se cache | Quoi enregistrer |
|---|---|---|
| Certificats TLS/X.509 | Répartiteurs de charge, serveurs web, passerelles API, secrets Kubernetes, magasins de certificats Windows, fichiers PEM, appliances | Sujet/SAN, émetteur, algorithme de signature, algorithme et taille de clé, expiration, propriétaire, endpoints servis, risque quantique |
| Clés privées et keystores | Fichiers PEM/DER, PKCS#12/PFX, JKS/JCEKS, TPM, répertoires de configuration applicative | Algorithme, taille de clé, format, emplacement, protection (fichier, HSM, KMS), propriétaire, certificat associé |
| Clés KMS et HSM | KMS cloud (AWS, Azure, GCP), HSM sur site, vaults | ID de clé, algorithme, taille, usage (chiffrement, signature, encapsulation), politique de rotation, données protégées, propriétaire |
| Protocoles et suites de chiffrement | Endpoints TLS, VPN IPsec/IKEv2, SSH, service mesh interne | Version du protocole, groupe d'échange de clés, suite de chiffrement, proposition ou non d'un échange de clés PQC ou hybride |
| Bibliothèques et usages dans le code | OpenSSL, BoringSSL, Java JCA/JCE, .NET, Go crypto, bibliothèques embarquées, dépendances CI/CD | Bibliothèque et version, algorithmes appelés, paramètres codés en dur, application propriétaire |
| Infrastructure de signature | Signature de code, signature des mises à jour de firmware et de logiciels, signature de documents, AC internes | Algorithme, taille de clé, validité, emplacement de la clé, artefacts qui en dépendent |
| Cryptographie embarquée et des fournisseurs | Appliances réseau, équipements OT, SaaS, logiciels COTS | Déclaration du fournisseur sur les algorithmes, feuille de route PQC, date de renouvellement du contrat |
| Données au repos | Bases de données, sauvegardes, chiffrement du stockage, archives | Algorithme, référence de clé, classification des données, durée de protection requise |
Pour chaque entrée, les champs minimaux sont : algorithme, taille de clé, propriétaire, date d'expiration ou de rotation, bibliothèque ou produit, protocole, données protégées et une évaluation du risque quantique. L'algorithme et la taille de clé indiquent si l'actif est vulnérable au quantique ; le propriétaire indique qui doit corriger ; la durée de vie des données indique l'urgence.
Aucune technique ne trouve tout à elle seule. Chaque méthode voit une couche différente, et les lacunes sont prévisibles.
| Méthode | Ce qu'elle trouve | Points forts | Angles morts |
|---|---|---|---|
| Analyse réseau/TLS passive ou active | Certificats, versions de protocole, suites de chiffrement et groupes d'échange de clés sur les endpoints joignables | Rapide, sans agent, couvre d'abord la surface d'attaque externe | Ne voit que ce qui est négocié sur le réseau ; manque les données au repos, les bibliothèques internes, les segments injoignables |
| Analyse des hôtes et des systèmes de fichiers | Fichiers de certificats et de clés, keystores, magasins de certificats du système d'exploitation | Trouve les clés et certificats orphelins que personne n'a enregistrés | Nécessite un agent ou des identifiants par hôte ; ne montre pas quel code utilise la clé |
| API des keystores, HSM et KMS | Clés gérées avec algorithme, taille, usage et métadonnées | Fait autorité pour les clés gérées ; peu de bruit | Ne couvre que les clés créées dans des systèmes gérés ; les clés fantômes restent invisibles |
| Analyse du code, des SBOM et des bibliothèques | Appels d'API cryptographiques, bibliothèques et versions, algorithmes codés en dur | Trouve la cryptographie avant la mise en production ; s'intègre au CI/CD | L'analyse statique peut sur- ou sous-déclarer ; la configuration à l'exécution peut différer |
| Exports d'AC et journaux Certificate Transparency | Certificats émis par vos AC ou pour vos domaines | Complet pour les certificats de confiance publique ; aucun accès aux systèmes requis | CT ne couvre que les certificats journalisés publiquement ; la couverture des AC privées dépend de la qualité des exports |
| Questionnaires fournisseurs | Cryptographie embarquée dans les produits et services | Seul moyen d'accéder aux produits fermés | Auto-déclaratif ; nécessite un suivi au renouvellement du contrat |
La réponse pratique consiste à les combiner : l'analyse réseau pour l'exposition, l'analyse des hôtes et des keystores pour ce qui se trouve sur disque, les API KMS/HSM pour les clés gérées, l'analyse du code pour ce que vos développeurs construisent, et le dialogue avec les fournisseurs pour ce que vous ne pouvez pas analyser. Ensuite, dédoublonnez : le même certificat vu sur un répartiteur de charge, dans un fichier PFX et dans un journal CT est un seul actif avec trois emplacements.
Les certificats constituent généralement la partie la plus volumineuse et la plus changeante de l'inventaire, et un outil de découverte des certificats est souvent le point de départ des équipes. Quatre sources combinées offrent une bonne couverture :
Rapprochez les quatre : un certificat présent dans CT mais pas sur le réseau peut être inutilisé (ou déployé quelque part que vous n'analysez pas) ; un certificat présent sur le réseau mais dans aucun export d'AC n'est pas géré. Les deux méritent un ticket. Une fois trouvés, les certificats doivent relever de la gestion du cycle de vie ; voir la gestion des certificats DuoKey.
Un inventaire cryptographique est le jeu de données de travail ; un CBOM (Cryptography Bill of Materials) en est un export normalisé et lisible par machine. CycloneDX a ajouté la prise en charge du CBOM dans la version 1.6, publiée par l'OWASP le 9 avril 2024 et décrite dans l'annonce comme « un cadre structuré pour inventorier les actifs cryptographiques ». La différence compte en pratique. Votre inventaire peut contenir les propriétaires, les tickets, les décisions de risque et le contexte métier. Le CBOM est ce que vous échangez avec les auditeurs, les outils de gestion des vulnérabilités et les fournisseurs, et ce que vous comparez d'une version à l'autre. Notre guide CBOM pour DuoKey Cockpit explique pas à pas comment en générer et en lire un ; nous ne le répétons donc pas ici.
Une première campagne de découverte renvoie généralement des milliers de résultats. Classez-les selon deux axes :
| Durée de vie courte des données | Durée de vie longue des données | |
|---|---|---|
| Exposition élevée (Internet, partenaires) | Planifier la migration ; surveiller la durée de vie des certificats | Priorité maximale : échange de clés hybride ou PQC en premier |
| Exposition faible (interne) | Migrer au rythme des cycles de renouvellement habituels | Planifier tôt ; vérifier les sauvegardes et les archives |
Les signatures obéissent à une autre logique : elles ne peuvent pas être falsifiées rétroactivement, si bien que la priorité va aux ancres de confiance à longue durée de vie, comme les AC racines, les clés de signature de firmware et de code, dont le remplacement prend le plus de temps. Notre guide de feuille de route de migration PQC montre comment transformer ce classement en un plan séquencé.
Un inventaire ponctuel est obsolète en quelques semaines : les certificats se renouvellent, de nouveaux services sont mis en production, les équipes cloud créent des clés, les fournisseurs livrent des mises à jour. Un projet ponctuel reste un moyen valable de produire la première base de référence et la première déclaration réglementaire, mais il doit ensuite laisser la place à un processus continu :
Cette boucle continue est ce que le marché appelle la gestion de la posture cryptographique (cryptographic posture management) : découvrir, évaluer, planifier et corriger, puis découvrir à nouveau.
Jours 1 à 30 : périmètre et base de référence
Jours 31 à 60 : passer à l'intérieur
Jours 61 à 90 : décider et opérationnaliser
Le PQC Scanner de DuoKey est le moteur de découverte de la gestion de la posture cryptographique (CPM) DuoKey. Selon la documentation DuoKey, il découvre :
Les résultats sont classés de P1 à P4 selon l'algorithme (RSA, DSA, 3DES, RC4, ECDSA P-256 et EdDSA sont signalés ; ML-KEM, ML-DSA et SLH-DSA sont en P4, à titre informatif). Chaque analyse produit un Quantum Readiness Score (QRS) de 0 à 100 et un CBOM, avec des références de conformité à CNSA 2.0 et BSI TR-02102, ainsi qu'une intégration ServiceNow pour suivre les travaux de migration.
DuoKey CPM exécute ce processus en boucle continue (découvrir, évaluer, simuler, corriger) avec un CBOM vivant, des alertes de dérive, des rapports de simulation, des pull requests de remédiation rédigées par un agent et approuvées par un humain, une synchronisation ServiceNow et une mise en correspondance réglementaire avec DORA, NIS2, FINMA 05/2026, NIST IR 8547 et CNSA 2.0.
Pour une première vue avant d'accorder le moindre accès, commencez par le Quantum Risk Score gratuit, qui ne nécessite aucun accès aux systèmes internes. Le scanner et la CPM fonctionnent sur la plateforme DuoKey Cockpit ; pour tout ce qui dépasse ce qui est décrit ici, contactez DuoKey.
Q: Qu'est-ce qu'un inventaire cryptographique ?
Un inventaire cryptographique est un registre tenu à jour de toute la cryptographie utilisée dans une organisation : algorithmes, tailles de clés, certificats, clés, bibliothèques et protocoles, avec leur emplacement, leur propriétaire, leur date d'expiration et les données qu'ils protègent. Il sert de base pour évaluer le risque quantique et planifier une migration post-quantique.
Q: Qu'est-ce que la découverte cryptographique ?
La découverte cryptographique est le processus qui consiste à trouver automatiquement la cryptographie, en analysant les réseaux et les endpoints TLS, les hôtes et les keystores, les API KMS et HSM, le code source et les dépendances, ainsi que les sources de certificats comme les journaux CT et les exports d'AC. Ses résultats alimentent l'inventaire cryptographique.
Q: Comment trouver tous les certificats de mon réseau ?
Combinez quatre sources : les journaux Certificate Transparency pour les certificats de confiance publique émis pour vos domaines, les analyses réseau de vos plages IP et de vos noms DNS, les exports de vos AC internes et les analyses d'hôtes portant sur les keystores et les fichiers de certificats. Rapprochez-les ensuite, car chaque source manque des certificats que les autres trouvent.
Q: Quelle est la différence entre un inventaire cryptographique et un CBOM ?
L'inventaire est votre jeu de données de travail, qui comprend les propriétaires, les décisions de risque et l'état de la remédiation. Un CBOM est un export normalisé et lisible par machine des actifs cryptographiques, défini dans CycloneDX depuis la version 1.6, qui sert à partager l'inventaire avec des outils, des auditeurs et des fournisseurs et à le comparer dans le temps.
Q: Un inventaire cryptographique est-il exigé par la réglementation ?
Au sein du gouvernement fédéral américain, oui : l'OMB M-23-02 impose aux agences de soumettre chaque année un inventaire priorisé, du 4 mai 2023 jusqu'en 2035. En Suisse, la communication FINMA 05/2026 attend des établissements surveillés qu'ils en tiennent un. Dans l'UE, les obligations de DORA et de NIS2 en matière de cryptographie et de gestion des actifs font de l'inventaire le moyen pratique de démontrer la conformité.
Q: Quels algorithmes sont considérés comme une cryptographie vulnérable au quantique ?
Les algorithmes à clé publique fondés sur la factorisation ou le logarithme discret : RSA, Diffie-Hellman, ECDH, ECDSA et DSA. L'OMB M-23-02 les énumère et demande aux agences d'inclure tout algorithme asymétrique dont la résistance au quantique n'est pas établie de manière définitive. Les algorithmes post-quantiques tels que ML-KEM, ML-DSA et SLH-DSA sont leurs remplaçants.
Q: Un scanner peut-il trouver automatiquement toute la cryptographie ?
Non. Les scanners manquent la cryptographie embarquée dans les produits fermés et les appliances, et chaque méthode ne voit que sa propre couche. La fiche de la CISA, de la NSA et du NIST recommande de demander aux fournisseurs la liste de la cryptographie embarquée pour combler cette lacune.
Q: À quelle fréquence faut-il mettre à jour un inventaire cryptographique ?
En continu, ou au minimum à chaque changement significatif. Des certificats se renouvellent, des clés sont créées et des services sont mis en production chaque semaine : un inventaire ponctuel devient donc rapidement obsolète. Utilisez des analyses planifiées et déclenchées par le CI/CD, des alertes de dérive et des exports CBOM périodiques.
Un inventaire cryptographique transforme le risque quantique, d'avertissement abstrait, en une liste d'actifs avec des propriétaires et des échéances. Construisez-le à partir de plusieurs méthodes de découverte, consignez le contexte qui guide les décisions, exportez-le sous forme de CBOM et maintenez-le en fonctionnement.
Écrit par
DuoKey Team
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
