Cyber Resilience Act : ce qu'il exige du matériel

Deux dates, et la plus proche passe inaperçue

Le règlement (UE) 2024/2847, le Cyber Resilience Act (CRA), couvre les « produits comportant des éléments numériques » mis à disposition sur le marché de l’Union. En pratique : tout ce qui embarque du firmware. Pour le matériel grand public et de santé, cela revient à presque tout ce qui s’expédie aujourd’hui.

La plupart des présentations retiennent une date : le 11 décembre 2027, à partir duquel la conformité complète s’applique et un produit non conforme ne peut plus être mis sur le marché. Les feuilles de route s’alignent dessus.

Une autre arrive avant : le 11 septembre 2026, début des obligations de notification de l’article 14. Elle passe inaperçue parce que ce n’est pas une échéance de conception, donc elle n’apparaît sur aucun planning matériel.

Elle devrait y figurer. Voici pourquoi.

L’horloge de notification remonte le temps

À partir du 11 septembre 2026, un fabricant qui prend connaissance d’une vulnérabilité activement exploitée dans son produit, ou d’un incident grave affectant sa sécurité, entre dans une horloge à paliers :

Étape	Délai à compter de la connaissance
Alerte précoce	24 heures
Notification technique	72 heures
Rapport final	14 jours (vulnérabilité exploitée) / 1 mois (incident grave)

Les destinataires sont l’ENISA et le CSIRT national compétent.

Le passage à relire : l’obligation de notification s’applique aux produits déjà mis à disposition sur le marché de l’Union, y compris ceux placés avant l’échéance. Les exigences de conception de l’annexe I visent les produits mis sur le marché à partir de décembre 2027, et les produits antérieurs seulement s’ils subissent une modification substantielle. L’obligation de notification ne connaît pas cette limite.

La question concrète pour une marque en septembre 2026 n’est donc plus « mon prochain produit est-il conforme ». Elle devient :

Un appareil expédié en 2023 présente une vulnérabilité activement exploitée. Le saurons-nous sous 24 heures, et connaissons-nous assez bien son contenu pour décrire le problème ?

Chez la plupart des marques matérielles, la réponse honnête à la seconde moitié est non. C’est un problème de dossiers de fabrication avant d’être un problème de sécurité.

→ Une autre échéance européenne qui devient une décision de boîtier : Règlement européen sur les batteries 2027

La période de support est une décision de nomenclature

L’annexe I impose une période de support déclarée d’au moins cinq ans, ou la durée de vie attendue si elle est plus courte, avec une date de fin connue de l’acheteur au moment de l’achat. Pendant cette période, le fabricant traite les vulnérabilités et fournit gratuitement les correctifs.

Lisez cela comme une contrainte d’approvisionnement, car c’en est une.

Si le module radio de votre conception fait tourner un SDK fournisseur qui cesse de recevoir des correctifs en troisième année, vous ne pouvez plus corriger ce qui repose dessus. Vous aurez déclaré cinq ans de support à la vente et perdu la capacité de l’honorer dès la troisième année, par une décision prise au moment du choix des composants.

Deux questions entrent donc dans la qualification d’un module, au même titre que le prix, le délai et la seconde source :

• Combien de temps ce fournisseur publiera-t-il des correctifs pour ce composant, par écrit, et que se passe-t-il en fin de vie ?
• Existe-t-il une seconde source dont la pile logicielle permettrait une migration sans reconcevoir la carte ?

Ces deux questions ne figurent habituellement pas dans une revue de nomenclature. Elles relèvent pourtant de la même conversation que le risque d’approvisionnement, car c’est le même risque : un composant devient indisponible, commercialement dans un cas, juridiquement dans l’autre.

→ Comment les composants sont notés et ce que signifie un rouge : Matrice de risque d’approvisionnement

Le SBOM doit décrire ce qui s’y trouve vraiment

L’annexe I partie II exige une nomenclature logicielle dans un format courant et lisible par machine, couvrant au moins les dépendances de premier niveau.

