Les obligations de signalement du CRA ont commencé plus tôt que beaucoup d’organisations ne l’avaient prévu. Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques qui relèvent du CRA doivent être en mesure de signaler les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit à l’ENISA et au coordinateur CSIRT désigné, comme le CCB en Belgique.
Pour de nombreuses organisations, décembre 2027 est devenu la date associée au Cyber Resilience Act. C’est à partir de cette date que le CRA s’applique de manière générale aux produits comportant des éléments numériques mis sur le marché de l’UE.
Mais les premières obligations opérationnelles de signalement sont arrivées plus tôt. Depuis le 11 septembre 2026, les fabricants de produits relevant du champ d’application du CRA doivent être en mesure de notifier les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit. Les lignes directrices de la Commission européenne de juillet 2026 confirment que cela s’applique aussi aux produits déjà mis sur le marché avant le 11 décembre 2027.
Cela change la question immédiate. Il ne s’agit plus seulement de savoir si une organisation peut démontrer sa pleine conformité au CRA d’ici 2027. Il s’agit de savoir si elle peut, dès aujourd’hui et dans des délais serrés, détecter, évaluer, escalader et signaler un événement lié à la sécurité d’un produit.
Votre organisation pourrait-elle, dès demain, déterminer, documenter et signaler un événement de sécurité produit relevant du CRA ?
1. Pourquoi la première échéance du CRA est-elle un défi opérationnel ?
À première vue, le signalement ressemble à une activité juridique ou de conformité. En pratique, le rapport n’est que le résultat visible d’un processus de sécurité bien plus large.
Avant de pouvoir signaler une vulnérabilité activement exploitée, un fabricant doit établir quels produits et quelles versions sont concernés, si la fonctionnalité vulnérable est accessible, si l’exploitation a lieu dans le contexte du produit, quels utilisateurs peuvent être touchés, quelles mesures d’atténuation sont disponibles et qui est habilité à prendre la décision de signaler.
Ces capacités dépendent généralement de la Product Security, de l’Application Security, de la gestion des vulnérabilités, de la réponse aux incidents et de l’ingénierie. Les parties prenantes juridiques et conformité restent importantes, mais elles ne peuvent pas produire les preuves techniques nécessaires une fois l’incident déjà commencé.
La séquence de signalement en un coup d’œil
| Déclencheur | Sous 24 h | Sous 72 h | Rapport final |
|---|---|---|---|
| Vulnérabilité activement exploitée | Alerte précoce | Notification de la vulnérabilité | Au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation |
| Incident grave ayant un impact sur la sécurité du produit | Alerte précoce | Notification de l’incident | Dans un délai d’un mois après la notification de l’incident |
2. Quand le compte à rebours commence-t-il ? La notion de « prise de connaissance »
Le compte à rebours ne démarre pas forcément à chaque signal vague, rumeur non vérifiée ou ticket de support suspect. Selon les lignes directrices de la Commission, le moment pertinent est atteint lorsque, après une première évaluation, le fabricant dispose d’un degré raisonnable de certitude qu’une vulnérabilité est activement exploitée ou qu’un incident grave a compromis la sécurité du produit.
Cette distinction est utile, mais exigeante. Elle signifie que l’organisation a besoin d’un chemin rapide et défendable entre le signal et la décision. Attendre une certitude parfaite peut créer des retards ; traiter chaque signal faible comme confirmé peut entraîner des escalades inutiles. La capacité opérationnelle réside dans cette première évaluation.
Pour mener cette évaluation de manière cohérente, les équipes ont besoin de critères convenus, de sources de preuves et d’une responsabilité claire pour la décision. Elles doivent pouvoir reconstituer quand un signal est arrivé, ce qui a été vérifié, quand un degré raisonnable de certitude a été atteint, qui a approuvé la conclusion et quand les notifications externes ont été soumises.
Les questions auxquelles le processus doit répondre
- Qui réalise la première évaluation technique ?
- Quelles preuves suffisent pour conclure à une exploitation active ?
- Comment les produits, versions et clients concernés sont-ils identifiés ?
- Qui peut déclarer qu’un degré raisonnable de certitude a été atteint ?
- Comment l’incertitude, les désaccords et les approbations sont-ils consignés ?
3. Pourquoi le signalement exige-t-il plus qu’un formulaire ?
Pour une vulnérabilité activement exploitée, le processus peut exiger une alerte précoce sous 24 heures, une notification de la vulnérabilité sous 72 heures et un rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation. Pour un incident grave, il peut exiger une alerte précoce sous 24 heures, une notification de l’incident sous 72 heures et un rapport final dans un délai d’un mois après la notification de l’incident.
Ces notifications doivent être soumises via la Single Reporting Platform (SRP) de l’ENISA, qui offre un canal de signalement unique et transmet les informations au coordinateur CSIRT national compétent, comme le CCB en Belgique.
Les premières étapes ne peuvent donc pas dépendre d’une rédaction partant de zéro. L’identification des produits, les contacts pour le signalement, les circuits d’approbation, la gestion des preuves et les modèles de communication doivent déjà exister. La soumission à 72 heures nécessite ensuite une première vue technique : la nature de l’exploit ou de l’incident, le produit concerné, l’évaluation d’impact disponible, les mesures déjà prises, les mesures que les utilisateurs peuvent prendre et la sensibilité des informations signalées.
Après la prise de connaissance, les utilisateurs concernés doivent aussi être informés et recevoir, si nécessaire, les mesures d’atténuation des risques ou mesures correctives appropriées. La communication doit être rapide, fondée sur les risques et proportionnée. Elle doit aider les utilisateurs à réduire leur exposition sans diffuser de détails techniques plus largement que nécessaire tant que l’exploitation reste possible.
Un composant tiers peut tout de même devenir un sujet de signalement au niveau du produit
Une CVE publique dans une dépendance n’est pas automatiquement à signaler par chaque fabricant qui l’utilise. L’organisation doit déterminer si la vulnérabilité est présente dans le contexte de son produit, si le code vulnérable est accessible et si la situation répond au critère d’exploitation active. Ce jugement dépend directement de la qualité du SBOM (software bill of materials), de la couverture SCA (software composition analysis), de la responsabilité des dépendances et de l’analyse d’accessibilité dans le contexte du produit.
4. Qu’est-ce que cela signifie pour chaque rôle ?
Pour les développeurs et les équipes produit. Les équipes produit n’ont pas besoin de devenir des spécialistes de la réglementation. Elles doivent en revanche pouvoir mettre rapidement à disposition les informations sur le produit lorsqu’un incident survient.
- Maintenir une responsabilité claire pour les produits, versions, modèles de déploiement et configurations prises en charge.
- Relier les vulnérabilités et incidents aux versions, composants et environnements clients concernés.
- Conserver les preuves techniques et documenter les mesures d’atténuation, correctifs et contournements.
- Escalader les signaux suspects liés à la sécurité des produits au lieu de les laisser dans les files de support ordinaires.
Pour les responsables Application Security et Product Security. Le rôle passe de la recherche de vulnérabilités à la facilitation de décisions au niveau du produit sous pression temporelle.
- Mettre en place un processus de réception et de triage des signalements provenant de chercheurs, clients, fournisseurs et équipes internes.
- Définir des critères d’évaluation de l’exploitabilité, de l’accessibilité et de l’impact sur le produit.
- Relier les résultats SBOM/SCA, les modèles de menaces et la connaissance de l’architecture à l’analyse des incidents.
- Tenir un journal des décisions qui montre comment la prise de connaissance et l’obligation de signalement ont été déterminées.
Pour les équipes de réponse aux incidents et PSIRT. La préparation aux signalements CRA repose sur un PSIRT (Product Security Incident Response Team) ou un modèle opérationnel équivalent qui relie l’investigation technique, la responsabilité des produits, le signalement aux autorités et la communication avec les clients.
- Définir des seuils d’escalade pour les vulnérabilités activement exploitées et les incidents graves de sécurité des produits.
- Préparer les workflows et modèles pour les étapes à 24 heures, à 72 heures et le rapport final.
- Coordonner les mesures correctives, les consignes aux utilisateurs et les mises à jour continues.
- Tester le workflow avant qu’un événement réel ne crée une pression liée aux délais.
Pour les CTO et les CISO. La direction a besoin de l’assurance que le processus fonctionne en pratique, et pas seulement qu’une politique existe.
- Quels produits relèvent du CRA, y compris ceux déjà sur le marché ?
- Qui est responsable de la décision de signaler ?
- L’organisation pourrait-elle établir une exploitation active en 24 heures ?
- L’organisation sait-elle comment l’ENISA et le coordinateur CSIRT désigné s’intègrent dans le workflow ?
- Pourrait-elle prouver la chronologie de la prise de connaissance, du triage, de l’approbation, de la soumission et de la communication aux utilisateurs ?
5. Comment construire le pont vers la préparation au signalement ?
La plupart des organisations n’ont pas besoin d’inventer des disciplines de sécurité entièrement nouvelles. Les briques existent déjà dans les programmes AppSec et de sécurité des produits matures. Le travail consiste à les relier en un processus opérationnel reproductible et fondé sur des preuves.
| Capacité | À quoi ressemble la préparation |
|---|---|
| Visibilité sur les produits | Un inventaire des produits potentiellement concernés, avec versions, responsables, dépendances, distribution et statut de support. |
| Réception des vulnérabilités | Un circuit structuré pour recevoir et suivre les signalements des clients, chercheurs, fournisseurs et équipes internes. |
| Responsabilité du PSIRT | Une responsabilité claire pour le triage, les décisions de signalement, les notifications, la coordination de la remédiation et la communication avec les utilisateurs. |
| Évaluation de l’exploitabilité | Des critères documentés pour l’accessibilité, les preuves d’exploitation, les versions concernées et l’impact au niveau du produit. |
| Workflow de signalement | Des étapes connues vers l’ENISA et le coordinateur CSIRT, des approbations internes, des contacts, des minuteurs et des modèles préparés. |
| Communication avec les utilisateurs | Un processus proportionné pour informer les utilisateurs concernés et leur fournir des consignes d’atténuation ou correctives concrètes. |
| Preuves et traçabilité | Un journal des décisions qui conserve les signaux, les étapes d’évaluation, le moment de la prise de connaissance, les approbations, les soumissions et les mises à jour. |
6. Quel lien avec l’AppSec et la sécurité des produits ?
La préparation aux signalements CRA n’est pas séparée du développement sécurisé. Les pratiques de Secure SDLC produisent la connaissance des produits et la traçabilité nécessaires lors d’un événement. La modélisation des menaces identifie les chemins d’abus, les actifs critiques et les besoins en télémétrie. OWASP SAMM peut aider à évaluer si les pratiques de gouvernance, de conception, d’implémentation, de vérification et d’exploitation sont reproductibles plutôt qu’informelles.
Les capacités SBOM et SCA deviennent des données opérationnelles pour l’analyse des composants. La gestion des vulnérabilités détermine la gravité, l’exploitabilité, la responsabilité et la remédiation. La réponse aux incidents apporte l’investigation et la coordination. La gouvernance de la sécurité des produits relie ces capacités à des décisions responsables et à la communication avec les clients.
Le véritable écart n’est souvent pas l’absence de certaines capacités. C’est le fait qu’elles fonctionnent de manière isolée. Un bon programme de préparation les relie avant qu’un événement réel n’oblige l’organisation à improviser.
En résumé
La première échéance opérationnelle du CRA n’était pas décembre 2027. C’était le 11 septembre 2026, et les obligations s’appliquent désormais.
Les organisations les mieux préparées sont celles qui peuvent identifier, évaluer, escalader et communiquer les problèmes de sécurité des produits rapidement et de manière cohérente. Une grande fonction de conformité ne peut pas compenser une faible visibilité sur les produits, une responsabilité PSIRT floue ou un triage technique lent.
La bonne nouvelle, c’est que les briques nécessaires sont connues : gestion des vulnérabilités, opérations PSIRT, modélisation des menaces, SBOM/SCA, réponse aux incidents et pratiques de développement sécurisé. Le défi consiste à les transformer en un seul processus opérationnel qui produit des décisions rapides, des preuves fiables et une communication proportionnée.
C’est le pont que les organisations doivent construire dès maintenant, avant que le premier événement réel ne le mette à l’épreuve.
Prochaine étape. Notre CRA Reporting Readiness Check évalue si vous pouvez respecter dès aujourd’hui les obligations de signalement, du périmètre produit et de la réception des vulnérabilités jusqu’au workflow ENISA et à la consignation des preuves. Découvrir le CRA Reporting Readiness Check
Pour aller plus loin. Téléchargez notre livre blanc « 10 clarifications pratiques issues des lignes directrices du CRA ». Télécharger le livre blanc
Questions fréquentes
Chaque CVE publique dans un composant que nous utilisons doit-elle être signalée ?
Non. Cela dépend de la présence de la vulnérabilité dans le contexte de votre produit, de l’accessibilité du code vulnérable et du fait que la situation réponde ou non au critère d’exploitation active.
Que faut-il soumettre sous 72 heures ?
Une première vue technique : la nature de l’exploit ou de l’incident, le produit concerné, l’évaluation d’impact disponible, les mesures déjà prises, les mesures que les utilisateurs peuvent prendre et la sensibilité des informations.
Avons-nous besoin d’une nouvelle fonction de sécurité ?
Généralement pas. Les briques existent déjà dans les programmes AppSec et de sécurité des produits matures. Le travail consiste à les relier en un seul processus reproductible.
Sources : European Commission CRA guidance, July 2026, Section 9.1 on reporting obligations. ENISA, CRA Single Reporting Platform (SRP)
Cet article propose une lecture pratique, sous l’angle de la sécurité, du CRA et des lignes directrices de la Commission. Il ne constitue pas un avis juridique.