Menaces quantiques : une nouvelle ère pour la cryptographie industrielle 

L’informatique quantique représente une menace pour les algorithmes cryptographiques classiques qui garantissent l’intégrité, l’authenticité et la confidentialité des communications, y compris celles des systèmes OT et des produits. Même si le “Q-Day” (le jour où les ordinateurs quantiques casseront la cryptographie actuelle) est encore à quelques années devant nous, le risque est déjà là : les attaquants peuvent d’ores et déjà procéder à des attaques de type « Harvest Now, Decrypt Later », stockant des données chiffrées aujourd’hui pour les déchiffrer dès que les algorithmes cryptographiques actuels seront brisés. Mais un autre risque, tout aussi critique, se profile : « Trust Now, Forge Later ». Les signatures numériques ou certificats jugés fiables aujourd’hui pourront être falsifiés demain, rendant possible l’installation transparente de logiciels malveillants ou encore la compromission de chaînes d’approvisionnement. Contrairement à la fuite progressive de données, cette attaque provoque une rupture immédiate de la confiance et de l’intégrité, avec des impacts massifs sur les environnements industriels et les produits connectés. Avec la feuille de route européenne jalonnant 2026, 2030 et 2035, la question réside dans l’ordonnancement de la transition.  

Dans l’industrie, où les équipements vivent plusieurs décennies, c’est un enjeu majeur. 

L’industrie est particulièrement touchée : les environnements OT et les produits embarqués reposent sur des usages cryptographiques critiques qui seront directement impactés par l’arrivée des algorithmes post-quantiques. 

Plusieurs cas d’usages industriels et produits prioritaires identifiés : 

• Administration sécurisée des systèmes OT et produits : garantir l’intégrité et la confidentialité des opérations. 
• Signature numérique et intégrité des firmwares : garantir la fiabilité des mises à jour logicielles (secure boot, code signing, X.509…).
• Accès distants sécurisés aux actifs industriels et produits : protéger les connexions VPN, SSH, RDP, et autres protocoles contre les attaques futures.
• Échanges de données IT/OT : sécuriser les flux entre les systèmes d’information et les environnements industriels (TLS, MQTTS, HTTPS…). 
• Confidentialité des données des processus industriels : préserver la confidentialité des données sensibles en transit ou au repos.
• Journalisation et historisation sécurisées : assurer la traçabilité et l’intégrité des logs et historiques critiques.

PQC pour l’OT & Produit : intégrer les  contraintes, préserver la crypto-agilité 

Contexte OT & Produit : des contraintes spécifiques 

Les systèmes OT et produits n’ont jamais été conçus pour la crypto-agilité. De nombreux protocoles industriels comme DNP3, Modbus ou MQTT ne sont pas chiffrés aujourd’hui car l’architecture OT repose historiquement davantage sur l’isolement réseau que sur la cryptographie, alors il n’y a pas de raison de penser qu’ils seraient tous chiffrés demain avec des algorithmes postquantiques.

Néanmoins, les communications chiffrées subiront cette rupture cryptographique.

Dans un second temps, beaucoup d’équipements OT présentent des contraintes matérielles importantes (processeur, mémoire, capacité de stockage) et disposent d’une durée de vie très longue, souvent entre 10 et 30 ans. Ces caractéristiques rendent les mises à jour difficiles et coûteuses : les mécanismes de mise à jour sécurisée à distance restent rares, et la signature des firmwares n’est pas systématiquement implémentée, ce qui est dans les faits une mauvaise pratique.

Ces contraintes expliquent pourquoi les environnements OT ne peuvent pas intégrer de nouvelles primitives cryptographiques au même rythme que l’IT, et pourquoi la PQC n’est pas encore prise en compte nativement.

Néanmoins, même si les produits et systèmes OT actuels ne sont pas conçus pour la cryptographie post-quantique, l’émergence des standards PQC, l’évolution des obligations réglementaires et la montée des risques liés au quantique rendent cette transition incontournable à moyen terme. 

Rendre la crypto-agilité opérationnelle pour l’industrie et les produits 

Le cadrage du projet PQC pour les Produits et l’OT peut s’axer en 4 volets principaux :

1. Réaliser l’inventaire cryptographique et prioriser les actifs critiques

Initier dès maintenant le dialogue avec vos fournisseurs de socles crypto (PKI, KMS, HSM) pour anticiper la migration.

2. Concevoir et déployer des architectures crypto-agiles

S’appuyer exclusivement sur les algorithmes standardisés par le NIST (ex : ML-KEM, ML-DSA, SLH-DSA), et proscrire tout développement interne ou adoption de librairies non standards pour les composants cryptographiques en privilégiant des solutions éprouvées et validées.

