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é ont été réalisés, avec la participation de différents CSIRT du réseau des CSIRT.
L'ENISA a réécrit la quasi-totalité de la FAQ sur la SRP le 4 septembre 2026 et a enfin publié la liste des CSIRT désignés comme coordinateurs, qui couvre l'ensemble des 27 États membres. Cette liste est référencée à la section 08 ci-dessous. Outre la FAQ, l'ENISA publie désormais une fiche d'information, un glossaire champ par champ, le Glossaire SRP, passé à la version 1.1 le 5 septembre 2026 et déplacé à une nouvelle adresse, et trois pages d'orientation pas à pas destinées aux représentants ; ces pages d'orientation restent datées du 3 août et 14 août 2026 , si bien que, lorsqu'elles contredisent la FAQ ou le glossaire, c'est la date la plus ancienne qui perd. L'ENISA indique qu'un manuel d'utilisation et des vidéos tutorielles seront publiés lors de la mise en service, et signale que toutes les orientations publiées sont susceptibles d'évoluer.
Deux choses dont l'ENISA a désormais confirmé qu'elles ne seront pas présentes dès le premier jour : la notification volontaire au titre de l'article 15, qui passe à une phase ultérieure sans date, et une interface de programmation pour la notification, une API, qui pourra être envisagée dans une phase ultérieure. Les normes harmonisées qui sous-tendent le traitement des vulnérabilités restent en attente ; elles sont désormais attendues aux alentours du 30 octobre 2026, après que le projet de modification de la demande de normalisation M/606 présenté par la Commission en juillet 2026 a repoussé de deux mois les échéances de 2026, et elles ne sont 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
La liste des coordinateurs a été publiée le 4 septembre 2026
Jusqu'au 4 septembre 2026 il n'existait aucune réponse publiée à la question la plus pratique de cette page : quelle équipe nationale reçoit effectivement votre dépôt. L'ENISA a désormais publié une liste des CSIRT désignés comme coordinateurs qui donne une ou plusieurs URL de contact pour chacun des 27 États membres. L'Irlande renvoie à une page NCSC dédiée au CRA ; l'Espagne indique deux voies INCIBE distinctes, l'une pour les incidents et l'autre pour la coordination des vulnérabilités.
La liste vous indique qui est le coordinateur de chaque État membre. Elle ne vous dit pas lequel est le vôtre, et le test de l'article 14(7) est plus étroit que ne le supposent la plupart des organisations. Votre établissement principal est l'État membre où les décisions relatives à la cybersécurité de vos produits comportant des éléments numériques sont principalement prises, qui peut être un site de développement plutôt qu'un siège social ou la plus grande implantation commerciale. Lorsque cela ne peut être déterminé, le critère de repli est l'État membre où vous comptez le plus grand nombre de salariés dans l'UE. En l'absence de tout établissement dans l'UE, l'ordre est le suivant : l'État membre où votre mandataire agit pour le plus grand nombre de produits, puis l'importateur qui met le plus de produits sur le marché, puis le distributeur qui en met le plus à disposition, puis l'État membre comptant le plus d'utilisateurs. Comme cela fixe le destinataire de tous vos dépôts futurs, tranchez la question à l'avance, avec un appui juridique, et consignez le raisonnement par écrit.
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 le Règlement délégué (UE) 2026/881, 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.
Le 9 septembre 2026 l'ENISA a publié une page d'orientations consacrée aux circonstances particulièrement exceptionnelles, qui tranche une question de champ d'application laissée ouverte par les documents précédents. Le PEC ne peut être invoqué que sur la notification à 72 heures d'une vulnérabilité activement exploitée. Il n'existe pas d'équivalent pour un incident sévère, et la plateforme n'offre aucune commande PEC sur une notification d'incident.
Concrètement, il s'agit d'un interrupteur au bas du formulaire à 72 heures, qui fait apparaître les trois motifs de report ainsi qu'une justification facultative en texte libre. Cette justification n'est pas décorative : l'ENISA indique qu'elle aide le CDaC à décider s'il accepte la soumission au titre du PEC. Invoquer le PEC revient donc à demander une restriction plutôt qu'à l'appliquer, et l'enregistrement passe simplement à l'état 72h Submitted under PEC et y reste tant que le coordinateur n'a pas tranché. Rédigez la justification comme si elle allait être lue par quelqu'un qui doit la mettre en balance avec l'intérêt d'informer rapidement les autres États membres, car ce sera le cas.
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, mises à jour le 3 août 2026 et complétées par une page sur les fonctions d'interface le 14 août 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, le statut de votre compte est « Active » et "AR Primary User" est le rôle que vous détenez, 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é dans le rôle "AR Backup User" 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, que l'ENISA abrège désormais en CDaC. 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 avec votre notification. Dans sa mise à jour du 3 août 2026 l'ENISA l'a établi sans ambiguïté : la validation par le CDaC n'est pas une condition préalable au respect de l'obligation de notification du CRA, et 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.
Lorsqu'un représentant rattache son compte à un fabricant via Association Management, l'association est créée avec le statut Unverified et une demande de vérification est transmise au CDaC. Les orientations sur les fonctions d'interface du 14 août 2026 fixaient le plafond à 10 notifications. La FAQ réécrite le 4 septembre 2026 double ce chiffre : un représentant non validé peut soumettre jusqu'à 20 notifications pour un même fabricant avant que la validation ne devienne obligatoire.
Les deux affirmations tiennent ensemble : la validation n'est pas un verrou sur votre premier dépôt, mais elle n'est pas non plus indéfiniment reportable. L'ENISA ne dit pas ce qui se passe à la vingt et unième tentative, ni si le plafond compte les événements ou les soumissions individuelles. Notez aussi que les pages d'orientation portent toujours l'ancien chiffre : si vous avez recopié « dix » dans une procédure interne en août, corrigez-le. Vingt, c'est généreux pour une entreprise mono-produit et cela reste fini pour un groupe qui dépose pour plusieurs entités ; si c'est votre cas, engagez la conversation avec votre CSIRT coordinateur plutôt que d'attendre qu'un incident vous y oblige.
Un seul compte peut porter plusieurs fabricants
Les mêmes orientations précisent la gestion courante des deux sièges. Un représentant principal invite un suppléant par adresse électronique, ce qui crée un enregistrement portant la mention "Pending Invitation" sans rôle tant qu'elle n'est pas acceptée. Un représentant secondaire peut demander à être promu principal, demande qui est transmise au CDaC pour examen. L'un comme l'autre peut supprimer une association, qui est alors marquée "Deleted". Et un seul compte peut porter des associations avec plusieurs fabricants, chacune ajoutée via Association Management et vérifiée séparément.
Ce dernier point compte pour les groupes comptant plusieurs entités de fabrication, et pour les entreprises agissant au titre de l'article 18 pour des fabricants établis hors de l'UE. C'est aussi là que le piège de dénomination exposé plus bas mord le plus fort.
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. Le tableau de bord peut être recherché par identifiant de notification, par fabricant ou par titre, trié par titre ou par dernière mise à jour, et filtré par État membre, par type de soumission ou par un indicateur Action Required correspondant.
Les orientations sur les fonctions d'interface du 14 août 2026 est explicite : le tableau de bord n'affiche que les brouillons que vous avez créés vous-même, et vous ne pouvez pas consulter les brouillons créés par un autre représentant associé au même fabricant. Les brouillons sont privés et propres à leur auteur, ils ne sont pas partagés au sein de l'entreprise.
Imaginez la conséquence. Quelqu'un commence une alerte précoce à 24 heures, enregistre un brouillon, puis devient injoignable ; le suppléant ouvre le tableau de bord et n'y trouve rien, alors que la fenêtre de 24 heures court depuis la prise de connaissance. Rédigez le texte en dehors de la plateforme, dans un document que votre équipe de réponse aux incidents partage déjà, et servez-vous de la plateforme pour le recopier.
- 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. Une fois soumise, elle est accessible à votre CSIRT désigné et, automatiquement, à l'ENISA. Les confirmations par courriel et par alerte sont adressées au CSIRT, à l'ENISA et à chaque représentant enregistré pour ce fabricant, et pas seulement à la personne qui a effectué le dépôt.
- 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 porte la mention "72h Submitted under PEC" 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. L'ENISA le reçoit automatiquement, sauf si les conditions de l'article 16(2) ont été invoquées.
Les orientations de l'ENISA du 3 août 2026 indiquent que les autres CSIRT concernés reçoivent l'alerte précoce, l'avis à 72 heures et le rapport final seulement après une diffusion manuelle par le CSIRT désigné comme coordinateur. Le texte du 31 juillet ne le disait que du rapport final. Rien ne change dans votre obligation, et le CDaC reste tenu par l'article 16(2) de diffuser sans délai, mais il est utile de savoir qu'une personne, dans un CSIRT national, se tient entre votre notification et les autres marchés où votre produit est vendu.
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.
Chaque champ a une limite de caractères, et l'une d'elles est très courte
Le Glossaire SRP de l'ENISA, passé à la version 1.1 le 5 septembre 2026, est le premier document de l'ENISA à publier la taille de chaque case. Rédigez vos modèles internes selon ces limites plutôt que de les découvrir à deux heures du matin :
- 4000 caractères pour les champs narratifs : le résumé, les informations générales sur la vulnérabilité ou l'incident, les mesures correctives que les utilisateurs peuvent prendre, les descriptions complètes de la gravité et de l'impact, et l'évaluation initiale.
- 2000 caractères pour les mesures correctives ou d'atténuation que vous avez déjà prises.
- 255 caractères pour le titre, le nom du produit, la plage de versions du produit, le nom du composant, le vecteur d'attaque, la justification de sensibilité et la cause racine probable.
- 100 caractères pour l'acteur malveillant qui a exploité la vulnérabilité. Cela représente environ une ligne : prévoyez de nommer l'acteur ou de renvoyer à une référence d'indicateur plutôt que de décrire la campagne.
Le glossaire confirme aussi une petite commodité : le champ États membres où le produit est disponible arrive prérempli avec votre propre CSIRT coordinateur, et vous ajoutez vous-même les autres marchés.
La modification, et le point de non-retour
Une notification soumise peut être mise à jour, et la plateforme envoie automatiquement une alerte et un courriel à votre CSIRT ainsi qu'à 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.
Surveillez l'onglet Alerts, y compris le week-end
Chaque compte comporte un onglet Alerts à code couleur : les alertes non lues sont bleu clair et passent au gris une fois ouvertes, et les alertes de couleur rouge n'apparaissent que lorsqu'il s'est produit quelque chose d'exceptionnel. L'exemple donné par l'ENISA est celui d'un CSIRT désigné qui a invalidé une soumission. Le dépôt n'est donc pas la fin de l'échange, et aucun délai de l'article 14 ne bouge parce qu'une notification vous revient. Celui qui surveille cet onglet doit le surveiller en dehors des heures ouvrables, ce qui plaide encore pour une boîte aux lettres d'équipe surveillée derrière les deux sièges plutôt que deux adresses personnelles.
Le compteur 72 heures de la plateforme ne compte pas depuis la prise de connaissance
La FAQ du 4 septembre 2026 révèle le comportement réel des comptes à rebours affichés, et ceux-ci ne suivent pas le délai légal. Dans la version actuelle, le compteur 72 heures affiche une date d'échéance 48 heures après la soumission du rapport à 24 heures, et non 72 heures après votre prise de connaissance. L'ENISA indique clairement qu'une notification peut donc apparaître comme en retard avant que 72 heures ne se soient écoulées depuis la prise de connaissance, et que la logique sera modifiée dans une version ultérieure pour compter à partir du champ « date et heure à laquelle vous avez eu connaissance » une fois ce champ rendu obligatoire.
Les compteurs du rapport final diffèrent encore. Pour un incident sévère le compteur affiche un mois après la notification à 72 heures. Pour une vulnérabilité activement exploitée il n'y a aucun compteur, parce que le délai dépend du moment où une mesure corrective devient disponible, ce que la plateforme ne peut pas savoir.
L'ENISA est explicite : les compteurs existent pour la visibilité et ne remplacent pas l'obligation de l'article 14. Démarrez votre horloge au moment de la prise de connaissance et consignez-la dans votre journal d'incident. Déposer rapidement votre alerte précoce, ce qui est exactement ce que veut la loi, rend le compteur affiché plus strict que le compteur légal. Un indicateur "overdue" à l'écran n'est pas un constat de non-conformité, et un compteur vert n'est pas un moyen de défense.
À la mise en service, la plateforme n'enregistre pas le moment où vous avez eu connaissance
Le 5 septembre 2026 l'ENISA a remplacé son glossaire SRP champ par champ par la version 1.1, et deux notes de bas de page y importent plus que tout le reste de la page. Pour une vulnérabilité activement exploitée, le champ Date/time when you become aware porte la mention qu'il sera disponible dans la prochaine version de la plateforme. Pour un incident sévère, la note indique que, dans la version actuelle, le champ équivalent s'intitule Date/time the incident was detected.
Rapproché de la logique des compteurs ci-dessus, cela boucle la boucle. La FAQ indiquait que le compteur 72 heures serait corrigé une fois que le champ de prise de connaissance deviendrait obligatoire ; le glossaire confirme que ce champ n'est pas dans la version mise en service le 11 septembre. Ainsi, dès le premier jour, la plateforme ne capture aucun horodatage de prise de connaissance pour les vulnérabilités, et pour les incidents elle capture le moment de la détection, qui n'est pas le moment de la prise de connaissance.
Selon les conseils de la Commission du 27 juillet 2026 , vous avez connaissance dès qu'une évaluation initiale vous donne un degré raisonnable de certitude qu'une vulnérabilité de votre produit est exploitée ou qu'un incident sévère s'est produit. La détection intervient normalement plus tôt, parfois bien plus tôt. Puisque la plateforme enregistrera le moment de la détection et non celui de l'évaluation, l'enregistrement qu'elle conserve n'est pas le moment à partir duquel l'article 14 compte ses délais. Conservez votre propre note horodatée du moment où l'évaluation initiale a conclu et de la personne qui a pris cette décision. Si une autorité de surveillance du marché demande un jour pourquoi l'alerte précoce est arrivée à ce moment-là, c'est cette note, et non la plateforme, qui constitue votre preuve.
L'ENISA a ajouté une réponse sur les indisponibilités le 4 septembre 2026. Si la SRP est temporairement indisponible, attendez son rétablissement puis soumettez. Lorsqu'une communication immédiate est nécessaire dans l'intervalle, vous pouvez contacter directement votre CSIRT désigné, mais la notification doit tout de même passer par la plateforme une fois le service rétabli.
Il vaut la peine de le dire clairement, puisque l'ENISA ne le fait pas : rien dans le CRA ne suspend les fenêtres de 24 heures, 72 heures, 14 jours ou un mois pendant une indisponibilité. Horodatez l'indisponibilité et tout contact direct que vous prenez, et conservez les deux à côté de votre horodatage de prise de connaissance.
L'ENISA indique ce qui suit : aucune interface de programmation d'application ne sera fournie lors de la version initiale, et que des fonctionnalités d'API pourront être envisagées dans une phase ultérieure. 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 finira par accepter 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. La FAQ du 31 juillet 2026 indiquait que cela serait activé après le 11 septembre 2026. La réécriture du 4 septembre 2026 est plus ferme et plus tardive : le 11 septembre, la plateforme n'accepte que les notifications obligatoires au titre des articles 14 et 24, et la notification volontaire au titre de l'article 15 passe à une phase ultérieure sans date. Rien de ce qui est juridiquement exigé ne manque, mais il n'y a pas de répétition à faible enjeu, et un processus de divulgation qui prévoyait d'acheminer les vulnérabilités non exploitées via la SRP n'a encore nulle part où les envoyer.
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é. L'ENISA a publié la liste des coordinateurs pour les 27 États membres le 4 septembre 2026, si bien que c'est désormais une tâche que vous pouvez achever. Appliquez le test de l'établissement principal de l'article 14(7), choisissez votre ligne et consignez le raisonnement.
- 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. Conservez-le dans un endroit que les deux représentants peuvent ouvrir, car les brouillons de la plateforme ne sont visibles que par celui qui les a créés.
- 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.
- Décidez qui lit l'onglet Alerts en dehors des heures ouvrables. Un CSIRT désigné peut invalider une soumission, et l'alerte qui l'indique arrive dans la plateforme et non dans votre seule boîte de réception. Placez une boîte aux lettres surveillée derrière les deux sièges de représentant.
- Ne vous fiez pas au compte à rebours de la plateforme. Consignez vous-même l'horodatage de votre prise de connaissance. Le compteur 72 heures affiché court à partir de la soumission du rapport à 24 heures, et non de la prise de connaissance : il peut donc signaler un dépôt comme en retard avant l'expiration du délai légal.
- Guettez les documents de lancement. L'ENISA indique qu'un manuel d'utilisation et des vidéos tutorielles seront publiés à la mise en service de la plateforme, en même temps que l'URL publique elle-même.
08Suivre le sujet à la source
Cette page reflète la situation au 9 septembre 2026. La plateforme évolue encore, et l'ENISA modifie ses pages discrètement plutôt que d'annoncer chaque changement. La FAQ a été réécrite le 4 septembre 2026, date à laquelle la liste des coordinateurs est également parue ; le glossaire est passé en version 1.1 le 5 septembre 2026, et une cinquième page d'orientations sur les circonstances particulièrement exceptionnelles est arrivée le 9 septembre 2026. Pour les questions d'assistance, l'ENISA publie une adresse de service d'assistance sur la page centrale, cra-srp-helpdesk [at] enisa.europa.eu. Ce sont les sources primaires ; tout ce qui précède est notre lecture de celles-ci.
Nous avions suggéré de noter cette mention à côté de tout ce que vous reprenez dans une procédure interne. Ce conseil appelle une réserve. Entre le 7 et le 9 septembre 2026 l'ENISA a profondément réécrit la page AR Notification submission and update tout en laissant sa mention indiquer 3/08/2026 : la terminologie est passée partout à CDaC , les références à une couche de données de points de contact nationaux ont disparu, les confirmations de soumission vont désormais à chaque représentant assigné du fabricant, et non plus seulement à l'auteur du dépôt, et il est désormais expressément indiqué que l'alerte précoce ne parvient aux autres CSIRT concernés qu'après une diffusion manuelle de la notification. Si une page d'orientations compte pour votre procédure, conservez votre propre copie datée du texte plutôt que de vous fier à la date que l'ENISA y imprime.
- ENISA · Plateforme de notification unique ; la page centrale, avec la fiche d'information, l'adresse du service d'assistance et les liens vers les orientations. C'est là que l'URL publique sera annoncée.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
- ENISA · Foire aux questions sur la SRP (réécrite le 4 septembre 2026) ; base juridique, délais, acheminement, tableau des champs, logique des compteurs et conduite à tenir en cas d'indisponibilité. La plus récente des pages SRP de l'ENISA.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
- ENISA · Liste des CSIRT désignés comme coordinateurs (4 septembre 2026) ; points de contact pour les 27 États membres. Identifiez votre ligne à l'aide du test de l'article 14(7) de la section 04.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators
- ENISA · Glossaire CRA SRP (version 1.1, 5 septembre 2026) ; orientations champ par champ sur la signification de chaque champ de notification, la manière de le remplir, son format attendu, sa limite de caractères et le stade auquel il s'applique. Attention à l'adresse : l'ENISA a déplacé le glossaire vers une URL glossary2 , et l'ancienne est toujours référencée depuis certaines de ses propres pages : vérifiez donc la ligne de version en haut avant de vous fier à une copie.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2
- 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/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-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/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-notification-submission-and-update
- ENISA · Orientations sur les fonctions d'interface de la SRP (14 août 2026) ; paramètres, associations de fabricants, plafond des associations non vérifiées (indiqué ici à 10, porté à 20 dans la FAQ du 4 septembre), le tableau de bord et l'onglet des alertes. La page centrale renvoie actuellement mal vers cette page : atteignez-la par la liste Content située en haut de la page centrale.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-interface-functions
- ENISA · Orientations sur les circonstances particulièrement exceptionnelles dans la SRP (9 septembre 2026); quand le PEC s'applique, l'interrupteur et les motifs de report du formulaire à 72 heures, et ce que le CSIRT coordinateur fait de la justification. La cinquième page d'orientations, et la seule qui traite directement du PEC.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-particular-exceptional-circumstances-pec
- 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.
La liste des CSIRT coordinateurs est-elle publiée ?
Oui, depuis le 4 septembre 2026. L'ENISA publie des points de contact pour les 27 États membres. La liste identifie le coordinateur de chaque État membre ; lequel est le vôtre relève toujours du test de l'établissement principal de l'article 14(7), qui dépend du lieu où les décisions relatives à la cybersécurité de vos produits sont principalement prises.
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 7 septembre 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 à partir du 11 septembre 2026, et l'ENISA indique que des tests utilisateurs et de sécurité ont été réalisés, avec la participation de différents CSIRT.
Que faire si la plateforme est en panne au moment où je dois déposer ?
La réponse de l'ENISA, ajoutée le 4 septembre 2026, est d'attendre et de soumettre une fois la plateforme de nouveau disponible. Si une communication immédiate est nécessaire entre-temps, vous pouvez contacter directement votre CSIRT désigné, mais la notification doit tout de même passer ensuite par la plateforme. Notez que rien dans le CRA ne suspend vos délais pendant une indisponibilité : horodatez donc l'indisponibilité et tout contact direct.
Le compte à rebours de la plateforme correspond-il à mon délai légal ?
Pas exactement. Dans la version actuelle, le compteur 72 heures affiche une date d'échéance 48 heures après la soumission du rapport à 24 heures, et non 72 heures après votre prise de connaissance : un dépôt peut donc s'afficher comme en retard avant l'expiration du délai légal. L'ENISA indique que la logique changera dans une version ultérieure et que les compteurs ne remplacent pas l'obligation de l'article 14. Tenez votre propre horloge, démarrée à la prise de connaissance.
La plateforme enregistre-t-elle le moment où j'ai eu connaissance ?
Pas à la mise en service. Le Glossaire SRP du 5 septembre 2026 indique que le champ de prise de connaissance pour une vulnérabilité activement exploitée n'arrivera que dans une version ultérieure, et que, pour un incident sévère, le champ actuel enregistre le moment de la détection. La détection précède généralement la prise de connaissance, que les conseils de la Commission de juillet 2026 rattachent à une évaluation initiale atteignant une certitude raisonnable. Conservez votre propre trace du moment où cette évaluation a conclu.
Puis-je invoquer le PEC pour un incident sévère ?
Non. Les orientations de l'ENISA du 9 septembre 2026 indiquent que les circonstances particulièrement exceptionnelles ne s'appliquent qu'à la notification à 72 heures d'une vulnérabilité activement exploitée. Il n'existe aucune commande PEC sur une notification d'incident sévère. Notez également qu'invoquer le PEC est une demande : le CSIRT coordinateur décide de l'accepter ou non, en s'aidant de la justification facultative que vous fournissez.
Quelle longueur chaque champ peut-il avoir ?
Le glossaire publie des limites : 4000 caractères pour les champs narratifs, 2000 pour les mesures déjà prises, 255 pour le titre, le produit, le composant, le vecteur d'attaque et la cause racine, et seulement 100 pour l'acteur malveillant. Construisez votre modèle interne à ces tailles.
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. L'ENISA a confirmé le 3 août 2026 que cette validation n'est pas une condition préalable au respect de l'obligation de notification et qu'elle ne bloque pas la soumission.
Y a-t-il une limite au dépôt avant que mon CSIRT ne me vérifie ?
Oui, et le chiffre a changé. Les orientations de l'ENISA sur les fonctions d'interface du 14 août 2026 le fixaient à 10 notifications ; la FAQ réécrite le 4 septembre 2026 indique qu'un représentant non validé peut soumettre jusqu'à 20 notifications pour un même fabricant avant que la validation ne devienne obligatoire. La validation n'est pas un verrou sur votre premier dépôt, mais elle n'est pas non plus indéfiniment reportable.
Mon déclarant suppléant peut-il voir un brouillon que j'ai commencé ?
Non. Le tableau de bord n'affiche que les brouillons créés par le représentant connecté : une alerte précoce à moitié rédigée est donc invisible pour votre suppléant. Rédigez en dehors de la plateforme, dans un document que votre équipe de réponse aux incidents partage, et servez-vous de la plateforme pour le recopier.
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 du Règlement délégué (UE) 2026/881, 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 publie une adresse de service d'assistance, cra-srp-helpdesk [at] enisa.europa.eu, pour les questions auxquelles la FAQ ou les pages d'orientation ne répondent pas, et indique qu'un manuel d'utilisation et des vidéos tutorielles suivront au lancement.