Règlement (UE) 2024/2847 sur la cyberrésilience
Direct answer
Le Cyber Resilience Act (Règlement (UE) 2024/2847, aussi appelé règlement européen sur la cyberrésilience) est la première loi européenne à imposer des exigences obligatoires de cybersécurité aux produits à éléments numériques. Il couvre les fabricants, importateurs et distributeurs, exige des produits sécurisés dès la conception et exempts de vulnérabilités connues exploitables, impose la gestion des vulnérabilités et une liste des composants logiciels, et introduit une obligation de déclaration en 24 h / 72 h / 14 jours à l'ENISA à partir du 11 septembre 2026 (Art. 14, 71).
Le Règlement sur la cyberrésilience (Règlement (UE) 2024/2847) est la première loi européenne à imposer des exigences obligatoires de cybersécurité aux produits à éléments numériques, couvrant le matériel et les logiciels tout au long de leur cycle de vie (Art. 1).
Il déplace la responsabilité de la sécurité d'un produit vers l'organisation qui le met sur le marché, et non vers l'utilisateur. En pratique, un produit à éléments numériques ne peut être mis à disposition dans l'UE que s'il satisfait aux exigences essentielles de l'Annexe I et que le fabricant a rempli les obligations qui y sont attachées, démontrées par une évaluation de la conformité, une déclaration UE de conformité et le marquage CE. Pour une équipe sécurité ou conformité, le RCR se lit mieux non comme une nouvelle norme à adopter de zéro, mais comme un ensemble d'obligations au niveau produit qui s'ajoutent aux obligations organisationnelles que vous portez déjà au titre de NIS2 et, pour les entités financières, de DORA.
Le RCR s'applique aux fabricants, importateurs et distributeurs de produits à éléments numériques dont l'usage prévu ou raisonnablement prévisible inclut une connexion de données directe ou indirecte (Art. 2, 3).
Les fabricants portent les obligations principales : conception sécurisée, documentation technique, évaluation de la conformité et gestion des vulnérabilités. Les importateurs ne peuvent mettre sur le marché que des produits conformes et doivent vérifier que les obligations du fabricant ont été respectées ; les distributeurs doivent agir avec diligence et vérifier la présence du marquage CE et de la documentation. Le règlement est extraterritorial : une entreprise établie hors de l'UE qui vend dans l'Union est dans le périmètre et doit s'assurer qu'un opérateur économique responsable existe dans l'UE. Les solutions de traitement de données à distance nécessaires au fonctionnement du produit sont traitées comme faisant partie du produit et sont également couvertes. Les produits déjà régis par des règles sectorielles, tels que les dispositifs médicaux, les véhicules à moteur et l'aviation civile, sont exclus, et les logiciels open source non commerciaux développés en dehors d'une activité commerciale se situent largement hors du périmètre.
Le logiciel en tant que service (SaaS) autonome se situe hors du périmètre lorsqu'il fonctionne indépendamment d'un produit physique. Les composants cloud ne sont réglementés que lorsqu'ils constituent des solutions de traitement de données à distance -- c'est-à-dire que le produit physique dépend fonctionnellement de ce traitement à distance pour exécuter une fonction essentielle, et que le logiciel distant est développé par le fabricant ou sous sa responsabilité explicite.
Le RCR crée également une catégorie juridique spécifique de gestionnaire de logiciels open source. Les gestionnaires doivent maintenir une politique de cybersécurité, coopérer avec les autorités de surveillance du marché et déclarer les vulnérabilités activement exploitées, mais ils sont explicitement exemptés des amendes administratives de l'article 64.
Une nuance de chaîne d'approvisionnement : le RCR impose des obligations à l'entité qui met le produit sur le marché de l'UE sous son propre nom ou sa marque. Un développeur OEM en amont qui fournit des composants ou du matériel en marque blanche à un tiers n'est pas le « fabricant » aux fins de conformité RCR, sauf s'il commercialise également le produit fini directement. La charge réglementaire suit la marque sur l'emballage -- et non l'origine de la technologie sous-jacente.
La voie de conformité dépend du degré de criticité du produit (Art. 6--7, Annexes III--IV). La classification suit la fonctionnalité essentielle du produit, et non chaque fonction qu'il inclut.
| Classe | Exemples | Voie de conformité |
|---|---|---|
| Par défaut | La majorité des produits à éléments numériques | Auto-évaluation |
| Important, classe I | Gestionnaires de mots de passe, logiciels de gestion de réseau, VPN | Normes harmonisées ou évaluation par un tiers |
| Important, classe II | Systèmes d'exploitation, pare-feu, microprocesseurs | Évaluation par un tiers |
| Critique | Compteurs intelligents, cartes à puce, éléments sécurisés | Certification obligatoire |
L'Annexe I distingue les exigences essentielles entre les propriétés que le produit doit posséder et les processus que le fabricant doit mettre en œuvre (Annexe I).
Le produit doit être sécurisé dès la conception et par défaut, livré exempt de vulnérabilités connues exploitables et fourni avec une surface d'attaque minimisée. Le fabricant doit mettre en œuvre un processus de gestion des vulnérabilités, fournir des mises à jour de sécurité gratuites pendant une période de support définie (généralement attendue d'au moins cinq ans, sauf si l'usage prévu du produit est plus court), maintenir une liste des composants logiciels dans un format lisible par machine couramment utilisé, et déclarer les vulnérabilités activement exploitées et les incidents graves. Pour une équipe déjà engagée dans un programme ISO 27001 ou NIS2, la gestion des vulnérabilités, le risque et les mécanismes de preuve recoupent largement ce que vous avez déjà ; le travail réellement nouveau est au niveau produit et documentaire, et non un second système de management.
La démonstration de conformité suit une séquence fixe, et la voie empruntée est déterminée par la classe du produit (Art. 28, 32, Annexes V, VII).
Compilez la documentation technique décrite à l'Annexe VII et conservez-la pendant dix ans après la mise sur le marché du produit ; réalisez l'évaluation de la conformité (les produits par défaut peuvent s'auto-évaluer, les produits importants recourent aux normes harmonisées ou à un organisme notifié, les produits critiques exigent une certification) ; rédigez la déclaration UE de conformité conformément à l'Annexe V ; et apposer le marquage CE. Le RCR est, en pratique, un prérequis strict pour le marquage CE sur les produits à éléments numériques, ce qui explique pourquoi les fabricants hors UE qui s'appuient sur le marquage CE pour la distribution sont dans le périmètre même s'ils ne vendent jamais directement dans l'Union.
À partir du 11 septembre 2026, les fabricants doivent déclarer les vulnérabilités activement exploitées et les incidents graves à l'ENISA et au CSIRT national concerné via la plateforme unique de déclaration (Art. 14, 16).
L'horloge fonctionne en trois étapes : alerte précoce à 24 heures, notification à 72 heures et rapport final à 14 jours (un mois pour les incidents). L'horloge de 24 heures ne s'interrompt pas pour les week-ends -- contrairement à DORA (règlement délégué (UE) 2025/301 de la Commission).
| Règlement sur la cyberrésilience | NIS2 | DORA | |
|---|---|---|---|
| Instrument | Regulation (EU) 2024/2847 | Directive (EU) 2022/2555 | Regulation (EU) 2022/2554 |
| Ce qu'il régit | Sécurité des produits à éléments numériques | Cybersécurité des entités essentielles et importantes | Risque TIC des entités financières |
| Ce que vous déclarez | Vulnérabilités activement exploitées et incidents graves | Incidents significatifs | Incidents majeurs liés aux TIC |
| Alerte précoce | 24 heures à compter de la prise de connaissance (pas de report le week-end) | 24 heures | La classification comme majeur doit intervenir sans retard indu (dans les ~24 h suivant la prise de connaissance) ; la notification initiale est ensuite due dans les 4 heures suivant cette classification |
| Notification | 72 heures | 72 heures | Rapport intermédiaire : 72 heures |
| Rapport final | 14 jours après correction (vulnérabilité) · 1 mois (incident grave) | 1 mois | 1 mois |
| Déclarer à | ENISA + CSIRT national (plateforme unique de déclaration) | CSIRT / autorité compétente | Autorité financière compétente |
| Base juridique | Art. 14, 16 | Art. 23 | Art. 19 + RTS/ITS |
Le règlement est déjà en vigueur. Les sanctions peuvent atteindre 15 millions d'EUR ou 2,5 % du chiffre d'affaires annuel mondial (Art. 71, 64).
Entrée en vigueur le 10 décembre 2024. Déclarations à partir du 11 septembre 2026 (y compris pour les produits existants). Application complète à partir du 11 décembre 2027. Paliers de sanctions : 15 M EUR / 2,5 % pour les manquements à l'Annexe I ou aux articles 13 et 14 ; 10 M EUR / 2 % pour les autres obligations ; 5 M EUR / 1 % pour des informations incorrectes. Les microentreprises et petites entreprises sont exemptées d'amendes pour le non-respect du délai d'alerte précoce de 24 heures.
| Date | Jalon |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du règlement |
| 11 juin 2026 | Application du cadre de notification des organismes d'évaluation de la conformité (chapitre IV) |
| 11 septembre 2026 | Application des obligations de déclaration (Art. 14) : alerte précoce 24 h · notification 72 h · rapport final 14 jours |
| 11 décembre 2027 | Application complète : toutes les exigences essentielles et obligations des fabricants s'appliquent |
EXPLORER
L'horloge de déclaration en trois étapes au titre de l'article 14 : alerte précoce à 24 heures, notification à 72 heures et rapport final à 14 jours à l'ENISA et au CSIRT national concerné.
Ce qu'est la plateforme unique de déclaration, quand elle sera lancée, comment les déclarations sont soumises, et ce que l'absence d'API automatisée implique pour la préparation.
Les quatre dates échelonnées de l'entrée en vigueur jusqu'à l'application complète en décembre 2027, et ce que chaque jalon signifie pour les fabricants.
Quelles obligations débutent le 11 septembre 2026, lesquelles en décembre 2027, et comment le calendrier affecte les produits déjà sur le marché.
Fabricants, importateurs, distributeurs, portée extraterritoriale, et produits et secteurs exclus du périmètre.
Comment les produits Par défaut, Important classe I, Important classe II et Critique sont classifiés et pourquoi la voie de conformité en dépend.
Ce que l'exigence de liste des composants logiciels signifie en pratique : format, contenu et intégration dans un flux de gestion des vulnérabilités.
Le plafond de sanction de 15 millions d'EUR / 2,5 % et les paliers inférieurs pour d'autres infractions, avec la base juridique à l'article 64.
Comment les obligations RCR au niveau produit interagissent avec les devoirs organisationnels de NIS2, et comment les deux peuvent fonctionner sur un même ensemble de contrôles.
Comment les obligations de déclaration du RCR se comparent au régime d'incidents TIC de DORA pour les entités financières soumises aux deux règlements.
Quand le FOSS est dans le périmètre, comment fonctionne le seuil d'activité commerciale, le rôle de gestionnaire open source, et pourquoi les intégrateurs commerciaux restent pleinement responsables.
Comment la conformité RCR devient une condition préalable au marquage CE, les étapes requises, et pourquoi les fabricants hors UE sont dans le périmètre.
Le test en trois parties pour déterminer quand un backend cloud fait partie du périmètre produit RCR, et la frontière avec l'infrastructure tierce.
Ce que signifie l'obligation de qualité à la mise sur le marché, comment elle diffère du déclencheur de déclaration, et pourquoi le CVSS est utile mais non imposé par la loi.
Mesures de proportionnalité pour les microentreprises et petites entreprises, documentation technique simplifiée, et obligations non dérogées.
CONFORMITÉ RCR
Acuna mappe les obligations produit RCR aux côtés de NIS2 et DORA dans un seul ensemble de contrôles -- pour que les preuves de gestion des vulnérabilités, la déclaration d'incidents et la maintenance de la SBOM alimentent un programme plutôt que trois silos.
Comment le Cyber Resilience Act s'intègre à un programme GRC existant
Si vous gérez déjà un programme multi-cadres, le RCR s'intègre mieux qu'il ne s'exécute en projet séparé. Les obligations de gestion des vulnérabilités, de risque et de preuve se mappent sur des contrôles que vous exploitez presque certainement déjà.
Le travail réellement nouveau est spécifique au produit : classifier chaque produit, maintenir la SBOM, produire la documentation technique et la déclaration de conformité, et connecter la voie de déclaration 24 h / 72 h / 14 jours vers l'ENISA. Voir gérer les obligations RCR aux côtés de NIS2 et DORA.