Cyber Resilience Act : quelles obligations pour les fabricants de produits numériques ?

Le CRA concerne-t-il les produits de votre entreprise ?

Un industriel peut acheter des équipements connectés, fabriquer une machine comportant un logiciel ou commercialiser une application. Ces situations impliquent des rôles différents. Pour préparer le Cyber Resilience Act, la première étape consiste à identifier le produit, son usage et votre responsabilité dans sa mise sur le marché.

Le règlement européen sur la cyberrésilience, appelé CRA, établit des exigences pour les produits comportant des éléments numériques. Son champ repose notamment sur la mise à disposition sur le marché et la connexion logique ou physique, directe ou indirecte, à un dispositif ou à un réseau. Il prévoit aussi des exclusions et des règles propres à certains produits. Règlement UE 2024/2847, articles 2 et 3.

Ce dossier aide les dirigeants industriels, responsables produits et équipes informatiques à organiser la préparation. Il faut vérifier le champ du règlement pour chaque famille de produits. L’utilisation d’un matériel connecté dans un atelier ne suffit pas, à elle seule, à faire de l’entreprise son fabricant.

Quelles échéances sont confirmées ?

Le CRA est entré en vigueur le 10 décembre 2024. Les obligations de signalement prévues à l’article 14 s’appliquent depuis le 11 septembre 2026. Les principales obligations du règlement s’appliqueront le 11 décembre 2027. Le chapitre consacré à la notification des organismes d’évaluation de la conformité s’applique depuis le 11 juin 2026. Calendrier de la Commission européenne.

Ces dates ne correspondent pas à une seule échéance de mise en conformité. Une entreprise peut avoir besoin d’un processus de signalement opérationnel avant la préparation complète de ses dossiers produits. Les dispositions transitoires, notamment pour les produits déjà mis sur le marché et les modifications substantielles, doivent également être examinées. Règlement CRA, articles 69 et 71.

Dans votre registre de veille, séparez le calendrier réglementaire du calendrier interne : produits à examiner, responsables désignés, procédures à tester et documentation à compléter. Cette distinction permet de suivre les travaux sans présenter une cible de projet comme une échéance légale.

Fabricant, intégrateur ou utilisateur : préciser votre rôle

Le règlement définit notamment les rôles du fabricant, de l’importateur et du distributeur. Il prévoit aussi des situations où un autre acteur reprend les obligations d’un fabricant, par exemple lorsqu’il commercialise un produit sous son propre nom ou réalise certaines modifications substantielles. Le mot « intégrateur » utilisé commercialement ne permet pas de conclure au rôle réglementaire. Règlement CRA, articles 3 et 21.

Nous recommandons une fiche par famille de produits :

• le produit vendu, sa destination et les marchés concernés ;
• le nom sous lequel il est commercialisé ;
• les composants matériels, logiciels et services nécessaires à son fonctionnement ;
• les fournisseurs et les responsabilités de mise à jour ;
• les opérations de transformation ou de modification ;
• la justification du périmètre et les points à faire valider.

Pour un fabricant de machines, une passerelle ou une fonction distante doit être examinée dans son contexte. Pour une société de développement, il faut analyser le produit livré et son mode de commercialisation. Un projet sur mesure, un logiciel libre ou un service en ligne ne permet pas de déduire une exemption générale sans examiner les conditions prévues par le texte.

Qu’en est-il des produits destinés à la défense ?

Le règlement exclut les produits développés ou modifiés exclusivement à des fins de sécurité nationale ou de défense, ainsi que ceux spécifiquement conçus pour traiter des informations classifiées. Le terme « exclusivement » est important pour l’analyse. Fournir un client militaire ou vendre un produit utilisé aussi dans le civil ne suffit pas à appliquer automatiquement cette exclusion. Règlement CRA, article 2, paragraphe 7.

Pour un sous-traitant, nous conseillons de documenter la destination du produit et les exigences du contrat avec le donneur d’ordres. Conservez la justification du traitement retenu. Les règles contractuelles ou sectorielles doivent être examinées même lorsqu’un produit se situe hors du champ du CRA.

Quels événements signaler et dans quels délais ?

Depuis le 11 septembre 2026, les fabricants concernés doivent signaler les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité de leurs produits. La Commission indique une alerte précoce sous 24 heures après en avoir eu connaissance, puis une notification sous 72 heures. Le rapport final intervient au plus tard 14 jours après la disponibilité d’une mesure corrective pour une vulnérabilité activement exploitée ; pour un incident grave, il intervient dans le mois suivant la notification de 72 heures. Le signalement passe par la plateforme unique CRA. Commission européenne : obligations de signalement.

