Signalement CRA du 11 septembre 2026 : quoi déclarer, à qui, sous quel délai

La plupart des plans de conformité au Cyber Resilience Act visent décembre 2027, date du marquage CE cybersécurité. C'est une erreur de calendrier.

La première obligation contraignante du règlement (UE) 2024/2847 s'applique le 11 septembre 2026, et elle concerne tous les produits dans le périmètre du règlement, y compris ceux mis sur le marché bien avant l'entrée en application complète du texte.

Pour le coup, cette obligation n'est pas documentaire, elle impose un délai de 24 heures et malheureusement un processus qui n'a jamais été exécuté ne tiendra jamais ce délai.

L'essentiel en cinq points

• Deux types d'événements sont à déclarer : les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit.
• Trois échéances : 24 heures, 72 heures, puis un rapport final au plus tard 14 jours après la mise à disposition du correctif (1 mois pour les incidents graves).
• Un seul canal : la plateforme unique de signalement de l'ENISA, qui devrait être mise en ligne le 11 septembre 2026.
• Le parc installé est concerné, pas seulement les produits futurs, et l'obligation survit même à la fin de la période de support.
• Sanction maximale : 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Ce qu'il faut déclarer

Les vulnérabilités activement exploitées. Une vulnérabilité pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation de son propriétaire. Dans tous les cas, il s'agit de vérifier que l'éventuelle preuve de concept publiée s'applique bien à votre produit avant de conclure quoi que ce soit.

Les incidents graves ayant une incidence sur la sécurité du produit. Un incident qui affecte, ou est susceptible d'affecter, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité des données ou des fonctions.

Les gestionnaires de logiciels libres, les open-source software stewards, sont également soumis à une obligation de signalement lorsqu'ils sont impliqués dans le développement des produits concernés.

Les trois échéances

Étape	Délai	Contenu attendu
Alerte précoce	24 h après la prise de connaissance	Produit, version, résumé, date de prise de connaissance, États membres concernés
Notification	72 h après la prise de connaissance	Évaluation initiale, mesures correctives appliquées, actions possibles pour les utilisateurs
Rapport final	14 jours après la mise à disposition d'un correctif (vulnérabilité) ou 1 mois après la notification à 72 h (incident)	Description complète de la gravité et de l'impact

A noter : le compteur démarre à la prise de connaissance, pas à la découverte de la vulnérabilité ni à la publication d'un correctif.

Les orientations publiées par la Commission le 27 juillet 2026 situent ce moment. Face à un événement suspect ou à un signalement venu d'un client, d'un chercheur ou d'un média, le fabricant doit procéder immédiatement à une évaluation initiale, et il est réputé avoir pris connaissance lorsque, à l'issue de cette évaluation, il dispose d'un degré raisonnable de certitude que la vulnérabilité est activement exploitée ou que l'incident a compromis la sécurité de son produit.

La formulation laisse une marge d'appréciation, mais la Commission insiste sur la rapidité de cette évaluation initiale : faire traîner l'analyse pour retarder le départ du compteur n'est pas une stratégie tenable.

Vos produits actuels sont concernés

L'obligation ne dépend pas de la date de mise sur le marché, elle couvre aussi tous les produits dans le champ du CRA mis sur le marché avant le 11 décembre 2027.

Concrètement, un produit conçu en 2019, vendu en 2022, toujours supporté et disponible dans l'Union entre dans le périmètre dès cette semaine, alors même qu'il ne portera jamais de marquage CE cybersécurité.

A noter : ce point a été clarifié par un rectificatif publié au Journal officiel le 2 juillet 2025 (2025/90555), la version initiale du règlement étant ambiguë sur ce point.

La Commission précise également que l'obligation de signalement continue de s'appliquer après la fin de la période de support, contrairement aux exigences de gestion des vulnérabilités de l'annexe I partie II qui s'arrêtent avec le support. Un produit que vous ne maintenez plus mais qui reste en service chez vos clients relève donc toujours de l'article 14.

Il n'y a en revanche pas de rétroactivité sur la connaissance. Une exploitation active dont vous aviez déjà connaissance avant le 11 septembre 2026 n'est pas à déclarer rétrospectivement. En revanche, si la prise de connaissance intervient après cette date, l'obligation s'applique, y compris lorsque la vulnérabilité était déjà connue.

Si le périmètre CRA de votre produit n'est pas tranché, notre outil de détermination du périmètre donne une première réponse en quelques minutes.

À qui déclarer

Le signalement passe par la plateforme unique de signalement de l'ENISA, la Single Reporting Platform.

Le destinataire est le CSIRT désigné comme coordinateur dans l'État membre de votre établissement principal, c'est-à-dire le lieu où les décisions relatives à la cybersécurité de vos produits sont principalement prises.

Sans établissement principal identifiable dans l'Union, la règle applique la cascade suivante :

1. État membre où se trouve votre plus gros effectif dans l'Union
2. État membre où votre mandataire agit pour le plus grand nombre de produits
3. État membre où votre importateur met le plus de produits sur le marché
4. État membre où votre distributeur en met le plus à disposition
5. État membre comptant le plus d'utilisateurs

Une seule notification suffit pour un événement donné, même avec plusieurs filiales dans l'Union ou une maison mère hors Union. Évidemment, la coordination interne relève de votre responsabilité.