Pour une application web, c’est une sortie d’outil de build. Pour un produit physique, c’est une question d’assemblage, car le firmware vous appartient rarement en totalité. Un appareil grand public connecté typique embarque :

• le firmware applicatif écrit pour ce produit
• un SDK fournisseur arrivé avec le module radio
• une pile protocolaire (Bluetooth, Wi-Fi, Thread) livrée sous forme binaire
• un système d’exploitation temps réel
• des bibliothèques open source apportées par l’un des éléments précédents

La marque possède généralement le premier point et n’a aucune visibilité sur le reste, arrivé via le fabricant et ses fournisseurs de modules. Constituer un SBOM réel suppose d’interroger l’usine, puis de lui faire interroger ses fournisseurs.

Cette demande coûte bien moins cher pendant le développement qu’après un incident. Elle vous apprend aussi si votre fournisseur de module accepte de dire ce que contient son binaire, information qu’il vaut mieux détenir avant de l’intégrer.

Sécurisé par défaut, et capable d’être mis à jour

Deux autres exigences de l’annexe I retombent sur des décisions matérielles très précoces.

Sécurisé par défaut signifie que le produit est livré avec une configuration sûre : pas de mot de passe par défaut partagé, pas de service ni de port ouvert inutile, surface d’attaque réduite. Ce sont des valeurs par défaut du firmware, généralement écrites par celui qui écrit le firmware. Si c’est votre sous-traitant, la mise en œuvre lui revient et la spécification vous revient.

Des mises à jour gratuites pendant la période de support supposent que le produit puisse en recevoir. Cette capacité ne relève pas du logiciel :

• Budget flash. Un schéma à deux partitions pour des mises à jour à distance sûres double à peu près l’espace nécessaire. S’en apercevoir après le gel de la nomenclature laisse le choix entre changer de mémoire ou renoncer à l’OTA.
• Connectivité. Un appareil sans accès à Internet ne se met à jour que sur site ou via une application compagnon, avec des taux d’achèvement très inférieurs à ce que suppose une obligation de cinq ans.
• Énergie. Une mise à jour lancée sur batterie faible qui rend l’appareil inutilisable est pire que pas de mise à jour. La logique de mise à jour a donc besoin d’un seuil d’énergie, qui a besoin d’une jauge.

Rien de tout cela ne se rattrape à bas coût. Tout cela se décide en revue d’ingénierie, avant l’outillage.

→ La revue où ces contraintes remontent : Revue de risque DFX avant outillage

Ce que cela change concrètement sur un projet

Pour un produit entrant en développement et destiné à l’Union, trois choses changent :

1. La qualification des modules gagne une question de durée de correctifs. Demandez l’engagement de support par écrit, et traitez « nous ne publions pas cette information » pour ce que c’est : une réponse.
2. Le SBOM devient un livrable. Inscrivez-le au contrat de développement à côté des plans et des rapports d’essai, pour qu’il arrive avec le produit plutôt que d’être reconstitué sous une horloge de 24 heures.
3. L’aptitude à la mise à jour se spécifie avant l’outillage. Réserve flash, schéma de partitions et voie de mise à jour se décident à peu de frais au stade du concept et coûtent cher une fois le boîtier réalisé.

Pour les produits déjà commercialisés, la question à court terme est plus étroite et plus pressante : savez-vous ce qu’ils contiennent, et en combien de temps ?

Note sur la portée

Ceci est une lecture de textes publiés, non un avis juridique, et les modalités d’application du CRA continuent d’être précisées par des normes et des lignes directrices. Faites confirmer par un conseil qualifié la manière dont il s’applique à votre catégorie de produit et à vos marchés avant d’en tirer un plan. Ce qui est assez stable pour concevoir, c’est la direction : le support de sécurité est devenu un engagement déclaré et daté, et les décisions qui le rendent possible ou impossible se prennent dans le matériel, tôt.

→ Le détail au niveau carte, du schéma à la ligne SMT : Sous-traitance en électronique grand public