- Depuis le 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits (article 14 du règlement (UE) 2024/2847).
- Trois étapes : alerte précoce sous 24 heures, notification sous 72 heures, et rapport final 14 jours après la disponibilité d'un correctif (vulnérabilités) ou un mois après la notification (incidents).
- Les notifications sont adressées au CSIRT désigné comme coordinateur dans l'État membre de votre établissement principal dans l'UE, et simultanément à l'ENISA, via la plateforme unique de notification.
- Elle s'applique à tous les produits déjà sur le marché, pas seulement aux nouveaux. Le reste du CRA suit le 11 décembre 2027.
Qui doit notifier : les fabricants et les produits concernés
Le Cyber Resilience Act (CRA) couvre les produits comportant des éléments numériques : matériel et logiciels dont l'utilisation prévue ou raisonnablement prévisible inclut une connexion de données à un appareil ou à un réseau. Cela va des routeurs, caméras et objets connectés domestiques aux applications de bureau et mobiles, micrologiciels et bibliothèques logicielles vendus ou autrement monétisés.
Un fabricant est toute personne qui « développe ou fabrique des produits comportant des éléments numériques, ou fait concevoir, développer ou fabriquer de tels produits, et les commercialise sous son nom ou sa marque, à titre onéreux, monétisé ou gratuit » (article 3, point 13). Un importateur ou un distributeur qui appose sa propre marque sur un produit, ou le modifie substantiellement, devient lui aussi fabricant (article 21).
Points d'attention pour les PME :
- Le SaaS pur est en général hors champ. Le CRA ne couvre le cloud que comme « solution de traitement de données à distance » nécessaire au fonctionnement d'un produit, comme le backend applicatif d'un thermostat connecté. Les considérants précisent que les services cloud conçus hors de la responsabilité d'un fabricant de produit ne sont pas couverts, et renvoient à NIS2 pour le SaaS, le PaaS et l'IaaS.
- Des exclusions sectorielles existent pour les produits soumis à leur propre régime, comme les dispositifs médicaux, les véhicules à moteur, l'aviation civile et les équipements marins.
- La taille ne vous exempte pas de la notification. Les micro et petits fabricants n'échappent qu'aux amendes pour non-respect du délai d'alerte précoce de 24 heures (article 64, paragraphe 10, point a), pas à l'obligation elle-même.
Ce qui déclenche une notification
1. Une vulnérabilité activement exploitée
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 du propriétaire du système » (article 3, point 42). Une vulnérabilité signalée par un chercheur, ou découverte lors de vos propres tests, n'est pas « activement exploitée » tant qu'il n'existe pas de preuve d'une utilisation malveillante réelle. Le compte à rebours démarre alors lorsque vous avez connaissance de cette preuve.
2. Un incident grave ayant une incidence sur la sécurité du produit
Selon l'article 14, paragraphe 5, un incident est grave lorsqu'il :
- porte atteinte, ou est susceptible de porter atteinte, à la capacité du produit de protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ; ou
- a conduit, ou est susceptible de conduire, à l'introduction ou à l'exécution de code malveillant dans le produit ou dans les réseaux et systèmes d'information d'un utilisateur.
L'exemple classique est la compromission de votre chaîne de build ou de votre serveur de mises à jour, qui pourrait diffuser du code malveillant aux clients. Notez que l'incident concerne la sécurité de votre produit, ce qui peut inclure votre propre infrastructure de développement et de distribution.
Délais et contenu
| Étape | Vulnérabilité activement exploitée (art. 14, par. 2) | Incident grave (art. 14, par. 4) |
|---|---|---|
| Alerte précoce | Sans retard injustifié, dans les 24 heures suivant la prise de connaissance. Si connus, les États membres où le produit est disponible. | Dans les 24 heures. Indiquer si l'incident est présumé résulter d'actes illicites ou malveillants et, si connus, les États membres concernés. |
| Notification | Dans les 72 heures : informations générales sur le produit, nature de l'exploitation et de la vulnérabilité, mesures correctives ou d'atténuation prises, mesures que les utilisateurs peuvent prendre, et degré de sensibilité que vous attribuez aux informations. | Dans les 72 heures : nature de l'incident, évaluation initiale, mesures prises et mesures que les utilisateurs peuvent prendre, et sensibilité des informations. |
| Rapport final | Au plus tard 14 jours après la disponibilité d'une mesure corrective ou d'atténuation : description, gravité et impact, informations sur l'acteur malveillant le cas échéant, détails de la mise à jour de sécurité. | Dans le mois suivant la notification des 72 heures : description détaillée, gravité et impact, type de menace ou cause profonde probable, atténuation appliquée et en cours. |
| Rapport intermédiaire | Uniquement si le CSIRT coordinateur demande des points d'avancement (art. 14, par. 6). | |
Chaque étape ultérieure s'applique « sauf si les informations pertinentes ont déjà été fournies », de sorte qu'une alerte précoce complète n'a pas à être répétée. Utilisez notre calculateur de délais de violation pour convertir un horodatage de prise de connaissance en échéances concrètes, et programmez des rappels dans votre agenda.
Comment notifier : la plateforme unique de notification
Les notifications passent par la plateforme unique de notification (SRP) de l'ENISA, en service depuis le 11 septembre 2026 sur portal.cra-srp.enisa.europa.eu. Vous soumettez au point d'accès électronique du CSIRT désigné comme coordinateur dans l'État membre de votre établissement principal dans l'UE : là où sont principalement prises les décisions de cybersécurité concernant vos produits, ou à défaut, là où vous employez le plus de personnel dans l'UE (article 14, paragraphe 7). L'ENISA reçoit la notification en même temps, et le CSIRT coordinateur la transmet aux CSIRT des autres États membres où le produit est disponible. Dans des cas exceptionnels, il peut différer cette diffusion pour des motifs de cybersécurité.
Les fabricants sans établissement dans l'UE notifient au CSIRT de l'État membre où est établi, dans cet ordre, leur mandataire, importateur ou distributeur pour le plus grand nombre de produits, ou bien où se trouve la majorité de leurs utilisateurs.
Selon la FAQ de l'ENISA, les personnes qui notifient pour le compte d'un fabricant ont besoin d'un compte EU Login avec authentification multifacteur, et la plateforme a été lancée en anglais. Enregistrez vos déclarants avant d'en avoir besoin : un délai de 24 heures n'est pas le bon moment pour créer des comptes.
Informer vos utilisateurs
L'article 14, paragraphe 8, ajoute une obligation facile à négliger. Après avoir pris connaissance d'une vulnérabilité activement exploitée ou d'un incident grave, vous devez informer les utilisateurs concernés, et le cas échéant tous les utilisateurs, en leur indiquant les mesures d'atténuation et correctives qu'ils peuvent prendre, le cas échéant dans un format structuré et lisible par machine. Si vous ne le faites pas à temps, le CSIRT peut informer lui-même vos utilisateurs. Une page d'avis de sécurité et un flux CSAF ou équivalent sont la réponse pratique.
Stewards open source et composants open source
Un steward de logiciels open source est une personne morale, autre qu'un fabricant, qui soutient systématiquement le développement de produits libres et open source spécifiques destinés à des activités commerciales et en assure la viabilité. Les fondations en sont l'exemple typique. Les stewards relèvent d'un régime allégé (article 24) : une politique de cybersécurité documentée, la coopération avec les autorités de surveillance du marché, et la notification au titre de l'article 14 uniquement dans la mesure où ils participent au développement, ou pour les incidents touchant l'infrastructure qu'ils fournissent pour le développement. La FAQ de l'ENISA indique que la notification par les stewards s'applique à partir du 11 décembre 2027. Les stewards ne peuvent pas être sanctionnés au titre du CRA (article 64, paragraphe 10, point b).
Les projets open source amateurs non monétisés ne sont pas des fabricants. Mais si vous livrez un produit contenant une bibliothèque open source et que celle-ci est activement exploitée dans votre produit, l'obligation de notification vous incombe en tant que fabricant du produit. À partir du 11 décembre 2027, vous devrez aussi signaler les vulnérabilités que vous découvrez dans les composants intégrés, open source compris, à ceux qui les maintiennent (article 13, paragraphe 6).
Le reste du calendrier du CRA
- 10 décembre 2024Entrée en vigueur du CRA (publié au Journal officiel le 20 novembre 2024).
- 11 juin 2026Application du chapitre IV : règles applicables aux organismes d'évaluation de la conformité (organismes notifiés).
- 11 septembre 2026Application de la notification de l'article 14 à tous les produits relevant du champ d'application, y compris ceux mis sur le marché avant le 11 décembre 2027 (article 69, paragraphe 3).
- 1er octobre 2026 : vous êtes ici
- 11 décembre 2027Application complète : exigences essentielles de cybersécurité (annexe I), gestion des vulnérabilités, marquage CE, évaluation de la conformité, périodes de support, documentation technique, et obligations des importateurs, distributeurs et stewards open source. Les produits mis sur le marché avant cette date ne sont soumis à ces exigences qu'après une modification substantielle.
- 11 juin 2028Les attestations d'examen UE de type existantes relatives aux exigences de cybersécurité au titre d'autres législations expirent, sauf si elles expirent plus tôt.
Les amendes pour violation de l'annexe I ou des articles 13 et 14 peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu (article 64, paragraphe 2).
Notification CRA et NIS2 côte à côte
Les deux régimes se ressemblent (24 heures, 72 heures, un rapport final) mais répondent à des questions différentes. NIS2 demande si votre service aux clients a été perturbé de manière significative. Le CRA demande si votre produit est exploité ou si sa sécurité a été compromise.
| CRA, article 14 | NIS2, article 23 | |
|---|---|---|
| Qui | Fabricants de produits comportant des éléments numériques (toute taille) | Entités essentielles et importantes des secteurs des annexes I et II |
| Déclencheur | Vulnérabilité activement exploitée ; incident grave affectant la sécurité du produit | Incident significatif affectant la fourniture des services de l'entité |
| Destinataire | CSIRT coordinateur et ENISA via la plateforme unique de notification | CSIRT national ou autorité compétente, via les canaux nationaux |
| Chronologie | 24 h / 72 h / rapport final 14 jours après le correctif (vulnérabilité) ou 1 mois (incident) | Alerte précoce 24 h / notification 72 h / rapport final sous 1 mois |
| Depuis | 11 septembre 2026 | Dépend de la transposition nationale (l'échéance était le 17 octobre 2024) |
Une entreprise peut relever des deux. Un fabricant d'équipements réseau de taille moyenne peut relever de NIS2 (la fabrication de produits informatiques, électroniques et optiques est un secteur de l'annexe II) et du CRA. Une compromission de son serveur de mises à jour pourrait alors être à la fois un incident significatif au titre de NIS2 et un incident grave au titre du CRA, avec deux notifications par deux canaux. Prévoyez les deux dans un même playbook. Les considérants du CRA encouragent les États membres à proposer des guichets uniques nationaux, et en novembre 2025 la Commission a proposé un guichet unique européen pour la notification des incidents dans son paquet Digital Omnibus. Tant qu'un tel guichet n'existe pas dans votre pays, partez du principe que vous notifiez séparément. Si des données personnelles sont concernées, la notification de violation de données sous 72 heures du RGPD s'applique en parallèle des deux. Si vous êtes une entité NIS2, notre vérificateur d'incident significatif NIS2 vous aide pour le critère « significatif ».
Checklist de préparation
- Listez vos produits comportant des éléments numériques et les États membres où ils sont disponibles.
- Déterminez votre établissement principal et donc votre CSIRT coordinateur.
- Enregistrez au moins deux déclarants sur la plateforme unique de notification avec EU Login et MFA.
- Définissez « activement exploitée » et « incident grave » dans vos procédures de gestion des vulnérabilités et des incidents, avec des exemples.
- Mettez en place la réception : un contact sécurité (par exemple security.txt), une politique de divulgation coordonnée des vulnérabilités, et une veille sur les menaces comme le catalogue CISA KEV et les avis des CSIRT.
- Tenez un SBOM pour savoir en quelques heures si un composant exploité se trouve dans vos produits.
- Préparez des modèles pour les rapports de 24 h, 72 h et final, ainsi qu'un avis aux utilisateurs.
- Consignez les horodatages de prise de connaissance : le délai court à partir du moment où vous en avez connaissance.
- Répétez une fois avec un exercice sur table, en combinant les délais du CRA, de NIS2 et du RGPD le cas échéant.
Gérez les délais à partir d'un seul dossier d'incident
Le registre des incidents de Dazr Compliance enregistre l'heure de prise de connaissance une seule fois et affiche chaque échéance : RGPD 72 heures, NIS2 24 h, 72 h et un mois, et des délais personnalisés comme le rapport final du CRA. Il conserve les preuves et les références de dossier auprès des autorités dans une piste d'audit exportable.
FAQ
La notification CRA s'applique-t-elle aux produits vendus avant le 11 décembre 2027 ?
Oui. L'article 69, paragraphe 3, rend les obligations de notification de l'article 14 applicables à tous les produits relevant du champ d'application, y compris ceux mis sur le marché avant le 11 décembre 2027. Les exigences de conception ne s'appliquent à ces produits existants qu'après une modification substantielle.
Quand le compte à rebours de 24 heures démarre-t-il ?
Lorsque le fabricant prend connaissance de la vulnérabilité activement exploitée ou de l'incident grave. Pour les vulnérabilités, c'est le moment où vous disposez de preuves fiables d'une exploitation malveillante, et non celui où le bug a été signalé pour la première fois.
Notre plateforme SaaS est-elle couverte par la notification CRA ?
En général non, sauf s'il s'agit d'une solution de traitement de données à distance sans laquelle un produit comportant des éléments numériques ne peut remplir l'une de ses fonctions. Le SaaS en tant que tel relève de NIS2 si vous remplissez ses critères de taille et de secteur.
Les petites entreprises sont-elles exemptées ?
Non. Les micro et petits fabricants doivent aussi notifier. Ils ne peuvent pas être sanctionnés pour avoir manqué le délai d'alerte précoce de 24 heures, mais les autres obligations et amendes s'appliquent toujours.
À lire aussi
Sources (situation au 1er octobre 2026)
- Règlement (UE) 2024/2847 (Cyber Resilience Act), articles 3, 13, 14, 16, 21, 24, 64, 69 et 71.
- ENISA: The CRA Single Reporting Platform is launched, 11 septembre 2026.
- FAQ de la plateforme unique de notification de l'ENISA.
- Commission européenne : obligations de notification du Cyber Resilience Act.
- Directive (UE) 2022/2555 (NIS2), article 23.
Ce guide explique le CRA au 1er octobre 2026 et ne constitue pas un avis juridique.