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é ?
• Comment intégrer la sécurité dès la conception ?
• Le SBOM : pierre angulaire de la conformité CRA
• 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.

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.

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.

Date	Étape	Obligation pour le fabricant
10 décembre 2024	Entrée en vigueur du règlement	Période préparatoire — adapter les processus internes
11 juin 2026	Désignation des organismes notifiés	Préparer le dossier d’évaluation pour produits Important Class I/II
11 septembre 2026	Obligations de reporting actives	Notification des vulnérabilités exploitées sous 24h, incidents graves sous 72h via le portail unique ENISA
11 décembre 2027	Application pleine et entière	Toutes les obligations CRA opposables — marquage CE étendu, SBOM, gestion vulnérabilités sur 5+ ans

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.

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

Catégorie	Exemples	Évaluation
Default (~90 % des produits)	Capteurs IoT grand public, jouets connectés, périphériques USB, applications mobiles non sensibles	Auto-évaluation par le fabricant
Important Class I	Navigateurs, gestionnaires de mots de passe, antivirus, systèmes de domotique avec fonctions de sécurité, contrôleurs industriels génériques	Application de normes harmonisées ou évaluation par tierce partie
Important Class II	Pare-feu d’entreprise, microcontrôleurs pour infrastructures critiques, hyperviseurs, systèmes IDS/IPS	Évaluation obligatoire par tierce partie (organisme notifié)
Critical	Hardware Security Modules, cartes à puce, compteurs intelligents	Schéma européen de certification cybersécurité (EUCC)

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.

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.

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. Aucun n’est optionnel.

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.

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.

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.

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.

• 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.

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, 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.

• 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é