Cyber Resilience Act 2026 : guide de conformité IoT et embarqué

Le Cyber Resilience Act (CRA) est le règlement européen qui impose des exigences de cybersécurité à tout produit avec éléments numériques vendu dans l'UE. Entré en vigueur le 10 décembre 2024, il devient pleinement contraignant le 11 décembre 2027, avec une obligation de reporting des vulnérabilités exploitées sous 24 heures dès le 11 septembre 2026.

Pour les fabricants d'équipements industriels, IoT, médicaux ou grand public, ce texte change radicalement les règles du jeu. Là où la directive RED couvrait déjà la sécurité radio, le CRA étend les obligations à tout produit logiciel et matériel connectable, avec un horizon de support obligatoire de cinq ans minimum, un SBOM (Software Bill of Materials) à fournir, une politique de divulgation de vulnérabilités à publier, et des sanctions financières atteignant 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Chez AESTECHNO, bureau d'études électronique basé à Montpellier, nous avons commencé à intégrer les exigences CRA dans nos projets dès leur conception. Ce guide pratique détaille les obligations, le calendrier réel à respecter, et les choix techniques qui sécurisent la conformité, non pas comme une formalité de fin de projet, mais comme une discipline d'ingénierie alignée sur notre signature : le design produit EST le design production, conforme dès la première itération.

Sommaire

Cet article couvre dans l'ordre les fondamentaux du CRA, son calendrier d'application, sa portée juridique, les exigences techniques de sécurité, le SBOM, notre méthodologie AESTECHNO, des cas concrets et une checklist actionnable. Utilisez les liens ci-dessous pour accéder directement à une section.

• Qu'est-ce que le Cyber Resilience Act (CRA) ?
• Quel calendrier de conformité CRA respecter ?
• À qui s'applique le CRA ?
• Pourquoi les 24 heures de reporting ne sont pas une formalité ?
• Où déclarer : la Single Reporting Platform de l'ENISA
• Comment intégrer la sécurité dès la conception ?
• Le SBOM : pierre angulaire de la conformité CRA
• Le CRA pour les systèmes embarqués et Linux embarqué
• Notre méthodologie AESTECHNO pour préparer le CRA
• Cas concrets rencontrés en lab
• Outils, standards et toolchain conformité
• En résumé : la checklist CRA
• FAQ : Cyber Resilience Act

Qu'est-ce que le Cyber Resilience Act (CRA) ?

Le Cyber Resilience Act est un règlement européen, Règlement (UE) 2024/2847, qui établit des exigences horizontales de cybersécurité pour tous les produits avec éléments numériques (PEN) mis sur le marché de l'Union européenne. Adopté en novembre 2024, il vise à combler les lacunes du cadre réglementaire actuel et à uniformiser les obligations sur l'ensemble du cycle de vie du produit. Le texte est entré en vigueur le 10 décembre 2024 et devient pleinement contraignant le 11 décembre 2027, avec une étape intermédiaire décisive le 11 septembre 2026 pour les obligations de notification. Les sanctions prévues atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial, et le support de sécurité doit couvrir au moins cinq ans. Pour une analyse exhaustive article par article, voir le guide Cyber Resilience Act 2024/2847 : champ, classes, calendrier.

Concrètement, le CRA encadre quatre dimensions :

• Conception sécurisée : le produit doit être conçu, développé et fabriqué pour assurer un niveau approprié de cybersécurité, en intégrant les exigences essentielles dès la phase de design.
• Gestion des vulnérabilités : le fabricant doit identifier, traiter et notifier les vulnérabilités tout au long de la durée de support du produit, fixée par défaut à un minimum de cinq ans.
• Transparence : un SBOM (Software Bill of Materials) doit être disponible, une politique de divulgation des vulnérabilités doit être publiée, et la documentation technique doit être maintenue.
• Conformité formelle : marquage CE étendu au volet cybersécurité, déclaration UE de conformité, évaluation par tierce partie pour les produits classés Important.

Les sanctions pour non-conformité atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le plus élevé des deux. Pour les fabricants d'équipements industriels et IoT déjà soumis à RED, EMC ou LVD, le CRA s'ajoute sans s'y substituer, il faut donc l'intégrer comme une couche supplémentaire dans le dossier technique CE. Notre checklist de certification CE/RED détaille le contenu attendu de ce dossier technique, de la déclaration UE de conformité aux obligations CRA qui survivent à la mise sur le marché.

Quel calendrier de conformité CRA respecter ?

