CRA : Cyber Resilience Act, exigences EU pour produits numériques

Auteur Hugues Orgitello Mis à jour le 26 mai 2026

Guide · Cyber Resilience Act

Adopté en octobre 2024 et entré en vigueur le 10 décembre 2024, le règlement (UE) 2024/2847, dit Cyber Resilience Act (CRA), instaure le premier socle horizontal d'exigences de cybersécurité applicable à l'ensemble des produits comportant des éléments numériques mis sur le marché de l'Union. Sa pleine application est fixée au 11 décembre 2027, avec des obligations intermédiaires de signalement activées dès septembre 2026. Ce guide expose le périmètre du texte, ses trois classes de produits, les treize exigences essentielles de son annexe I, les voies d'évaluation de conformité, le calendrier de transition et l'articulation avec la RED 3.3 et la série EN 18031.

Pourquoi un règlement horizontal de cybersécurité

Avant le CRA, la cybersécurité des produits numériques relevait en Europe d'un patchwork sectoriel : RED 3.3 pour les équipements radio connectés, MDR pour les dispositifs médicaux, règlement NIS2 pour les opérateurs d'entités essentielles, schémas EUCC sous le règlement Cybersecurity Act. Aucun texte ne couvrait les produits non radio, non médicaux, non utilisés par des opérateurs essentiels. Une caméra IP filaire, un disque dur réseau, un logiciel d'entreprise vendu en boîte, un firmware embarqué dans un automate restaient hors champ direct.

Cette fragmentation a produit deux effets documentés par la Commission dans l'étude d'impact : un niveau de cybersécurité hétérogène selon le canal de distribution, et une charge réglementaire imprévisible pour les fabricants amenés à couvrir le même produit sous plusieurs régimes. Le CRA répond par un socle commun, applicable à toute personne mettant un produit numérique sur le marché européen, complété par une stratification proportionnée au risque.

Le règlement est de portée extra-territoriale : il s'applique à tout fabricant, importateur ou distributeur qui place un produit sur le marché de l'UE, indépendamment de sa localisation. Un éditeur logiciel américain distribuant un outil de sauvegarde à des utilisateurs européens entre dans le champ, au même titre qu'un industriel chinois exportant des caméras IP.

Périmètre : les produits comportant des éléments numériques

Le CRA introduit la notion de product with digital elements (PDE), traduite par "produit comportant des éléments numériques". L'article 3 la définit comme tout produit logiciel ou matériel et ses solutions de traitement à distance des données, dont la connexion logique ou physique à un dispositif ou à un réseau est prévue.

Cette définition englobe :

• Les équipements matériels connectés : caméras IP, routeurs, NAS, capteurs IoT, équipements industriels avec interface réseau, jouets connectés, électroménager connecté.
• Les logiciels autonomes distribués sur le marché : systèmes d'exploitation, navigateurs, antivirus, suites bureautiques, logiciels métiers vendus en licence ou en SaaS lorsque l'élément logiciel est livré au client.
• Les composants logiciels et matériels mis à disposition séparément pour intégration dans un produit final, dans la mesure où ils sont commercialisés en tant que tels.

Le règlement précise plusieurs exclusions explicites à l'article 2, fondées sur l'existence d'une réglementation sectorielle déjà spécifique à la cybersécurité :

Catégorie exclue	Texte applicable
Dispositifs médicaux	Règlement (UE) 2017/745 (MDR) et 2017/746 (IVDR)
Véhicules automobiles	Règlement (UE) 2019/2144, UNECE R155/R156
Aviation civile	Règlement (UE) 2018/1139
Équipements maritimes	Directive 2014/90/UE
Produits exclusivement destinés à la défense ou à la sécurité nationale	Hors compétence Marché intérieur

