Cyber Resilience Act 2026 : ce que les fabricants européens doivent savoir

Qu’est-ce que la loi sur la cyber-résilience ?

La loi sur la cyber-résilience (CRA) est un règlement de l’UE qui fixe des exigences obligatoires en matière de cybersécurité pour tous les produits comportant des éléments numériques vendus sur le marché européen. Elle couvre le matériel et les logiciels tout au long de leur cycle de vie, de la conception à la fin de l’assistance. Les fabricants doivent intégrer la sécurité par défaut, tenir à jour une nomenclature des logiciels, gérer activement les vulnérabilités et signaler les incidents dans des délais stricts. Le règlement est entré en vigueur en décembre 2024 et devient pleinement applicable le 11 décembre 2027.

L’ARC comble un vide laissé par la réglementation précédente. Le NIS2 explique aux organisations comment se protéger. DORA explique aux institutions financières comment gérer la résilience opérationnelle. L’ARC indique aux fabricants comment construire des produits sécurisés. Si vous fabriquez un produit qui se connecte à un réseau et que vous le vendez dans l’UE, ce règlement s’applique à vous.

Pour les fabricants du marché intermédiaire européen, 2026 est l’année où les préparatifs se transforment en réalité opérationnelle. Les obligations de déclaration commencent en septembre 2026. Les organismes notifiés pour les évaluations de la conformité doivent être en place d’ici juin 2026. Attendre 2027, c’est se battre contre des échéances que vos concurrents ont déjà respectées.

Ce que l’ARC demande aux fabricants

Le règlement définit 21 exigences regroupées en deux catégories : les propriétés de sécurité des produits et les processus de traitement de la vulnérabilité.

Sécurité dès la conception et par défaut. Les produits doivent être livrés dans une configuration par défaut sécurisée. Les ports, services et fonctionnalités inutiles doivent être désactivés dès la livraison. L’authentification et le contrôle d’accès doivent être intégrés, et non pas ajoutés après coup. Les données en transit et au repos doivent être cryptées. Des mécanismes de mise à jour sécurisés doivent être disponibles dès le premier jour.

Gestion des vulnérabilités tout au long du cycle de vie du produit. Les fabricants doivent définir une période de soutien pendant laquelle ils s’engagent à corriger les vulnérabilités. Le minimum général est de cinq ans. Cela inclut des tests de sécurité réguliers, un processus coordonné de divulgation des vulnérabilités (CVD) pour les chercheurs externes, et le maintien d’une nomenclature des logiciels (SBOM) pour chaque produit.

Signalement des incidents et des vulnérabilités. À partir du 11 septembre 2026, les fabricants devront signaler à l’ENISA et aux CSIRT nationaux les vulnérabilités activement exploitées. Les délais sont serrés :

Pour un fabricant de taille moyenne disposant d’une petite équipe informatique et d’un centre d’opérations de sécurité fonctionnant 24 heures sur 24 et 7 jours sur 7, le respect de ces délais nécessite une certaine préparation. Vous avez besoin d’une équipe de réponse aux incidents de sécurité des produits (PSIRT) avec des rôles clairs, des alertes automatisées et des modèles de notification préétablis avant l’échéance de septembre 2026. Les organisations qui gèrent leur sécurité à l’aide d’une console de gestion unique disposent d’un avantage structurel à cet égard. Lorsque les journaux d’accès, les événements réseau et les changements de politique sont regroupés en un seul endroit, l’élaboration d’un rapport d’alerte précoce dans les 24 heures devient un processus plutôt qu’une course effrénée. La plateforme SASE de Jimber, par exemple, capture ces points de données de manière centralisée, ce qui signifie que votre PSIRT consacre son temps à l’analyse de l’incident plutôt qu’à la corrélation des journaux provenant de cinq outils distincts.

Évaluation de la conformité. Avant de mettre un produit sur le marché, les fabricants doivent en démontrer la conformité. La procédure d’évaluation dépend de la classification des risques du produit.

Quels sont les produits couverts (et ceux qui ne le sont pas) ?

L’ARC s’applique à tout « produit contenant des éléments numériques » (PDE), défini comme du matériel ou des logiciels dont l’utilisation prévue implique une connexion directe ou indirecte à un appareil ou à un réseau. Cette définition est délibérément large.

Le règlement classe les produits en quatre niveaux de risque :

Il est important d’obtenir une classification correcte. Un fabricant qui évalue lui-même un produit de classe I risque une suspension de l’accès au marché et des amendes. Si votre production concerne la sécurité des réseaux, la gestion des identités ou le contrôle industriel, vérifiez soigneusement les listes des annexes III et IV.

