Cyber Resilience Act : obligations des fabricants dès 2026

La directive RED et sa norme EN 18031 s’appliquent depuis le 1er août 2025. Une deuxième vague réglementaire arrive maintenant : le Cyber Resilience Act, ou CRA — le règlement (UE) 2024/2847. Son principe : tout produit comportant des éléments numériques vendu dans l’Union devra être cybersécurisé dès la conception. Il devra ensuite le rester pendant tout son cycle de vie. Premières obligations depuis le 11 septembre 2026, application complète le 11 décembre 2027. Vous concevez, ou faites concevoir, un objet connecté, une carte communicante, un équipement industriel piloté par logiciel ? Le CRA vous concerne directement. Le logiciel PC ou tablette qui accompagne le produit entre lui aussi dans le champ. Voici ce qu’il faut retenir — et comment l’anticiper dès la conception.

Qu’est-ce que le Cyber Resilience Act ?

Le Cyber Resilience Act est le règlement européen sur la cyberrésilience. Il fixe pour la première fois des exigences essentielles de cybersécurité, applicables aux produits matériels comme logiciels vendus dans l’Union européenne. Entré en vigueur le 10 décembre 2024, il complète le cadre existant : NIS2 pour les organisations, RED pour les équipements radio. Le CRA, lui, cible le produit lui-même — et toute sa chaîne d’approvisionnement logicielle.

L’objectif du CRA est double. D’abord réduire les vulnérabilités des produits numériques mis sur le marché. Ensuite maintenir cette sécurité pendant toute la vie du produit. Cela passe par des mises à jour de sécurité et une information claire de l’utilisateur.

Quels produits et quelles entreprises sont concernés ?

Le CRA s’applique aux produits comportant des éléments numériques : matériels et logiciels, y compris les composants mis sur le marché séparément. Concrètement, pour l’électronique industrielle :

• cartes électroniques avec microcontrôleur et firmware ;
• objets connectés, quel que soit le protocole (LoRa, NB-IoT/LTE-M, Wi-Fi, Bluetooth…) ;
• passerelles et équipements communicants (domotique, agricole, industrie) ;
• logiciels embarqués et applications associées au produit ;
• logiciels livrés ou vendus seuls : application PC (Windows, macOS, Linux), application tablette ou smartphone, outil de configuration ou de supervision, bibliothèque logicielle, système d’exploitation.

C’est le point le plus souvent mal compris : le CRA ne vise pas que le matériel. Le règlement le définit à l’article 3, point 1 : « un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément ». Autrement dit : un logiciel PC de configuration, une application tablette de supervision, un utilitaire de mise à jour. Chacun est un produit à part entière. Il porte les mêmes obligations de SBOM, de correctifs et de signalement que la carte qu’il pilote. La direction générale des Entreprises le dit sans détour : sont concernés « les éditeurs de logiciels, y compris lorsque le logiciel est fourni indépendamment du matériel ».

Une seule condition de rattachement, posée à l’article 2. L’utilisation prévue ou raisonnablement prévisible du produit doit comprendre « une connexion directe ou indirecte, logique ou physique, à un dispositif ou à un réseau ». Ainsi, une application qui dialogue avec une carte en USB, en série ou en Bluetooth remplit cette condition. Celle qui va simplement chercher ses mises à jour aussi. Un logiciel totalement isolé, sans réseau ni liaison à un équipement, reste l’exception.

Le règlement classe les produits selon leur criticité :

• Catégorie par défaut : la grande majorité des produits — le fabricant démontre lui-même la conformité (autoévaluation), comme pour le marquage CE actuel ;
• Produits « importants » (classes I et II) : systèmes d’exploitation, pare-feux, hyperviseurs… avec des exigences d’évaluation renforcées ;
• Produits critiques : soumis à certification (HSM, compteurs intelligents…).

La plupart des cartes et objets connectés industriels relèvent de la catégorie par défaut. Un acte d’exécution de la Commission européenne précise les catégories de produits.