Le règlement aménage par ailleurs une exemption pour les logiciels libres et open source distribués en dehors d'une activité commerciale. Un projet communautaire bénévole reste hors champ. En revanche, dès qu'un éditeur tire un revenu direct ou indirect de la distribution (support payant, version entreprise, intégration dans une offre commerciale), il bascule dans le périmètre. Le texte introduit également la figure de steward de logiciel open source, soumise à des obligations allégées centrées sur la politique de sécurité et la coopération avec les autorités.

Trois classes de produits, trois voies d'évaluation

Le CRA stratifie les produits selon leur niveau de risque cybersécurité, déterminé par leur usage prévu et par leur capacité à compromettre d'autres composants du système d'information.

Classe par défaut

C'est la classe résiduelle, qui couvre la majorité des produits numériques non listés à l'annexe III ou IV. Pour cette classe, le fabricant procède par auto-évaluation (module A) sur la base des normes harmonisées européennes lorsqu'elles existent, et établit lui-même la déclaration UE de conformité. L'annexe I doit être intégralement satisfaite, mais aucune intervention de tiers n'est requise.

Classe importante (annexe III)

L'annexe III liste les produits importants pour la cybersécurité du marché numérique européen. Elle est répartie en deux sous-classes :

• Classe I : gestionnaires d'identité, gestionnaires de mots de passe, navigateurs web autonomes, antivirus, VPN, systèmes de gestion de réseau, contrôleurs SCADA de second niveau, équipements de routage domestique. L'auto-évaluation reste possible si toutes les normes harmonisées pertinentes sont intégralement appliquées. Sinon, un examen par organisme notifié devient nécessaire (module B+C ou H).
• Classe II : hyperviseurs, runtimes de conteneurs, pare-feux de niveau entreprise, systèmes de détection d'intrusion, microprocesseurs sécurisés, microcontrôleurs avec éléments de sécurité, lecteurs de cartes à puce. L'évaluation par tiers est obligatoire (module B+C ou H), même en présence de normes harmonisées intégralement appliquées.

Classe critique (annexe IV)

L'annexe IV regroupe les produits critiques dont la compromission entraînerait des conséquences systémiques : dispositifs cryptographiques matériels (HSM), passerelles de compteurs intelligents sécurisées, cartes à puce sécurisées. Pour ces produits, le règlement permet à la Commission d'imposer par acte délégué un schéma européen de certification cybersécurité (EUCC) au titre du règlement (UE) 2019/881. À défaut d'un tel acte, l'évaluation suit la voie de la classe importante II.

Tableau de synthèse

Classe	Exemples	Voie d'évaluation	Tiers requis
Par défaut	Capteur IoT, caméra IP grand public, application bureautique	Module A (interne)	Non
Importante I (annexe III)	Antivirus, VPN, navigateur, routeur domestique	Module A si normes harmonisées intégralement appliquées, sinon B+C ou H	Conditionnel
Importante II (annexe III)	Hyperviseur, pare-feu entreprise, micro-contrôleur sécurisé	Module B+C ou H	Oui (organisme notifié)
Critique (annexe IV)	HSM, passerelle compteur intelligent, smartcard sécurisée	Schéma européen de certification cybersécurité ou module B+C/H	Oui (certification ou ON)

Ce découpage rappelle, dans son esprit, la modulation de l'évaluation RED par l'article 3.3 et le niveau d'assurance retenu (basic / substantial / high), avec une granularité accrue pour le logiciel.

Les treize exigences essentielles de l'annexe I

L'annexe I du règlement liste les exigences techniques que tout PDE doit satisfaire. La partie I traite des propriétés du produit (cybersécurité par conception et par défaut). La partie II encadre la gestion des vulnérabilités tout au long du cycle de vie.

Partie I, propriétés du produit (13 exigences)

