Guardian360
Démarrer l’essai gratuitDevenir partenaire
← Tous les articles

Opinion

Tout le monde surveille NIS2. Le Cyber Resilience Act est celui qui peut retirer votre produit du marché.

Par Jan Martijn Broekhof ·

Le 9 juillet, j’ai assisté à CRA Connect, un événement consacré au Cyber Resilience Act organisé par CyberVeilig Nederland, FME et le ministère néerlandais des Affaires économiques, accueilli par Tesorion à Nieuwegein. J’y suis allé en pensant déjà connaître l’essentiel. Guardian360 développe des logiciels, donc bien sûr que le CRA s’applique à nous ; ce point n’a jamais fait de doute. Ce qui m’a pris au dépourvu, c’est la vitesse. Pas la date phare de décembre 2027, que la plupart des personnes présentes dans la salle pouvaient réciter, mais celle qui se tient discrètement juste avant : le 11 septembre 2026. Ce n’est pas une obligation lointaine. C’est un délai de préparation qui a déjà commencé à courir.

Je soupçonne ne pas être le seul à avoir eu ce calendrier légèrement de travers dans ma tête. Et la raison pour laquelle cela compte est simple : en ce moment, presque tout le monde en cybersécurité regarde vers NIS2. Le CRA arrive dans son ombre, et des deux, c’est le CRA qui peut, à terme, vous empêcher de vendre votre produit tout court.

Qu’est-ce exactement que le Cyber Resilience Act ?

Le Cyber Resilience Act est une réglementation européenne visant la sécurité des produits comportant des éléments numériques. Il est entré en vigueur le 10 décembre 2024 et, s’agissant d’un règlement et non d’une directive, il s’applique directement dans toute l’UE sans devoir être transposé en droit national.

Son champ d’application est large. Il couvre non seulement les appareils physiques connectés tels que le matériel IoT, les pare-feux et les équipements réseau, mais aussi les logiciels : systèmes d’exploitation, applications mobiles, firmware et composants logiciels commercialisés séparément. Si un produit comportant des éléments numériques est mis sur le marché de l’UE dans le cadre d’une activité commerciale, il entre très probablement dans le champ d’application. Cette portée s’étend au-delà de l’Europe également ; un fabricant établi hors de l’UE est soumis au CRA dès l’instant où ses produits sont mis à disposition sur le marché de l’UE.

Il existe une exception qui mérite d’être mentionnée, car elle est largement mal comprise. Les logiciels open source à but non commercial se situent en dehors du champ du CRA. Mais dès que vous intégrez des composants open source dans un produit commercial, ces composants font partie de votre produit, et les obligations du CRA s’appliquent à l’ensemble. Vous ne pouvez pas externaliser la responsabilité vers un projet en amont que vous n’avez jamais financé.

Quand devez-vous réellement vous conformer ?

C’est là que se cache la surprise. Il y a deux dates, et la seconde capte toute l’attention alors que la première fait les dégâts.

Le 11 septembre 2026, l’obligation de signalement entre en vigueur. À compter de cette date, les fabricants qui prennent connaissance d’une vulnérabilité activement exploitée ou d’un incident grave affectant leur produit doivent le signaler, avec une première notification dans les 24 heures, via le canal national sur mijn.NCSC.nl. Le 11 décembre 2027, le reste du règlement s’applique pleinement : les exigences essentielles de cybersécurité, l’évaluation de conformité, le marquage CE, la documentation technique. À compter de cette date, seuls les produits conformes au CRA pourront être mis sur le marché de l’UE.

Maintenant, retournez ces dates. Ne les regardez pas comme des échéances mais comme le moment où votre préparation doit être terminée. Un processus fonctionnel de signalement des incidents et des vulnérabilités, testé et doté en personnel, doit exister avant septembre 2026. Une évaluation de conformité complète, avec toute la documentation qui l’accompagne, doit être réalisée avant décembre 2027. Soustrayez le temps que chacune de ces tâches prend réellement, et les deux dates renvoient au même endroit inconfortable : maintenant.

Tout le monde regarde vers NIS2. C’est là que réside le danger.

Le secteur de la cybersécurité a passé les deux dernières années absorbé par NIS2 et sa transposition néerlandaise. Cette attention n’est pas déplacée, mais elle a créé un angle mort, et cet angle mort est dangereux précisément parce que les deux lois ne sont pas des concurrentes pour votre attention. Elles s’imbriquent.

Le CRA constitue, en réalité, l’instrument de sécurisation de la chaîne d’approvisionnement sous-jacent à NIS2. Une organisation soumise à NIS2 ne peut être sécurisée que si les produits qu’elle achète le sont eux-mêmes. Un hôpital, un opérateur d’utilité publique, un exploitant logistique ; chacun n’est aussi résilient que les produits connectés et les logiciels qu’il achète. C’est exactement ce que le CRA réglemente au niveau du produit. Ne regarder que NIS2, c’est gérer la moitié du problème en supposant que l’autre moitié se règle d’elle-même.