Contrairement à de nombreuses directives européennes qui laissent une période de transition étalée, le CRA suit un calendrier resserré. Les fabricants ont environ trois ans entre l'entrée en vigueur et l'obligation pleine et entière, mais la première échéance contraignante intervient bien avant cette date butoir : il s'agit de l'obligation de reporting, qui devient active dès septembre 2026. Trois dates structurent la préparation : le 10 décembre 2024 marque l'entrée en vigueur et ouvre la période préparatoire ; le 11 septembre 2026 active la notification des vulnérabilités activement exploitées sous 24 heures et des incidents graves sous 72 heures ; le 11 décembre 2027 rend l'ensemble des exigences applicables, marquage CE étendu compris. La date opérationnellement contraignante est donc septembre 2026, quinze mois avant l'échéance que beaucoup de fabricants retiennent à tort.

Le 11 septembre 2026 est la date à retenir absolument. Beaucoup de fabricants supposent qu'ils ont jusqu'en décembre 2027 pour se mettre en conformité. C'est faux : l'obligation de notifier les vulnérabilités activement exploitées sous 24 heures et les incidents graves sous 72 heures intervient quinze mois plus tôt. Sans processus interne de détection, de triage et de notification déjà en place à cette date, l'organisation est mécaniquement non conforme dès la première vulnérabilité publique.

À qui s'applique le CRA ?

Le règlement vise tous les produits avec éléments numériques mis sur le marché de l'UE, qu'ils soient matériels, logiciels, ou des services numériques associés. La portée est volontairement large pour éviter les contournements, et la plupart des produits IoT, équipements industriels connectés, équipements médicaux non couverts par le MDR, équipements grand public et logiciels professionnels sont concernés. Les exemptions sont étroites et couvrent pour l'essentiel les produits déjà régis par une réglementation sectorielle équivalente, comme les dispositifs médicaux sous MDR. La question à se poser n'est donc pas « suis-je concerné ? » mais « dans quelle catégorie mon produit tombe-t-il ? », car le niveau d'évaluation exigé en dépend. Un fabricant hors UE est concerné dès lors que son produit est mis sur le marché européen : la localisation du siège ne protège de rien.

Le CRA distingue quatre catégories selon le niveau de criticité, ce qui détermine la procédure d'évaluation de conformité applicable :

Quelques exemptions existent : produits déjà couverts par le MDR (médical), aviation civile (Règlement 2018/1139), véhicules automobiles (Règlement 2019/2144) et matériels militaires. Pour les fabricants à cheval sur plusieurs réglementations, l'arbitrage est délicat, un dispositif médical IoT peut sortir du champ CRA mais y rentrer pour son application mobile compagnon.

Pourquoi les 24 heures de reporting ne sont pas une formalité ?

L'obligation de notifier les vulnérabilités activement exploitées sous 24 heures, qui devient effective le 11 septembre 2026, est probablement la disposition la plus opérationnellement contraignante du CRA. Elle exige du fabricant trois capacités qui ne s'improvisent pas : détecter une exploitation active, qualifier rapidement la portée, et déclencher la notification dans la fenêtre légale. La notification passe par le portail unique européen opéré par l'ENISA, avec un préavis initial sous 24 heures puis un rapport intermédiaire sous 72 heures pour les incidents graves. Sans processus interne de détection, de triage et de décision déjà répété avant l'échéance, la fenêtre légale est mécaniquement intenable : c'est une capacité organisationnelle à construire, pas un formulaire à remplir.

Concrètement, le fabricant doit :

• Disposer d'un canal de réception des vulnérabilités (politique CVD, Coordinated Vulnerability Disclosure) accessible publiquement, conforme à ISO/IEC 29147 et ISO/IEC 30111.
• Maintenir une équipe ou un processus de triage 24/7 capable de qualifier la criticité d'un signalement entrant.
• Notifier l'ENISA et le CSIRT national via le portail unique européen, avec un préavis initial sous 24 heures et un rapport intermédiaire sous 72 heures.
• Notifier les utilisateurs concernés sans délai injustifié, avec mesures de mitigation.

Contrairement à l'idée qu'une équipe sécurité dédiée est réservée aux grandes entreprises, dans notre pratique chez AESTECHNO, nous avons constaté qu'une PME peut tenir l'engagement 24h à condition d'avoir préparé en amont les bons artefacts : une boîte aux lettres dédiée monitorée hors heures ouvrées, un playbook de triage avec critères de gravité documentés, et un canal d'escalade vers le décisionnaire technique. Ce qui prend du temps, ce n'est pas la notification, c'est la prise de décision en pleine nuit avec des informations partielles. Préparer le processus revient à pré-décider en temps calme ce qui sera décidé sous pression.