1. Le produit est livré sans vulnérabilité exploitable connue.
2. Le produit est livré avec une configuration sécurisée par défaut, modifiable par l'utilisateur.
3. Les vulnérabilités peuvent être corrigées par mises à jour de sécurité, automatiques le cas échéant.
4. Le produit assure la protection contre l'accès non autorisé par des mécanismes d'authentification, de gestion d'identité ou de contrôle d'accès appropriés.
5. Le produit protège la confidentialité des données stockées, traitées ou transmises (chiffrement au repos et en transit, gestion des clés).
6. Le produit protège l'intégrité des données, des commandes et des paramètres internes contre la modification ou la manipulation non autorisée.
7. Le produit traite uniquement les données nécessaires à son usage prévu (minimisation).
8. Le produit protège la disponibilité des fonctions essentielles, y compris la résilience aux attaques par déni de service.
9. Le produit limite son impact négatif sur la disponibilité des services d'autres dispositifs ou réseaux.
10. Le produit est conçu, développé et produit pour limiter ses surfaces d'attaque, y compris les interfaces externes.
11. Le produit est conçu pour réduire l'impact d'un incident grâce à des techniques et mécanismes d'atténuation.
12. Le produit fournit des informations relatives à la sécurité (journaux, événements internes) accessibles à l'utilisateur ou à un agent de surveillance.
13. Le produit permet à l'utilisateur de supprimer ou de transférer ses données et configurations de manière sécurisée.

Partie II, gestion des vulnérabilités

Le fabricant doit identifier et documenter les vulnérabilités et composants du produit, y compris en établissant une software bill of materials (SBOM) structurée et lisible par machine. Il doit corriger les vulnérabilités sans retard, par mises à jour de sécurité gratuites et distinctes des mises à jour de fonctionnalité. Il doit publier une politique de divulgation coordonnée des vulnérabilités, mettre à disposition une adresse de signalement, et documenter les correctifs publiés. La durée minimale de support sécurité est laissée à l'appréciation du fabricant mais ne peut être inférieure à la durée d'usage attendue du produit et, dans la plupart des cas, à cinq ans.

Voies d'évaluation de conformité

Le règlement reprend la structure des modules de la décision n° 768/2008/CE. La grille de choix est plus simple que sous RED puisque le CRA exclut certains modules.

Module	Description	Cas d'usage CRA
A	Contrôle interne de production	Classe par défaut ; classe importante I avec normes harmonisées intégralement appliquées
B + C	Examen UE de type (par ON) + conformité au type	Classe importante I sans normes harmonisées complètes, classe importante II
H	Assurance qualité complète	Classe importante I et II, fabricants à fort volume avec SMQ mature
Certification européenne	Schéma EUCC sous règlement 2019/881	Classe critique (annexe IV) lorsque la Commission l'impose

Pour comparaison avec les autres directives électroniques, voir le guide auto-déclaration vs organisme notifié qui détaille la mécanique des modules.

Obligations de signalement à l'ENISA

L'article 14 du règlement instaure un dispositif de signalement à étages, calqué sur le modèle NIS2 mais propre aux produits numériques. Le signalement s'effectue via une plateforme unique gérée par l'ENISA, reliée aux CSIRT nationaux.

Échéance	Contenu attendu	Destinataire
24 heures après prise de connaissance	Alerte précoce indiquant qu'une vulnérabilité activement exploitée ou un incident grave est suspecté	CSIRT national + ENISA
72 heures	Notification de vulnérabilité avec évaluation initiale (sévérité, exploitation, mesures correctives envisagées)	CSIRT national + ENISA
Sans retard injustifié	Information des utilisateurs concernés des mesures correctives et des actions à entreprendre	Utilisateurs du produit
14 jours après disponibilité d'un correctif	Mise à jour du rapport, y compris le correctif	CSIRT national + ENISA
Rapport final dans le mois	Description détaillée, cause racine, mesures d'atténuation pérennes	CSIRT national + ENISA

La double dimension du signalement est notable : l'ENISA et le CSIRT national reçoivent l'information technique ; les utilisateurs reçoivent en parallèle une notification opérationnelle leur permettant d'appliquer les correctifs disponibles ou de prendre des mesures de mitigation. Le fabricant ne peut pas se contenter de patcher silencieusement.

