123% de CVE signalées en plus par jour en 2026 par rapport à l'an dernier.

Qu'est-ce que le Cyber Resilience Act ?

La loi de l'UE qui fixe les règles de cybersécurité des produits matériels et logiciels, et ce qu'elle demande aux entreprises qui les fabriquent

Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, est un règlement de l'UE qui fixe des exigences de cybersécurité obligatoires pour les produits comportant des éléments numériques : le matériel et les logiciels qui se connectent à un appareil ou à un réseau, des routeurs et appareils de maison connectée aux applications, systèmes d'exploitation et composants logiciels vendus séparément. Il est entré en vigueur le 10 décembre 2024. Les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves depuis le 11 septembre 2026, et le reste du règlement s'applique à partir du 11 décembre 2027.

L'essentiel des obligations repose sur les fabricants. Ils évaluent le risque de cybersécurité, conçoivent les produits selon les exigences essentielles de l'annexe I, tiennent une nomenclature logicielle (SBOM), gèrent les vulnérabilités pendant une période de support d'au moins cinq ans, passent une évaluation de la conformité et apposent le marquage CE. Les importateurs et les distributeurs vérifient que cela a été fait. Les amendes atteignent €15 millions ou 2,5 % du chiffre d'affaires annuel mondial.

CRACI automatise une part importante des preuves requises par ces obligations : il enregistre sous forme de SBOM les composants récupérés par chaque build, les revérifie face aux nouvelles vulnérabilités après la livraison et exporte des preuves d'audit pour votre documentation technique. Lorsqu'une vulnérabilité doit être signalée, CRACI soumet les notifications prévues par le CRA aux autorités en votre nom. Voir comment CRACI soutient la conformité au CRA.

What the Cyber Resilience Act asks manufacturers to do

Le champ d'application du règlement (UE) 2024/2847, ses dates d'entrée en application, les délais de notification et la place des obligations relatives à la SBOM et à la gestion des vulnérabilités.

Petteri Pulkkinen et Erika Marttinen lors de Kubernetes Community Days Helsinki 2026, 8:03 à 15:20 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

Dates clés

DateCe qui se passe
23 octobre 2024 Adoption du règlement (UE) 2024/2847 par le Parlement européen et le Conseil
20 novembre 2024 Publication au Journal officiel de l'Union européenne
10 décembre 2024 Entrée en vigueur
11 juin 2026 Application des règles relatives à la notification des organismes d'évaluation de la conformité (chapitre IV)
11 septembre 2026 Application du signalement des vulnérabilités activement exploitées et des incidents graves (article 14), y compris pour les produits déjà sur le marché
11 décembre 2027 Application du reste du règlement

Les aspects clés du CRA

Exigences de sécurité obligatoires

Les produits doivent respecter les exigences essentielles de cybersécurité de l'annexe I lors de leur mise sur le marché et pendant toute leur période de support.

Classification fondée sur les risques

La plupart des produits relèvent de la catégorie par défaut. Les produits importants et critiques sont soumis à des procédures d'évaluation de la conformité plus strictes.

Gestion des vulnérabilités

Les fabricants tiennent une SBOM, corrigent les vulnérabilités sans délai et signalent celles qui sont activement exploitées dans les 24 heures.

Marquage CE

Après une évaluation de la conformité, le fabricant signe une déclaration UE de conformité et appose le marquage CE.

Documentation et transparence

La documentation technique est conservée au moins 10 ans ou pendant la période de support, et les utilisateurs savent quand le support prend fin.

Surveillance du marché

Les autorités nationales peuvent demander la documentation, ordonner des mesures correctives ou des rappels et infliger des amendes.

The CRA timeline is ticking

Key milestones you need to prepare for under the Cyber Resilience Act.

Notified body rules apply
June 2026
Vulnerability reporting enforcement
September 2026
We are here
Full application of the CRA act
December 2027
€15M
maximum fine, or 2.5% of global annual turnover
24 hours
to send an early warning of an actively exploited vulnerability
72 hours
to follow up with a full vulnerability notification

Qui est concerné par le CRA ?

Fabricants

