Cyber Resilience Act et directive RED : ce que doit anticiper un fabricant d'objets connectés

Pour un fabricant d'objets connectés vendus dans l'Union, deux textes européens se superposent en ce moment : la directive sur les équipements radioélectriques (RED) et le règlement sur la cyber-résilience (CRA). Leurs calendriers diffèrent, et les confondre est le meilleur moyen d'être pris de court.

RED : déjà obligatoire pour les équipements radio

Le règlement délégué (UE) 2022/30 a introduit des exigences de cybersécurité dans la directive RED : protection des réseaux, protection des données personnelles, prévention de la fraude. Elles s'appliquent depuis le 1^er août 2025, avec les normes harmonisées de la série EN 18031 publiées au Journal officiel en janvier 2025 (Zühlke, RedComply). Elles concernent tout produit comportant une liaison radio — Wi-Fi, Bluetooth, Zigbee, LoRa, cellulaire.

CRA : un calendrier en deux temps

• 11 septembre 2026 : les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves — alerte précoce sous 24 heures, notification sous 72 heures, rapport final ensuite — via une plateforme unique gérée par l'ENISA (Commission européenne).
• 11 décembre 2027 : application de l'ensemble des exigences essentielles — conception sécurisée, gestion des vulnérabilités, documentation technique, mises à jour de sécurité sur la durée de vie du produit. À cette échéance, selon les analyses juridiques, le CRA devient le cadre principal de cybersécurité pour ces produits, et les dispositions de cybersécurité de la RED sont appelées à s'effacer pour éviter les doublons.

Le CRA a un champ plus large que la RED : il couvre tous les produits comportant des éléments numériques, avec ou sans radio. Un fabricant d'objets sans fil devra donc, en pratique, répondre aux deux.

Ce que cela implique concrètement

• Un processus de gestion des vulnérabilités opérationnel dès maintenant : une adresse de signalement, une personne d'astreinte, un moyen de qualifier une vulnérabilité « activement exploitée » et de la notifier sous 24 heures. Le 11 septembre est passé : le processus doit exister, pas être en projet.
• Un inventaire des composants (nomenclature logicielle) : savoir quelle bibliothèque, dans quelle version, tourne dans quel produit — y compris les composants libres, dont le fabricant répond.
• Des mises à jour signées : l'OTA sécurisé n'est plus un confort mais une condition de conformité sur toute la durée de vie annoncée.
• Une durée de support annoncée et tenue : le fabricant doit assurer les correctifs de sécurité pendant la période de support qu'il déclare.
• Une documentation technique à jour : évaluation des risques, choix de conception, résultats de tests (voir l'article sur l'IA embarquée pour la dimension modèle et données).

Une conception qui facilite tout

Ce qui coûte cher, c'est d'ajouter ces fonctions après coup à un produit conçu sans elles. Le démarrage sécurisé, le stockage protégé des clés, les identifiants uniques par appareil (jamais de mot de passe par défaut commun), le chiffrement des communications et un canal de mise à jour signé se prévoient dès la carte électronique. Notre page Qualité & normalisation présente le référentiel normatif que nous prenons pour cadre de conception.

Cet article est une information générale, pas un avis juridique : la qualification d'un produit et le choix de la procédure d'évaluation de conformité dépendent de chaque cas.

Sources

• Commission européenne — CRA, obligations de signalement
• Zühlke — CRA compliance starts with the RED delegated act
• RedComply — EN 18031 vs. the EU Cyber Resilience Act