Calendrier de transition

Le règlement est entré en vigueur le 10 décembre 2024, vingt jours après sa publication au Journal officiel. L'article 71 organise une mise en application progressive sur trente-six mois.

Date	Étape	Périmètre activé
10 décembre 2024	Entrée en vigueur	Texte juridiquement contraignant, dispositions transitoires
11 juin 2026	+18 mois	Obligations applicables aux organismes notifiés (désignation, accréditation)
11 septembre 2026	+21 mois	Obligations de signalement des vulnérabilités activement exploitées et des incidents graves à l'ENISA
11 décembre 2027	+36 mois, pleine application	Toutes les autres obligations : exigences essentielles annexe I, évaluation de conformité, marquage CE au titre du CRA, déclaration UE de conformité, sanctions

La fenêtre intermédiaire de septembre 2026 mérite attention : un fabricant qui n'a pas encore préparé son dispositif de surveillance des vulnérabilités, son canal de signalement utilisateurs et sa relation avec l'ENISA s'expose à un manquement dès cette date, alors même que les exigences techniques de l'annexe I ne sont pas encore opposables. La séquence est volontaire : la Commission a estimé qu'une remontée de signalements rapide était nécessaire pour calibrer les futurs schémas d'évaluation.

Articulation avec le marquage CE et les autres directives

Le CRA s'inscrit dans la famille du marquage CE. La conformité au règlement est matérialisée par l'apposition du marquage CE sur le produit et par l'émission d'une déclaration UE de conformité. Pour un produit déjà soumis à d'autres actes (RED, CEM, basse tension), la déclaration unique cite l'ensemble des textes applicables. Les règles transversales du marquage sont détaillées dans le guide marquage CE et la procédure CE.

Recouvrement avec la RED 3.3

Pour les produits radio connectés à Internet, deux régimes coexistent à compter de 2027 : la RED 3.3 (règlement délégué 2022/30, activé depuis le 1ᵉʳ août 2025) et le CRA. La RED 3.3 couvre trois exigences essentielles ciblées (protection du réseau, protection des données personnelles et de la vie privée, protection contre la fraude) et s'applique aux équipements relevant de la directive 2014/53/UE. Le CRA introduit un socle horizontal plus large (treize exigences, gestion des vulnérabilités, signalement) couvrant tous les produits numériques.

Sur le périmètre commun (produits radio connectés à Internet), les deux textes s'appliquent en parallèle. Le règlement CRA prévoit à son article 12 un mécanisme de présomption de conformité croisée : un produit conforme aux exigences cybersécurité d'autres actes de l'Union peut être présumé conforme à certaines exigences correspondantes du CRA. Une consolidation réglementaire est attendue d'ici 2028, dont les contours restent à préciser.

Les normes harmonisées EN 18031-1/-2/-3 publiées au JOUE en août 2024 servent de socle technique commun aux deux régimes : elles présument la conformité à la RED 3.3 dès maintenant, et leur révision en cours intègre les exigences CRA pour servir la même fonction dans le futur cadre.

Pour le détail de la cartographie RED, voir les pages directive RED, normes harmonisées RED et tests RED, ainsi que la checklist RED qui intègre déjà l'article 3.3.

Sanctions et surveillance du marché

L'article 64 du règlement fixe le régime de sanctions administratives :

• Violation des exigences essentielles de l'annexe I et des obligations du fabricant : jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial annuel (le montant le plus élevé étant retenu).
• Manquement aux obligations de signalement et de coopération avec les autorités : jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires mondial.
• Information inexacte, incomplète ou trompeuse fournie aux autorités : jusqu'à 5 millions d'euros ou 1 % du chiffre d'affaires mondial.

La surveillance du marché est assurée par les autorités nationales désignées au titre du règlement (UE) 2019/1020, qui peuvent ordonner le retrait, le rappel ou l'interdiction d'un produit non conforme. L'ENISA tient un registre public des vulnérabilités signalées (avec filtrage des informations sensibles) et coordonne les actions transfrontalières.

