Cyber Resilience Act

Un règlement, trois dates

Le Cyber Resilience Act est le règlement (UE) 2024/2847 du 23 octobre 2024 concernant des exigences de cybersécurité horizontales pour les produits comportant des éléments numériques. Il est entré en vigueur le 10 décembre 2024. Ses obligations de signalement (article 14) s'appliquent depuis le 11 septembre 2026, et le reste du règlement, exigences essentielles, évaluation de conformité, marquage CE, s'appliquera le 11 décembre 2027. Il vise les fabricants de produits matériels et logiciels comportant des éléments numériques mis sur le marché de l'Union.

Ces éléments sont des points d'attention, pas un conseil juridique : faites-les valider par votre propre juriste.

Les délais de signalement en vigueur depuis le 11 septembre 2026

L'article 14 impose au fabricant de signaler toute vulnérabilité activement exploitée dans son produit et tout incident grave ayant un impact sur sa sécurité. Le calendrier est le même dans les deux cas pour les premières étapes : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures. Le rapport final diffère : pour une vulnérabilité, dans les 14 jours suivant la mise à disposition d'une mesure corrective ou d'atténuation ; pour un incident grave, dans le mois suivant la notification.

Les signalements passent par la plateforme unique de déclaration opérée par l'ENISA, dont l'agence a annoncé le lancement le 11 septembre 2026 en « initial operating capability » : une interface web, en anglais, sans API à l'ouverture ; le signalement volontaire prévu par l'article 15 viendra plus tard. Pour une organisation qui édite ou intègre du logiciel, le compte à rebours commence donc à la découverte d'une exploitation active, ce qui suppose d'être en mesure de la découvrir.

Composants, nomenclature logicielle et code fermé

Le règlement demande au fabricant de documenter les composants de son produit, notamment par une nomenclature logicielle (SBOM, « software bill of materials ») couvrant au moins ses dépendances de premier niveau, dans le cadre des exigences de traitement des vulnérabilités de son annexe I. La forme exacte et le niveau de détail attendus dépendent des actes d'exécution et des normes harmonisées en préparation, et une organisation a intérêt à suivre ce calendrier plutôt qu'à figer un format aujourd'hui.

Pour un acheteur, le CRA déplace une question : ce que contient un binaire fourni par un éditeur devient une information que le fabricant doit connaître et documenter. Quand cette documentation manque, ou quand le produit a été mis sur le marché avant que les exigences s'appliquent, la rétro-ingénierie du binaire, dans les limites du droit (article L122-6-1 du Code de la propriété intellectuelle, licence du produit), permet de vérifier les dépendances embarquées, les bibliothèques connues pour leurs CVE et la télémétrie. Un agent outillé avec REA extrait ces éléments d'un exécutable, d'une archive Electron ou d'un APK en quelques minutes ; le résultat s'utilise pour poser des questions au fournisseur, pas pour se substituer à sa déclaration.

Ce que SFEIR en fait

Les délais de 24 et 72 heures ne se tiennent que si l'organisation sait, avant l'incident, où sont ses failles. L'offre AI Cyber part de cette contrainte : analyser en boîte blanche, à chaque nouvelle génération de modèle, le code des applicatifs internes et du legacy, un projet et un type de faille à la fois, avec une preuve par test et un correctif prouvé pour chaque bug remonté. Le stock de vulnérabilités connues et corrigées, daté, est aussi ce qu'un fabricant doit pouvoir produire quand l'ENISA ou un client le lui demande.