Où déclarer : la Single Reporting Platform de l'ENISA

La Single Reporting Platform (SRP) est le guichet unique européen par lequel transitent les déclarations imposées par l'article 14 du CRA. Le fabricant y dépose une notification unique, que la plateforme route ensuite vers le CSIRT national compétent et vers l'ENISA, sans démarche parallèle auprès de chaque État membre concerné.

Cette centralisation allège la charge administrative, mais elle ne déplace pas le point de départ du chronomètre. La fenêtre légale se déclenche quand le fabricant a connaissance de l'exploitation active, pas quand il termine son analyse. Chez AESTECHNO, nous recommandons de créer et de tester le compte sur la plateforme avant l'échéance, au même titre qu'un dossier technique se prépare en amont : découvrir une interface pendant un incident consomme des heures que la fenêtre de 24 heures ne contient pas.

Le parc déjà vendu est concerné, contrairement au reste du règlement

C'est le point qui surprend le plus les fabricants que nous accompagnons. L'article 69(2) prévoit que les produits mis sur le marché avant le 11 décembre 2027 ne relèvent du règlement que s'ils font l'objet d'une modification substantielle. L'article 69(3) déroge explicitement à cette règle pour le seul article 14 : les obligations de déclaration s'appliquent à tous les produits dans le champ du règlement mis sur le marché avant cette date. L'antériorité protège la conformité technique, elle ne protège pas le reporting.

Un capteur industriel expédié en 2023, toujours installé chez un client et toujours dans le champ du CRA, ouvre donc une obligation de déclaration dès le 11 septembre 2026 si une vulnérabilité y est activement exploitée. Dans notre pratique, c'est cette catégorie qui pose le plus de difficultés : le parc installé est rarement inventorié avec la rigueur appliquée aux produits en cours de conception, et la responsabilité de sa surveillance n'est presque jamais attribuée nommément. Notre méthodologie de sécurisation d'un produit IoT de la conception au déploiement traite ce périmètre au même titre que les nouveaux développements.

Une réserve de calendrier à intégrer au plan

La Commission européenne indique que la plateforme sera opérationnelle au 11 septembre 2026. Elle n'était toutefois pas encore ouverte fin juin 2026, à moins de trois mois de l'échéance. Nous conseillons donc de construire le processus interne indépendamment de l'outil : l'obligation court à la date prévue, que l'interface soit stabilisée ou non, et un processus qui suppose un portail encore inconnu n'est pas un processus. Les rappels de nos fondamentaux de cybersécurité pour l'électronique embarquée et les exigences déjà applicables au titre de la certification CE / RED pour les objets connectés restent les deux entrées les plus rapides pour cadrer ce travail.

Comment intégrer la sécurité dès la conception ?

Le CRA introduit le principe de security by design comme exigence essentielle : la sécurité ne peut plus être une couche ajoutée en fin de projet, elle doit structurer l'architecture du produit dès le cahier des charges. Pour un produit avec éléments numériques typique, sept piliers techniques doivent être traités, et aucun n'est optionnel. Ces piliers couvrent la modélisation de menaces de type STRIDE, le démarrage sécurisé (secure boot), le chiffrement des communications en TLS 1.3, les mises à jour OTA signées avec protection anti-retour-arrière, l'inventaire logiciel SBOM, la politique de divulgation coordonnée (CVD) et la documentation technique associée. Chacun laisse une trace vérifiable dans le dossier de conformité, ce qui permet de constater l'avancement au fil du projet.

1. Threat modeling structuré

L'analyse de menaces, selon des méthodes éprouvées comme STRIDE, PASTA ou OCTAVE, doit être documentée dès la phase de cadrage. Elle identifie les actifs à protéger, les attaquants probables, les vecteurs d'attaque, les contre-mesures associées. Sans cette étape, l'architecture sécurité repose sur des suppositions implicites, exactement ce que le CRA refuse.

2. Boot sécurisé et chaîne de confiance

La chaîne de confiance démarre au premier octet exécuté. Un secure boot vérifie cryptographiquement la signature du bootloader, qui vérifie la signature de l'image firmware, qui vérifie la signature des composants applicatifs. Les SoC modernes (NXP i.MX, ST STM32H/U5, Nordic nRF54, Renesas RA) intègrent ces mécanismes nativement, mais leur configuration correcte est un travail d'ingénieur, pas une case à cocher.