Préparer un produit CRA-ready

Pour un fabricant qui met aujourd'hui un produit numérique sur le marché européen, la trajectoire de conformité passe par plusieurs jalons.

1. Classification : déterminer la classe du produit (par défaut, importante I/II, critique) sur la base des annexes III et IV. Documenter la décision.
2. Cartographie des exigences : pour chaque exigence des parties I et II de l'annexe I, identifier les contrôles techniques en place, les écarts, et les actions correctives.
3. SBOM : produire une SBOM exploitable (formats CycloneDX, SPDX) couvrant l'ensemble des composants logiciels, y compris les bibliothèques tierces et les firmwares de modules embarqués.
4. Politique de divulgation : publier une politique de divulgation coordonnée, une adresse de signalement (security.txt, contact dédié), un SLA de réponse.
5. Veille vulnérabilités : abonner les composants critiques aux flux CVE, NVD, GitHub Advisory ; automatiser la corrélation SBOM/CVE.
6. Process de mise à jour : assurer la signature cryptographique, le canal sécurisé, l'anti-rollback, l'historisation des versions déployées.
7. Voie d'évaluation : pour les classes importante II et certaines classes importante I, présélectionner un organisme notifié (la liste sera consolidée à partir de juin 2026 dans la base NANDO).
8. Documentation technique : préparer le dossier technique selon l'annexe VII (description du produit, conception, évaluation des risques, rapports d'essais, SBOM).
9. Déclaration UE de conformité : modèle annexe V, cumulant le cas échéant CRA, RED, CEM, basse tension.

Les fabricants qui mènent déjà une démarche RED 3.3 disposent d'un socle réutilisable significatif : analyse de risques cybersécurité, mécanismes de signature firmware, gestion des secrets, OTA signée. La transposition vers le CRA reste un effort additionnel, principalement concentré sur la SBOM, la gestion formalisée des vulnérabilités et le dispositif de signalement à l'ENISA.

Le glossaire spilma reprend les termes-clés (PDE, SBOM, EUCC, divulgation coordonnée) avec leurs définitions de référence.

Besoin d’un appui ?

Un audit de 30 minutes avec les ingénieurs AESTECHNO.

AESTECHNO est le bureau d'études qui édite spilma. Nous aidons les équipes produit à cadrer leur démarche de certification et à éviter les pièges classiques.

Réserver un audit gratuit

Points de vigilance

Risque	Conséquence	Action
Confondre RED 3.3 et CRA	Périmètre sous-évalué pour les produits non radio	Cartographier les deux régimes séparément
Négliger l'exemption open source	Non-conformité de l'éditeur d'un projet monétisé	Documenter le modèle économique et le statut
Sous-estimer la SBOM	Impossibilité de qualifier une vulnérabilité signalée	Industrialiser dès la conception
Reporter le dispositif de signalement à 2027	Manquement dès septembre 2026	Activer la veille et le canal utilisateurs avant fin 2025
Confondre support sécurité et support fonctionnel	Mises à jour de sécurité non gratuites ou liées à un contrat	Distinguer dès la politique commerciale
Oublier la déclaration de conformité unifiée	DoC incomplète, exposition au retrait	Intégrer le CRA dans la trame DoC dès 2026

Un cas concret de le cadrage CRA et la cartographie des écarts pour un produit numérique ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Sources & références

1. Règlement (UE) 2024/2847 sur la cyber-résilience , EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
2. Cyber Resilience Act, page officielle de la Commission européenne , Commission européenne digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
3. ENISA, dossier Cyber Resilience Act , ENISA www.enisa.europa.eu/topics/cyber-resilience-act
4. Règlement délégué (UE) 2022/30, activation de l'article 3.3 RED , EUR-Lex eur-lex.europa.eu/eli/reg_del/2022/30/oj
5. CENELEC, portail des normes européennes harmonisées , CENELEC www.cenelec.eu/