Cyber Resilience Act embarqué : déclarer une faille en 24 h

Depuis le 11 septembre 2026, le Cyber Resilience Act oblige tout fabricant de produit comportant des éléments numériques à signaler sous 24 heures une vulnérabilité activement exploitée. Pour un produit embarqué, le texte ne pose pas d’abord une question juridique : il demande de savoir ce qui tourne réellement dans le firmware déployé, de décider vite si l’on est touché, puis de corriger sur des appareils qui sont sur le terrain, parfois depuis des années. Le Cyber Resilience Act embarqué se manage donc dans le BSP, la chaîne de build et le canal de mise à jour bien plus que dans le service juridique.

Le règlement (UE) 2024/2847 s’applique en deux temps. L’essentiel des exigences de conception arrive le 11 décembre 2027, mais les obligations de déclaration s’appliquent déjà depuis le 11 septembre 2026. Deux événements déclenchent une notification : une vulnérabilité pour laquelle il existe une preuve fiable d’exploitation par un acteur malveillant, et un incident grave qui affecte la sécurité du produit.

Le calendrier, détaillé dans la FAQ de l’ENISA sur la plateforme unique de signalement, court à partir du moment où le fabricant prend connaissance de l’événement :

• Alerte précoce : 24 heures au plus après la prise de connaissance ;
• Notification : 72 heures au plus, avec les informations générales et une première évaluation ;
• Rapport final d’une vulnérabilité : 14 jours au plus après la mise à disposition d’un correctif ou d’une mesure d’atténuation ;
• Rapport final d’un incident grave : un mois après la notification à 72 heures.

Le point qui surprend le plus les équipes embarquées : l’obligation vaut pour tout produit dans le champ du règlement, y compris ceux mis sur le marché avant décembre 2027. L’ENISA précise aussi qu’un fabricant qui découvre l’exploitation après le 11 septembre 2026 doit la déclarer, même si la vulnérabilité elle-même était connue auparavant. Le parc installé est donc concerné dès aujourd’hui, pas seulement la prochaine génération de cartes. L’enjeu n’est pas symbolique : le livre blanc de la cybersécurité embarquée d’Embedded France rappelle que le règlement prévoit des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial, en plus du retrait possible du produit.

Le règlement vise le fabricant, c’est-à-dire celui qui met le produit sur le marché sous son nom. Dans une chaîne embarquée, c’est en général l’intégrateur de l’équipement final ; le fondeur du SoC ou l’éditeur d’une brique logicielle peuvent être fabricants de leur propre composant, mais cela ne décharge pas l’intégrateur. Ce dernier répond de son produit dans son entièreté : le texte lui demande une diligence raisonnable sur les composants obtenus auprès de tiers, logiciels libres compris, et, quand il découvre une vulnérabilité dans l’un d’eux, d’en informer le mainteneur et de lui transmettre le correctif appliqué.

Plusieurs secteurs de l’embarqué sont en revanche couverts par leur propre réglementation. Le même règlement écarte de son champ les dispositifs médicaux et de diagnostic in vitro relevant des règlements 2017/745 et 2017/746, les produits soumis à la réception par type des véhicules (règlement 2019/2144, qui renvoie au règlement ONU n° 155), les produits certifiés au titre de la sécurité aérienne civile (règlement 2018/1139), ainsi que les produits développés exclusivement pour la défense ou la sécurité nationale. Les équipements de télécoms grand public, les passerelles, l’IoT industriel, la domotique et la plupart des objets connectés restent pleinement dans le champ.

Certains produits cumulent même deux régimes. Une machine industrielle pilotée par un calculateur relève à la fois du CRA et du règlement (UE) 2023/1230 sur les machines, dont les exigences de protection contre la corruption et de fiabilité des systèmes de commande recoupent en partie celles du CRA. Le livre blanc d’Embedded France recommande, à ce titre, de suivre le projet de norme EN 50742 sur la protection contre la corruption. Pour les produits radio, il range EN 18031:2024 parmi les normes de référence ; pour les systèmes industriels, il cite la série IEC 62443.

La frontière se trace produit par produit. Les lignes directrices publiées par la Commission le 27 juillet 2026 apportent 67 exemples pratiques sur le champ, la notion de modification substantielle, la période d’assistance et les obligations de déclaration. C’est la première lecture à faire avant de conclure qu’un produit échappe au texte.