Concevoir des architectures crypto‑agiles implique de prendre en compte la dimension embarquée et ses contraintes (mémoire limitée, circuits imprimés, ressources énergétiques).  L’implémentation des algorithmes PQC sur ces systèmes reste incertaine. Toutefois, des algorithmes optimisés pour l’embarqué émergent et ouvrent la voie à une adoption réaliste.

3. Migrer progressivement via l’hybridation et l’itération

La transition vers la cryptographie post-quantique ne peut pas être pensée comme un projet ponctuel ou une migration « One Shot ». Il s’agit d’un processus itératif, à piloter dans la durée, en commençant par l’hybridation des algorithmes : c’est la stratégie explicitement recommandée par l’ANSSI et la Commission européenne.

La crypto-agilité n’est pas une option, mais une nécessité pour garantir la résilience, la conformité de vos environnements industriels et produits face à la menace quantique. Elle s’appuie sur une démarche structurée, pilotée par l’inventaire, l’architecture, la migration hybride et la gouvernance.

Retours terrain & cas d’usage concrets : des acteurs à des stades différents 

Notre expérience terrain révèle un écart de maturité saisissant entre deux profils d’acteurs industriels face à la cryptographie post-quantique : 

1. Les industriels avec une compréhension encore embryonnaire 

• Constat : Dans de nombreux environnements industriels, la PQC reste un concept abstrait, souvent perçu comme lointain ou réservé aux experts. 
• Symptômes :  
  • Les équipes opérationnelles et métiers ne sont pas impliquées dans les réflexions stratégiques sur la cryptographie. 
  • Les roadmaps actuelles manquent de maturité et de clarté, les chantiers sous-jacents sont souvent sous-estimés quant à leur coût. La priorité reste la continuité de service, la sécurité quantique étant reléguée au second plan. 
  • Les notions de HNDL & TNFL sont peu comprises, voire ignorées. 
• Risques :  
  • Perturbation de la production et fuite de données de processus industriels :  des communications vulnérables entre équipements critiques, basées sur des algorithmes obsolètes, exposent les données sensibles et peuvent entraîner des interruptions ou des perturbations majeures dans les opérations industrielles (perte d’intégrité des données).
  • Indisponibilité de production liée à une migration brutale : Une transition forcée vers la cryptographie post‑quantique, sans préparation ni crypto‑agilité, peut provoquer des arrêts de production, des surcoûts importants et des impacts sévères sur la continuité opérationnelle. 

 2. Les fournisseurs de produits : des pionniers déjà en phase d’industrialisation 

• Constat : À l’opposé, certains fournisseurs de produits (notamment dans l’automobile, ou les objets connectés) ont pris une longueur d’avance. 
• Symptômes :  
  • Les chantiers PQC sont priorisés sur les cas d’usage critiques : signature de firmware et mises à jour (OTA), gestion des identités d’équipements, sécurisation des accès distants, etc. 
  • Des pilotes sont lancés sur des lignes de produits ou des environnements représentatifs, avec des retours d’expérience concrets sur la performance, la compatibilité et la robustesse des solutions hybrides. 
  • La démarche s’industrialise : intégration de clauses PQC dans les contrats fournisseurs, automatisation de l’inventaire cryptographique CBOM, montée en compétence des équipes, et gouvernance dédiée. 

Conclusion & Roadmap : Passez à l’action pour bâtir un futur “quantum-safe” 

La menace quantique n’est plus une perspective lointaine : elle impose dès aujourd’hui une transformation profonde de la cybersécurité industrielle et produit.

1. Anticipez pour protéger l’avenir

Démystifiez les concepts quantiques et intégrez-les dès maintenant dans vos processus de cybersécurité, que ce soit pour vos produits, vos environnements OT ou vos systèmes IT. L’anticipation est la clé pour éviter la rupture.

2. Faites de la crypto-agilité une vision stratégique

Ne la considérez plus comme un simple projet technique, mais comme un pilier de votre résilience et de votre souveraineté numérique. Construisez une feuille de route claire, avec des jalons à court, moyen et long terme.

3. Appuyez-vous sur des partenaires de confiance

Le marché est prêt : des experts et des solutions existent pour vous accompagner dans la modernisation et la sécurisation de vos infrastructures critiques. Ne restez pas isolés face à la complexité.

4. Industrialisez la démarche

Passez du pilote à la généralisation : 

• Mettre en place une stratégie PQC pour cartographier, prioriser et piloter la migration des usages critiques (inclure des clauses PQC dans les contrats).
• Lancer un programme de transition pour moderniser les socles de confiance (PKI, CLM, HSM), automatiser l’inventaire et assurer la continuité des opérations.
• S’appuyer sur les retours d’expérience des pairs et des secteurs déjà engagés dans la PQC.

