CRA

01 — DéfinitionQu'est-ce que le Cyber Resilience Act ?

Source officielle : Cyber Resilience Act sur le site de la Commission européenne.

Le Cyber Resilience Act (CRA), formellement Règlement (UE) 2024/2847, est le règlement européen qui impose pour la première fois des exigences horizontales de cybersécurité à tous les produits comportant des éléments numériques commercialisés dans l'Union européenne.

Proposé par la Commission européenne en septembre 2022, négocié avec débats intenses notamment autour du logiciel open source, il a été adopté définitivement par le Conseil le 10 octobre 2024 et publié au Journal officiel le 20 novembre 2024. Son entrée en vigueur a eu lieu le 10 décembre 2024, avec une application complète fixée au 11 décembre 2027.

L'ambition est claire : mettre fin à la situation où n'importe quel produit connecté peut être vendu en Europe sans exigence de cybersécurité. Jusqu'ici, un routeur WiFi, une caméra IP, un jouet connecté, un système industriel pouvaient être commercialisés sans aucune obligation réglementaire en matière de sécurité informatique. Résultat : un écosystème de produits vulnérables exploités massivement par les botnets et les campagnes ransomware.

Le CRA impose désormais :

• Cybersécurité dès la conception : exigences essentielles intégrées dès la phase de développement.
• Marquage CE étendu : pas de vente UE sans conformité démontrée.
• Gestion du cycle de vie : mises à jour de sécurité pendant la durée de support.
• Transparence : SBOM, documentation technique, notification des vulnérabilités.
• Responsabilité partagée : obligations pour fabricants, importateurs et distributeurs.

Le CRA est au numérique ce que les normes de sécurité électrique ou de jouets pour enfants sont au monde physique : une ligne rouge minimale en dessous de laquelle un produit ne peut pas être mis sur le marché européen.

02 — PérimètreQuels produits sont concernés

Produits couverts

Le CRA couvre tous les produits comportant des éléments numériques — une définition volontairement très large qui inclut :

• Matériel connecté grand public : routeurs WiFi, caméras IP, thermostats intelligents, montres connectées, assistants vocaux, jouets connectés, appareils électroménagers connectés.
• Logiciels commerciaux : applications destop et mobile, systèmes d'exploitation, bibliothèques logicielles commerciales, firmwares.
• Équipements industriels : automates programmables (PLC), équipements SCADA, capteurs industriels connectés.
• Composants matériels : puces avec fonctions de sécurité, modules WiFi/Bluetooth intégrés.
• Produits professionnels : imprimantes réseau, équipements réseau, systèmes de vidéosurveillance.

Exclusions

Certains produits sont exclus car déjà couverts par d'autres réglementations sectorielles :

• Dispositifs médicaux : couverts par le Règlement (UE) 2017/745 (MDR) et 2017/746 (IVDR).
• Véhicules : couverts par UN-R155/R156 (cybersécurité auto).
• Aéronautique civile : Règlement (UE) 2018/1139.
• Équipements maritimes : directive 2014/90/UE.
• Produits destinés exclusivement à la défense ou sécurité nationale.
• Certains services cloud relevant déjà de NIS2.

Acteurs concernés

Le règlement distingue plusieurs acteurs avec des obligations spécifiques :

• Fabricants : principales obligations, responsables de la conformité du produit.
• Importateurs : vérifient que les produits qu'ils importent dans l'UE sont conformes, que le marquage CE est présent, que la documentation existe.
• Distributeurs : obligations allégées mais réelles de vérification avant mise sur le marché.
• Stewards de logiciels open source : nouvelle catégorie créée par le CRA pour les fondations qui structurent l'OSS (voir section dédiée).
• Mandataires : représentants UE des fabricants hors UE.

Application territoriale

Le CRA s'applique dès qu'un produit est mis sur le marché de l'UE, quelle que soit l'origine du fabricant. Un fabricant chinois ou américain vendant ses produits en Europe est pleinement soumis au règlement. Les fabricants hors UE doivent désigner un mandataire européen qui assume les responsabilités opérationnelles.

03 — ObligationsCe qui est concrètement exigé

1. Exigences essentielles de cybersécurité (Annexe I)

Les produits doivent être conçus et fabriqués pour garantir un niveau « approprié » de cybersécurité. Principales exigences :

