--- title: "Le Cyber Resilience Act" description: "Cyber Resilience Act (règlement UE 2024/2847) : produits concernés, exigences de sécurité, gestion des vulnérabilités, notifications et plan d'action." url: https://acove.fr/blog/le-cyber-resilience-act/ author: Michael Harlaut date: 2025-08-28 lastmod: 2025-08-28 tags: ["Actualité"] language: fr-FR --- # Le Cyber Resilience Act *Cyber Resilience Act (règlement UE 2024/2847) : produits concernés, exigences de sécurité, gestion des vulnérabilités, notifications et plan d'action.* Vous connaissez certainement la directive NIS 2, et si vous êtes déjà concerné vous avez même peut être déjà avancé sur la mise en œuvre. Notez que si vous pensez attendre, [ce n'est pas forcément une bonne idée d'ailleurs](https://acove.fr/blog/nis2-attendra-vraiment/) Mais oublions NIS 2 pour le moment : le sujet d'aujourd'hui est un autre règlement : le **Cyber Resilience Act**, référencé [(EU) 2024/2847.](https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202402847) A partir de cet instant, on va parler de **CRA**, puisqu'on est entre nous. L'histoire du CRA remonte à 2022, quand les états membres ont commencé à se pencher sur la meilleure manière de sécuriser les produits "comportant des composants numériques". > [!NOTE] > Objectif : **garantir la sécurité, la transparence et la confiance des utilisateurs**. Parce qu'il n'est plus tolérable de voir des produits faire tourner du code sans la moindre prise en compte de la cybersécurité. Ces travaux ont donné lieu à la publication du règlement CRA le 23 octobre 2024. Notez qu'on parle bien d'un règlement. La nuance avec une directive est que le règlement est d'application immédiate dans l'intégralité des états membres sans donner lieu à une transposition locale. > [!NOTE] > En résumé, **le CRA s'impose dès maintenant**, avec des contrôles dès 2026 ! ## Applicabilité du CRA Le CRA s’applique aux « **produits comportant des éléments numériques** » **mis à disposition sur le marché UE**, dont l’usage prévu (ou raisonnablement prévisible) **implique une connexion logique ou physique à un appareil ou à un réseau**. Il couvre aussi les solutions de **traitement de données à distance fournies par le fabricant** lorsqu’elles sont nécessaires au fonctionnement du produit (ex. fonctions cloud d’un objet connecté). C'est encore un peu vague ? Prenons quelques exemples : | **Objet** | **Assujetti Oui / Non** | **Pourquoi** | |---|---|---| | Smartphone | **Oui** | Système d’exploitation + connexion internet + MAJ nécessaires | | Logiciel commercial | **Oui** | Distribué sur le marché, doit être maintenu et sécurisé | | Serrure connectée | **Oui** | Sécurité physique dépendant d’un accès numérique | | Voiture connectée | Non | Déjà couverte par réglementation automobile | | Dispositif médical connecté | Non | Déjà réglementé par le MDR (Medical Device Regulation) | | Logiciel Open Source gratuit | Non | Pas d’activité commerciale | | Logiciel Open Source avec version commerciale | **Oui** | Exigences allégées | | Machine à laver connectée | **Oui** | Traitement des données, se connecte à un smartphone | | Machine à laver non connectée | Non | | A ce stade, vous devriez commencer à savoir si vos produits sont concernés ou pas. ### Les implications du CRA Le CRA impose un certain nombre d'exigences qui vont nécessiter un travail de fond plus ou moins important, selon votre maturité sur le sujet. #### Exigences « produit » (Annexe I – Partie I) - Les produits doivent, entre autres, être sécurisés par conception et par défaut, protéger confidentialité–intégrité–disponibilité, limiter la surface d’attaque, journaliser les événements pertinents, permettre l’effacement sécurisé des données, et maintenir les fonctions essentielles même après incident. #### Gestion des vulnérabilités (Annexe I – Partie II) - Le fabricant doit inventorier les composants et documenter les vulnérabilités, y compris via une SBOM (au minimum les dépendances de premier niveau) dans un format lisible par machine. - Le fabricant doit tester régulièrement la sécurité, publier des informations sur les vulnérabilités une fois corrigées, mettre en place une politique de divulgation coordonnée, et distribuer des mises à jour de sécurité, automatiquement quand c’est techniquement possible. #### Période de support & mise à jour - Le fabricant doit définir une « période de support » proportionnée, au moins 5 ans (ou la durée d’usage prévue si <5 ans), et maintenir accessibles les mises à jour de sécurité ≥10 ans (ou pendant la période de support si plus longue). - L’échéance de support (mois/année) doit être communiquée au moment de l’achat. #### Information à l’utilisateur, marquage et documentation - Fournir un point de contact vulnérabilités et des instructions (installation sécurisée, MAJ, fin de vie). - Préparer la déclaration UE de conformité et le marquage CE, avec dossier technique (incluant SBOM, politique CVD, analyses de risque, etc.) #### Notification à ENISA / CSIRT (Article 14) À compter de l’application de l’art. 14 (voir le calendrier plus loin) : - Vulnérabilité activement exploitée : Alerte précoce < 24 h après découverte. Notification détaillée < 72 h. Rapport final ≤ 14 jours après la mise à disposition d’une mesure corrective. - Incident grave affectant la sécurité du produit : Alerte précoce < 24 h.  Notification d’incident < 72 h. Rapport final ≤ 1 mois. Notifications via la plateforme unique gérée par ENISA ; information aux utilisateurs « en temps utile ». #### Classes de produits & évaluation de conformité - Produits « importants » (Annexe III) – ex. OS, routeurs, VPN, SIEM, gestion d’identités, pare-feu/IDS/IPS (classe II), etc. Les classes I/II impliquent des modules d’évaluation plus stricts (jusqu’à organisme notifié). - Produits « critiques » (Annexe IV) – ex. HSM, smartcards/secure elements, smart meter gateways : certification européenne possible/exigée à un niveau d’assurance au moins “substantiel” si un schéma existe. > [!NOTE] > On le voit, **il y aura pas mal d'efforts à faire** pour une prise en compte de l'ensemble des exigences, comme dans beaucoup de projets de conformité. > > Et donc un véritable besoin d'anticipation pour coller au calendrier et ne pas devoir tout faire dans l'urgence (qui dit urgence, dit inconfort et hausse des coûts). ### Et justement, parlons du calendrier : - Fin 2025, publication des premiers documents d'harmonisation. - 11 juin 2026 : application du Chapitre IV (mise en place et notification des organismes d’évaluation de conformité). A ce jour ce point reste à mettre en place, en France. - **11 sept. 2026** : application de l’Article 14 (obligations de reporting vulnérabilités/incidents via ENISA) - 11 déc. 2027 : application générale du CRA (exigences produit, CVD, SBOM, CE, etc.). - Produits déjà sur le marché avant le 11 déc. 2027 : restent hors champ **sauf** en cas de modification substantielle (mais les obligations de l’art. 14 s’appliquent à eux aussi à partir du 11 sept. 2026). > [!NOTE] > En gros, la date la plus importante est celle du 11 septembre 2026. Car à cette date, **vous devez être en mesure de pouvoir effectuer les signalements** des vulnérabilités et incidents selon les contraintes données plus haut. Et ça ne s'improvise pas. Parce que pour cela il faut une procédure en place, mais aussi (et surtout) pouvoir disposer des capacités de détection associées. Pour vous donner une idée des implications, voici une "petite" check list ... ### Les actions à anticiper : - Nommer un sponsor & **un pilote CRA** (produits, juridique, cyber, qualité). - **Cartographier** le portefeuille (hardware, software, services « à distance » du fabricant) et classer vis-à-vis des annexes III/IV. - **Mesurer l'écart** entre les pratiques actuelleset l'Annexe I : CIA, surface d’attaque, journaux, effacement, mises à jour, etc. - **Définir** la période de support (≥5 ans en principe) et le plan de patch management (y compris accessibilité des MAJ ≥10 ans). - **Mettre en place** une politique CVD publique, un PSIRT, une adresse de contact, et simuler la chaîne de report (24 h / 72 h / 14 j / 1 mois) vers ENISA/CSIRT. - Générer une **SBOM** (formats SPDX ou CycloneDX) au minimum des dépendances de premier niveau et l’intégrer à la doc technique. - Préparer la **documentation** : Dossier technique (Annexe VII), Déclaration UE (Annexe V), Informations utilisateur (Annexe II), marquage CE. - **Surveiller** les [normes harmonisées](https://www.stan4cra.eu/technicalwork) & schémas de certification EUCC pour bénéficier de présomptions de conformité. - **Planifier** l’évaluation : si produit en classe II ou critique, anticiper l’organisme notifié (capacité limitée), conformément aux exigences de notification d’ici septembre 2026. A noter, les organismes ne sont pas encore connus pour le moment, ce qui n'empêche pas de commencer ... - **Former** les équipes produit/DevSecOps/Support sur les exigences et le calendrier ; aligner avec NIS2 et RGPD pour éviter les doublons de notification. > [!NOTE] > En bref, si vous vous demandez quand commencer, j'ai une réponse extrêmement claire : **maintenant** ! Parce que même sans les fameux documents d'harmonisation, il y a déjà beaucoup de choses qui relèvent du bon sens (disposer d'une SBOM par exemple, mais pas seulement). ### Les bénéfices à se mettre en conformité - Accès plus simple au marché UE via un cadre unique (fin des exigences nationales variables selon les pays). - Réduction du risque (incidents, rappels, litiges), coûts de cycle de vie mieux maîtrisés grâce aux MAJ structurées. - Avantage concurrentiel (période de support claire, sécurité démontrée), meilleure prise en compte dans les achats publics/privé. Ne négligez pas un aspect important : comme souvent, ce sont les partenaires qui vont rapidement vous demander où vous en êtes. Et ils risquent de ne pas attendre la fin d'année 2026 ! ## En conclusion J'ai pratiqué le développement de logiciel sur des matériels divers et pratiqué l'informatique embarquée pendant plus d'une décennie. Je connais les contraintes associées et je suis conscient que, pour beaucoup de structures, la mise en conformité va demander un effort parfois significatif. Mais en tant que consommateur, je suis aussi rassuré de voir que, ENFIN, cet aspect longtemps négligé de la cybersécurité va prendre de l'importance. Si vous avez besoin d'éclaircissements sur ce sujet, [n'hésitez pas à me contacter](https://acove.fr/contact/) ou à parcourir [ma page orientée conseil](https://acove.fr/conseil/).