NIS2 et CRA : deux textes, deux logiques

La distinction mérite d’être posée clairement. Le CRA se concentre sur la sécurité du produit mis sur le marché. L’objectif est d’éviter que des équipements ou logiciels insuffisamment sécurisés deviennent des portes d’entrée récurrentes. Cela complète des textes comme NIS2, qui portent davantage sur l’organisation et la sécurité des entités, et non sur la conformité intrinsèque d’un produit commercialisé. Dit autrement : NIS2 vous demande ce que vous faites pour vous protéger en tant qu’organisation. Le CRA demande à ceux qui fabriquent ou intègrent vos équipements ce qu’ils ont fait pour que ces équipements soient sûrs dès la conception — et le restent dans la durée.

Ce que l’obligation du 11 septembre implique pour un opérateur de site sensible

La première question à se poser est simple : pour chaque équipement connecté de votre architecture de sûreté, existe-t-il un engagement contractuel précisant comment et dans quel délai le fabricant vous informe d’une vulnérabilité critique ? Si cette question n’a pas de réponse documentée, le CRA vient de la rendre urgente.

La deuxième question touche à ce qu’on appelle le SBOM — Software Bill of Materials. Le CRA étend les obligations à tout produit logiciel et matériel connectable, avec un horizon de support obligatoire de cinq ans minimum, un SBOM à fournir et une politique de divulgation de vulnérabilités à publier. Pour un opérateur, le SBOM est une fenêtre sur ce qui tourne réellement sur ses équipements : les bibliothèques logicielles, les dépendances tierces, les composants open source qui peuvent présenter des vulnérabilités sans que personne ne le sache. Les systèmes déployés sur des sites critiques depuis plusieurs années ont souvent été conçus à une époque où cette transparence n’était pas exigée. Ce n’est pas une critique — c’est un constat qui justifie un audit.

La chaîne de responsabilité s’étend

Le règlement distingue fabricants, importateurs et distributeurs, mais précise qu’un acteur qui commercialise un produit sous sa propre marque, ou qui le modifie substantiellement, endosse les mêmes obligations qu’un fabricant. Les intégrateurs qui reconditionnent, personnalisent ou distribuent des solutions sous leur propre nom doivent donc évaluer précisément leur statut au regard du CRA. Ce point va changer concrètement les pratiques du secteur de la sécurité électronique, où la frontière entre fabricant et intégrateur est souvent floue.

Les manquements exposent le fabricant à 15 millions d’euros ou 2,5% de son chiffre d’affaires. La fourniture d’informations inexactes aux organismes d’évaluation et autorités de surveillance est sanctionnée par une amende pouvant atteindre 5 millions d’euros. Un produit jugé non conforme ou présentant un risque pourra faire l’objet de restrictions allant jusqu’au retrait du marché.

Conclusion : C’est précisément parce que la traçabilité logicielle et la maîtrise de la chaîne technologique ne sont pas des contraintes administratives mais des conditions de fonctionnement réel que Komanche a construit ses architectures sur une logique documentée et contrôlée. Le CRA ne change pas notre démarche — il lui donne un cadre réglementaire que nous appliquions depuis l’origine.