3. Stockage cryptographique des secrets

Les clés de signature, les certificats et les credentials ne doivent jamais être stockés en clair dans la flash. Les secure elements dédiés (Microchip ATECC608B, NXP SE050, Infineon OPTIGA Trust M, ST STSAFE-A110) ou les enclaves matérielles ARM TrustZone fournissent ce stockage. Le coût d'un SE est de quelques dixièmes d'euro, négligeable face au risque d'extraction de clés.

4. Communications chiffrées

Toute communication réseau doit utiliser des protocoles chiffrés modernes : TLS 1.3 minimum pour HTTP/MQTT, DTLS pour CoAP, ou chiffrement applicatif end-to-end pour les architectures sans intermédiaire de confiance. Les bibliothèques mbed TLS, wolfSSL ou BearSSL couvrent les contraintes embarquées.

5. Mécanisme de mise à jour signé

Les mises à jour OTA doivent être signées numériquement, vérifiées avant installation, et capables de rollback en cas d'échec. Sans cette capacité, un produit ne peut être patché en cas de vulnérabilité, ce qui rend le CRA mécaniquement intenable. Les bibliothèques MCUboot (FreeRTOS) et Mender (Linux) sont aujourd'hui des standards de facto.

6. Politique de divulgation publiée

Une page web publique, accessible via une URL stable type https://votreentreprise.com/security ou via un fichier security.txt à la racine du domaine (RFC 9116), doit décrire le canal de signalement, le périmètre couvert, les délais de traitement et la politique de divulgation coordonnée. Sans ce dispositif, les chercheurs en sécurité ne peuvent pas vous notifier, et le CRA vous tient pour responsable de cette absence.

7. Fin de support documentée

La période de support, minimum 5 ans selon le règlement, davantage pour les produits dont la durée de vie attendue est plus longue, doit être annoncée à l'achat et tenue. La fin de support déclenche elle-même des obligations : notification aux utilisateurs, documentation finale des vulnérabilités résiduelles, recommandations de migration.

Le SBOM : pierre angulaire de la conformité CRA

Le Software Bill of Materials (SBOM) est l'inventaire détaillé de tous les composants logiciels d'un produit, bibliothèques tierces, dépendances open source, modules propriétaires, versions exactes. Le CRA en fait une obligation explicite : sans SBOM à jour, impossible de prouver que vous savez ce qui tourne dans votre produit, donc impossible de garantir que vous pouvez réagir à une vulnérabilité dans une de ces dépendances. Générer l'inventaire une fois ne suffit pas : il doit être régénéré à chaque build et confronté en continu aux bases de vulnérabilités connues, faute de quoi il devient un document mort qui donne une fausse assurance de conformité.

Deux formats standards dominent le marché et sont reconnus par la Commission européenne :

• CycloneDX : format développé par OWASP, JSON ou XML, optimisé pour la sécurité. Riche en métadonnées (licences, hash, fournisseurs, dépendances transitives). Notre format préféré en projets industriels pour sa lisibilité par les outils de veille CVE.
• SPDX : format Linux Foundation, standard ISO/IEC 5962:2021, plus orienté licences et compliance juridique. Souvent imposé par les grands donneurs d'ordre et l'administration américaine.

Générer un SBOM ponctuellement ne suffit pas. Le CRA exige que le SBOM soit maintenu à jour tout au long du cycle de vie. Cela impose une intégration dans le pipeline CI/CD : à chaque build firmware, le SBOM est régénéré, comparé au précédent, croisé avec les bases CVE/NVD, et archivé. Les outils Syft (Anchore), cdxgen, SPDX SBOM Generator ou les solutions intégrées comme Black Duck et FOSSA automatisent ce travail.

Sur nos projets clients, nous avons constaté que la difficulté n'est pas de générer le SBOM initial, c'est de le maintenir vivant pendant 5 à 10 ans. Une dépendance transitive obscure peut devenir critique trois ans après la mise sur le marché. Sans automatisation CI/CD couplée à une veille CVE quotidienne, la dette sécurité s'accumule silencieusement jusqu'à exploser au pire moment.

Du scan à la remédiation : le vrai défi

Trouver les CVE est la partie facile. Sur un projet embarqué complexe, un scan Grype ou Trivy peut remonter plus de 3000 vulnérabilités depuis un SBOM Yocto, un mur de données brut qu'aucune équipe ne peut traiter sans priorisation. L'enjeu d'ingénierie se déplace alors du scan vers le pilotage de la remédiation : trier par contexte opérationnel (vecteur d'attaque, privilèges requis, complexité d'exploitation), suivre les états de correction (To Do, In Progress, Fixed, Whitelisted), documenter les justifications de non-remédiation, et produire un reporting décisionnel pour les instances techniques et qualité.

