Connexion Premium

Cyber Resilience Act : les obligations de signalement entrent en vigueur le 11 septembre

Sécurité dès la conception

Cyber Resilience Act : les obligations de signalement entrent en vigueur le 11 septembre

Illustration : Flock

Le Cyber Resilience Act, un important règlement pour la cybersécurité en Europe, entrera dans une nouvelle phase le 11 septembre. À cette date, les fabricants auront l’obligation de signaler les failles activement exploitées et les incidents graves à l’ENISA, l’agence centrale européenne de cybersécurité.

Le règlement européen sur la résilience cyber, ou CRA (UE 2024/2847), est entré en vigueur le 10 décembre 2024. S’agissant d’un règlement, il s’applique à l’ensemble des pays membres de l’Union, sans distinction. Contrairement aux directives, il ne nécessite pas de transposition dans le droit national.

La pleine entrée en application est attendue pour décembre 2027. Les responsabilités seront alors nombreuses, ainsi que les entreprises concernées : toute structure commercialisant un produit qui intègre au moins un composant numérique y est soumise. Le CRA distingue trois niveaux de risque :

  • les produits « courants » (la grande majorité) relèvent d’une auto-évaluation du fabricant,
  • les produits « importants » (définis à l’annexe III) comprennent de nombreuses catégories – systèmes de gestion d’identité, les navigateurs, les gestionnaires de mots de passe, les antivirus, hyperviseurs ou encore les VPN – et nécessitent de passer par un organisme dédié,
  • les produits « critiques » (définis à l’annexe IV) comprennent les dispositifs matériels avec boitier de sécurité, les « passerelles pour compteur intelligent » et les systèmes de cartes à puce, qui nécessitent eux aussi un organisme dédié.

Avant d’entrer toutefois dans le cœur de ces obligations, la mise en application passe par une étape intermédiaire : le signalement des failles exploitées et des incidents graves.

L’obligation de faire remonter les informations

L’article 14 du règlement entre en application le 11 septembre 2026, donc dans quelques jours à peine. Il impose aux fabricants de produits comportant des éléments numériques de signaler deux types d’événements distincts : toute vulnérabilité activement exploitée affectant ces produits, et tout incident grave ayant un impact sur leur sécurité.

Plus précisément, le fabricant devra notifier l’ENISA dans les 24 heures suivant la découverte (elle est qualifiée de « précoce »). Un rapport complet devra être fourni dans les 72 heures, puis un rapport final dans les 14 jours. Ces délais sont les mêmes que pour la directive NIS2, afin d’harmoniser le cadre de la cybersécurité (nous y reviendrons). Ils sont également identiques pour les failles exploitées et les incidents graves.

L’ENISA a le rôle de guichet central. L’agence sera chargée de distribuer ensuite les informations aux CSIRT (Computer Security Incident Response Team) nationaux des pays membres de l’Union. En France, il s’agit du CERT-FR. Via ce dernier, l’ANSSI assure alors la réception, l’analyse et la coordination du traitement. Si le produit est commercialisé dans d’autres pays, le CERT-FR doit aussi diffuser les informations obtenues à ses homologues.

Si la pleine application du Cyber Resilience Act aura des conséquences majeures, l’obligation du 11 septembre n’en est pas moins cruciale. Et pour cause : non seulement l’obligation pèse sur de très nombreuses entreprises, mais elle est également rétroactive. Contrairement à d’autres cadres européens, comme l’obligation pour les smartphones d’avoir au moins cinq ans de mises à jour logicielles, le CRA s’applique rétroactivement à tous les produits commercialisés.

Il reste 74% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (14)

votre avatar
La définition d'un incident grave a certainement fait souffler bon nombre de RSSI avec le susceptible de qui change pas mal de choses.
C'est toujours une sensation étrange que de devoir se poucave soi-même à une autorité qui peut t'infliger des uppercut bien salés. je suis curieux de voir les premières sanctions tomber d'ici 5 à 10 ans :dent:
votre avatar
A noter que la création de comptes à l'ENISA ne sera possible qu'à partir du 11 septembre et pas avant. On demande donc à toutes les sociétés commercialisant en Europe des équipements comportant des éléments numériques connectés directement ou indirectement à un réseau, de créer leur compte le 11 septembre pour être prêts le jour même à déclarer des failles exploitées activement ou des incident de cybersécu.

Le portail va tenir, c'est sûr (méthode coulé)
votre avatar
L'ENISA recommande justement de ne pas créer de compte le 11 septembre mais uniquement lorsque l'on doit envoyer la première notification ... mais c'est sûr que pour respecter les délais de notification, il va y avoir pas mal de monde qui aura envie d'avoir un compte prêt :)
votre avatar
Sachant que les personnes qui vont créer ce compte ne sont pas celles qui vont l'utiliser, c'est mort.