Ce qui ne relève pas de l’ARC. Les produits déjà réglementés par des cadres sectoriels sont largement exclus : les dispositifs médicaux (MDR/IVDR), les véhicules (UNECE R155), l’aviation et les équipements marins. Les logiciels libres développés en dehors de toute activité commerciale sont exemptés, mais les distributions commerciales de composants libres ne le sont pas. Le SaaS pur fourni entièrement dans le nuage est hors du champ d’application, mais tout composant téléchargeable ou élément sur site ramène le produit dans le champ d’application.

Comment l’ARC s’intègre-t-elle dans NIS2 et DORA ?

L’ARC est le troisième pilier du cadre réglementaire européen en matière de cybersécurité. Chaque règlement aborde une dimension différente :

Un fabricant de contrôleurs industriels peut être confronté à ces trois types de problèmes. L’ARC régit le produit lui-même. Le NIS2 s’applique si le fabricant est classé comme entité importante. Et DORA s’applique indirectement : les institutions financières qui utilisent ces contrôleurs exigeront des produits conformes à l’ARC dans le cadre de leur propre registre d’informations DORA.

Pour les organisations qui travaillent déjà sur la conformité au NIS2 pour le marché intermédiaire, le chevauchement est un avantage. Les méthodologies d’évaluation des risques, les inventaires d’actifs et les processus de réponse aux incidents développés pour le NIS2 se traduisent directement par les exigences de l’ARC. Des plateformes telles que Jimber, qui consolident les contrôles de sécurité dans un système unique et vérifiable, aident les organisations à naviguer dans les deux cadres sans dupliquer le travail.

Pourquoi la conformité de l’ARC commence à l’usine

Voici la partie qui échappe à la plupart des guides de conformité. L’ARC exige que votre produit soit sécurisé. Mais un produit construit dans un environnement de production compromis n’est pas sûr, quelle que soit la qualité de sa conception.

Si un pirate accède à votre pipeline de construction, à votre serveur de compilation de microprogrammes ou à votre infrastructure de distribution de logiciels, il peut injecter un code malveillant dans votre produit avant qu’il ne quitte l’usine. Ce n’est pas une théorie. Les attaques de la chaîne d’approvisionnement contre SolarWinds, Kaseya et 3CX ont suivi exactement ce modèle.

Pour les fabricants de produits connectés, la sécurisation de l’environnement de production est une exigence de conformité de l’ARC, et pas seulement une bonne pratique. Vous devez démontrer que l’intégrité de votre produit a été maintenue tout au long du processus de fabrication.

C’est là que la sécurité des réseaux de production prend tout son sens. La plateforme SASE de Jimber répond aux défis spécifiques auxquels sont confrontés les fabricants :

Segmentation du réseau entre les technologies de l’information et les technologies de la terre. Le réseau de l’entreprise sur lequel fonctionnent la messagerie et l’ERP doit être strictement séparé de l’environnement de production sur lequel le firmware est compilé et flashé. Le SD-WAN et le FWaaS de Jimber assurent cette séparation grâce à des règles basées sur l’identité et gérées à partir d’une console unique. Une épidémie de ransomware au bureau ne devrait jamais atteindre les serveurs de production.

Accès sans confiance aux systèmes de production. Seuls les ingénieurs autorisés devraient être en mesure de modifier le micrologiciel ou les logiciels du produit. L’accès réseau zéro confiance de Jimber accorde un accès par application en fonction de l’identité de l’utilisateur et de l’état de l’appareil, et non de l’emplacement du réseau. Chaque décision d’accès est enregistrée avec une piste d’audit complète.

Isolation en ligne pour les équipements de production sans agent. Les automates, les IHM et les stations de flashage ne peuvent pas exécuter d’agents de sécurité. Le matériel NIAC de Jimber s’intercale entre ces appareils et le réseau, appliquant des politiques de communication par appareil sans toucher à l’appareil lui-même. Un ordinateur portable compromis sur le réseau informatique se heurte à un mur avant d’atteindre l’équipement de production. Le guide SASE pour la fabrication couvre la mise en œuvre technique en détail.

Enregistrement centralisé pour les preuves d’audit. Les évaluations de conformité de l’ARC vous demanderont comment vous assurez l’intégrité de la production. Une console de gestion unique qui enregistre chaque décision d’accès, chaque changement de politique et chaque flux de communication entre les appareils fournit la piste de preuves attendue par les auditeurs.

Cinq étapes pour se préparer à la mise en conformité avec les règles de l’ARC

Étape 1 : évaluer les lacunes par rapport à l’annexe I

Dressez la liste de tous les produits de votre portefeuille qui contiennent des éléments numériques. Classez chacun d’entre eux selon les niveaux de risque de l’ARC. Comparez ensuite vos pratiques de sécurité actuelles aux 21 exigences de l’annexe I.