Déclarer en 24 heures suppose de répondre en quelques heures à une question simple : la version vulnérable est-elle présente dans nos images, et lesquelles ? Sans inventaire fiable, la réponse prend des jours. C’est le rôle de la nomenclature logicielle (SBOM, Software Bill of Materials : la liste des composants, de leurs versions et de leurs dépendances). Sur Linux embarqué, l’outillage existe : le système de build OpenEmbedded du Yocto Project génère par défaut une SBOM au format SPDX, et peut y joindre la configuration du noyau, ce qui sert directement à trier les vulnérabilités applicables.

Encore faut-il conserver la SBOM de chaque image livrée, pas seulement celle de la branche courante, et la relier aux numéros de série ou aux lots du parc. Une SBOM produite au build puis oubliée dans un artefact de CI ne permet pas de répondre en 24 heures.

Le noyau Linux illustre la difficulté du tri. Depuis que la communauté du noyau attribue elle-même ses CVE, son équipe dédiée attribue un identifiant à quasiment chaque correctif susceptible d’avoir un impact de sécurité, par prudence, ce qui produit un volume élevé de CVE. La même documentation précise que l’applicabilité d’une CVE dépend de l’usage du noyau et qu’il revient à l’utilisateur de la déterminer. Elle ajoute qu’aucune CVE n’est attribuée pour une version que l’équipe stable ou LTS ne maintient plus.

Ce dernier point vise directement l’embarqué : un noyau de BSP fourni par un fondeur et resté sur une branche abandonnée sort du radar des CVE du noyau. Les failles y existent toujours, mais personne ne les numérote pour cette version. Ajoutez les binaires fermés livrés avec le SoC (firmware radio, blobs GPU, TrustZone), et l’on comprend que la veille de vulnérabilités d’un produit embarqué ne se résume pas à interroger une base publique.

Le rapport final d’une vulnérabilité exploitée part 14 jours après la mise à disposition du correctif : encore faut-il pouvoir le distribuer. Le règlement demande que les mises à jour de sécurité soient, quand c’est techniquement possible, fournies séparément des mises à jour de fonctionnalités. Sur un produit embarqué, cela se prépare à la conception : partitionnement A/B ou image de secours, retour arrière automatique en cas d’échec de démarrage, et un processus de release capable de sortir un correctif de sécurité sans embarquer toute la feuille de route fonctionnelle du trimestre.

Le canal de mise à jour est lui-même une cible. Parmi les exemples d’incident grave, le texte cite l’injection de code malveillant dans le canal par lequel le fabricant distribue ses mises à jour de sécurité. La chaîne de signature des images, la protection des clés et la vérification au démarrage sécurisé relèvent donc aussi de l’obligation de déclaration : une compromission de l’infrastructure OTA est un incident à notifier, pas seulement un problème interne.

Le délai est court parce qu’il court dès la prise de connaissance, y compris un vendredi soir. Il faut savoir à l’avance qui reçoit le signal (support, équipe produit, chercheur externe), qui qualifie l’exploitation, qui décide de déclarer et qui saisit la notification. La plateforme de l’ENISA impose ses propres contraintes pratiques : comptes personnels EU Login avec authentification multifacteur, un représentant principal et jusqu’à vingt représentants secondaires par fabricant, une interface uniquement en anglais au lancement et aucune API dans la première version, donc une saisie manuelle.

La notification part vers le CSIRT désigné comme coordinateur dans l’État membre de l’établissement principal du fabricant, et l’ENISA la reçoit en même temps. Côté fabricant, le livre blanc d’Embedded France recommande de structurer cette capacité en PSIRT, une équipe de réponse aux incidents de sécurité des produits. Elle s’aligne sur ISO/IEC 29147 pour la divulgation et sur ISO/IEC 30111 pour le traitement des vulnérabilités. Le livre blanc conseille de la monter après une analyse d’écarts, menée par exemple avec la méthode EBIOS de l’ANSSI.

Une politique de divulgation coordonnée publiée, un point de contact pour les chercheurs et une procédure répétée à blanc au moins une fois valent mieux qu’un document de conformité : le jour où l’exploitation est confirmée, ce sont les ingénieurs firmware qui tiennent le délai.