Certains secteurs sont exclus du CRA : les dispositifs médicaux (règlements MDR/IVDR), l’automobile et le secteur marin. Tous sont déjà couverts par une réglementation sectorielle. Les logiciels open source développés hors cadre commercial bénéficient par ailleurs d’un régime allégé. Mais leur intégration dans un produit commercial reste, elle, sous la responsabilité du fabricant qui les embarque.

Le logiciel en mode service (SaaS) mérite une précision, car il se confond facilement avec le cas précédent. Un service en nuage autonome n’est en principe pas un produit au sens du CRA. Il relève d’autres textes, au premier rang desquels la directive NIS 2. En revanche, une solution de traitement de données à distance sans laquelle le produit ne fonctionne pas en fait partie. Elle entre donc dans le champ (considérant 12 du règlement).

Le CRA impose des obligations à toute la chaîne. Les fabricants au premier chef, mais aussi les importateurs et les distributeurs. Ces derniers doivent vérifier le marquage CE et la conformité des produits qu’ils mettent sur le marché européen. Un donneur d’ordres qui fait concevoir son produit en porte, lui, la responsabilité de fabricant. C’est lui qui le met sur le marché.

CRA et RED EN 18031 : quelle articulation ?

Les deux textes ne coexistent que le temps d’une transition. Ce qu’on appelle le « RED DA » n’est pas une directive. C’est un règlement délégué, le règlement (UE) 2022/30. Il active les exigences de cybersécurité de la directive RED 2014/53/UE, détaillées par les normes harmonisées EN 18031. Il ne couvre que les équipements radio, et il s’applique depuis le 1er août 2025.

En février 2026, la Commission a adopté un règlement délégué qui abroge ce texte au 11 décembre 2027. C’est le jour même où le CRA devient pleinement applicable. Le motif est explicite. Les exigences du CRA reprennent l’ensemble des éléments couverts par les exigences de cybersécurité de la RED. Maintenir les deux régimes soumettrait donc les mêmes équipements radio à une double obligation.

Pour un fabricant, cela dessine deux périodes nettes. Le régime applicable dépend de la date de mise sur le marché — pas de la conception, pas de la fabrication :

• Jusqu’au 10 décembre 2027 : un équipement radio se conforme via la RED et les normes EN 18031.
• À partir du 11 décembre 2027 : c’est le CRA qui s’applique, seul — et à tous les produits comportant des éléments numériques, radio ou non, matériel ou logiciel.

Le passage de l’un à l’autre élargit le périmètre. Mais il change surtout la nature de l’exigence. La RED évalue le produit au moment de sa mise sur le marché. Le CRA, lui, impose des obligations dans la durée : gestion des vulnérabilités, mises à jour, signalement des incidents. Il exige en plus une transparence sur la composition logicielle du produit (SBOM).

Un produit conforme EN 18031 arrivera donc au 11 décembre 2027 avec une base solide mais un dossier incomplet. Il lui manquera l’inventaire logiciel, le processus de correction des vulnérabilités, et la capacité à signaler vite. À terme, des normes harmonisées publiées au Journal officiel donneront, comme pour la RED, une présomption de conformité au CRA.

Les obligations des fabricants

Concrètement, le CRA exige une analyse de risques dès la conception : surface d’attaque réduite, configuration sécurisée par défaut, protection des données traitées. Les mécanismes de mise à jour, eux, se prévoient dès l’architecture. C’est le principe security by design / secure by default.

Le SBOM (Software Bill of Materials) est l’inventaire des composants logiciels du produit — firmware, bibliothèques, middlewares, composants open source, modules tiers. Il permet de savoir immédiatement si une vulnérabilité publiée (CVE) affecte le produit, et conditionne toute la gestion des vulnérabilités exigée par le CRA.

Par ailleurs, le fabricant doit disposer d’un processus documenté pour identifier, corriger et diffuser les correctifs de sécurité pendant la période d’assistance. Il doit aussi informer les utilisateurs des mises à jour disponibles.