• Aucune vulnérabilité exploitable connue au moment de la mise sur le marché.
• Configuration sécurisée par défaut : pas de mots de passe par défaut faibles, services inutiles désactivés.
• Contrôle d'accès robuste : authentification forte, gestion des identités.
• Protection des données : chiffrement des données sensibles en transit et au repos.
• Intégrité : protection contre les modifications non autorisées du code et des données.
• Disponibilité : résilience aux attaques par déni de service.
• Minimisation de la surface d'attaque : limitation des fonctionnalités exposées.
• Journalisation des événements de sécurité.
• Capacité à publier des mises à jour de sécurité.

2. Gestion des vulnérabilités

Les fabricants doivent :

• Tenir un SBOM du produit, au moins pour les composants de plus haut niveau, dans un format lisible par machine (SPDX ou CycloneDX).
• Identifier et documenter les vulnérabilités.
• Traiter rapidement les vulnérabilités en fournissant des correctifs.
• Mettre en place un point de contact public (security contact) pour recevoir les signalements.
• Adopter une politique de divulgation coordonnée des vulnérabilités.
• Fournir des mises à jour pendant la durée de support attendue du produit.

3. Notifications obligatoires (à partir de septembre 2026)

• Vulnérabilités activement exploitées : notification à l'ENISA et au CSIRT compétent dans les 24 heures après connaissance, avec un rapport complet dans les 14 jours.
• Incidents graves affectant la sécurité du produit : mêmes délais.
• Informations aux utilisateurs affectés, sans délai injustifié.

4. Documentation technique

Le fabricant doit produire et tenir à jour une documentation technique complète comprenant :

• Description du produit et de ses composants.
• SBOM actualisé.
• Analyse de risques cybersécurité.
• Description des mesures de sécurité mises en œuvre.
• Résultats des tests effectués.
• Instructions et informations pour l'utilisateur (durée de support, configuration sécurisée, procédure de mise à jour).

5. Marquage CE

Avant mise sur le marché, le fabricant appose le marquage CE qui atteste la conformité au règlement. Pour les produits de certaines catégories (voir section suivante), un numéro d'organisme notifié accompagne le marquage.

6. Durée de support et mises à jour

Obligation de fournir des mises à jour de sécurité pendant une durée adaptée à la nature du produit. Pour la plupart des produits grand public : minimum 5 ans à partir de la mise sur le marché. Cette durée peut être plus longue pour certains produits (systèmes industriels, équipements critiques). Elle doit être clairement communiquée au consommateur avant l'achat.

04 — ClassesClassification et procédure de conformité

Les catégories de produits

Le règlement distingue plusieurs catégories avec des procédures de conformité de rigueur croissante :

Produits par défaut (non critiques)

La grande majorité des produits (environ 90%). Auto-évaluation suffisante : le fabricant vérifie lui-même la conformité, tient la documentation, appose le marquage CE. Pas d'intervention d'organisme notifié. Exemples : applications non critiques, jouets connectés standard, petits appareils connectés.

Produits importants — Classe I

Produits ayant un rôle de sécurité notable. Auto-évaluation + référentiels harmonisés : le fabricant peut s'appuyer sur des standards techniques harmonisés (à développer par les organismes européens de normalisation) qui donnent présomption de conformité. Exemples : systèmes de gestion des identités, gestionnaires de mots de passe, lecteurs de cartes à puce, navigateurs web, systèmes de contrôle d'accès physique connectés.

Produits importants — Classe II

Produits avec un impact cybersécurité significatif. Évaluation par un organisme notifié obligatoire dans certains cas. Exemples : hyperviseurs, pare-feu, systèmes d'exploitation, microprocesseurs à usage général avec fonctions de sécurité, routeurs industriels, systèmes de détection d'intrusion.

Produits critiques

Catégorie ajoutée lors des négociations pour les produits d'importance systémique. Évaluation obligatoire par organisme notifié, voire certification européenne de cybersécurité (EUCC). Exemples envisagés : HSM (Hardware Security Modules), cartes à puce, passerelles pour compteurs intelligents.

Organismes notifiés