Le risque quantique est déjà là : chiffrement asymétrique fragilisé, signatures et données exposées.  

Comme mentionné précédemment, nous partons du constat que Les éléments qui ne sont pas chiffrés aujourd’hui dans l’environnement OT, n’ont pas vocation à être chiffrés demain avec des algorithmes postquantiques, car les mesures existantes assurent déjà un niveau de risque jugé acceptable.

Autrement dit, la PQC ne vise pas à transformer l’ensemble de l’OT, mais à protéger les usages qui reposent réellement sur des mécanismes cryptographiques exposés au risque quantique.

Pour autant, ce constat ne réduit pas l’importance de la préparation.

Les deux priorités restent les suivantes :  

• Migrer vos actifs critiques avant 2030 et agir dès aujourd’hui pour protéger la confidentialité des données.  
• Définir votre périmètre, et bâtir votre plan d’action, et surtout engager une démarche de migration dès aujourd’hui. 

Cet article La cryptographie post-quantique pour les produits et l’OT : de la tendance à la réalité industrielle est apparu en premier sur RiskInsight.

RSSI, DSI et équipes DevSecOps s’interrogent tous sur la manière de le mettre en pratique et de l’exploiter.

Qu’est-ce que le SBOM et dans quel contexte intervient-il ?

Le SBOM (Software Bill of Materials) est un inventaire formel, généralement au format Xlsx, JSON, XML ou texte brut, qui est conçu pour être lu par des machines. Il contient des informations détaillées sur les composants logiciels d’un système, y compris leurs dépendances, leurs attributs et leurs relations hiérarchiques. L’objectif principal d’un SBOM est de fournir une vue complète et à jour de tous les éléments logiciels qui composent une application ou un système. (source : NTIA-Software-Bill-Of-Materials)

À l’instar d’un produit physique, un logiciel est un ensemble complexe composé de divers éléments. Il comprend du code développé en interne, des composants tiers (qu’il s’agisse de bibliothèques open source ou de modules soumis à différentes licences) ainsi que l’ensemble des outils nécessaires à l’assemblage du produit final.

Or, à chaque nouvelle vulnérabilité découverte par des chercheurs ou exploitée par des hackers, les fournisseurs et acheteurs, se retrouvent confrontés à une question cruciale : où se situent les éventuelles vulnérabilités critiques au sein de leur produit ?

Aujourd’hui, l’analyse de Wavestone atteste de manière formelle que le SBOM est indéniablement un élément essentiel pour résoudre cette problématique.

Méthodes de génération du SBOM

Une analyse technique approfondie des outils disponibles sur le marché a révélé les méthodes de génération des SBOMs (Software Bill of Materials).

Trois sources principales émergent pour créer un SBOM à partir d’un logiciel :

• Code Binaire (compilé)
• Code source du projet
• Conteneur d’image, généré par des plates-formes telles que Docker.

Ces trois sources ont la capacité de produire un fichier conforme aux standards établis, notamment SPDX et CycloneDX. Cependant, il est essentiel de noter que tous les outils ne prennent pas en charge ces trois entrées de manière uniforme.

Le défi technique réside, par exemple, dans la décompilation du code binaire, qui peut parfois entraver son intégration. Dans de tels cas, la recherche d’indicateurs spécifiques préalablement définis au sein du code s’avère être une méthode efficace pour identifier la majeure partie des interdépendances hiérarchiques dans un format approprié.

Types d’entrées pour la génération d’un SBOM

Malgré ces techniques d’extraction et d’analyse de code, l’exhaustivité des données n’est pas pour autant garantie et une vérification additionnelle doit être considérée.

Une génération facilitée mais une exploitation qui reste à déterminer et pose encore de nombreuses questions

La création d’un SBOM, s’est considérablement simplifiée grâce à la présence d’acteurs majeurs spécialisés sur le marché, tels que Dependency Track, Adolus ou encore Fossa, pour n’en nommer que quelques-uns. De plus, les outils d’Analyse de Composition Logicielle SCA, bien établis au sein des équipes de développement de nos clients offrent désormais la possibilité de générer et de lire un SBOM.

Sa génération n’est aujourd’hui plus un défi majeur, en raison de la mise en œuvre des standards énumérés plus haut. Ils facilitent la génération automatisée du SBOM en fournissant des directives claires sur la manière dont les informations sur les composants doivent être structurées et présentées.

Cependant, les systèmes conçus pour l’analyser ne sont pas encore pleinement matures. Par exemple. Les entreprises qui reçoivent ces inventaires se trouvent souvent confrontés à des questions sur la manière de les utiliser et de les partager avec d’autres parties. Par ailleurs, à cette problématique technique s’additionne des problématiques organisationnelles car le cadre d’utilisation entre organisations n’est pas encore clairement défini.