La plateforme se charge ensuite de diffuser l'information aux organismes européens concernés (CSIRT, autorités de surveillance du marché, etc.). L'ENISA publiera son URL publique sur sa page dédiée avant la mise en service.

Trois contraintes d'accès à anticiper

• L'authentification passe par EU Login, avec authentification multifacteur obligatoire. Les comptes peuvent et doivent être créés à l'avance.
• Un représentant principal, jusqu'à vingt secondaires. Le représentant principal enregistre l'entité et invite les autres, sachant que la validation par le CSIRT ne bloque pas la soumission d'une première déclaration.
• Aucune API à la mise en service. La soumission finale est manuelle, via l'interface, même si l'automatisation reste possible en amont dans vos propres outils.

En cas d'indisponibilité de la plateforme, l'ENISA indique qu'il faut attendre son rétablissement pour soumettre, le contact direct avec le CSIRT restant possible si la situation l'exige.

Les prérequis pour tenir 24 heures

Pour arriver à l'heure, il faut arriver en avance.

Savoir ce que contient le produit. Une vulnérabilité activement exploitée dans un composant tiers est déclarable par le fabricant du produit fini, et sans nomenclature logicielle à jour pour chaque version livrée, rapprocher une exploitation signalée dans la nature d'un produit du catalogue prend des jours. Notre article sur la gestion des CVE avec Yocto détaille une chaîne exploitable en production.

Savoir si le composant est réellement atteignable. La Commission est explicite sur ce point : si la vulnérabilité du composant tiers ne peut pas être exploitée dans votre produit, parce que le code vulnérable n'est pas atteignable par exemple, ou si elle n'y a tout simplement pas été exploitée, elle ne relève pas du signalement obligatoire. Vos obligations de gestion des vulnérabilités et de remontée vers le mainteneur du composant restent entières, et le signalement volontaire reste ouvert, mais une analyse d'atteignabilité documentée vous évite des déclarations inutiles tout en constituant la justification à produire si votre décision de ne pas déclarer venait à être contestée.

Savoir qui décide. Il faut une personne identifiée, joignable hors heures ouvrées, habilitée à qualifier un événement comme déclarable et à soumettre.

Avoir répété. Un premier signalement effectué sous pression, sur une interface jamais utilisée, avec un compte à créer dans l'urgence, ne tiendra pas 24 heures.

Informer les utilisateurs, une obligation distincte

La prise de connaissance déclenche aussi l'article 14(8), qui impose d'informer les utilisateurs impactés et, lorsque cela est approprié, l'ensemble des utilisateurs. À défaut d'information en temps utile, le CSIRT destinataire de la notification peut se substituer au fabricant pour informer directement les utilisateurs.

Informer ne signifie pas divulguer. La Commission précise que cette obligation n'implique ni publication ni diffusion indistincte, et que la communication détaillée peut être restreinte aux seuls utilisateurs concernés. Le cas est explicitement visé pour les produits déployés en environnement sensible ou essentiel, où publier des détails techniques augmenterait le risque. Une divulgation plus large trouve sa place une fois la vulnérabilité corrigée, l'annexe I partie II imposant de toute façon de publier les informations sur les vulnérabilités corrigées une fois la mise à jour disponible.

La contrainte opérationnelle porte sur la capacité à joindre nominativement les utilisateurs impactés, ce qui suppose de savoir qui déploie vos produits. C'est rarement le cas lorsque la vente passe par des distributeurs ou des intégrateurs.

Le niveau de sanction

Le non-respect de l'obligation de signalement relève de la tranche haute du règlement : jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.

Deux dérogations s'appliquent :

• Les microentreprises et petites entreprises ne sont pas exposées aux amendes pour un manquement au seul délai de 24 heures, mais l'obligation de déclarer demeure, tout comme les échéances suivantes.
• Les gestionnaires de logiciels libres sont exemptés d'amendes administratives, leur obligation de signalement restant applicable.

À faire cette semaine

1. Déterminer si vos produits entrent dans le champ du CRA.
2. Identifier votre établissement principal et le CSIRT coordinateur correspondant.
3. Créer les comptes EU Login des personnes habilitées à déclarer, avec MFA activée.
4. Désigner un représentant principal et des suppléants, avec une astreinte réelle.
5. Vérifier que la nomenclature logicielle de chaque produit supporté est à jour.
6. Rédiger une procédure de qualification d'une page, qui répond à une seule question : cet événement est-il déclarable, oui ou non.

---

TrustnGo accompagne les fabricants sur la mise en place des processus de gestion des vulnérabilités exigés par le CRA, de la génération de SBOM à la procédure de signalement. Voir nos services Cyber Resilience Act ou nous contacter.

Sources

• Règlement (UE) 2024/2847, articles 14, 16, 24, 64 et 69
• Rectificatif 2025/90555 du 2 juillet 2025, JO L
• ENISA, Single Reporting Platform, foire aux questions, mise à jour du 4 septembre 2026
• Commission européenne, FAQs on the CRA Implementation, section 5
• Commission européenne, communication C(2026) 5252 et son annexe, orientations sur l'application du CRA, 27 juillet 2026, points 210 à 220