Règlement de résilience cybernétique à compter du 11 septembre 2026 : l’obligation de déclaration dans les 24 heures, sur laquelle les équipes de sécurité informatique doivent désormais mettre en place des processus

7 min. de lecture

À compter du 11 septembre 2026, l’obligation de déclaration du Cyber Resilience Act (CRA) pour les vulnérabilités activement exploitées entrera en vigueur : alerte précoce sous 24 heures, déclaration complète sous 72 heures, rapport final sous 14 jours. Ceux qui ne disposent pas aujourd’hui d’un processus de réponse aux incidents (Incident Response) conforme au CRA ne pourront pas respecter ces délais en cas d’incident réel. Pour les fabricants de produits comportant des éléments numériques, il reste un délai de préparation de cinq mois – et ce temps est compté.

Points clés

• Le Cyber Resilience Act est en vigueur depuis le 11 décembre 2024. L’obligation de signalement pour les vulnérabilités activement exploitées et les incidents graves prend effet le 11 septembre 2026 (EU Digital Strategy, 2026).
• L’applicabilité intégrale du CRA, avec l’ensemble des exigences techniques pour les produits comportant des éléments numériques, débutera le 11 décembre 2027.
• La chaîne de signalement comporte trois niveaux : une alerte précoce sous 24 heures, un rapport complet sous 72 heures, et un rapport final sous 14 jours après la disponibilité de la mesure corrective.
• Les signalements transitent par la CRA Single Reporting Platform vers le CSIRT compétent du pays où se situe le siège social. L’ENISA reçoit l’information en parallèle, sans qu’une déclaration supplémentaire soit nécessaire.
• Les SBOM (Software Bill of Materials) ne sont plus une simple recommandation, mais une composante obligatoire de la gestion des vulnérabilités. Sans transparence des composants, un signalement ne peut être justifié de manière satisfaisante.

Ce que l’obligation de signalement du CRA implique concrètement à compter de septembre 2026

Le Cyber Resilience Act (CRA) constitue le premier règlement européen relatif à la cybersécurité des produits. Il vise les fabricants, les importateurs et les distributeurs de produits comportant des éléments numériques – c’est-à-dire pratiquement tout ce qui contient un logiciel ou est connecté en réseau. Sont concernés les éditeurs de logiciels classiques tout comme les fabricants de matériel disposant de systèmes embarqués, les fournisseurs d’appareils ménagers connectés, de capteurs industriels, de passerelles IoT et de produits bénéficiant de mises à jour de micrologiciel (firmware). L’application complète est prévue pour le 11 décembre 2027, mais un bloc d’obligations essentiel entre en vigueur plus tôt : à partir du 11 septembre 2026, les fabricants devront signaler les vulnérabilités activement exploitées et les incidents de sécurité graves.

Cette obligation de signalement représente, sur le plan opérationnel, la partie la plus critique du CRA. Elle intègre directement les équipes de sécurité informatique dans les processus réglementaires et crée une interface rigide entre la gestion des vulnérabilités et la communication avec les autorités. Les produits mis sur le marché après la date limite relèvent intégralement de l’obligation de signalement. Des règles transitoires s’appliquent aux produits existants, mais dès qu’une mise à jour est déployée, le fabricant doit être en mesure d’activer la chaîne de signalement du CRA.

L’Office fédéral de la sécurité des technologies de l’information (BSI) a précisé, dans le cadre de son initiative de conseil sur le CRA, qu’il s’agit d’obligations de signalement opérationnelles et non de simple documentation de conformité formelle. Les délais sont stricts. Les destinataires sont clairement définis. Le contenu des rapports est exigeant, tant techniquement que sur le fond. Un rapport standard piloté par le marketing ne suffit pas – il faut fournir des indications précises sur les produits concernés, les exploits, le statut des mesures d’atténuation et la disponibilité des correctifs.

L’horloge 24-72-14 : les chaînes de signalement en détail

Les trois délais du CRA (Cyber Resilience Act) pour les vulnérabilités activement exploitées s’enchaînent et contraignent les équipes de sécurité à adopter une routine d’escalade clairement cadencée. Le chronomètre commence à tourner dès que le fabricant a connaissance de l’exploitation active. À partir de ce moment, il reste 24 heures pour une Early Warning (alerte précoce), qui contient les informations fondamentales sur la vulnérabilité, le produit concerné et l’état des connaissances. L’Early Warning n’est pas une déclaration complète, mais un signal d’alerte précoce destiné aux autorités.

