Cyber Resilience Act : Guide de Conformite Produits

Le Cyber Resilience Act, règlement UE 2024/2847 publié au Journal officiel de l'Union européenne le 20 novembre 2024, constitue la première obligation légale de cybersécurité applicable à l'ensemble des produits numériques commercialisés en Europe. Avant ce règlement, aucune exigence contraignante n'imposait aux fabricants de logiciels ou de dispositifs connectés de garantir la sécurité de leurs produits — seules des normes volontaires existaient. Avec le CRA, les fabricants, importateurs et distributeurs qui mettent sur le marché européen un produit contenant des éléments numériques — d'un simple routeur Wi-Fi domestique à un hyperviseur datacenter en passant par une application mobile ou un automate industriel — ont désormais des obligations légales précises en matière de cybersécurité. Le texte impose la sécurité par conception (security by design), la configuration sécurisée par défaut, la gestion proactive des vulnérabilités, la production d'un SBOM (inventaire logiciel), et des obligations de signalement rapide des vulnérabilités activement exploitées. Selon l'ENISA, les vulnérabilités logicielles non corrigées coûtent 5,5 milliards d'euros par an aux entreprises européennes, un coût que le CRA vise à réduire en responsabilisant les fabricants tout au long du cycle de vie de leurs produits. Avec environ 400 millions de produits connectés sur le marché européen et une montée en puissance des attaques ciblant la chaîne d'approvisionnement logicielle — de SolarWinds à Log4Shell — ce règlement arrive à point nommé pour structurer les obligations du marché.

Champ d'application : quels produits sont concernés par le CRA ?

Le CRA s'applique à tout produit avec éléments numériques (Product with Digital Elements, PDE) mis sur le marché de l'UE à titre commercial. La définition est intentionnellement large : elle couvre les produits dont la fonctionnalité principale ou accessoire repose sur un traitement de données, une connectivité réseau ou un microcontrôleur programmable.

Sont inclus dans le périmètre CRA :

• Logiciels autonomes installés sur des appareils : suites bureautiques, ERP, antivirus, gestionnaires de mots de passe, navigateurs, solutions de sécurité, OS génériques
• Dispositifs connectés (IoT) : routeurs, caméras IP, smart speakers, thermostats connectés, wearables, domotique
• Systèmes embarqués dans des équipements non médicaux : automates industriels, contrôleurs PLC/SCADA non exclusivement critiques, équipements ferroviaires, équipements énergétiques
• Applications mobiles distribuées commercialement sur des stores (App Store, Google Play, Huawei AppGallery)
• Logiciels open source commercialisés ou intégrés dans des produits commerciaux vendus
• Composants et bibliothèques logiciels vendus séparément : SDK, modules cryptographiques, moteurs de chiffrement

Sont exclus du périmètre CRA :

• Dispositifs médicaux et équipements de diagnostic in vitro (règlements MDR 2017/745 et IVDR 2017/746)
• Véhicules à moteur et systèmes embarqués couverts par les règlements UN-ECE (R155, R156)
• Équipements aéronautiques civils sous la supervision de l'EASA
• Équipements de défense, militaires et de sécurité nationale
• Logiciels uniquement accessibles via navigateur sans composant local installé (SaaS purs, couverts par NIS2)
• Logiciels open source non commerciaux développés hors cadre d'activité professionnelle rémunérée

Classification CRA : Default, Class I et Class II

Le règlement établit une gradation des exigences selon le niveau de risque cybersécurité intrinsèque du produit, déterminant la procédure d'évaluation de conformité requise et donc le coût et la complexité de la mise en conformité. Cette classification est définie dans les Annexes III (Class I) et IV (Class II) du règlement.

Les exigences essentielles de cybersécurité (Annexe I du CRA)

L'Annexe I du CRA définit les exigences essentielles de cybersécurité — le cœur technique du règlement — que tout produit doit respecter quel que soit son niveau de classification. Ces exigences s'articulent en deux parties : celles relatives au produit lui-même et celles relatives aux processus du fabricant.