Toute vulnérabilité activement exploitée et tout incident grave devront être signalés via la plateforme de l’ENISA, l’agence européenne pour la cybersécurité. Le délai est court : alerte précoce sous 24 h, notification sous 72 h. En France, le CERT-FR, rattaché à l’ANSSI, est le CSIRT coordinateur qui reçoit ces notifications. L’ANFR, elle, assure la surveillance du marché.

Enfin, le CRA s’intègre au dispositif CE existant. Il demande une évaluation de la conformité — autoévaluation par défaut, organisme notifié pour les produits importants ou critiques. S’y ajoutent une déclaration UE de conformité, une documentation technique tenue à jour, et le marquage CE.

Le calendrier du CRA et les sanctions

Échéance	Obligation
10 décembre 2024	Entrée en vigueur du règlement (UE) 2024/2847
11 septembre 2026	Signalement obligatoire des vulnérabilités activement exploitées et incidents graves (24 h / 72 h)
11 décembre 2027	Application complète : tout produit mis sur le marché doit être conforme

Les sanctions sont dissuasives : jusqu’à 15 M€ ou 2,5 % du chiffre d’affaires mondial pour les manquements aux exigences essentielles. Mais le vrai enjeu de calendrier est industriel. Un produit qui entre en conception aujourd’hui sera commercialisé sous le régime du CRA. Or intégrer la cybersécurité après coup coûte toujours plus cher que de la concevoir dès le départ. En jeu : le microcontrôleur (secure boot, stockage des clés), l’architecture du firmware, la mise à jour, l’inventaire logiciel.

Comment Innovel anticipe le CRA sur ses projets

Cette logique « sécurité dès la conception », nous l’appliquons déjà. Concrètement, sur nos projets de cartes électroniques et de firmwares embarqués, nous générons des SBOM au format CycloneDX. C’est l’inventaire complet des composants logiciels : HAL, middlewares, bibliothèques open source, bootloader, modules développés en interne. Nous documentons ensuite l’analyse des vulnérabilités publiées (CVE) au format VEX. Le composant est-il réellement exploitable dans le produit ? Quelle correction a été appliquée ? C’est précisément la mécanique documentaire que le CRA attend d’un fabricant.

Pour un donneur d’ordres, faire ce travail dès la phase d’étude change tout. C’est vrai en particulier pour une PME sans équipe cybersécurité dédiée. Le dossier technique se construit alors au fil du projet. Il n’est plus à reconstituer dans l’urgence au moment de la mise sur le marché.

Se préparer au CRA : les bonnes questions à se poser

Avant de lancer ou de refondre un produit connecté, cinq questions cadrent l’effort :

1. Dans quelle catégorie du CRA le produit tombera-t-il (par défaut, important, critique) ?
2. Comment les mises à jour de sécurité seront-elles déployées sur le terrain (OTA, intervention…) ?
3. Qui maintiendra l’inventaire logiciel (SBOM) et la veille sur les vulnérabilités ?
4. Qui signalera un incident dans les 24 h, et selon quel processus interne ?
5. Quelle durée d’assistance est promise au client final ?

Ces choix structurent l’architecture électronique et logicielle — ils se prennent dès la conception, pas en fin de projet.

Ressources officielles utiles

• La page CRA de l’ANSSI — synthèse française de référence ;
• Le Cyber Resilience Act sur le site de la Commission européenne — texte et actualités du règlement ;
• Le texte du règlement (UE) 2024/2847 sur EUR-Lex ;
• La page CRA de l’ANFR — surveillance du marché ;
• Le décryptage CRA de la direction générale des Entreprises — ce qui change pour les entreprises françaises, y compris les éditeurs de logiciels.

En résumé

En définitive, le Cyber Resilience Act transforme la cybersécurité d’option en exigence réglementaire, pour tout produit numérique vendu en Europe. Le calendrier est désormais court : signalement obligatoire depuis septembre 2026, conformité complète fin 2027. Comme pour le marquage CE et la RED, la clé reste d’intégrer ces exigences dès le cahier des charges. Vous préparez un produit connecté ou une évolution d’un produit existant ? Parlons-en en amont : demandez un devis — l’anticipation réglementaire fait partie de l’étude.

FAQ — Cyber Resilience Act