Dans les 72 heures suivant cette même prise de connaissance, la déclaration complète doit suivre. Elle contient des informations sur la nature de la vulnérabilité, les versions de produits concernées, les premières recommandations d’atténuation et l’état actuel de la gestion de l’incident. Quiconque ne respecte pas ce créneau de 72 heures enfreint l’une des obligations centrales de conformité du CRA. La conséquence pratique est que les processus de réponse aux incidents doivent, dès le premier jour ouvrable suivant la découverte, non seulement fonctionner techniquement, mais aussi être prêts à déclarer sur le plan réglementaire.

La troisième étape est le rapport final. Pour les vulnérabilités activement exploitées, un délai de 14 jours s’applique à compter de la disponibilité d’une mesure corrective – c’est-à-dire à partir du moment où le correctif peut être déployé. Pour les incidents de sécurité graves, cette période est étendue à un mois. Le rapport final documente la cause racine, les mesures prises, l’état du déploiement du correctif et les enseignements pour les futures versions du produit. Il constitue la base des audits ultérieurs menés par l’ENISA et les autorités nationales.

Qui déclare au sein de l’entreprise et vers qui ?

Les déclarations au titre du Cyber Resilience Act (CRA) transitent centralement par la CRA Single Reporting Platform – un système de déclaration géré par l’ENISA qui prévoit une saisie unique. Le fabricant adresse formellement la déclaration au Computer Security Incident Response Team (CSIRT) de l’État membre de son siège social. En Allemagne, l’autorité compétente est le BSI (Bundesamt für Sicherheit in der Informationstechnik) ou le CERT-Bund. L’information est transmise en parallèle à l’ENISA, sauf dans des cas d’exception clairement définis présentant des intérêts de sécurité particuliers.

Pour les entreprises disposant de plusieurs sites de production ou de filiales dans différents États membres de l’UE, la règle du siège social est déterminante. Elle définit quel CSIRT est compétent, quelles directives nationales s’appliquent et qui doit être contacté en cas de questions. Les conglomérats aux structures mixtes doivent documenter proprement cette attribution et clarifier au sein de l’organisation qui déclenche la déclaration en cas d’urgence. Un simple responsable produit sans mandat pour la communication avec les autorités échouera face à la réalité du CRA.

Au sein de l’entreprise, la déclaration CRA nécessite une responsabilité clairement définie. Elle réside typiquement au sein du Product Security Incident Response Team (PSIRT), en lien direct avec le bureau du CISO (Chief Information Security Officer). Ceux qui ne disposent pas encore d’un PSIRT doivent mettre en place cette fonction avant la date limite. L’alternative consiste à contraindre les équipes de développement ad hoc à la procédure de déclaration – ce qui ne s’adapte pas à l’échelle et échouera face aux délais de 24 heures. La question des ressources humaines est au moins aussi importante que la préparation technique.

Ce qu’un processus de réponse aux incidents prêt pour le CRA doit accomplir

Un processus conforme au Cyber Resilience Act (CRA) repose sur trois piliers : la détection, l’évaluation et le signalement. La détection signifie que le fabricant identifie précocement l’exploitation active – grâce à la surveillance de ses propres produits, à l’analyse de flux de Threat Intelligence, aux canaux de divulgation coordonnée des vulnérabilités (CVD) et à l’intégration aux structures des ISAC (Information Sharing and Analysis Centers). Un fabricant qui réagit uniquement aux plaintes de clients se trouve en position désavantageuse, car il atteint tardivement le seuil de connaissance et que l’horloge des 24 heures démarre en parallèle au triage de l’incident.

L’évaluation signifie qu’il faut être capable d’apprécier la pertinence d’un signalement en quelques heures seulement. La vulnérabilité signalée est-elle réellement exploitée activement, ou seulement exploitable théoriquement ? Quelles versions de produits sont concernées ? Des mesures d’atténuation existent-elles déjà, ou faut-il développer un correctif à chaud ? Cette capacité de triage exige un Software Bill of Materials (SBOM) à jour, des environnements de reproduction testés et une matrice d’escalade claire. Les équipes qui ne terminent leur triage aujourd’hui qu’après plusieurs jours ont besoin d’investir dans leurs processus et leurs outils.

Le signalement constitue le dernier pilier et simultanément le point où l’obligation de conformité rencontre la réalité technique. Le contenu des rapports doit être structuré, précis et juridiquement sécurisé. Le CSIRT (Computer Security Incident Response Team) n’attend pas de communication marketing, mais des indications techniques au niveau CVE (Common Vulnerabilities and Exposures), des horodatages clairs et des étapes d’atténuation traçables. Celui qui, en situation réelle, doit faire la traduction entre le développement, le service juridique et la communication perd du temps. Les textes types et les modèles validés sont des préparatifs obligatoires.

La nomenclature logicielle (SBOM) comme prérequis technique