Ces délais ont des points de départ différents. La procédure interne doit préciser comment une information est reçue, qualifiée, horodatée et transmise au responsable. Elle doit aussi prévoir la coordination avec les fournisseurs et les clients concernés.

Un exercice utile consiste à simuler une alerte sur un composant intégré au produit : quelles versions sont touchées, existe-t-il une exploitation active, qui mène l’analyse et qui peut décider de la communication ? L’objectif est d’identifier les informations manquantes et les relais indisponibles avant un incident réel.

Comment préparer la gestion des vulnérabilités ?

Le CRA prévoit des exigences concernant la sécurité des produits et le traitement de leurs vulnérabilités. Le règlement traite notamment de l’évaluation des risques, des composants, des mises à jour et de la documentation. Les modalités d’évaluation de la conformité dépendent du produit et de sa classification. Règlement CRA, article 13, article 32 et annexe I.

Pour organiser les travaux, nous proposons de réunir les équipes produit, développement, support et sécurité autour de questions concrètes. Où sont recensés les composants et versions ? Comment reçoit-on une information de sécurité d’un fournisseur ? Qui peut produire, tester et diffuser un correctif ? Comment sait-on quels clients utilisent une version touchée ?

Une liste de composants doit être reliée aux produits livrés et aux informations de support. Sinon, une alerte peut être connue sans que l’entreprise puisse déterminer rapidement les installations concernées. La qualité de cette liaison mérite d’être testée sur quelques cas représentatifs.

Pour un équipement d’atelier, la préparation doit aussi tenir compte des contraintes d’exploitation : arrêt de production, validation constructeur, compatibilité et retour arrière. Ces contraintes doivent être intégrées au traitement du risque et au dialogue avec le client.

Construire un dossier exploitable par les équipes

Un dossier utile relie les décisions de conception, les risques, les versions et les preuves de vérification. Nous recommandons de définir un responsable documentaire et une règle de mise à jour lors des changements du produit. Le dossier doit permettre de retrouver la justification d’une décision, même si l’équipe a changé.

Commencez par une famille de produits représentative. Recensez les documents existants et identifiez les écarts : architecture, composants, décisions de sécurité, résultats de tests, traitement des alertes et informations données aux utilisateurs. Les documents réglementairement requis doivent être confirmés selon le rôle et le produit.

Cette approche permet d’intégrer les travaux dans le cycle de développement et de support. Elle évite qu’une documentation soit préparée une seule fois, puis déconnectée des versions effectivement commercialisées.

Comment articuler le CRA, NIS2 et ISO 27001 ?

Le CRA examine la cybersécurité des produits ; NIS2 traite les organisations relevant de son périmètre ; ISO 27001 structure un système de management de la sécurité de l’information. Une entreprise peut rencontrer plusieurs de ces démarches. Leur périmètre et leurs mécanismes doivent rester identifiés.

Des travaux communs peuvent être réutilisés : responsabilités, gestion des incidents, relations fournisseurs et suivi des risques. Nous conseillons de conserver une matrice distinguant l’exigence, sa source, le responsable et la preuve. Notre dossier NIS2 et ReCyF pour les PME industrielles complète cette lecture côté organisation.

Comment IT Support peut vous accompagner

IT Support peut contribuer à organiser la gouvernance cyber, identifier les dépendances et sécuriser les accès de l’entreprise et de ses ateliers. Le RSSI externalisé peut coordonner les actions avec les équipes produit, vos partenaires et les spécialistes nécessaires à l’évaluation réglementaire.

Nos prestations de développement sur mesure et d’intégration et de sécurisation des réseaux industriels permettent de travailler sur les interfaces et les responsabilités techniques. L’analyse du champ du CRA et l’évaluation de conformité du produit doivent être confiées aux acteurs compétents ; cet accompagnement ne vaut pas certification du produit.

Questions fréquentes

Une petite entreprise peut-elle être concernée ?

La qualification doit partir du produit et du rôle de l’entreprise. Il ne faut pas transposer au CRA les critères de taille utilisés pour analyser NIS2.

Acheter des équipements connectés impose-t-il de les certifier soi-même ?

Votre rôle doit être vérifié. En tant qu’utilisateur, préparez surtout les informations sur les versions, le support et les interlocuteurs. Une commercialisation ou une modification du produit peut modifier l’analyse des responsabilités.

Un certificat ISO 27001 couvre-t-il les produits ?

Il concerne le SMSI et son périmètre. Il ne remplace pas l’analyse des exigences et des modalités de conformité propres aux produits relevant du CRA.