Les enjeux diffèrent également, et c’est le point qui devrait faire réagir. La non-conformité à NIS2 entraîne une surveillance et des amendes. C’est sérieux. Mais le CRA fonctionne comme le marquage CE pour la sécurité physique : à partir de décembre 2027, un produit sans évaluation de conformité valide ne pourra tout simplement pas être mis sur le marché de l’UE. Le pire scénario sous NIS2 est une sanction. Le pire scénario sous le CRA est que votre produit ne puisse pas être vendu. Pour un éditeur de logiciels, ce n’est pas un coût de conformité. C’est un enjeu existentiel.

Nous nous sommes testés nous-mêmes

Je veux être honnête sur la position de Guardian360 dans tout cela, car c’est la façon la plus claire de montrer pourquoi « on s’en occupera » est le mauvais réflexe.

Nous sommes certifiés ISO 27001. Nous maintenons déjà une nomenclature logicielle (Software Bill of Materials) pour nos produits. Sur le papier, nous étions mieux préparés que la plupart. Et la conclusion à laquelle nous sommes arrivés reste néanmoins de nature à faire réfléchir : cette préparation nous donne une longueur d’avance, pas une exemption. L’ISO 27001 régit notre système de management de la sécurité de l’information, notre organisation et ses processus. Le CRA régit la sécurité du produit lui-même. Les deux sont complémentaires, mais ils ne sont pas interchangeables, et un certificat ISO 27001 accroché au mur ne rend pas un produit conforme au CRA.

Puis nous avons commencé à cartographier nos propres produits selon les catégories du CRA, et cela s’est révélé encore plus intéressant. Le règlement classe les produits comportant des éléments numériques en produits ordinaires, produits importants de classe I et classe II, et produits critiques, l’évaluation devenant plus lourde à mesure que le risque augmente. La classe II, qui comprend les systèmes de détection et de prévention d’intrusion, exige une évaluation par un organisme notifié externe ; l’auto-évaluation n’est pas suffisante. Une partie de ce que nous faisons se situe précisément dans ce domaine de la détection d’intrusion. Autrement dit, certains de nos produits relèvent du régime le plus lourd, pas du plus léger. Déterminer exactement quel produit relève de quelle catégorie, et documenter le raisonnement, est précisément le genre de tâche qui prend des mois. Ce n’est pas quelque chose que l’on fait dans la précipitation à la fin de l’été 2026.

Pourquoi vous ne pouvez pas attendre, même pour « seulement » l’obligation de signalement

Voici l’objection légitime, et elle mérite une réponse franche. Quelqu’un dira : septembre 2026 n’est que l’obligation de signalement, pas la conformité complète du produit. La conformité complète, c’est 2027. Alors n’exagérons-nous pas l’urgence ?

Non, et voici pourquoi. L’obligation de signalement n’est pas un interrupteur que l’on actionne. Vous ne pouvez pas signaler ce que vous ne surveillez pas, ce qui signifie que le processus de détection et de signalement doit être opérationnel, et rodé, avant l’échéance. Vous ne pouvez pas signaler avec précision sur un produit dont vous n’avez jamais cartographié les dépendances tierces, et c’est là qu’intervient la nomenclature logicielle ; en assembler une sur un véritable portefeuille de produits représente des mois de travail, pas un après-midi. Et pour quiconque construit des produits physiques, le calendrier est encore moins clément. Lors de l’événement, Ferry Mulders de VDL Agrobotics a évoqué le cycle de vie d’une machine, la nécessité de prouver qu’une machine ne peut pas être piratée sur toutes les années où elle reste en service. Un fabricant de machines avec un cycle de développement pluriannuel conçoit aujourd’hui les produits qui arriveront sur le marché après 2027. Pour eux, 2027 n’est pas l’avenir. C’est le cahier des charges actuel.

Erik de Jong de Tesorion, dont l’entreprise a accueilli l’événement, a formulé la version honnête de cette réalité sans détour : ils aident d’autres organisations à se mettre en conformité et sont eux-mêmes assis sur un chantier CRA conséquent. C’est la réalité dans tout notre secteur. Les personnes qui conseillent sur ce sujet y sont elles-mêmes soumises.

Ce que cela signifie pour les partenaires

Si vous êtes un partenaire, un MSP, un intégrateur, un revendeur ou un spécialiste en cybersécurité, cela atterrit deux fois sur votre bureau.

D’abord, pour vous-même. Si vous développez, importez ou distribuez un produit comportant des éléments numériques, allez vérifier si le CRA s’applique à vous, et à quelle catégorie chaque produit appartient. Ne présumez pas qu’une activité de service échappe au champ d’application ; un grand nombre de prestataires de services livrent également des logiciels, des appliances ou des produits intégrés sans y penser en ces termes.

Ensuite, pour vos clients. Ils vont vous demander ce que le CRA signifie pour eux, et les partenaires capables de répondre correctement, calmement, précisément, avec le calendrier et les catégories bien en tête, sont ceux qui gagneront la confiance qui en découle. La conversation arrive de toute façon. La seule question est de savoir si vous avez fait le travail avant que votre client ne le demande, ou après.

Voici donc la question que je vous laisse. Avez-vous déjà confronté vos propres produits aux annexes du CRA, ou supposez-vous tranquillement que 2027 est encore confortablement loin ? Parce que lorsque vous retournez les dates, ce n’est pas le cas.

Sources