Néanmoins, des acteurs travaillent activement à mettre en place une architecture d’intégration sécurisée de ces SBOM au sein de leurs pipelines CI/CD. Actuellement, la récupération fiable du SBOM d’un tiers reste un défi. Les préoccupations sur l’échange et le partage émergent dès que l’on aborde ce sujet. La diversité des contrats avec les fournisseurs, qui souhaitent protéger leur propriété intellectuelle, et la difficulté de centralisation posent des défis au contenu de ce type d’inventaire. Chaque inventaire est élaboré de manière hétérogène, sans suivi ni cadre réglementaire uniforme imposé. D’un point de vue technique, chaque entité a la liberté de remonter les informations de son choix.

A date, nous constatons que les pionniers dans le domaine, optent pour la génération interne de leurs SBOM, y compris sur les logiciels tiers. Cette approche offre davantage de contrôle sur la qualité et la spécificité des données, soulignant la nécessité d’une réglementation plus détaillée et de normes plus strictes pour assurer la fiabilité des échanges d’inventaires logiciels.  

Le SBOM intégré au cœur de vos processus logiciels

Toutes ces lacunes ont incité à concevoir un processus optimal à l’état théorique pour le moment, afin d’intégrer un SBOM au sein d’un pipeline CI/CD, processus pouvant être décomposé en quelques étapes.

1. Création d’un espace de génération et de collecte du SBOM, en Automatisant la collecte de ces données pour garantir leur précision et leur exhaustivité ;
2. Stockage des SBOM dans un Répertoire, en Configurant un référentiel centralisé pour stocker tous les SBOM générés. Il peut s’agir d’un référentiel de gestion de versions ou d’un système de stockage de données adapté ;
3. Distribution d’un Paquet SBOM sur Demande d’un Client, en s’assurant que les SBOM sont facilement accessibles et que les clients peuvent les récupérer de manière sécurisée.

Projection sur l’intégration d’un SBOM au sein d’une chaîne d’approvisionnement logiciel

Cette prospective théorique ouvre la voie à une automatisation du processus de génération, stockage et diffusion des inventaires et rapports de vulnérabilité.

Cela offrira aux parties prenantes la capacité de :

• Recevoir en temps réel des SBOM et des rapports de vulnérabilité ;
• Authentifier la légitimité des artefacts reçus (conteneurs d’images, documents, etc..) ;
• Etablir une confiance et une validation par le bais de la transparence au cœur du processus de production logicielle.

Un futur radieux pour le SBOM ?

 Les instances politiques prennent conscience du niveau d’impréparation de leurs infrastructures face à la montée en puissance des cyberattaques. Dans ce contexte, le SBOM est de plus en plus considéré comme un moyen efficace d’accroître la réactivité en matière de vulnérabilités susceptibles d’affecter un grand nombre d’entreprises de manière concomitante.

Même si le marché n’est pas encore tout à fait prêt pour une transition vers une utilisation généralisée de cette solution, il est courant que la réglementation, même si elle peut sembler arbitraire, influence profondément la trajectoire dans une nouvelle direction.

Il est probable que l’Europe finira par converger vers la réglementation établie aux États-Unis, même si celle-ci semble encore être à un stade préliminaire et incomplet, en particulier en ce qui concerne les mécanismes de partage et d’échange de ces inventaires.

Dans le contexte actuel, les acteurs concernés se voient contraints de réévaluer leurs critères de priorité. Il sera important de disposer des données sur la composition des logiciels, l’origine de ses composants, leur provenance, les vulnérabilités connues, et d’avoir confiance dans le processus de production et de contrôle de qualité.

Cependant, il est nécessaire de remettre à l’ordre du jour la série de défis auxquels ils se confrontent plus généralement :

• Données lacunaires ou incomplètes, l’absence de données exhaustives sur la composition des logiciels peut rendre difficile l’évaluation des risques.
• Approches ad hoc pour le partage de données, les méthodes non standardisées et les approches improvisées pour le partage d’informations peuvent rendre la communication inefficace et peu fiable.
• Coûts additionnels pour la collecte et la maintenance des données, la collecte, la vérification et la mise à jour des informations sur la composition des logiciels peuvent engendrer des surcoûts ;
• Absence de standardisation, le manque de normes dans la collecte et le partage des données rend difficile la comparaison et l’analyse des informations entre les différentes parties prenantes ;
• Gouvernance et confidentialité des données, La gestion des données sensibles sur la composition des logiciels soulève des préoccupations quant à leur confidentialité, intégrité et disponibilité

Cet article Pourquoi le SBOM est considéré comme un allié indispensable de la sécurité de vos produits ? est apparu en premier sur RiskInsight.