Le Cyber Resilience Act (CRA) exige explicitement la création et la maintenance d’une nomenclature logicielle (Software Bill of Materials – SBOM) comme base de la gestion des vulnérabilités. Une SBOM est une liste lisible par machine de tous les composants logiciels d’un produit, incluant les versions, les licences et les dépendances. Sans SBOM, il est impossible de déterminer rapidement quels produits sont concernés en cas de faille de sécurité. Le respect des délais de déclaration devient alors pratiquement impossible.

Les deux formats de SBOM les plus courants sont SPDX et CycloneDX. Tous deux sont lisibles par machine, pris en charge par des outils et conformes aux normes de l’ENISA (Agence de l’Union européenne pour la cybersécurité). Pour la mise en œuvre, il est recommandé de les générer lors du processus de compilation (build) ; les SBOM issus des dépôts de code sont souvent incomplets car ils ne reflètent pas fidèlement les dépendances binaires et les bibliothèques transitives. Des outils comme Syft, Trivy ou les intégrations SBOM des principaux gestionnaires de paquets se sont imposés dans les environnements de développement de la région DACH (Allemagne, Autriche, Suisse) et fournissent des résultats valides.

La maintenance continue est cruciale. Un SBOM créé uniquement lors de la publication devient obsolète en quelques jours si des dépendances sont corrigées. Les organisations prêtes pour le CRA traitent les SBOM comme des artefacts vivants, versionnés à chaque compilation et disponibles dans un stockage centralisé. En cas d’urgence, une simple interrogation permet alors de déterminer en quelques minutes quelles versions de produit contiennent une bibliothèque affectée, condition préalable à une notification rapide.

Calendrier : échéances et obligations

Sources : EU Digital Strategy, BSI CRA Portal, Hogan Lovells Insights 2026

Analyse des écarts : six questions sur votre propre processus

Avant toute mise en œuvre, il est conseillé de procéder à une analyse des écarts structurée basée sur six questions opérationnelles. L’équipe CISO (Chief Information Security Officer) peut y répondre en une demi-journée, ce qui permet d’établir un plan d’action clair :

1. Seuil de connaissance : Comment l’entreprise est-elle informée aujourd’hui des vulnérabilités activement exploitées dans ses propres produits ? Existe-t-il une politique de divulgation coordonnée des vulnérabilités (Coordinated Vulnerability Disclosure Policy) avec des temps de réaction courts ? Le renseignement sur les menaces (Threat Intelligence) est-il filtré et analysé pour les produits propres ?
2. Capacité de triage : Le service de sécurité est-il en mesure d’évaluer, dans un délai de trois à quatre heures, si une vulnérabilité signalée fait l’objet d’une exploitation active ? Des environnements de reproduction existent-ils pour toutes les versions logicielles en production ?
3. Actualité des SBOM : Un SBOM (Software Bill of Materials) à jour est-il généré et conservé pour chaque produit livré ? Les SBOM sont-ils lisibles par machine et consultables, ou sont-ils stockés sous forme d’export PDF dans un wiki ?
4. Responsabilité de signalement : Qui, au sein de l’entreprise, est habilité à envoyer un signalement CRA au BSI (Office fédéral allemand pour la sécurité des technologies de l’information) ? Cette personne est-elle joignable 24h/24 et 7j/7 ? Comment la coordination avec le service juridique et la communication est-elle réglementée ?
5. Textes types : Des modèles préalablement validés existent-ils pour l’alerte précoce (Early Warning), le rapport complet et le rapport final ? Sont-ils approuvés par le service juridique et remplis sur le plan technique ?
6. Niveau d’exercice : La chaîne de signalement CRA a-t-elle déjà été testée lors d’un exercice à blanc ? Les exercices sur table (Tabletop exercises) avec une escalation chronométrée révèlent les lacunes du processus avant qu’elles ne coûtent cher dans un cas réel.

Quiconque peut répondre par un « oui » fiable aux six questions est prêt pour le CRA. Ceux qui ne peuvent pas répondre par l’affirmative à deux questions ou plus ont besoin immédiatement d’une feuille de route concrète avec un calendrier allant jusqu’en août 2026 – un mois de marge avant la date limite est le strict minimum.

Conclusion

Le Cyber Resilience Act (CRA) instaure une date limite réglementaire ferme au 11 septembre 2026, une échéance qui n’existait pas jusqu’ici dans le droit allemand des produits. L’obligation de signalement des vulnérabilités activement exploitées ne constitue pas un simple document de conformité, mais un processus opérationnel qui doit être fonctionnel en moins de 24 heures. Les équipes de sécurité IT ont besoin d’une responsabilité clairement établie, de voies d’escalade définies, de nomenclatures logicielles (SBOM) à jour et de modèles de notification prêts à l’emploi. La mise en place technique est réalisable en cinq mois, mais à condition de débuter l’analyse des écarts dès maintenant.

