Cyber Resilience Act : ce qui change concrètement pour un produit embarqué
Le règlement (UE) 2024/2847, dit Cyber Resilience Act, n'est pas une recommandation de bonnes pratiques. C'est un règlement d'application directe, adossé au marquage CE. Son article 64 prévoit, pour le non-respect des exigences essentielles de l'annexe I et des obligations des articles 13 et 14, des amendes administratives pouvant atteindre 15 000 000 d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Pour un fabricant de produits embarqués, il transforme la sécurité d'un argument commercial en condition de mise sur le marché.
Les échéances réelles
Trois dates comptent, et deux sont déjà passées ou imminentes.
10 décembre 2024 : entrée en vigueur, vingt jours après la publication au Journal officiel. Rien d'exigible encore.
11 septembre 2026 : les obligations de signalement deviennent applicables. C'est la première contrainte opérationnelle, et elle est souvent sous-estimée parce qu'elle arrive plus de deux ans avant le reste.
11 décembre 2027 : application pleine. Tout produit comportant des éléments numériques mis sur le marché après cette date doit être conforme.
Le point qui surprend les équipes : le CRA s'applique au produit mis sur le marché, pas au produit conçu. Un firmware écrit en 2025 et vendu en 2028 est concerné. Les décisions d'architecture prises aujourd'hui, notamment le choix d'un SoC sans démarrage sécurisé ou sans mémoire OTP pour les clés, engagent la conformité de 2028.
Les trois classes, et pourquoi la vôtre compte
Le règlement classe les produits selon leur criticité, et la classe détermine qui évalue la conformité.
Produits par défaut, la grande majorité : auto-évaluation. Le fabricant applique les exigences, constitue son dossier technique et appose le marquage CE lui-même.
Classe I (annexe III), qui inclut les gestionnaires de mots de passe, les systèmes d'exploitation, les microprocesseurs et microcontrôleurs dotés de fonctions de sécurité, les routeurs, les VPN : auto-évaluation possible uniquement si des normes harmonisées sont appliquées intégralement. Sinon, organisme notifié.
Classe II, la plus critique, qui couvre notamment les hyperviseurs, les pare-feu industriels et les éléments sécurisés matériels : organisme notifié obligatoire.
La ligne « microcontrôleurs dotés de fonctions de sécurité » mérite une lecture attentive. Un STM32 avec TrustZone, un élément sécurisé, ou un module de communication avec pile TLS intégrée peuvent y basculer selon leur rôle dans le produit. Ce classement change entièrement le calendrier et le coût de mise en conformité, et c'est la première chose à trancher.
Les exigences de l'annexe I, traduites en décisions de firmware
L'annexe I, partie I, est la liste des exigences essentielles. Voici ce qu'elles impliquent dans le code, et non dans un document.
Livraison sans vulnérabilité exploitable connue. Impossible à garantir sans savoir ce qu'on embarque : cela présuppose une nomenclature logicielle et une veille CVE automatisée sur les composants tiers, ce qui est précisément l'objet d'un SBOM.
Configuration sécurisée par défaut. Pas de mot de passe par défaut identique sur toute la série. Pas de port de débogage ouvert. Pas de service réseau actif sans nécessité. Concrètement, cela signifie désactiver le JTAG ou le SWD en production, ce qui est irréversible sur beaucoup de microcontrôleurs et doit donc être décidé avant la fabrication.
Protection contre l'accès non autorisé et intégrité. C'est le démarrage sécurisé, avec vérification de signature à chaque étage, et un stockage de clés qui ne se lit pas simplement en dumpant la mémoire flash.
Confidentialité et minimisation des données. Chiffrement au repos et en transit, et surtout ne collecter que ce qui est nécessaire à la fonction.
Mises à jour de sécurité, gratuites et si possible automatiques. Le règlement impose un mécanisme de mise à jour. Un produit dont le firmware ne peut pas être remplacé sur le terrain devient, de fait, non conforme.
Journalisation des accès et surveillance. Le produit doit pouvoir enregistrer les événements pertinents pour la sécurité, ce qui suppose de la mémoire persistante et une politique de rotation.
La période de support, la contrainte la plus structurante
Le fabricant doit assurer les mises à jour de sécurité pendant la durée de vie attendue du produit, avec un minimum de cinq ans, sauf si la durée de vie est manifestement plus courte.
Cinq ans de correctifs de sécurité, pour un firmware embarqué, ce n'est pas une clause administrative. C'est une contrainte d'ingénierie qui remonte jusqu'au choix du silicium et de la pile logicielle. Il faut pouvoir recompiler, resigner et redéployer un firmware cinq ans après, donc figer une chaîne de compilation reproductible, archiver les sources de chaque dépendance et conserver les clés de signature en état.
C'est aussi ce qui rend un système de construction à couches, avec archivage des sources et manifestes de licences, nettement plus confortable qu'un arbre modifié à la main.
Le signalement sous 24 heures
C'est l'obligation la plus opérationnelle, et elle démarre en septembre 2026.
En cas de vulnérabilité activement exploitée ou d'incident grave affectant la sécurité du produit, le fabricant doit émettre une alerte précoce à l'ENISA et au CSIRT compétent sous 24 heures après en avoir pris connaissance. Puis une notification sous 72 heures. Le rapport final est attendu au plus tard 14 jours après qu'une mesure corrective ou d'atténuation est disponible dans le cas d'une vulnérabilité, et dans le mois suivant la notification à 72 heures dans le cas d'un incident grave.
Vingt-quatre heures suppose une astreinte, un canal de réception des signalements, et une procédure écrite qui ne dépend pas d'une seule personne. C'est un processus à mettre en place, pas une ligne de code.
Ce qu'il faut décider maintenant
| Décision | Pourquoi maintenant |
|---|---|
| Classe du produit (défaut, I ou II) | Détermine s'il faut un organisme notifié, donc le calendrier |
| SoC avec démarrage sécurisé et stockage de clés | Non rattrapable après le choix du silicium |
| Mécanisme de mise à jour sur le terrain | Sans lui, pas de conformité possible |
| Génération de SBOM dans la chaîne de compilation | Prérequis de la veille CVE et du dossier technique |
| Reproductibilité de la construction sur cinq ans | Condition de la capacité à corriger |
| Procédure de signalement sous 24 heures | Exigible dès septembre 2026 |
Le piège classique consiste à traiter le CRA comme un chantier documentaire à ouvrir en 2027. Or les quatre premières lignes de ce tableau sont des décisions d'architecture matérielle et logicielle : les prendre après coup revient à refaire le produit.
Références
- Règlement (UE) 2024/2847, texte intégral sur EUR-Lex
- Commission européenne, Cyber Resilience Act, dates d'application
- Commission européenne, résumé du texte législatif, délais de signalement 24 h, 72 h, 14 jours et un mois
- Article 64 du règlement, amendes administratives
Pour aller plus loin
Ces exigences deviennent concrètes quand on les traduit en dossier technique et en choix d'implémentation, produit par produit. C'est l'objet de notre formation dédiée au Cyber Resilience Act, et de nos cours sur le développement de systèmes embarqués sécurisés.