L’outil de conformité CRACy de Jimber a été développé dans le cadre d’une initiative soutenue par l’UE, spécifiquement à cette fin. Il traduit les exigences abstraites de l’annexe I en contrôles techniques concrets, identifie les lacunes et aide à hiérarchiser les mesures correctives. Pour les PME qui ne disposent pas d’une équipe dédiée à la conformité, cette approche structurée remplace des mois d’interprétation manuelle.

Étape 2 : construire et entretenir votre SBOM

Une nomenclature logicielle documente chaque composant de votre produit : bibliothèques, frameworks, dépendances open-source et leurs versions. Utilisez des formats standardisés comme CycloneDX ou SPDX. Mettez à jour la nomenclature à chaque version.

Le SBOM n’est pas seulement un document de conformité. C’est votre système d’alerte précoce. Lorsqu’une nouvelle vulnérabilité apparaît dans une bibliothèque largement utilisée (comme Log4j en 2021), un SBOM à jour vous indique en quelques heures si vos produits sont concernés.

Étape 3 : établir la divulgation des vulnérabilités et la réponse aux incidents

Mettre en place un processus coordonné de divulgation des vulnérabilités avant septembre 2026. Les chercheurs externes ont besoin d’une méthode claire et documentée pour signaler les vulnérabilités. En interne, définissez votre PSIRT avec des rôles nommés, des voies d’escalade et des modèles de notification pré-rédigés qui répondent aux exigences de signalement 24/72/14 jours.

La qualité de votre réponse aux incidents dépend de la rapidité avec laquelle vous pouvez déterminer ce qui s’est passé. Si votre architecture de sécurité enregistre les décisions d’accès, les évaluations de la posture des appareils et les flux du réseau dans une seule ligne de temps, l’analyse des causes profondes s’accélère considérablement. C’est l’une des raisons pratiques pour lesquelles les fabricants qui s’appuient sur une plateforme SASE unifiée, telle que Jimber, trouvent que la préparation de la réponse aux incidents est plus facile à mettre en œuvre.

Étape 4 : mise en œuvre des tests de sécurité

Des tests de pénétration réguliers et une analyse automatisée des vulnérabilités devraient couvrir à la fois le produit et son environnement de production. Testez les mécanismes de mise à jour pour vous assurer qu’ils ne peuvent pas être manipulés. Validez que les configurations par défaut sont réellement sûres.

Étape 5 : préparer votre documentation de conformité

Pour les produits de la catégorie par défaut, la documentation interne suivant le module A est suffisante. Pour les produits importants des classes I et II, vous devez faire appel à un organisme notifié. Ces organismes sont désignés tout au long de l’année 2026 et la capacité d’accueil sera limitée. Réservez tôt pour éviter des retards qui pourraient bloquer votre accès au marché en 2027.

Votre dossier technique doit comprendre l’évaluation des risques, les résultats des tests, le SBOM, les procédures de traitement des vulnérabilités et les preuves des processus de sécurité par conception. L’effort requis pour compiler ces preuves varie énormément en fonction de votre architecture de sécurité. Un fabricant qui utilise cinq outils distincts doit extraire, corréler et croiser les journaux de chacun d’entre eux. La console de gestion unique de Jimber génère une piste d’audit unifiée qui couvre le contrôle d’accès, la segmentation du réseau et les flux de communication des appareils en un seul jeu de données exportable. Cette différence peut réduire la préparation de la documentation de plusieurs mois à quelques semaines.

Contexte belge et Benelux

Le Centre belge de cybersécurité (CCB) joue un rôle central dans la mise en œuvre de l’ARC. En tant que CSIRT national, le CCB reçoit les rapports d’incidents et supervise les processus de certification.

Le projet SECURE. L’UE a mis en place un financement spécialement destiné à aider les PME à se mettre en conformité avec les règles de l’ARC. Les entreprises belges peuvent demander des subventions allant jusqu’à 30 000 euros, couvrant 50 % des coûts d’évaluation des risques, de développement de SBOM et de tests de sécurité. La première fenêtre de candidature s’est ouverte jusqu’en mars 2026, mais d’autres appels sont prévus.

Chevauchement des principes fondamentaux du cyberespace (CyFun). Les fabricants belges qui travaillent déjà à l’auto-évaluation des CyFun trouveront un chevauchement important avec les exigences de l’ARC. Le CyFun couvre un grand nombre des mêmes contrôles techniques, en particulier en ce qui concerne la gestion des accès, le traitement des incidents et l’inventaire des actifs. La certification CyFun n’équivaut pas à la conformité avec l’ARC, mais elle constitue une base solide. Les organisations qui gèrent leur collecte de preuves CyFun par le biais d’une plateforme consolidée comme celle de Jimber peuvent réutiliser une grande partie de cette documentation à des fins d’évaluation des risques. Les journaux d’accès, les politiques de segmentation et les inventaires d’appareils qui satisfont à la fonction de protection de CyFun correspondent directement aux contrôles de l’environnement de production attendus par l’ARC. La liste de contrôle de conformité NIS2 correspond à des contrôles spécifiques qui s’appliquent aux trois cadres.