Toute personne qui développe ou fabrique un produit comportant des éléments numériques, ou le fait fabriquer, et le commercialise sous son propre nom ou sa propre marque, à titre onéreux ou gratuit. Les fabricants situés hors de l'UE sont couverts lorsqu'ils y vendent.

Importateurs et distributeurs

Les importateurs et les distributeurs doivent vérifier qu'un produit porte le marquage CE et que le fabricant a respecté ses obligations avant de le mettre à disposition dans l'UE.

Logiciels open source

Seul l'open source fourni dans le cadre d'une activité commerciale est couvert. Les intendants de logiciels open source suivent un régime allégé, et les fabricants restent responsables des composants open source qu'ils intègrent.

Fournisseurs de logiciels et de SaaS

Les logiciels vendus en tant que produits sont couverts, tout comme le backend cloud dont un produit a besoin pour fonctionner. Le logiciel en tant que service seul relève de NIS2 plutôt que du CRA.

Hors champ : les produits déjà régis par les règles de l'UE sur les dispositifs médicaux, le diagnostic in vitro et la réception par type des véhicules, les produits aéronautiques certifiés, les équipements marins, les pièces de rechange identiques et les produits conçus exclusivement pour la sécurité nationale ou la défense (article 2).

Catégories de produits et évaluation de la conformité

Chaque fabricant réalise une évaluation de la conformité avant de mettre un produit sur le marché. La procédure dépend de la catégorie du produit.

CatégorieExemplesÉvaluation de la conformité
Par défaut La plupart des produits comportant des éléments numériques non listés à l'annexe III ou IV L'auto-évaluation (contrôle interne) est autorisée
Important, classe I (annexe III) Gestion des identités et des accès, navigateurs, gestionnaires de mots de passe, VPN, systèmes d'exploitation, routeurs et commutateurs, produits de sécurité pour la maison connectée Auto-évaluation uniquement si des normes harmonisées, des spécifications communes ou un schéma de certification sont appliqués ; sinon, un organisme notifié
Important, classe II (annexe III) Hyperviseurs et environnements d'exécution de conteneurs, pare-feu et systèmes de détection d'intrusion, microprocesseurs et microcontrôleurs inviolables Évaluation par un tiers via un organisme notifié, ou un schéma européen de certification de cybersécurité
Critique (annexe IV) Dispositifs matériels à boîtier de sécurité, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés Un certificat européen de cybersécurité lorsque la Commission l'exige ; sinon, une évaluation par un tiers

Exigences essentielles

L'annexe I fixe deux groupes d'exigences essentielles. Le premier couvre le produit lui-même, sur la base d'une évaluation documentée du risque de cybersécurité :

  • Aucune vulnérabilité exploitable connue lors de la mise sur le marché du produit
  • Une configuration sécurisée par défaut
  • Des mises à jour de sécurité, automatiques par défaut lorsque c'est applicable
  • Une protection contre les accès non autorisés, ainsi que de la confidentialité et de l'intégrité des données
  • La minimisation des données, la disponibilité des fonctions essentielles et une surface d'attaque limitée
  • La suppression sécurisée et définitive des données et réglages des utilisateurs

Le second couvre la façon dont le fabricant gère les vulnérabilités :

  • Une SBOM couvrant au minimum les dépendances de niveau supérieur
  • La correction des vulnérabilités sans délai, avec des mises à jour de sécurité distinctes des mises à jour fonctionnelles lorsque c'est possible
  • Des tests et des examens de sécurité réguliers
  • Une politique de divulgation coordonnée des vulnérabilités et un contact pour signaler les vulnérabilités
  • La divulgation publique des vulnérabilités corrigées dès qu'une mise à jour est disponible
  • La distribution sécurisée et gratuite des mises à jour, accompagnée de messages d'avertissement

Les fabricants fixent aussi une période de support d'au moins cinq ans, sauf si le produit est censé être utilisé moins longtemps, gardent chaque mise à jour de sécurité disponible pendant au moins 10 ans, et conservent la documentation technique et la déclaration UE de conformité pendant au moins 10 ans ou pendant la période de support si elle est plus longue (article 13).

Obligations et délais de signalement