Sur ce point précis, nous partageons l'analyse de Thierry Durand chez Embedded Expertise, bureau d'études spécialisé en Linux embarqué, Yocto et cybersécurité produit, qui souligne que la vraie valeur ajoutée réside dans la capacité à piloter la correction effective, pas dans la collecte du constat. La conformité CRA est un cadre réglementaire ; la sécurité réelle du produit se joue dans l'architecture et dans la discipline de remédiation maintenue sur toute la durée de support. Cette convergence de vue entre bureaux d'études cybersécurité français valide l'approche : scanner est nécessaire mais insuffisant, la remédiation pilotée est le livrable qui compte pour le CRA.

Le CRA pour les systèmes embarqués et Linux embarqué

Les systèmes embarqués entrent pleinement dans le champ du CRA : un produit connecté construit sur un microcontrôleur ou sur Linux embarqué est un produit avec éléments numériques comme un autre, soumis aux mêmes obligations de SBOM, de gestion des vulnérabilités et de notification décrites plus haut. La différence tient à l'exécution. Une image Linux embarqué assemblée avec Yocto ou Buildroot agrège des centaines de paquets, noyau, bootloader, bibliothèque C, démons userspace, si bien que l'inventaire logiciel, la veille CVE et le mécanisme de mise à jour doivent fonctionner à l'échelle d'une distribution, exactement l'origine du mur de 3000 vulnérabilités remonté d'un SBOM Yocto évoqué plus haut. Un produit classe MCU sous FreeRTOS ou Zephyr a un inventaire plus réduit, mais moins de ressources pour la cryptographie et les mises à jour. Dans les deux cas, les leviers de conformité restent identiques : un SBOM généré par le système de build, une veille CVE noyau et userspace continue, des mises à jour OTA signées avec rollback, et une fenêtre de support de sécurité d'au moins cinq ans.

• Produits Linux embarqué : SBOM SPDX ou CycloneDX généré par le système de build, scan Grype ou Trivy à chaque build CI, mises à jour signées déployées via RAUC ou Mender avec rollback, et une branche noyau LTS dont l'horizon de maintenance couvre la durée de support annoncée. Notre comparatif des distributions Linux embarqué détaille les arbitrages Yocto / Buildroot / Debian derrière ce choix.
• Produits classe MCU : SBOM assemblé depuis le manifeste de dépendances verrouillé, images signées MCUboot avec protection anti-rollback, secure element pour le stockage des clés, mbed TLS ou wolfSSL pour TLS 1.3. Notre comparatif Zephyr / FreeRTOS / Linux embarqué montre comment le choix d'OS structure cette liste.
• Les deux classes : politique CVD publiée, processus de notification 24h/72h, et la discipline de threat model détaillée dans notre guide cybersécurité IoT industriel.

Pour Linux embarqué spécifiquement, le système de build est la source naturelle du SBOM : selon la documentation du Yocto Project, la classe create-spdx émet des documents SPDX au moment du build, Buildroot expose les manifestes de paquets et de licences via make legal-info, et Syft génère du CycloneDX depuis le rootfs final. Les vulnérabilités noyau méritent une règle de triage dédiée : depuis que le projet du noyau Linux est devenu sa propre CVE Numbering Authority en 2024, les CVE noyau sont attribuées à un rythme bien plus élevé, et seul un filtrage par les sous-systèmes et drivers réellement compilés dans votre image garde le pilotage de remédiation décrit plus haut tenable sur une fenêtre de support de cinq ans.

Notre méthodologie AESTECHNO pour préparer le CRA

Notre approche du CRA s'inscrit dans la continuité de notre signature : le design produit EST le design production, avec la conformité intégrée dès la première itération et non bricolée en fin de cycle. Pour le CRA spécifiquement, nous structurons nos projets autour d'une checklist en cinq jalons que nous appliquons à chaque nouveau produit destiné au marché européen. Ces jalons alignent la conformité sur les phases de développement existantes plutôt que d'ajouter un processus parallèle : chaque jalon produit un livrable qui alimente directement le dossier technique CRA, du modèle de menaces initial jusqu'au processus de notification testé à blanc avant l'échéance de septembre 2026. La conformité se constate ainsi au fil du projet au lieu de se découvrir à la fin.