Partie 1 — Exigences relatives au produit :

• Pas de vulnérabilité connue exploitable à la mise sur le marché (security by design) — obligation de réaliser une analyse de risques et des tests de sécurité avant commercialisation
• Configuration sécurisée par défaut : mots de passe uniques générés individuellement (interdiction des mots de passe universels partagés), ports non essentiels fermés par défaut, services inutilisés désactivés, principe du moindre privilège appliqué
• Protection de la confidentialité : données sensibles chiffrées au repos (AES-256 ou équivalent) et en transit (TLS 1.2+ minimum, TLS 1.3 recommandé), données personnelles minimisées
• Protection de l'intégrité : mécanismes de détection d'altération des données et des configurations (signatures cryptographiques, vérification d'intégrité au démarrage — secure boot)
• Surface d'attaque minimale : interfaces, protocoles et services réduits au strict nécessaire ; chaque interface exposée doit être documentée et justifiée
• Résilience de base : résistance aux attaques par déni de service (DoS) communes, gestion robuste des erreurs sans divulgation d'informations sensibles
• Journalisation des événements de sécurité : logs accessibles à l'utilisateur/administrateur pour les événements significatifs (authentifications, accès administratifs, erreurs de sécurité)

Partie 2 — Exigences relatives aux processus du fabricant :

• Identification, analyse et gestion proactive des vulnérabilités tout au long du cycle de vie du produit
• Fourniture de mises à jour de sécurité gratuites pendant la durée de support attendue (5 ans minimum pour la plupart des produits, moins si le cycle de vie estimé est plus court)
• Publication et maintien d'une politique de divulgation coordonnée des vulnérabilités (CVD/VDP) avec un canal de contact sécurisé (ex : security.txt, adresse email dédiée)
• Production et maintien à jour d'un SBOM (Software Bill of Materials) documentant tous les composants tiers, leurs versions et leurs vulnérabilités connues
• Signalement obligatoire sous 24 heures à l'ENISA et à l'autorité nationale (ANSSI) dès qu'une vulnérabilité est activement exploitée dans la nature

Signalement des vulnérabilités : le délai contraignant de 24 heures

L'obligation de notification rapide est l'une des exigences les plus opérationnellement structurantes du CRA. Dès qu'un fabricant apprend qu'une vulnérabilité de son produit est activement exploitée (being actively exploited in the wild), la chronologie suivante s'impose impérativement :

• Sous 24 heures (J+1) : notification initiale à l'ENISA via la plateforme de signalement dédiée ET à l'autorité nationale compétente (ANSSI pour la France). Contenu minimum requis : identification précise du produit concerné (nom, version, numéro de modèle), nature de la vulnérabilité, impact potentiel sur la confidentialité/intégrité/disponibilité, mesures de mitigation temporaires disponibles le cas échéant
• Sous 72 heures (J+3) : rapport de notification précoce (early warning) incluant une évaluation de la sévérité selon le standard CVSS 4.0, la liste des produits et versions affectés, et les premières mesures techniques de remédiation engagées
• Sous 14 jours (J+14) : rapport intermédiaire avec l'état d'avancement du développement du correctif, le calendrier de déploiement prévu, et les mesures de mitigation conseillées aux utilisateurs dans l'attente du patch définitif
• À la résolution complète : rapport final documentant le patch développé, son calendrier de distribution (automatique ou manuelle), les versions corrigées, et les mesures préventives pour éviter des vulnérabilités similaires dans les futures versions du produit

Ce mécanisme s'applique également aux incidents de sécurité significatifs affectant la disponibilité du produit ou compromettant la sécurité de ses utilisateurs. L'ENISA centralise ces signalements et les partage, selon leur criticité, avec les équipes CSIRT nationales des États membres, permettant une réponse coordonnée à l'échelle européenne.

Le SBOM : obligation d'inventaire logiciel sous le CRA

Le SBOM (Software Bill of Materials) est l'inventaire structuré et exhaustif de tous les composants logiciels qui constituent un produit : bibliothèques open source, frameworks, modules tiers, dépendances directes ET transitives, firmwares de composants matériels. Le CRA en fait une obligation légale formelle pour les fabricants, qui doivent produire ce document, le maintenir à jour tout au long du cycle de vie du produit, et le mettre à disposition des autorités de surveillance du marché sur demande.

Un SBOM conforme CRA doit documenter pour chaque composant intégré :

• Identification précise : nom canonique du composant, version exacte (PURL — Package URL recommandé), fournisseur/mainteneur
• Licence d'utilisation : GPL, MIT, Apache 2.0, LGPL, propriétaire — avec analyse des compatibilités
• Vulnérabilités connues : CVE identifiés, score CVSS, statut (corrigé, non affecté, en cours de remédiation)
• Dépendances transitives : les dépendances des dépendances, souvent source de vulnérabilités cachées (cf. Log4Shell)
• Composants en fin de vie (EOL) : signalement des composants dont la maintenance est abandonnée

Les formats standards reconnus par le CRA incluent SPDX 2.3 (Linux Foundation), CycloneDX 1.6 (OWASP) et SWID (ISO/IEC 19770-2). Pour l'automatisation de leur génération en pipeline CI/CD, les outils open source Syft (Anchore), Trivy (Aqua Security) et cdxgen (OWASP) sont les plus utilisés. Voir notre article complet sur SBOM 2026 : obligation de transparence logicielle pour le guide d'implémentation détaillé incluant l'intégration GitHub Actions.

Marquage CE cybersécurité : procédure de déclaration de conformité

Le marquage CE cybersécurité atteste que le produit respecte les exigences essentielles du CRA. Ce marquage devient, après la période de transition, une condition sine qua non pour commercialiser un produit numérique sur le marché européen — son absence expose au retrait du marché.

La procédure de marquage CE comprend quatre étapes principales :

• Évaluation de conformité : selon la classe du produit (auto-évaluation pour Default, organisme tiers ou normes harmonisées pour Class I, organisme notifié obligatoire pour Class II)
• Constitution du dossier technique : analyse de risques cybersécurité, résultats des tests de sécurité réalisés, SBOM complet, politique VDP, documentation des mises à jour prévues, description de la configuration par défaut et des mesures de sécurité implémentées
• Rédaction et signature de la déclaration EU de conformité (EU Declaration of Conformity) par le fabricant ou son représentant autorisé en UE — document légal engageant la responsabilité du signataire
• Apposition du marquage CE sur le produit ou son emballage, accompagné du numéro de l'organisme notifié pour les produits Class II, dans un format lisible et indélébile

Pour les produits Class I, les normes harmonisées CEN/CENELEC (groupe de travail JTC13 WG8) confèrent une présomption de conformité aux exigences essentielles. Ces normes sont développées en réponse au mandat M/604 de la Commission et sont attendues entre fin 2025 et 2026. En attendant leur publication, les fabricants peuvent s'appuyer sur des normes existantes (IEC 62443, ETSI EN 303 645, OWASP ASVS) comme base de travail.

Sanctions et surveillance du marché : un régime dissuasif

Le régime de sanctions administratives du CRA est confié aux autorités de surveillance du marché de chaque État membre. En France, le partage de compétences entre l'ANSSI (aspects cybersécurité technique) et la DGCCRF (aspects protection du consommateur et conformité marché) est formalisé dans la loi de transposition.

Le barème des sanctions administratives :

• Violation des exigences essentielles de l'Annexe I : jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial annuel du groupe (le montant le plus élevé retenu)
• Non-conformité aux obligations du fabricant (signalement, SBOM, VDP, mises à jour) : jusqu'à 10 millions d'euros ou 2 % du CA mondial
• Fourniture d'informations incorrectes aux autorités de surveillance : jusqu'à 5 millions d'euros ou 1 % du CA mondial

Au-delà des amendes pécuniaires, les autorités de surveillance du marché disposent de pouvoirs de police administrative pouvant s'avérer encore plus dommageables économiquement : retrait du marché du produit non conforme (avec publication d'une alerte officielle aux utilisateurs), rappel des produits déjà commercialisés auprès des utilisateurs finals, interdiction temporaire de mise sur le marché, ou saisie de produits lors de contrôles. Ces mesures, particulièrement médiatisées dans un secteur B2B, causent des dommages réputationnels et contractuels qui peuvent dépasser largement le montant des amendes. La publication de la liste des produits non conformes par l'ANSSI est également prévue par le règlement, renforçant encore la pression sur les fabricants.