On parle tout de même d'une forme d'astreinte, s'agissant d'une obligation d'alerte sous 24h 7j/7, même le 1er mai.

Vu le coût des astreintes pour une entreprise, le compte devra être créé le plus tôt possible pour que le processus puisse se faire.

Globalement, cela va être mis en place en même temps que la page web permettant d'informer les fabricants des appareils concernés d'une faille activement exploitée ou d'un incident majeur, affectant l'un de leurs produits.
votre avatar
Mhh c'est pas forcément 7j/7. La notification dois avoir lieu dans les 24h après avoir pris connaissance de l'exploitation / incident (They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours.).
votre avatar
@TiTs c'est une question souvent posée et jusqu'à présent, la majorité des pros le traduisent bien par une dispo 7j/7. Cela a du sens car, curieusement, les pirates ne respectent pas les jours fériés (décidément, ils ne respectent rien).

Et vu que la recherche de correspondance entre les CVE publiées par le NIST ou l'EUVD, et les composants listés dans les SBOM est automatisée et se fait plusieurs fois par jour, les alertes peuvent tomber tous les jour.
votre avatar
Étant pro moi même, c'est intéressant. Dans mon cercle (produit industriel), la notion d'awarness est communément admise que tu ne dois pas être activement en attente de récupérer les signaux d'exploitation ou d'incident mais tu dois réagir dès que tu es au courant (email PSIRT, monitoring, retour d'équipe de maintenance/client ...). Après ne pas ouvrier les cas de support "cyber" ou l'email PSIRT c'est pas non plus la meilleures stratégie pour pas être au courant, il faut une adéquation entre les moyen et le risque.
votre avatar
La définition d'incident grave est tellement claire ^^
du coup il faudra leur reporter chaque coupure de courant aussi ?!
votre avatar
Ça pourrait peut-être aider à rendre plus ouverts les objets connectés, au grand plaisir d'Alexandre ? 😁
votre avatar
Il y a une subtilité qui m'échappe : si je suis éditeur de logiciel, je suis touché par ce règlement ?

L'article dit :
toute structure commercialisant un produit qui intègre au moins un composant numérique y est soumise
Un "produit", c'est forcément un objet physique, ou un logiciel aussi en est un ?
Et un site web (par exemple basé sur WordPress), c'est aussi un "produit" ? Si oui, si on trouve une faille dans WordPress, tous ses utilisateurs (ceux qui font le site avec WordPress, pas les visiteurs) doivent déclarer la faille, ou l'incident d'une attaque détectée utilisant cette faille ?
votre avatar
ça dépends !

La règle de base, c'est si le logiciel s'installe sur un device (PC/mobile), oui. Si c'est du SaaS / Web, non.

Plus d'info ici: https://cra.orcwg.org/faq/official/faq_1-2/
votre avatar
@potn oui si ton logiciel est sur le marché européen et qu'il est relié à un réseau logiquement, de manière directe ou indirecte.

Tout logiciel, commercialisé, tournant sur un PC ou autre plateforme connectée est donc concerné par le marquage CE.

Le SI derrière est aussi concerné au passage. Exemple, la passerelle de Somfy et tout le SI et l'application qui va avec.

Mais si ton logiciel ne fait aucun accès réseau, tu va pouvoir te défausser sur l'OS et sa bonne configuration par les utilisateurs pour être conforme.
votre avatar
Hum, des questions me viennent à l’esprit :


  • quid des produits purement en ligne (pure players), en opposition au bien physique

  • et quid des locations ? Par exemple une box Fibre estampillée Orange, fabriquée par Sagemcom, loué aux utilisateurs finaux ?

  • est ce que pour le grand publique (B2C) ou ça touche aussi le monde pro (B2B) ?




Super interessant sinon, ça pourrait impacter l’entreprise dans laquelle je travaille.
votre avatar
Les Software as a Service et les site internet ne sont pas touché: https://cra.orcwg.org/faq/official/faq_1-2/ (sauf si ils font partie d'un produit plus global, genre device IoT).

Pour les locations, cela dépends de qui le met sur le marché. A priori, ici c'est Orange qui signe: https://cdn.woopic.com/c10f167280f2414abb346a5347e1ecd9/prod/binaries/files/992931_29122644_5_UE_2025_2807_LIVEBOX_W7_254096484_BLB_signed.pdf

La CRA touche tous les produits mis sur le marché de l'UE, que ce soit en B2B ou B2C. La notion de mise sur le marché, c'est (en très gros) si un produit est vendu off the shelf. Si tu fais du custom pour un seul client, tu peux (éventuellement) ne pas être considéré comme « mis sur le marché ». C'est une notion bien plus large que la CRA, vu qu'elle définit si toutes les normes liées au marquage CE s'appliquent. Plus d'infos : https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0629(04)