Cyber Resilience Act : le compte à rebours a commencé pour les produits connectés

Le Cyber Resilience Act (CRA) est le règlement européen qui impose des exigences de cybersécurité à tout produit comportant des éléments numériques mis sur le marché de l'Union — matériel comme logiciel. Sa première échéance concrète tombe le 11 septembre 2026 avec les obligations de signalement des vulnérabilités activement exploitées ; l'essentiel des obligations s'applique au 11 décembre 2027. Pour un fabricant ou un éditeur, la préparation commence maintenant.
Qui est concerné : bien plus que les objets connectés
Le champ du CRA est volontairement large : il couvre les produits comportant des éléments numériques, c'est-à-dire le matériel connecté (équipements réseau, capteurs, machines industrielles pilotables, électronique grand public) mais aussi les logiciels mis sur le marché européen — applications, systèmes embarqués, composants. La description officielle du texte est disponible sur le site de la Commission européenne.
Trois points élargissent le cercle des organisations concernées :
- Le lieu du siège ne protège pas. Comme pour les autres textes européens, c'est la mise sur le marché de l'Union qui déclenche les obligations. Un éditeur mauricien qui vend un logiciel ou un équipement à des clients européens entre dans le champ comme fabricant, exactement comme la cascade NIS2 rattrape les fournisseurs hors UE.
- Toute la chaîne est mobilisée. Le texte vise d'abord les fabricants, mais assigne aussi des responsabilités aux importateurs et distributeurs, qui devront vérifier la conformité de ce qu'ils mettent en rayon.
- Les acheteurs vont s'en servir. Même une entreprise qui ne fabrique rien verra le CRA arriver dans ses appels d'offres : la conformité des produits achetés deviendra un critère de sélection et une exigence contractuelle.
Deux dates à retenir
Le calendrier d'application est progressif, avec deux jalons structurants :
- 11 septembre 2026 : les obligations de signalement des vulnérabilités activement exploitées (article 14) deviennent applicables pour les fabricants. C'est la première échéance opérationnelle, et elle arrive avant le reste du texte.
- 11 décembre 2027 : l'essentiel des obligations s'applique — exigences de sécurité dès la conception, gestion des vulnérabilités sur la durée de vie du produit, documentation technique et marquage attestant la conformité.
L'ordre de ces échéances est un message en soi : le législateur commence par la capacité à détecter et signaler qu'un produit est attaqué, avant même d'exiger la conformité complète. Précision utile : cet article est une synthèse d'information, pas un conseil juridique — le périmètre exact de vos obligations se vérifie avec vos conseils.
L'article 14 : ce que « signaler » exige en pratique
Signaler une vulnérabilité activement exploitée suppose une chaîne complète qui, dans beaucoup d'organisations, n'existe pas encore :
- Savoir qu'elle existe. Il faut un canal par lequel chercheurs, clients et partenaires peuvent vous remonter une vulnérabilité — une politique de divulgation coordonnée publiée, une adresse dédiée, un processus de réception qui ne perd rien.
- Savoir qu'elle est exploitée. Distinguer une faille théorique d'une exploitation active demande de la télémétrie, des journaux exploitables et une capacité d'analyse — en clair, une supervision réelle de ce qui se passe sur et autour du produit.
- Qualifier et notifier dans des délais courts. Le signalement aux autorités obéit à des délais serrés : sans processus écrit, testé, avec des rôles définis et des astreintes, la conformité sur le papier ne tiendra pas face à un incident réel.
- Corriger et informer. Le signalement n'est pas une fin : il faut être capable de produire un correctif, de le distribuer et d'informer les utilisateurs concernés.
Quoi préparer dès 2026
Les fondations demandées par le CRA sont les mêmes que celles d'une hygiène produit sérieuse — autant les construire une fois, correctement :
- Inventaire des produits et composants : quels produits sont mis sur le marché européen, avec quelles versions, quelles dépendances et quels composants tiers.
- SBOM (Software Bill of Materials) : une nomenclature logicielle générée automatiquement à chaque build, pas un document rédigé à la main une fois par an. C'est elle qui permet de répondre vite à la question « sommes-nous exposés ? » quand une vulnérabilité touche un composant répandu.
- Processus de gestion des vulnérabilités : veille sur les composants, triage, correction, distribution des mises à jour, politique de support par version.
- Canal de signalement : politique de divulgation publiée, point de contact sécurité, procédure interne de qualification et de notification avec rôles et remplaçants.
- Preuves : tout ce qui précède doit être documenté et démontrable — le régulateur comme vos clients demanderont des éléments, pas des intentions. Un audit de sécurité permet de mesurer l'écart entre l'existant et ces exigences.
Checklist CRA : où en êtes-vous ?
- Nous avons établi si nos produits (matériels ou logiciels) sont mis sur le marché de l'UE.
- Notre rôle dans la chaîne (fabricant, importateur, distributeur) est qualifié produit par produit.
- Un inventaire des produits, versions et composants tiers existe et est tenu à jour.
- Un SBOM est généré automatiquement pour chaque version livrée.
- Une politique de divulgation coordonnée est publiée, avec un contact sécurité joignable.
- Le processus de qualification d'une exploitation active est écrit et testé.
- La chaîne de notification (qui décide, qui notifie, qui communique) est définie avec des remplaçants.
- La distribution des correctifs vers les clients est outillée et mesurée.
- Les contrats avec nos propres fournisseurs de composants couvrent le signalement des vulnérabilités.
Si l'échéance de l'article 14 semble lointaine, rappelez-vous qu'elle exige des capacités opérationnelles, pas des documents : un canal de signalement, une télémétrie, une astreinte. Ces briques se construisent en mois. Un diagnostic de votre chaîne produit permet de séquencer le chantier avant que le calendrier ne le fasse à votre place.
Comment SOVALYX peut vous aider
SOVALYX aide les éditeurs et fabricants à mettre en place les fondations que le CRA exige : processus de gestion des vulnérabilités, génération et suivi de SBOM, canal de signalement outillé et supervision 24/7 sous SLA pour détecter et qualifier une exploitation active. Ces briques se construisent en quelques mois — pas dans l'urgence d'une notification obligatoire.
Parler conformité avec un ingénieur🧰 L'outil qui va avec : Êtes-vous prêt pour l'AI Act ? — gratuit · 2 minutes.
Relu et optimisé par IA.