Depuis le 11 septembre 2026, les fabricants notifient les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement, au CSIRT désigné comme coordinateur dans leur principal État membre de l'UE et à l'ENISA simultanément (article 14). Cela s'applique aussi aux produits déjà sur le marché.

ÉtapeVulnérabilité activement exploitéeIncident grave
Alerte précoce Dans les 24 heures suivant la prise de connaissance Dans les 24 heures suivant la prise de connaissance
Notification Dans les 72 heures, avec des détails sur le produit, l'exploit et les éventuelles mesures d'atténuation Dans les 72 heures, avec une évaluation initiale et les éventuelles mesures d'atténuation
Rapport final Au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation Dans un délai d'un mois après la notification de l'incident

Les fabricants doivent aussi informer les utilisateurs concernés et, le cas échéant, tous les utilisateurs, en indiquant les mesures d'atténuation qu'ils peuvent prendre. Tenir un délai de 24 heures suppose de savoir en quelques heures quels produits et quelles releases contiennent le composant vulnérable : c'est à cela que sert une SBOM par release.

Sanctions

Les États membres fixent les sanctions, dans la limite de ces plafonds (article 64). Les autorités de surveillance du marché peuvent aussi ordonner des mesures correctives, le retrait ou le rappel d'un produit.

ManquementAmende administrative maximale
Exigences essentielles de cybersécurité (annexe I) et obligations des fabricants (articles 13 et 14) Jusqu'à €15 millions ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu
Autres obligations, y compris celles des importateurs et des distributeurs, la déclaration de conformité, le marquage CE, la documentation technique et l'évaluation de la conformité Jusqu'à €10 millions ou 2 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu
Informations inexactes, incomplètes ou trompeuses fournies aux organismes notifiés ou aux autorités de surveillance du marché Jusqu'à €5 millions ou 1 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu

Les microentreprises et les petites entreprises ne sont pas sanctionnées pour le non-respect du délai de 24 heures de l'alerte précoce, et les intendants de logiciels open source ne sont sanctionnés pour aucune infraction.

L'open source et le CRA

Les logiciels libres et open source ne sont couverts que lorsqu'ils sont fournis dans le cadre d'une activité commerciale, et héberger un projet sur un dépôt ouvert ou un gestionnaire de paquets ne suffit pas à le mettre à disposition sur le marché. Les intendants de logiciels open source, des personnes morales telles que les fondations qui soutiennent des projets open source destinés à un usage commercial, doivent disposer d'une politique de cybersécurité documentée, coopérer avec les autorités de surveillance du marché et signaler les vulnérabilités activement exploitées dans la mesure où ils participent au développement (article 24).

Pour les fabricants, l'open source est un composant comme un autre. Ils doivent faire preuve de diligence raisonnable lors de son intégration, signaler les vulnérabilités qu'ils trouvent au projet qui le maintient et partager les correctifs qu'ils développent (article 13). C'est pourquoi la SBOM compte : elle enregistre quels composants open source, et dans quelles versions, sont livrés dans chaque release.

Ce que le CRA signifie pour les équipes de développement

Un produit d'aujourd'hui est surtout constitué du code des autres : bibliothèques open source, paquets récupérés dans des registres, images de base de conteneurs, SDK tiers, ainsi que les outils de build et les pipelines CI/CD qui assemblent le tout. L'attaque SolarWinds est passée par un système de build, et Log4Shell était une vulnérabilité dans une bibliothèque largement utilisée ; toutes deux ont atteint des produits finis. Le CRA rend le fabricant responsable de tout cela, y compris de la diligence raisonnable sur les composants tiers et open source qu'il intègre (article 13).

En pratique, les équipes qui se préparent au CRA :

  • Savent ce qui est livré dans chaque release, en produisant une SBOM à partir de chaque build dans un format lisible par machine tel que CycloneDX ou SPDX, plutôt qu'une seule fois au moment de la release
  • Surveillent les versions publiées, et pas seulement la branche principale, car une vulnérabilité trouvée après la release doit quand même être corrigée sans délai pendant la période de support
  • Conviennent de politiques de dépendances : comment choisir et examiner les nouveaux composants, à quelle vitesse les mises à jour arrivent et quels résultats bloquent une release
  • S'entraînent à tenir le délai de 24 heures : qui confirme l'exploitation active, qui dépose l'alerte précoce et qui informe les utilisateurs
  • Conservent les preuves au fil de l'eau, car les enregistrements de build, les SBOM et les résultats de tests alimentent la documentation technique à conserver au moins 10 ans