Entités indépendantes désignées par chaque État membre pour effectuer les évaluations de conformité aux procédures les plus strictes. En France, ces organismes sont désignés après accréditation par le COFRAC (Comité français d'accréditation). Ils doivent être en place au plus tard le 11 juin 2026.

Références aux standards existants

Les fabricants peuvent s'appuyer sur des standards techniques pour démontrer leur conformité :

• ETSI EN 303 645 : cybersécurité de base pour l'IoT grand public (déjà largement adopté).
• ISO/IEC 27001, 27002 : gestion de la sécurité de l'information.
• ISO/IEC 27034 : sécurité des applications.
• IEC 62443 : cybersécurité industrielle.
• Common Criteria (ISO/IEC 15408) pour les composants critiques.
• Standards harmonisés européens en cours de développement 2025-2027.

05 — CalendrierLes phases d'application

Jalons officiels

• 10 octobre 2024 : adoption définitive par le Conseil.
• 20 novembre 2024 : publication au Journal officiel de l'UE.
• 10 décembre 2024 : entrée en vigueur du règlement.
• 11 juin 2026 : obligation pour les États membres d'avoir désigné leurs organismes notifiés et autorités de surveillance du marché.
• 11 septembre 2026 : entrée en vigueur des obligations de notification des vulnérabilités exploitées et des incidents graves.
• 11 décembre 2027 : application complète du règlement. Tout produit mis sur le marché après cette date doit être pleinement conforme.

Que faire chronologiquement — fabricants

Dispositions transitoires

Les produits déjà sur le marché avant le 11 décembre 2027 bénéficient d'une tolérance : ils n'ont pas besoin d'être retirés, à condition qu'ils ne subissent pas de modification substantielle. Les nouveaux produits et les mises à jour majeures après cette date doivent être conformes.

06 — Open sourceLes dispositions spéciales

La controverse initiale

La proposition initiale de la Commission en 2022 a soulevé une inquiétude majeure dans la communauté open source : risquait-elle de rendre les mainteneurs bénévoles responsables de vulnérabilités dans leur code, potentiellement jusqu'à 15 M€ d'amende ? Une lettre ouverte signée par Linux Foundation, Apache Foundation, Eclipse Foundation, Python Software Foundation et de nombreuses autres a alerté sur le risque d'étouffement de l'innovation open source européenne.

Le compromis adopté

Les négociations 2023-2024 ont produit un équilibre désormais codifié dans le règlement :

Exclusion pour les contributions non commerciales

Le logiciel open source développé et fourni hors activité commerciale est explicitement exclu du règlement. Un mainteneur individuel qui publie son code sur GitHub sans activité commerciale associée n'est pas soumis aux obligations CRA. Cette protection couvre la grande majorité des contributeurs open source individuels.

Statut du « steward de logiciel open source »

Création d'un nouveau statut intermédiaire pour les organisations qui structurent les communautés open source sans les commercialiser : fondations (Linux, Apache, Eclipse, Mozilla), associations, consortiums. Les stewards ont des obligations allégées mais réelles :

• Politique de cybersécurité documentée.
• Coopération avec les autorités lors d'incidents.
• Support aux signalements de vulnérabilités.
• Pas de marquage CE, pas d'évaluation de conformité par organisme notifié.

Responsabilité des intégrateurs commerciaux

Les éditeurs qui intègrent des composants open source dans leurs produits commerciaux restent pleinement responsables de la cybersécurité du produit livré. Ils doivent :

• Tenir un SBOM exhaustif incluant les composants OSS.
• Suivre les vulnérabilités dans ces composants.
• Patcher ou remplacer les composants vulnérables.
• Contribuer éventuellement upstream aux corrections de sécurité.

Activités commerciales « commerciales »

La frontière entre activité commerciale et non commerciale est nuancée par le texte. Indicateurs d'activité commerciale :

• Vente de licence, d'abonnement, de support commercial.
• Modèle « open core » (version gratuite + version payante).
• Services de consulting ou d'intégration rémunérés autour du produit.
• Publicité monétisée.

Les sociétés comme Red Hat, SUSE, Databricks sont clairement dans le périmètre. Les fondations à but non lucratif qui ne commercialisent pas bénéficient du statut de steward.

Impact attendu sur l'écosystème

• Pression accrue sur les éditeurs commerciaux pour investir dans la sécurité des composants OSS qu'ils utilisent.
• Renforcement des fondations comme tampon entre les contributeurs individuels et les obligations réglementaires.
• Financement accru de la sécurité open source (tendance déjà amorcée avec OpenSSF, Alpha-Omega).
• Possible réduction de la fragmentation — les éditeurs pourraient concentrer leur usage sur les projets matures avec gouvernance solide.

07 — SanctionsSurveillance et pénalités

Autorités de surveillance du marché

Chaque État membre désigne une ou plusieurs autorités nationales chargées de surveiller l'application du règlement. En France, l'organisation exacte fait l'objet de textes de transposition et d'application, avec un rôle attendu pour l'ANSSI en coordination avec la DGCCRF pour les aspects consommateurs.

Pouvoirs des autorités

• Demander au fabricant de démontrer la conformité d'un produit.
• Effectuer des tests et audits techniques.
• Interdire ou restreindre la commercialisation d'un produit non conforme.
• Ordonner le rappel ou le retrait d'un produit dangereux.
• Imposer des mesures correctives.
• Coopérer avec leurs homologues européens via le système CSIRT Network et ICSMS.

Sanctions financières

Barème de sanctions calqué sur le RGPD avec trois niveaux selon la gravité :

• Manquement aux exigences essentielles ou aux obligations principales (fabricants) : jusqu'à 15 millions d'euros ou 2,5% du chiffre d'affaires mondial annuel, le plus élevé des deux.
• Manquement aux autres obligations (importateurs, distributeurs, non-respect des procédures) : jusqu'à 10 M€ ou 2% du CA mondial.
• Informations incorrectes, incomplètes ou trompeuses fournies aux autorités : jusqu'à 5 M€ ou 1% du CA mondial.

Autres conséquences

• Retrait du marché du produit non conforme.
• Rappel obligatoire auprès des clients.
• Publication des manquements — effet réputationnel significatif.
• Responsabilité civile possible envers les victimes d'incidents liés à une non-conformité.
• Responsabilité pénale envisageable dans les cas graves.

Coordination avec les autres réglementations

Le CRA s'articule avec d'autres cadres européens :

• NIS2 : couvre la cybersécurité opérationnelle des entités essentielles. CRA couvre la cybersécurité des produits.
• DORA : spécifique au secteur financier pour les prestataires TIC critiques.
• RGPD : protection des données personnelles — non redondant, complémentaire.
• AI Act (Règlement UE 2024/1689) : couvre l'IA ; CRA s'applique aux produits IA en complément pour leurs aspects cybersécurité.
• Product Liability Directive révisée : responsabilité civile étendue aux produits logiciels.

Relation avec les standards sectoriels

Le CRA peut s'appuyer sur des référentiels existants pour démontrer la conformité. Un produit certifié ISO 27001 ou IEC 62443 bénéficie d'une présomption partielle de conformité pour certaines exigences. Les schémas de certification européens (EUCC — Common Criteria européen) constituent une voie privilégiée pour les produits critiques.

08 — FAQQuestions fréquentes

Le CRA s'applique-t-il aux services SaaS ?

Partiellement. Les services SaaS purs relèvent principalement de NIS2. Le CRA couvre cependant les logiciels distribués (applications cloud avec client lourd, applications mobiles, services avec composant local). Une frontière nuancée qui fera l'objet de clarifications par la Commission et ENISA dans les lignes directrices.

Que signifie « durée de support attendue » ?

Le règlement ne fixe pas de durée rigide mais exige qu'elle soit proportionnée à la nature du produit et communiquée clairement au consommateur avant achat. Lignes directrices attendues :

• Produits grand public courants : 5 ans minimum.
• Produits durables (électroménager, systèmes industriels) : 7 à 15 ans.
• Équipements critiques (santé, industriel) : 10 à 20 ans, parfois plus.

Cette obligation renverse la pratique actuelle où certains fabricants cessent les mises à jour peu après commercialisation.

Qu'est-ce que cela change pour les développeurs ?

Côté éditeurs commerciaux : pratiques secure development lifecycle obligatoires, intégration SBOM en CI/CD, processus de gestion des vulnérabilités formalisé, documentation produit renforcée, formation des équipes. Côté développeurs OSS individuels : pas d'obligation si l'activité n'est pas commerciale. Côté fondations OSS : statut de steward avec obligations proportionnées.

Comment les autorités vont-elles vérifier la conformité ?

Plusieurs mécanismes prévus : surveillance active du marché (achats tests, audits), contrôles lors d'incidents signalés, réaction aux plaintes et alertes de tiers (chercheurs en sécurité, concurrents, ONG), coopération internationale entre autorités européennes. Le système ICSMS existant de surveillance des produits sera étendu au CRA. La transparence des SBOM facilitera les vérifications croisées.

Et si mon fabricant étranger ignore le CRA ?

Les importateurs et distributeurs UE ont obligation de vérifier la conformité avant mise sur le marché européen. Un produit sans marquage CE ou avec documentation manquante ne peut pas être légalement distribué dans l'UE. Les plateformes e-commerce (Amazon, AliExpress) sont progressivement responsabilisées via le Digital Services Act et le futur Digital Fairness Act. Les produits importés individuellement par des consommateurs depuis l'étranger restent un angle mort pratique mais ne sont pas couverts par le CRA.