1. Cadrage CRA dans le cahier des charges, Dès la phase de spécification, nous identifions la catégorie probable du produit (Default, Important Class I/II, Critical), les exigences essentielles applicables et les contraintes d'évaluation. Cette étape impacte directement les choix d'architecture matérielle (présence d'un secure element, capacité de signed boot, ressources mémoire pour TLS 1.3).
2. Threat model documenté, Avant le routage du PCB, nous produisons un document STRIDE listant actifs, attaquants, vecteurs et contre-mesures. Ce document devient une annexe du dossier technique CE.
3. Architecture sécurité by design, Sélection du SE (ATECC608B, SE050, OPTIGA), configuration du secure boot (MCUboot, U-Boot signed images, ROM bootloaders propriétaires), choix du framework crypto (mbed TLS, wolfSSL), définition de la stratégie de mise à jour OTA (Mender, SUOTA, custom signed FOTA).
4. Pipeline CI/CD avec SBOM continu, Notre pipeline CI/CD embarqué intègre la génération automatique du SBOM (CycloneDX), le scan de vulnérabilités CVE, la signature du firmware et l'auto-déploiement conditionné aux tests. Chaque livrable est traçable et reproductible.
5. Préparation opérationnelle 24h/72h, Mise en place de la politique CVD publique, du security.txt, du canal de réception, du playbook de triage et de la chaîne d'escalade. Sans ces artefacts, l'obligation de septembre 2026 n'est pas tenable.

Cette discipline n'est pas spécifique à nos clients ; nous l'appliquons à nos propres outils internes. Dans notre lab, nous utilisons les mêmes pipelines CI/CD, les mêmes secure elements, les mêmes processus de divulgation que ceux que nous mettons en place chez nos clients. Le retour terrain qui en découle alimente directement la qualité de ce que nous livrons.

Cas concrets rencontrés en lab

Voici trois exemples concrets de problèmes que nous avons rencontrés en accompagnant des clients sur leur préparation CRA. Ces cas illustrent que les obligations du règlement révèlent souvent des dettes techniques accumulées qui n'apparaissaient pas tant qu'aucune réglementation ne les forçait à la surface. Ils proviennent de missions d'accompagnement menées depuis notre laboratoire de Montpellier et sont restitués sans identifier les clients, conformément à nos engagements de confidentialité, car leur valeur est générique : chaque équipe qui prépare le CRA rencontrera au moins une de ces situations. Le point commun est que le coût de remédiation croît avec la proximité de l'échéance, ce qui plaide pour un état des lieux précoce.

• Cas 1 : produit IoT sans secure boot, à six mois de la mise sur le marché. Un client venait nous voir avec un produit basé sur un STM32 standard, firmware non signé, OTA via HTTP en clair. Contrairement à l'intuition que la conformité CRA pouvait être ajoutée par firmware update, la requalification a imposé un changement de variante MCU (passage à un STM32 avec ROM bootloader signé), un re-design partiel du PCB pour intégrer un ATECC608B et une refonte complète du protocole OTA. Coût d'un correctif tardif : six mois de retard et un respin PCB. Nous préconisons systématiquement de poser la question "quel est le secure boot ?" dès le choix du MCU, pas après.
• Cas 2 : SBOM impossible à reconstituer rétroactivement. Sur un produit déjà en production depuis trois ans, le client devait fournir un SBOM CycloneDX pour répondre à un appel d'offres incluant des clauses CRA anticipées. Contrairement à l'idée qu'un scan de binaire suffit, la reconstruction d'un SBOM précis nécessite l'environnement de build d'origine, toolchain GCC exacte, versions de bibliothèques tierces, options de compilation. Sans pipeline CI/CD reproductible archivé, la reconstitution prend des semaines et reste partielle. Plutôt que de subir cette dette, nous préconisons l'intégration SBOM dès la première itération.
• Cas 3 : politique de divulgation absente, vulnérabilité publique non remontée. Un chercheur en sécurité avait identifié une faille critique sur un produit client, n'avait trouvé aucun canal de signalement, et avait publié sur Twitter après 90 jours sans réponse. Le client n'avait jamais été notifié, il a découvert la vulnérabilité par le service client trois jours plus tard. Sans politique CVD publique conforme RFC 9116, le fabricant ne respecte pas seulement le CRA : il s'expose à une divulgation publique non coordonnée, ce qui maximise le risque d'exploitation. Nous installons systématiquement security.txt et la page /security dès la mise en ligne du site produit.

Outils, standards et toolchain conformité

La conformité CRA s'appuie sur un écosystème d'outils et de normes qui évolue rapidement. Voici les références que nous utilisons régulièrement chez AESTECHNO et que nous recommandons d'évaluer en fonction du contexte projet. L'écosystème se répartit en trois familles : les normes et standards qui fixent les exigences, les formats d'inventaire logiciel reconnus par la Commission européenne (CycloneDX et SPDX), et les outils d'analyse qui automatisent la détection de vulnérabilités dans la chaîne de build. Les deux formats d'inventaire sont eux-mêmes normalisés : CycloneDX est publié par l'OWASP et SPDX est un standard ISO/IEC 5962:2021. Chaque choix doit rester réversible : la réglementation évoluera d'ici 2027 et la toolchain doit pouvoir suivre, sans dépendance irréversible à un fournisseur unique.

Standards et normes harmonisées :

• EN 18031-1/-2/-3, normes harmonisées en cours de finalisation pour le volet RED Art. 3.3 (cybersécurité radio), souvent invoquées comme base de conformité CRA en attendant les normes harmonisées CRA spécifiques.
• ETSI EN 303 645, norme cybersécurité IoT grand public, base solide pour la plupart des produits Default class.
• IEC 62443-4-1, exigences de processus de développement sécurisé (Security Development Lifecycle).
• IEC 62443-4-2, exigences techniques composant pour systèmes industriels.
• NIST IR 8259/8425, NIST SP 800-213, guides américains sur la cybersécurité IoT, alignés avec la philosophie CRA.
• ISO/IEC 27001 / 27034, management de la sécurité de l'information et sécurité applicative.
• ISO/IEC 29147 / 30111, divulgation et traitement coordonné des vulnérabilités.
• RFC 9116, format security.txt pour publication des canaux de signalement.

Outils de génération et veille SBOM :

• Syft (Anchore), génération SBOM CycloneDX/SPDX depuis les artefacts de build, intégration CI native.
• cdxgen, générateur multi-langage CycloneDX, utile pour les projets polyglottes.
• Grype (Anchore), scanner CVE couplé à Syft, idéal pour CI/CD.
• Trivy, scanner vulnérabilités multi-cible, supporte conteneurs et binaires firmware.
• FOSSA, Black Duck, Snyk, solutions commerciales avec dashboards de gouvernance, recommandées pour les organisations à fort volume produit.

Outils d'analyse statique et qualité code :

• Coverity (Synopsys), Polyspace (MathWorks), CodeSonar (GrammaTech), analyse statique avancée, qualifiable pour normes safety/security.
• cppcheck, clang-tidy, scan-build, alternatives open source intégrables en CI sans coût de licence.
• OWASP IoT Top 10, référentiel des dix vulnérabilités IoT les plus fréquentes, base de checklist sécurité.

Composants matériels sécurité :

• Secure elements : Microchip ATECC608B, NXP SE050, Infineon OPTIGA Trust M, ST STSAFE-A110.
• Enclaves matérielles : ARM TrustZone (Cortex-M33/M55, Cortex-A), Intel TDX, AMD SEV-SNP.
• HSM : Yubico HSM 2, Thales Luna, Utimaco SecurityServer pour signature firmware en production.

Plutôt que de reconstituer une stack maison, nous recommandons d'aligner le choix d'outils avec les standards déjà en place dans l'organisation, un client qui utilise déjà GitLab CI a tout intérêt à intégrer Syft et Trivy en pipeline plutôt que de basculer sur une suite commerciale entièrement nouvelle.

En résumé : la checklist CRA

Le Cyber Resilience Act n'est pas une formalité administrative qui se règle en fin de projet, c'est une discipline d'ingénierie qui structure l'architecture du produit et les processus de l'organisation. Pour un fabricant qui démarre sa préparation, voici les dix points actionnables à valider avant septembre 2026. Cette liste condense les obligations développées dans l'article : cadrage réglementaire du produit, sécurité dès la conception, inventaire logiciel vivant, processus de notification opérationnel et support de sécurité planifié sur au moins cinq ans. Chaque point non validé à l'approche de l'échéance représente un risque réglementaire direct, avec des sanctions pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial. Imprimez-la et passez-la en revue de projet avant chaque jalon.

• Catégoriser le produit (Default / Important Class I/II / Critical) pour identifier la procédure d'évaluation applicable.
• Documenter le threat model selon STRIDE ou équivalent, avec actifs, attaquants et contre-mesures.
• Architecturer le secure boot et la chaîne de confiance dès le choix du MCU/SoC, pas après.
• Intégrer un secure element (ATECC608B, SE050, OPTIGA) ou une enclave matérielle pour le stockage des secrets.
• Implémenter TLS 1.3 / DTLS ou un chiffrement applicatif end-to-end pour toutes les communications réseau.
• Mettre en place un mécanisme OTA signé avec rollback (MCUboot, Mender, custom signed FOTA).
• Générer un SBOM CycloneDX ou SPDX automatiquement à chaque build via le pipeline CI/CD.
• Publier la politique CVD (page /security + fichier security.txt RFC 9116).
• Préparer le processus de notification 24h/72h avec playbook de triage et chaîne d'escalade.
• Annoncer la durée de support (5 ans minimum) à l'achat et planifier la roadmap de patching.

Pour les fabricants qui découvrent le règlement maintenant, le calendrier reste tenable mais serré, il faut compter trois à six mois pour mettre en place les artefacts de base (politique CVD, SBOM, processus 24h) et neuf à dix-huit mois pour ré-architecturer un produit existant. La fenêtre se referme. Démarrer maintenant, c'est se donner le temps de bien faire ; attendre septembre 2026, c'est subir.

FAQ : Cyber Resilience Act

Qu'est-ce que le Cyber Resilience Act en une phrase ?
Le CRA est un règlement européen (UE 2024/2847) qui impose des exigences de cybersécurité à tout produit avec éléments numériques vendu dans l'UE, avec marquage CE étendu, SBOM obligatoire, gestion des vulnérabilités sur 5 ans minimum et reporting des incidents sous 24h dès septembre 2026.

Quels sont les délais clés à retenir ?
Trois dates structurent le calendrier : 10 décembre 2024 (entrée en vigueur, période préparatoire), 11 septembre 2026 (obligations de reporting actives, vulnérabilités exploitées sous 24h, incidents graves sous 72h), 11 décembre 2027 (application pleine et entière, marquage CE étendu obligatoire). La date opérationnellement contraignante est septembre 2026.

Comment savoir si mon produit est concerné par le CRA ?
La quasi-totalité des produits avec composants logiciels ou hardware connectables sont concernés : équipements IoT, capteurs connectés, équipements industriels, applications mobiles compagnons, logiciels professionnels. Les exceptions principales sont les produits déjà couverts par d'autres règlements sectoriels (MDR pour le médical, aviation civile, automobile, militaire). En cas de doute, consulter l'Annexe III et IV du règlement et l'analyse d'organisme notifié.

Quelles sont les sanctions financières en cas de non-conformité ?
Les sanctions atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Pour les manquements aux obligations de reporting et de coopération, les sanctions peuvent atteindre 5 millions d'euros ou 1 % du chiffre d'affaires. Les autorités nationales de surveillance (en France, l'ANSSI et la DGCCRF) appliquent ces sanctions.

Le CRA s'applique-t-il aux produits déjà sur le marché ?
Les produits mis sur le marché avant le 11 décembre 2027 ne sont pas soumis au CRA, sauf modification substantielle après cette date. Mais attention : une mise à jour firmware significative, un changement matériel, une nouvelle variante peuvent constituer une modification substantielle qui requalifie le produit comme nouvelle mise sur le marché, donc soumis intégralement au CRA. La continuité commerciale d'un catalogue existant impose une stratégie de gestion des évolutions claire.

Comment AESTECHNO peut accompagner la préparation au CRA ?
Nous intégrons les exigences CRA dès le cadrage technique des nouveaux projets : threat model, architecture security by design, sélection des composants sécurité (secure element, MCU avec secure boot), pipeline CI/CD avec SBOM continu, mise en place de la politique de divulgation. Pour les produits existants, nous proposons un audit de gap analysis identifiant les écarts vs CRA et un plan de remédiation chiffré et priorisé. Notre approche s'inscrit dans notre signature : le design produit est conforme dès la première itération, pas adapté en fin de cycle.

Articles Connexes

• Cybersécurité IoT industriel : menaces et solutions, vue d'ensemble cyber pour produits connectés industriels
• Sécuriser un produit IoT de la conception au déploiement, méthodologie security by design pas à pas
• Certification CE/RED pour produits IoT, articulation avec RED Article 3.3 et marquage CE
• DevOps embarqué : CI/CD et tests automatisés, pipeline pour SBOM continu et signature firmware
• Concevoir l'électronique pour réussir dans l'IoT, fondamentaux de conception produit connecté
• Logiciel embarqué industriel : guide complet, pratiques de développement firmware sécurisé