Pénalités. Le non-respect des exigences de l’annexe I peut entraîner des amendes allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial. Le non-respect des obligations en matière d’établissement de rapports est passible du même plafond. Les régulateurs peuvent également ordonner le rappel de produits ou le retrait du marché, ce qui, pour la plupart des fabricants, est plus préjudiciable que n’importe quelle amende.

FAQ

Quand la loi sur la cyber-résilience entre-t-elle en vigueur ?

L’ARC est entré en vigueur le 10 décembre 2024. Les obligations de déclaration des vulnérabilités activement exploitées débutent le 11 septembre 2026. La mise en œuvre complète, y compris les évaluations de conformité et les exigences de marquage CE, commence le 11 décembre 2027.

L’ARC s’applique-t-elle aux logiciels ?

Oui. L’ARC couvre à la fois les produits matériels et logiciels comportant des éléments numériques, y compris les logiciels autonomes distribués pour être utilisés sur les appareils des utilisateurs finaux. Le SaaS pur fourni entièrement dans le nuage est exclu, mais tout composant téléchargeable ou élément côté client fait entrer le produit dans le champ d’application.

Qu’est-ce qu’un SBOM et pourquoi l’ARC en exige-t-il un ?

Une nomenclature logicielle (SBOM) est un inventaire lisible par machine de tous les composants de votre produit, y compris les bibliothèques open-source, les modules tiers et leurs versions. L’ARC exige un SBOM parce que les logiciels modernes sont généralement constitués de 75 % ou plus de composants externes. Une vulnérabilité dans l’un d’entre eux affecte votre produit. Le SBOM rend cette chaîne d’approvisionnement transparente.

Comment l’ARC et le NIS2 se chevauchent-ils ?

L’ARC régit la sécurité des produits que vous fabriquez. Le NIS2 régit la sécurité de votre organisation. Un fabricant classé comme entité importante dans le cadre du NIS2 doit se conformer aux deux cadres. Les chevauchements pratiques sont importants : l’évaluation des risques, la réponse aux incidents, le contrôle d’accès et la gestion de la chaîne d’approvisionnement figurent dans les deux cadres. En complétant CyFun ou ISO 27001 pour NIS2, vous aurez une longueur d’avance sur les exigences organisationnelles de l’ARC.

L’ARC affecte-t-elle mon environnement de production ?

Oui, l’ARC exige des fabricants qu’ils garantissent l’intégrité des produits tout au long de leur cycle de vie, y compris pendant la fabrication. Un environnement de production compromis peut injecter des vulnérabilités dans des produits par ailleurs bien conçus. La sécurisation des pipelines de construction, des serveurs de microprogrammation et des réseaux de production à l’aide de contrôles « Zero Trust » et de la segmentation du réseau fait partie de la démonstration de la conformité à l’ARC. Pour les équipements de production qui ne peuvent pas exécuter d’agents de sécurité, un matériel d’isolation en ligne comme le NIAC de Jimber applique des politiques de communication par appareil sans perturber les opérations.

Puis-je obtenir un soutien financier pour la mise en conformité de l’ARC en Belgique ?

Le projet SECURE, financé par l’UE, offre aux PME belges des subventions allant jusqu’à 30 000 euros, couvrant 50 % des coûts éligibles pour les activités de mise en conformité de l’ARC. D’autres programmes nationaux et régionaux, dont le KMO-portefeuille, peuvent couvrir les frais de conseil liés à la certification et à la conformité en matière de cybersécurité.

La loi sur la cyber-résilience modifie les conditions de base pour tous les fabricants qui vendent des produits connectés en Europe. La conformité n’est pas facultative et les délais sont plus courts qu’il n’y paraît. Les fabricants qui investissent dès maintenant dans des pratiques de développement sécurisées, dans la sécurité de l’environnement de production et dans une documentation structurée sur la conformité respecteront l’échéance de 2027 sans avoir à se démener. Ceux qui attendent risquent des retards dans l’accès au marché, des amendes et une atteinte à leur réputation s’ils sont pris au dépourvu. Prêt à sécuriser votre environnement de production pour la conformité à l’ARC ? Réservez une démonstration et découvrez comment la plateforme SASE de Jimber protège l’infrastructure dans laquelle vos produits sont construits.