Calendrier de conformité CRA : feuille de route 2024-2027

La période de transition de 36 mois laisse le temps aux fabricants de se préparer, mais les chantiers à mener sont substantiels. La feuille de route pratique :

• Maintenant (2024-2025) — Phase d'inventaire : Classification de tous les produits commercialisés dans l'UE (Default/Class I/Class II), premier inventaire des composants logiciels (ébauche SBOM), audit gap analysis des processus de développement existants par rapport aux exigences Annexe I
• Mi-2025 — Phase de préparation : Mise en place du processus VDP (politique rédigée, canal de signalement opérationnel), intégration des outils SCA (Software Composition Analysis) dans les pipelines CI/CD, premier plan de gestion des vulnérabilités, formation des équipes développement aux pratiques secure coding
• Avant septembre 2026 (21 mois) : Processus complet de signalement ENISA opérationnel et testé (dry run recommandé), tous les produits en production capable de signaler sous 24h une vulnérabilité exploitée
• 2026-2027 (jusqu'à décembre) : Finalisation des dossiers techniques par produit, rédaction des déclarations EU de conformité, apposition du marquage CE, lancement des audits par organismes notifiés pour les produits Class II (délai 6-18 mois à anticiper)

Les organisations déjà certifiées ISO 27001:2022 partent avec un avantage structurel : les contrôles A.8.25 à A.8.34 de l'Annexe A (cycle de vie de développement sécurisé, tests, gestion des vulnérabilités, gestion des changements) couvrent l'essentiel des exigences processus du CRA. Un audit CRA combiné à l'audit ISO 27001 permet de mutualiser les coûts de préparation et de réduire la charge documentaire globale.

Open source et CRA : exemptions et responsabilités clarifiées

La communauté open source a exprimé de vives inquiétudes lors des consultations préalables, craignant que le CRA ne pénalise les projets bénévoles. Le texte final intègre des exemptions importantes et clarifie la répartition des responsabilités dans la chaîne d'approvisionnement logicielle.

Exemptions confirmées :

• Logiciels open source développés exclusivement hors d'une activité professionnelle rémunérée : exemptés intégralement du CRA
• Logiciels open source commercialisés uniquement pour la version "community" gratuite sans support commercial : exemptés (mais le steward a des obligations de sécurité allégées)

Principe de responsabilité en cascade :

Dès qu'une bibliothèque open source est intégrée dans un produit commercial vendu, c'est le fabricant du produit final qui assume la responsabilité CRA de ce composant — pas le mainteneur amont. Cette logique oblige les éditeurs à exercer une due diligence rigoureuse sur leurs composants tiers : vérification de l'activité de maintenance, analyse des vulnérabilités historiques, qualification des contributeurs, mise en place de mécanismes de surveillance continue. L'article 13bis introduit la notion de steward open source pour les mainteneurs non commerciaux : obligation de publier une politique de sécurité et de coopérer aux signalements, mais sans marquage CE requis.

Interactions avec NIS2, AI Act et RGPD

Le CRA s'inscrit dans un triptyque réglementaire européen cohérent. Comprendre les interactions permet d'optimiser les efforts de conformité et d'éviter les doublons documentaires.

• CRA + NIS2 : NIS2 régule les opérateurs de secteurs essentiels (sécurité opérationnelle) ; le CRA régule les fabricants de produits numériques (sécurité intrinsèque des produits). Un hôpital sous NIS2 qui déploie un logiciel médical tombe sous NIS2 pour sa sécurité interne, et son éditeur sous CRA pour la sécurité du produit. Voir notre analyse de NIS2 en phase opérationnelle en 2026.
• CRA + AI Act : un robot industriel intégrant de l'IA relève des deux règlements simultanément. La Commission prépare des lignes directrices pour permettre un dossier technique unifié.
• CRA + RGPD : la conformité RGPD (article 32, privacy by design) est largement alignée avec les exigences CRA mais ne s'y substitue pas. Un produit conforme CRA facilite la conformité RGPD.
• CRA + PCI DSS : pour les terminaux de paiement et solutions e-commerce, voir notre analyse de PCI DSS 4.0.1.

Questions fréquentes

Le Cyber Resilience Act s'applique-t-il aux logiciels SaaS distribués en Europe ?

Les services purement SaaS accessibles uniquement via navigateur sans composant installé localement ne sont pas dans le périmètre direct du CRA — ils relèvent de NIS2 pour la résilience opérationnelle. Cependant, si votre SaaS accompagne un agent installé, un plugin, une extension navigateur ou un SDK clients, ces composants tombent dans le périmètre CRA. Les éditeurs SaaS qui livrent des bibliothèques clientes ou des modules d'intégration sont également concernés pour ces composants spécifiques. Validez précisément l'architecture de livraison de votre solution avant de conclure à une exemption totale.

Un fabricant non européen doit-il se conformer au CRA pour vendre dans l'UE ?

Oui, sans exception. Le CRA s'applique à tout produit numérique mis sur le marché européen, quelle que soit l'origine géographique du fabricant — principe du marché intérieur. Les fabricants extra-européens (américains, asiatiques, canadiens) qui n'ont pas d'établissement dans l'UE doivent désigner un représentant autorisé dans l'UE assumant la responsabilité de conformité en leur nom, sur le modèle du RGPD. L'absence de ce représentant suffit à interdire la commercialisation du produit dans l'UE.

Qu'est-ce qu'un organisme notifié CRA et comment en trouver un en France ?

Un organisme notifié (Notified Body) est un laboratoire accrédité par le COFRAC et formellement notifié à la Commission européenne pour évaluer la conformité aux règlements UE. Seuls les produits Class II (hyperviseurs, OS critiques, HSM, PKI) nécessitent obligatoirement cet audit tiers. En France, des organismes comme Bureau Veritas, LCIE Bureau Veritas, et certains laboratoires agréés par l'ANSSI seront susceptibles d'être notifiés CRA. La liste officielle sera publiée dans la base NANDO de la Commission. Anticipez des délais d'audit de 6 à 18 mois selon la complexité de votre produit.

Quand les normes harmonisées CEN/CENELEC pour le CRA seront-elles disponibles ?

CEN et CENELEC ont reçu le mandat M/604 de la Commission pour développer les normes harmonisées CRA via le groupe de travail JTC13 WG8. Les premières normes sont attendues fin 2025 ou début 2026, couvrant en priorité les exigences des produits IoT (ETSI EN 303 645 comme base) et les exigences génériques de l'Annexe I. En attendant, les fabricants peuvent s'appuyer sur les standards existants (IEC 62443, OWASP ASVS, NIST SP 800-53) comme référentiels intermédiaires, même sans présomption de conformité formelle.

Comment le CRA interagit-il avec la cyber assurance ?

La conformité CRA devient un critère croissant dans les questionnaires de souscription cyber. Un fabricant avec marquage CE CRA, SBOM disponible et VDP opérationnel représente un risque moindre — ce qui peut se traduire par des primes plus favorables. À l'inverse, commercialiser des produits non conformes après décembre 2027 pourrait exposer à des exclusions de couverture sur les incidents liés aux vulnérabilités produits. Voir notre analyse du marché de la cyber assurance en 2026 pour les critères de souscription actuels.