Pour les exigences sous forme de feuille de route étape par étape, voir le guide du CRA. Voir aussi ce que le CRA demande à une SBOM et comment CRACI soutient la conformité au CRA.

FAQ sur le Cyber Resilience Act

Des réponses courtes aux questions que les fabricants posent le plus souvent sur le CRA

Qu'est-ce que le Cyber Resilience Act ?

Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, est un règlement de l'UE qui fixe des exigences de cybersécurité obligatoires pour les produits matériels et logiciels comportant des éléments numériques mis sur le marché de l'UE. Il rend les fabricants responsables de la sécurité dès la conception et pendant une période de support d'au moins cinq ans, y compris la gestion des vulnérabilités, une SBOM et le signalement des vulnérabilités activement exploitées.

Quand le Cyber Resilience Act s'applique-t-il ?

Il est entré en vigueur le 10 décembre 2024. Les obligations de signalement de l'article 14 s'appliquent à partir du 11 septembre 2026, les règles relatives aux organismes d'évaluation de la conformité à partir du 11 juin 2026, et le reste du règlement à partir du 11 décembre 2027.

Le CRA s'applique-t-il aux logiciels et au SaaS ?

Les logiciels vendus ou fournis en tant que produits sont couverts, y compris les applications, les systèmes d'exploitation, les firmwares et les composants logiciels mis sur le marché séparément. Les services cloud ne sont couverts qu'en tant que traitement de données à distance d'un produit, par exemple le backend cloud qui permet de contrôler un appareil de maison connectée. Le logiciel en tant que service seul relève plutôt de NIS2 (considérant 12).

Le CRA s'applique-t-il aux logiciels open source ?

Uniquement à l'open source fourni dans le cadre d'une activité commerciale. Les projets open source non commerciaux sont hors de son champ. Les intendants de logiciels open source, comme les fondations qui soutiennent des projets destinés à un usage commercial, suivent un régime allégé et ne peuvent pas être sanctionnés par une amende. Les fabricants qui intègrent des composants open source à leurs produits en restent pleinement responsables.

Quelles sont les exigences de signalement du CRA ?

Les fabricants notifient les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement à leur CSIRT coordinateur et à l'ENISA : une alerte précoce dans les 24 heures, une notification dans les 72 heures, et un rapport final dans les 14 jours suivant un correctif pour les vulnérabilités ou dans un délai d'un mois pour les incidents. Ils informent aussi les utilisateurs concernés.

Le CRA exige-t-il une SBOM ?

Oui. L'annexe I, partie II exige une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de niveau supérieur. Elle fait partie de la documentation technique et est remise à une autorité de surveillance du marché sur demande ; elle n'a pas à être publiée.

Quelles sont les sanctions prévues par le CRA ?

Jusqu'à €15 millions ou 2,5 % du chiffre d'affaires annuel mondial en cas de manquement aux exigences essentielles ou aux obligations des fabricants, jusqu'à €10 millions ou 2 % pour les autres obligations, et jusqu'à €5 millions ou 1 % pour avoir induit les autorités en erreur. Les microentreprises et les petites entreprises ne sont pas sanctionnées pour le non-respect du délai de 24 heures de l'alerte précoce.

Le CRA s'applique-t-il aux produits déjà sur le marché ?

Les obligations de signalement oui, à partir du 11 septembre 2026. Pour le reste, les produits mis sur le marché avant le 11 décembre 2027 ne relèvent du CRA que s'ils font l'objet d'une modification substantielle après cette date.

Obtenez les preuves dont votre démarche CRA a besoin

Découvrez comment CRACI enregistre les SBOM de vos builds, surveille ce que vous avez livré et soumet les notifications prévues par le CRA en votre nom

Réserver une démo Vérifiez si le CRA vous concerne