01Ce qui doit être notifié
L'article 14 du Cyber Resilience Act crée deux obligations de notification pour les fabricants de produits comportant des éléments numériques. Elles sont plus étroites qu'il n'y paraît : les bogues de routine et les correctifs ordinaires ne sont pas concernés. Art. 14
- Vulnérabilités activement exploitées ; une vulnérabilité de votre produit 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. Une vulnérabilité que vous découvrez et corrigez avant qu'elle ne soit exploitée relève de votre processus de gestion des vulnérabilités, et non par ce canal de notification.
- Incidents sévères ; un incident qui affecte négativement, ou est susceptible d'affecter négativement, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité des données ou des fonctions. Les critères de gravité figurent à l'article 14(5).
Ces obligations ne se limitent pas aux fabricants commerciaux. Responsables de logiciels open source ont leurs propres obligations de notification dans la mesure où ils interviennent sur des produits comportant des éléments numériques. Art. 24(3)
Si une faiblesse de sécurité de votre produit est activement exploitée, ou si un incident de sécurité l'a gravement affecté, le délai de l'article 14 commence à courir. Tout le reste relève de votre gestion quotidienne des vulnérabilités.
Une vulnérabilité dont vous connaissiez déjà l'exploitation active avant l'entrée en application de l'obligation de notification, le 11 septembre 2026, n'a pas à être notifiée. L'obligation s'attache au moment de votre prise de connaissance, elle couvre donc ce que vous apprenez à compter de cette date, et rien avant.
C'est le point qui prend les gens de court, et il vaut la peine d'être précis. L'article 69(2) fixe la règle transitoire générale : les produits mis sur le marché avant le 11 décembre 2027 ne relèvent du règlement que s'ils sont substantiellement modifiés à compter de cette date. Lu isolément, cela laisse penser que votre catalogue existant n'est pas concerné.
L'article 69(3) en extrait ensuite directement l'article 14. Par dérogation expresse, les obligations de notification s'appliquent à tous les produits comportant des éléments numériques relevant du champ d'application du règlement qui ont été mis sur le marché avant le 11 décembre 2027, qu'ils soient un jour modifiés ou non.
Les deux règles jouent donc sur des axes différents. Un produit que vous avez vendu en 2025 n'aura peut-être jamais besoin du marquage CE au titre du CRA ; pourtant, si une vulnérabilité qu'il contient est activement exploitée et que vous en prenez connaissance le 11 septembre 2026 ou après, elle est notifiable. Votre parc installé relève de l'obligation de notification même lorsqu'il est hors du champ des exigences applicables aux produits. La Commission parvient à la même conclusion à la section 5.3 de sa FAQ sur la mise en œuvre du CRA. Art. 69(2)–(3)
02Les trois délais
Chaque notification se déroule en trois étapes, calculées à partir du moment où vous prise de connaissance de la vulnérabilité exploitée ou de l'incident sévère. Les fenêtres sont serrées, et c'est pourquoi la préparation compte. Art. 14(2)–(4)
- Dans les 24hAlerte précoce. Une première notification indiquant qu'une vulnérabilité activement exploitée ou un incident sévère est survenu, en précisant, pour les incidents, s'il est soupçonné d'être causé par des actes illicites ou malveillants.
- Dans les 72hNotification de vulnérabilité / d'incident. Un exposé plus complet : la nature générale de la vulnérabilité et de l'exploitation, une évaluation initiale, ainsi que les mesures correctives ou d'atténuation prises et celles que les utilisateurs peuvent prendre.
- Rapport finalRapport final. Pour une vulnérabilité, au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation. Pour un incident sévère, dans un mois à compter de la notification à 72 heures. Il expose la description complète, la gravité, l'impact et la remédiation appliquée.
Notez l'asymétrie de la dernière ligne : l'horloge de la vulnérabilité est déclenchée par l'existence d'un correctif, celle de l'incident par la notification précédente. Ce sont des mécaniques différentes, à consigner séparément dans votre procédure opérationnelle.
03Quand elles commencent
Les obligations de notification constituent la première partie majeure du CRA à entrer en vigueur. Alors que la plupart des dispositions s'appliquent à partir du 11 décembre 2027, l'article 14 s'applique à partir du 11 septembre 2026 ; 21 mois après l'entrée en vigueur du règlement. L'ENISA a prévu que la plateforme de notification unique soit opérationnelle à cette même date. Art. 71
La plateforme n'est pas encore en service et son URL publique n'a pas été publiée. L'ENISA indique qu'elle sera communiquée sur sa page consacrée à la plateforme de notification unique avant la mise en service. Des tests utilisateurs et de sécurité sont prévus au préalable, le réseau des CSIRT étant associé à ces tests.
L'ENISA a toutefois publié une fiche d'information, une FAQ enrichie et deux pages d'orientation pas à pas couvrant l'enregistrement et la soumission des notifications, toutes mises à jour pour la dernière fois le 31 juillet 2026. De courtes vidéos pédagogiques et un webinaire deux semaines avant la mise en service restent à venir. L'ENISA signale que les orientations publiées sont susceptibles d'évoluer.
Deux autres éléments manquent encore : la liste des CSIRT nationaux désignés comme coordinateurs, que l'ENISA dit vouloir fournir à un stade ultérieur, et les normes harmonisées qui sous-tendent la gestion des vulnérabilités, attendues vers le 30 août 2026 et pas encore citées au Journal officiel.
Contrairement au marquage CE, que vous accomplissez une fois avant la mise sur le marché d'un produit, la notification est une obligation vivante et continue qui débute en septembre 2026 et peut être déclenchée à tout moment par la suite. Être prêt n'est pas un projet ponctuel. Construisez dès maintenant le processus interne de détection et de notification ; l'obligation s'applique à partir du 11 septembre 2026, que l'outillage soit prêt ou non.
04À qui notifier
Les notifications sont adressées à ENISA et au CSIRT désigné comme coordinateur, par un point d'entrée unique plutôt que par des dépôts distincts auprès de chaque autorité nationale. Ce point d'entrée est la plateforme de notification unique, que l'ENISA établit, gère et maintient au titre de l'article 16. Art. 14 · 16
Le CSIRT dont vous relevez découle de votre établissement principal dans l'Union ou, si vous n'êtes pas établi dans l'UE, de celui de votre mandataire. Le CSIRT destinataire diffuse ensuite la notification aux CSIRT des États membres où le produit est disponible, ainsi qu'aux autorités de surveillance du marché en tant que de besoin. Art. 14(7) · 18
Un appui existe des deux côtés. ENISA gère un service d'assistance, avec une attention particulière aux PME, et les CSIRT désignés comme coordinateurs sont eux aussi tenus de fournir une assistance sur les obligations de l'article 14. L'ENISA alimente également en vulnérabilités corrigées la base de données européenne sur les vulnérabilités, et publie tous les deux ans un rapport technique sur les tendances, le premier étant attendu dans les 24 mois suivant le début des obligations de notification. Art. 17(6)
La diffusion d'une vulnérabilité notifiée peut être suspendue par le CSIRT, mais pas par vous
Le CSIRT destinataire peut différer ou retenir la diffusion ultérieure pour des motifs justifiés de cybersécurité, pendant une durée strictement nécessaire ; par exemple lorsqu'une vulnérabilité fait l'objet d'une procédure de divulgation coordonnée. La Commission en a précisé les modalités dans un acte délégué adopté le 11 décembre 2025. Lorsqu'un CSIRT retient une notification, il doit en informer immédiatement l'ENISA, avec une justification et une indication du moment où il procédera à la diffusion.
Par ailleurs, dans des circonstances particulièrement exceptionnelles, vous pouvez cocher l'une des conditions étroites de l'article 16(2) dans votre notification à 72 heures : que l'exploitation est circonscrite à l'État membre de votre CSIRT, qu'une diffusion plus large serait contraire aux intérêts essentiels de cet État membre, ou que la diffusion présente un risque élevé et imminent pour la cybersécurité. Si vous le faites, l'ENISA ne reçoit qu'une information limitée (qu'une notification a été faite, des informations générales sur le produit, la nature générale de l'exploitation, et le fait que des motifs de sécurité ont été invoqués) jusqu'à ce que le CSIRT libère la notification complète.
Aucun de ces mécanismes ne suspend votre horloge. Vous ne pouvez pas retarder le dépôt ; les fenêtres de 24 heures, de 72 heures et du rapport final courent à compter de la prise de connaissance. Ce que vous pouvez faire, c'est signaler la sensibilité, ce qui limite qui voit le contenu. La décision de retenir la diffusion appartient au CSIRT destinataire.
05S'enregistrer sur la plateforme
Les orientations de l'ENISA du 31 juillet 2026 sont le premier document à montrer les écrans réels. Vous ne pouvez pas vous enregistrer sur la plateforme elle-même avant sa mise en service, mais vous pouvez décider dès maintenant qui détiendra les comptes et préparer leurs identifiants ; et vous avez tout intérêt à connaître le parcours avant de l'affronter sous une horloge de 24 heures.
Désignez deux personnes avant d'en avoir besoin
La plateforme donne à chaque fabricant deux types de compte utilisateur, et vous pouvez décider dès aujourd'hui qui les occupera. Un représentant principal s'enregistre en premier et crée l'entrée du fabricant sur la plateforme. Cette personne invite ensuite un représentant secondaire qui occupe un rôle de secours auprès du même fabricant et peut déposer en son nom. Il s'agit dans les deux cas de personnes nommément désignées dans votre entreprise. La soumission étant manuelle, un déclarant désigné unique qui est en congé, endormi ou parti est un risque opérationnel réel : traitez le second siège comme nécessaire plutôt que facultatif.
EU Login est l'identifiant, et les deux personnes peuvent le créer dès aujourd'hui
Les comptes de la plateforme s'authentifient via EU Login, le service d'authentification partagé de la Commission européenne utilisé dans l'ensemble de ses systèmes en ligne. L'ENISA indique que le compte peut être créé à l'avance, et c'est la chose la plus utile que vous puissiez faire dès maintenant. Créez-en un pour le représentant principal et un pour le représentant secondaire sur ecas.ec.europa.eu, en utilisant des adresses professionnelles qui existeront encore dans un an. La Commission explique ce qu'est EU Login, et comment il s'inscrit dans son cadre d'identité plus large, sur les pages identité numérique de confiance de son site.
Le parcours d'enregistrement
Lors du premier accès à la plateforme, vous sélectionnez votre rôle, choisissez votre CSIRT désigné dans une liste déroulante, vous authentifiez via EU Login, lisez et acceptez l'accord juridique, confirmez vos données personnelles préremplies (prénom, nom, courriel, raison sociale), puis saisissez le nom, l'adresse et les informations complémentaires du fabricant. L'omission d'un champ obligatoire relatif au fabricant bloque le parcours. À l'issue, votre compte devient actif dans le rôle « AR Active », vous recevez un courriel de confirmation, et l'entité fabricant est créée dans la plateforme.
Le secondaire représentant rejoint la plateforme par invitation par courriel envoyée par le principal, confirme les données personnelles et les données du fabricant préremplies, et est enregistré comme utilisateur de secours auprès du même fabricant. Cette invitation expire au bout de 7 jours, après quoi l'enregistrement est marqué « Invitation Expired » et une nouvelle invitation doit être envoyée. Configurez le compte de secours dans la même séance que le principal ; une invitation périmée découverte en plein incident est un problème évitable.
Le CSIRT vérifie votre représentant manuellement, mais cela ne vous empêche pas de déposer
Quelqu'un doit confirmer qu'une personne donnée peut réellement notifier au nom d'un fabricant donné, et cette vérification incombe au CSIRT désigné comme coordinateur. C'est une étape manuelle, la procédure varie d'un CSIRT à l'autre, et chaque CSIRT est maître de sa propre approche. Point crucial, elle intervient après votre premier accès à la plateforme et se déroule en parallèle de votre notification : l'ENISA indique que la validation n'affecte pas votre capacité à soumettre des notifications. Un compte non validé peut tout de même déposer dans la fenêtre de 24 heures.
C'est aussi pourquoi l'ENISA conseille de s'enregistrer et de lancer la validation seulement lorsque vous avez réellement besoin de déposer, plutôt que de préenregistrer tout le marché et d'ensevelir les CSIRT sous des vérifications spéculatives. La préparation que vous faites à l'avance, ce sont les comptes EU Login et la décision sur qui occupe les deux sièges, pas l'enregistrement sur la plateforme lui-même.
Les orientations de l'ENISA sont rédigées pour les « Assigned Representatives » (AR), avec des utilisateurs principaux et des utilisateurs de secours. Il s'agit d'un rôle de compte sur la plateforme. Ce n'est pas le mandataire désigné par mandat écrit au titre de l'article 18 du CRA. Vous pouvez avoir le premier sans le second. Gardez les deux distincts dans votre procédure interne, sinon vous finirez par débattre d'une désignation juridique alors que tout ce dont vous avez besoin est un second identifiant.
06Déposer une notification
La notification se pilote depuis un tableau de bord. Vous créez une notification, puis vous complétez le même enregistrement à chaque étape plutôt que de déposer trois documents distincts. Chaque étape a son propre onglet, et chacune peut d'abord être enregistrée comme brouillon ; les brouillons ne sont visibles que par vous.
- Alerte précoceDémarrez une nouvelle notification depuis le tableau de bord, complétez les champs obligatoires et sélectionnez un fabricant existant ou ajoutez-en un. À la soumission, elle est envoyée à votre CSIRT désigné et, automatiquement, à l'ENISA. Des confirmations par courriel et par alerte vous parviennent, ainsi qu'au CSIRT et à l'ENISA.
- 72 heuresDisponible uniquement une fois qu'une alerte précoce existe. Ouvrez la même notification et complétez l'onglet 72 heures. L'ENISA la reçoit automatiquement sauf si vous invoquez les conditions de l'article 16(2), auquel cas l'enregistrement est signalé et la vue de l'ENISA est limitée jusqu'à ce que le CSIRT la libère.
- Rapport finalDisponible uniquement une fois que les deux étapes précédentes existent. Les autres CSIRT concernés ne reçoivent le rapport final qu'après que votre CSIRT coordinateur l'a diffusé manuellement.
Ce qui est obligatoire, et quand
L'ENISA a publié quels champs sont obligatoires à chaque étape. Le tableau corrige utilement une idée répandue : l'alerte précoce à 24 heures est une alerte, pas une enquête.
- À 24 heures ; le type et le niveau de notification, le nom du fabricant ou du responsable, le produit, et un titre. Pour les incidents, si des actes illicites ou malveillants sont soupçonnés. Les États membres où le produit est disponible ne sont exigés que si vous disposez déjà de l'information.
- À 72 heures ; la nature générale de la vulnérabilité et de l'exploitation, les mesures correctives ou d'atténuation prises, et les mesures que les utilisateurs peuvent prendre. Pour les incidents, quand il a été détecté et quand il s'est produit, ainsi qu'une évaluation initiale. La sensibilité est signalée ici.
- Au rapport final ; la description complète, la gravité et l'impact, la date à laquelle une mesure corrective est devenue disponible, et le détail de la mise à jour de sécurité. Pour les incidents, la cause racine probable et les mesures d'atténuation en cours.
Parmi les champs facultatifs qu'il vaut néanmoins la peine de saisir figurent le CVE ID et le EUVD ID, tous deux disponibles dès la première étape.
La modification, et le point de non-retour
Une notification soumise peut être mise à jour, et la plateforme alerte automatiquement votre CSIRT ainsi que l'ENISA et tout CSIRT l'ayant déjà reçue par diffusion. Deux limites s'appliquent : une notification clôturée ne peut pas être mise à jour, et l'enregistrement devient non modifiable une fois le rapport final soumis.
L'ENISA indique ce qui suit : aucune interface de programmation d'application ne sera fournie à ce stade. Vous pouvez automatiser en interne la détection, le tri et la rédaction, mais la soumission elle-même consiste en une personne qui remplit un formulaire dans un navigateur. Planifiez ce passage de relais de manière délibérée, et assurez-vous que plus d'une personne puisse l'effectuer en dehors des heures ouvrables et le week-end.
La plateforme acceptera aussi des signalements volontaires de vulnérabilités, de cybermenaces, d'incidents et de quasi-incidents, émanant de toute personne physique ou morale et non des seuls fabricants. L'ENISA indique que cette fonctionnalité est activée après le 11 septembre 2026, ce n'est donc pas un moyen de faire une répétition à faible enjeu avant l'échéance.
07Ce que vous pouvez faire dès aujourd'hui
Respecter une fenêtre de 24 heures est un problème opérationnel, pas un problème de paperasse, et presque toute la préparation est déjà possible. Rien de ce qui suit ne dépend de la mise en service de la plateforme.
- Créez vos comptes EU Login. Pour le déclarant principal et au moins un suppléant. Cela prend quelques minutes sur ecas.ec.europa.eu et supprime une étape que vous ne voulez pas découvrir en plein incident.
- Identifiez votre CSIRT désigné. Il découle de votre établissement principal dans l'Union, ou de celui de votre mandataire si vous êtes établi hors de l'UE. La liste complète des coordinateurs de l'ENISA reste à publier : consignez donc votre raisonnement dès maintenant et confirmez-le au regard de la liste lorsqu'elle paraîtra.
- Construisez le formulaire des 24 heures en interne. Un modèle court correspondant aux champs obligatoires de l'alerte précoce de l'ENISA, afin que votre premier dépôt réel soit une transcription plutôt qu'une rédaction.
- Nommez les personnes, y compris en dehors des heures ouvrables. Décidez qui juge qu'une notification est due, qui la rédige et qui la soumet. Puisqu'il n'y a pas d'API, la dernière étape est un humain identifié devant un clavier.
- Tenez un SBOM exact. Vous ne pouvez pas notifier au sujet d'un composant dont vous ignoriez la présence dans vos livraisons. Tenez une nomenclature logicielle et maintenez-la à jour au fil des versions.
- Surveillez-le en continu. Comparez vos composants aux sources de vulnérabilités connues afin qu'une faille activement exploitée apparaisse en quelques heures, pas en quelques semaines. Notre SBOM et analyseur de vulnérabilités suit votre nomenclature logicielle par rapport au NVD et à la base de données européenne des vulnérabilités (EUVD).
- Confirmez ce qui relève réellement du champ d'application. L'étape des 72 heures demande le type de produit et la catégorie de l'annexe III ou IV : réglez donc la classification avant d'en avoir besoin. Notre outil de classification y répond, et la matrice de conformité rattache la notification aux obligations plus larges de gestion des vulnérabilités de l'Annexe I dans lesquelles elle s'inscrit.
- Inscrivez le webinaire à votre agenda. L'ENISA prévoit d'en tenir un deux semaines avant l'entrée en service de la plateforme, et de publier de courtes vidéos pédagogiques plus près du lancement.
08Suivre le sujet à la source
Cette page reflète la situation au 6 août 2026. La plateforme évolue encore, et l'ENISA modifie ses pages discrètement plutôt que d'annoncer chaque changement : les mentions « dernière mise à jour » des pages ci-dessous méritent donc d'être vérifiées directement. Ce sont les sources primaires ; tout ce qui précède est notre lecture de celles-ci.
- ENISA · Plateforme de notification unique ; la page centrale, avec la fiche d'information et une FAQ détaillée couvrant la base juridique, les délais, l'acheminement, le tableau des champs et la sécurité de la plateforme. C'est là que l'URL publique sera annoncée.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
- ENISA · Orientations relatives à l'enregistrement des utilisateurs SRP ; le parcours d'enregistrement pas à pas pour les utilisateurs principaux et de secours, avec des captures d'écran de l'interface.enisa.europa.eu/cra-srp-ar-user-registration
- ENISA · Orientations relatives à la soumission des notifications SRP ; comment l'alerte précoce, la notification à 72 heures et le rapport final sont déposés et mis à jour, et ce que déclenche chaque statut.enisa.europa.eu/cra-srp-ar-notification-submission-and-update
- Commission européenne · Obligations de notification du CRA ; la page de politique publique, y compris la FAQ sur la mise en œuvre du CRA dont la section 5 couvre la notification.digital-strategy.ec.europa.eu/en/policies/cra-reporting
- Commission européenne · Orientations sur l'application du CRA (27 juillet 2026) ; le point 9.1 expose les obligations de notification des fabricants et des responsables de logiciels open source. Notre résumé des orientations couvre le reste.digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
- EU Login ; créez le compte que la plateforme utilisera. Faites-le dès maintenant.ecas.ec.europa.eu/cas/login
Pour le texte contraignant, les articles 14 à 17 exposent l'écosystème de notification et l'article 16 établit la plateforme ; lisez-les dans notre lecteur du règlement. Les dates clés sont suivies sur la page état des lieux de notre site.
09Questions fréquentes
Que dois-je notifier dans le cadre du CRA, et dans quel délai ?
Les vulnérabilités activement exploitées et les incidents sévères affectant la sécurité de votre produit. Une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification plus complète dans les 72 heures, et un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective pour une vulnérabilité, ou dans le mois suivant la notification à 72 heures pour un incident sévère. Art. 14
Quand les obligations de notification commencent-elles ?
11 septembre 2026 ; 21 mois après l'entrée en vigueur du règlement, bien avant l'application complète au 11 décembre 2027.
À qui dois-je notifier ?
L'ENISA et le CSIRT national désigné comme coordinateur, via la plateforme de notification unique établie au titre de l'article 16. Votre CSIRT découle de votre établissement principal dans l'Union, ou de celui de votre mandataire si vous n'êtes pas établi dans l'UE.
Dois-je notifier chaque bogue ou vulnérabilité ?
Non. Seules les vulnérabilités activement exploitées et les incidents sévères sont soumis à obligation de notification. Les vulnérabilités que vous détectez et corrigez avant exploitation sont gérées dans le cadre de votre processus ordinaire de gestion des vulnérabilités.
La plateforme de notification unique d'ENISA est-elle déjà disponible ?
Pas au 6 août 2026. La plateforme n'est pas en service et son URL publique n'a pas été publiée ; l'ENISA l'annoncera sur sa page SRP avant la mise en service. Elle doit être opérationnelle d'ici au 11 septembre 2026, avec des tests utilisateurs et de sécurité au préalable.
Puis-je m'enregistrer ou préparer quelque chose dès maintenant ?
Oui, et vous devriez le faire. Créez les comptes EU Login que la plateforme utilisera, pour un déclarant principal et un suppléant. Vous ne pouvez pas vous enregistrer sur la plateforme elle-même avant sa mise en service, et l'ENISA conseille de ne commencer l'enregistrement sur la plateforme que lorsque vous avez réellement besoin de déposer, car le CSIRT coordinateur valide le compte après le premier accès plutôt qu'avant. Cette validation ne bloque pas la soumission.
Puis-je soumettre des notifications via une API ?
Non. L'ENISA indique qu'aucune interface de programmation d'application ne sera fournie à ce stade. Vous pouvez automatiser la détection et la rédaction en interne, mais la soumission consiste en une personne qui remplit un formulaire dans un navigateur.
Que doit réellement contenir l'alerte précoce des 24 heures ?
Moins que ce que la plupart des gens imaginent. Les champs obligatoires sont le type et le niveau de notification, le nom du fabricant ou du responsable, le produit, un titre, et, pour les incidents, si des actes illicites ou malveillants sont soupçonnés. L'analyse de fond est due à 72 heures, pas le premier jour.
Existe-t-il déjà un format standard ou un modèle de notification ?
Les champs de données sont publiés. La FAQ de l'ENISA expose lesquels sont obligatoires aux étapes des 24 heures, des 72 heures et du rapport final : vous pouvez donc construire dès aujourd'hui un modèle interne correspondant. La Commission pourrait encore préciser le format et la procédure par des actes d'exécution.
Puis-je retarder une notification si la divulgation présentait un risque ?
Pas le dépôt. Les fenêtres de 24 heures, de 72 heures et du rapport final courent à compter de la prise de connaissance et rien ne les suspend. Vous pouvez signaler la sensibilité : au titre de l'article 16(2), vous pouvez cocher des conditions étroites qui limitent ce que voit l'ENISA jusqu'à ce que le CSIRT libère la notification complète. La décision de différer la diffusion ultérieure appartient au CSIRT destinataire, au titre de l'acte délégué adopté le 11 décembre 2025.
Dois-je notifier une exploitation dont j'avais déjà connaissance avant septembre 2026 ?
Non. L'obligation s'applique dès que vous en prenez connaissance, et ne s'étend pas aux vulnérabilités dont vous connaissiez déjà l'exploitation active avant le 11 septembre 2026.
La notification s'applique-t-elle aux produits que j'ai mis sur le marché il y a des années ?
Oui. L'article 69(2) dispose que les produits mis sur le marché avant le 11 décembre 2027 ne relèvent du règlement que s'ils sont substantiellement modifiés à compter de cette date, mais l'article 69(3) y déroge expressément pour l'article 14 : les obligations de notification s'appliquent à tous les produits relevant du champ d'application mis sur le marché avant le 11 décembre 2027, modifiés ou non. Un produit peut donc être hors du champ des exigences produit du CRA tout en restant dans le champ de la notification. Art. 69(2)–(3)
Tout cela s'applique-t-il aux projets open source ?
Les responsables de logiciels open source ont des obligations de notification dans la mesure où ils interviennent sur des produits comportant des éléments numériques, au titre de l'article 24(3). Les orientations de la Commission du 27 juillet 2026 traitent l'open source plus en détail.
Où obtenir de l'aide si je suis une petite entreprise ?
L'ENISA gère un service d'assistance avec une attention particulière aux PME, et les CSIRT désignés comme coordinateurs sont également tenus de fournir une assistance sur les obligations de l'article 14. L'ENISA prévoit en outre des vidéos pédagogiques et un webinaire deux semaines avant l'entrée en service de la plateforme.