La partie souvent sous-estimée est l’aspect organisationnel : qui effectue le signalement, sous quel mandat et sur quelle base juridique. Sans une responsabilité clarifiée, les préparatifs techniques risquent d’être vains en cas d’urgence réelle. Pour la plupart des fabricants de la zone DACH (Allemagne, Autriche, Suisse), la constitution d’une équipe de réponse aux incidents de sécurité des produits (Product Security Incident Response Team) représente l’étape cruciale – et il ne faudrait pas attendre le 1er septembre pour la lancer.

Questions fréquentes

Le CRA s’applique-t-il également aux logiciels Open Source ?

Le Cyber Resilience Act (CRA) traite le logiciel Open Source de manière différenciée. Les projets Open Source non commerciaux sont exemptés des principales obligations. Cependant, dès lors que l’Open Source est distribué dans le cadre d’un produit commercial ou intégré au sein d’entreprises, les obligations incombent au fournisseur du produit commercial – et non au mainteneur Open Source initial. Les entreprises qui s’appuient sur des composants Open Source assument donc l’entière responsabilité liée au CRA pour leurs produits intégrés.

Que se passe-t-il en cas d’oubli de signalement ?

Les violations des obligations de signalement du CRA peuvent être sanctionnées par des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel – le montant le plus élevé étant retenu. L’application de ces sanctions relève des autorités nationales de surveillance du marché. En Allemagne, la répartition des rôles est actuellement coordonnée entre le BSI (Office fédéral de la sécurité des technologies de l’information) et la BNetzA (Agence fédérale des réseaux). Plus important que le montant de l’amende est l’impact sur la réputation : une vulnérabilité activement exploitée et non signalée peut entraîner une exclusion du marché et des rappels de produits.

Un petit éditeur de logiciel avec 15 employés doit-il également être conforme au CRA ?

Oui. Le CRA ne prévoit pas d’exemption générale pour les PME, contrairement au Data Act de l’UE. Les obligations s’appliquent indépendamment de la taille de l’entreprise et de son chiffre d’affaires, dès qu’un produit comportant des éléments numériques est mis sur le marché de l’UE. La mise en conformité est particulièrement exigeante pour les petits fabricants, car ils doivent établir des processus de signalement avec des ressources limitées. Des associations et l’ENISA (Agence de l’Union européenne pour la cybersécurité) ont annoncé des guides pour les PME afin de faciliter cette mise en œuvre.

Comment le CRA s’articule-t-il avec l’obligation de signalement NIS2 ?

Le CRA et la directive NIS2 existent en parallèle et ciblent des publics différents. NIS2 s’adresse aux opérateurs d’infrastructures critiques et d’importance vitale dans 18 secteurs critiques. Le CRA vise les fabricants de produits comportant des éléments numériques. Une entreprise peut relever simultanément des deux réglementations – par exemple, un hôpital développant son propre logiciel médical. Les obligations de signalement diffèrent : NIS2 exige de signaler les incidents sur sa propre infrastructure, tandis que le CRA exige de signaler les vulnérabilités dans les produits vendus.

Qu’entend-on exactement par « Early Warning » au sens du CRA ?

L’« Early Warning » (alerte précoce) est un premier signalement formel informant l’autorité qu’un cas de signalement potentiel existe. Elle contient le type de vulnérabilité, le produit concerné, le moment de la prise de connaissance et une première évaluation de la gravité. Elle ne doit pas être confondue avec un communiqué de presse – au contraire, elle reste confidentielle entre le fabricant et le CSIRT (Computer Security Incident Response Team). Les détails techniques qui pourraient être détournés pour une exploitation ne doivent pas figurer dans l’« Early Warning », mais dans le signalement complet ultérieur via un canal sécurisé.

Un processus ISO-27001 existant suffit-il pour être conforme au CRA ?

Non, la norme ISO 27001 seule ne suffit pas. Ce standard couvre la gestion de la sécurité de l’information, mais pas les obligations spécifiques aux produits imposées par le CRA. En particulier, les délais de signalement, l’obligation de SBOM (Software Bill of Materials) et la dimension de sécurité des produits ne sont pas inclus dans l’ISO 27001. Des normes complémentaires comme l’IEC 62443 pour la cybersécurité industrielle ou l’ETSI EN 303 645 pour les produits IoT offrent les blocs manquants. Une documentation conforme au CRA combine typiquement plusieurs normes et les complète par des processus de signalement spécifiques au CRA.

Source de l’image de titre : Pexels / Tima Miroshnichenko

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow