CRA Article 14 : 24 heures pour signaler, et la plateforme n'est pas encore en ligne

La plupart des équipes GRC ont classé le Cyber Resilience Act sous deux mots : « produit » et « 2027 ».

Les deux sont faux.

L'obligation de notification prévue par l'article 14 s'applique à compter du 11 septembre 2026. Pas décembre 2027. C'est la date que tout le monde retient, et c'est la mauvaise.

Trois semaines.

Et elle ne couvre pas seulement ce que vous mettrez sur le marché l'année prochaine. Elle couvre ce que vous avez déjà mis sur le marché. Un produit placé sur le marché de l'UE en 2018 et encore disponible aujourd'hui est dans le périmètre de la notification dès le jour où l'obligation entre en vigueur.

Si votre organisation vend quoi que ce soit comportant des éléments numériques sur le marché de l'UE, c'est votre processus de gestion des incidents, pas la paperasse de l'équipe produit.

Ce que l'article 14 exige concrètement

Deux déclencheurs, trois délais, un canal.

Les déclencheurs :

• une vulnérabilité activement exploitée dans votre produit
• un incident grave ayant un impact sur la sécurité de votre produit

Les délais :

• 24 heures : alerte précoce, à compter du moment où vous prenez connaissance de l'événement
• 72 heures : notification complète, incluant les mesures correctives ou d'atténuation prises
• 14 jours : rapport final, dès qu'une mesure corrective est disponible pour une vulnérabilité activement exploitée
• un mois : rapport final pour un incident grave, une fois celui-ci traité

Le canal :

Une notification unique via la plateforme de signalement unique de ENISA, adressée au CSIRT du lieu de votre établissement principal, et mise à disposition de ENISA simultanément.

Notez ce qui n'est pas inclus. Il ne s'agit pas de « notifier chaque CVE ». Le déclencheur, c'est l'exploitation active dans la nature, ou un incident grave. Cette distinction est la différence entre un processus viable et une équipe qui coule dès la deuxième semaine.

Voyons ce que vous devez absolument maîtriser.

1. La date, c'est 2026. Celle que vous avez mémorisée, c'est 2027.

Le CRA (règlement (UE) 2024/2847) est entré en vigueur le 10 décembre 2024. L'essentiel des obligations (sécurité dès la conception, documentation technique, évaluation de la conformité, marquage CE) s'applique à partir du 11 décembre 2027.

L'article 71(2) isole les obligations de notification et les avance de quinze mois.

Puis l'article 69(3) ferme la porte de sortie. Les dispositions transitoires permettant aux produits existants de rester sur le marché jusqu'en décembre 2027 sans conformité complète ne s'étendent pas à la notification.

Ainsi, le périmètre concerné au 11 septembre n'est pas votre feuille de route 2027. C'est l'ensemble de votre parc installé.

Conseil : Si votre inventaire produits ne recense que ce qui est en développement actif, ce n'est pas un inventaire produits. C'est un backlog.

2. Le délai commence à « prise de connaissance ». Personne n'a défini ce terme.

C'est là que tout se joue, et ce n'est pas une question juridique.

Vingt-quatre heures, ce n'est pas long. C'est une journée de travail, ou un samedi soir. Le délai ne commence pas lorsque votre service juridique convient qu'il y a un problème. Il commence lorsque l'organisation prend connaissance de l'événement.

Alors, qui est « l'organisation » ?

• un ingénieur support qui voit un ticket suspect à 19h00
• un chercheur qui envoie un e-mail à votre adresse générique security@
• un flux de threat intel signalant le nom de votre produit
• le SOC d'un client qui appelle votre account manager

Chacun de ces cas peut constituer le moment de prise de connaissance. Si aucun d'eux ne sait quoi faire ensuite, vos 24 heures s'écoulent pendant qu'un e-mail reste non lu.

Vous avez besoin de trois éléments formalisés avant septembre :

• quel événement constitue une prise de connaissance, en langage clair
• qui est habilité à la déclarer, avec un remplaçant nommé
• où le délai est enregistré, afin de pouvoir prouver quand il a commencé

Ce dernier point est plus important qu'on ne le croit. Si un régulateur demande pourquoi l'alerte précoce est arrivée à la 31e heure, « nous avons pris connaissance de l'événement plus tard que vous ne le pensez » n'est une réponse que si vous pouvez le démontrer.

Anecdote : Nous avons tous vu ce scénario se produire avec le GDPR. Une violation est déclarée trois semaines en retard, non pas parce que quelqu'un cachait quoi que ce soit. Le support l'a enregistrée comme un bug. L'IT l'a qualifiée de problème de configuration. Personne dans la chaîne n'avait jamais convenu de ce qui comptait réellement comme violation de données personnelles, donc le délai n'a jamais commencé. Le service juridique l'a appris quand un client a posé une question.

Même mécanique sous le CRA, avec une fenêtre plus courte. Les définitions sont la partie ennuyeuse. Elles sont aussi la partie qui détermine si vous étiez en retard.

3. Le CRA vous demande de notifier avant de vous demander d'écouter

Voici le problème de séquençage que personne ne signale, et c'est celui qui piégera les équipes les plus rigoureuses.

L'article 13(8) impose aux fabricants de disposer de politiques et de procédures, y compris la politique de divulgation coordonnée des vulnérabilités prévue à l'annexe I, partie II, point (5), pour traiter et remédier aux vulnérabilités signalées depuis des sources internes ou externes.

Il y a en réalité trois obligations juridiquement distinctes, et dans la plupart des entreprises une seule boîte de réception sert les trois :

• une politique CVD, rédigée, publiée et appliquée
• une adresse de contact pour signaler les vulnérabilités de vos produits et des composants tiers que vous distribuez
• un point de contact unique permettant aux utilisateurs de joindre directement un interlocuteur humain

Venons-en au calendrier. Ces obligations figurent à l'annexe I, partie II. L'annexe I devient juridiquement contraignante le 11 décembre 2027. La notification au titre de l'article 14 devient contraignante le 11 septembre 2026.

Relisez cela. Pendant quinze mois, la loi vous impose de notifier les vulnérabilités activement exploitées dans vos produits, sans encore exiger que vous opériez le canal par lequel vous en prendriez connaissance.

Une équipe qui suit les dates à la lettre passera ces quinze mois sous une horloge de 24 heures sans moyen fiable de savoir que cette horloge a démarré. Parce que la réponse honnête à la question « comment la plupart des fabricants apprennent-ils qu'un de leurs produits est activement exploité ? » est : quelqu'un les en informe.

Il y a une deuxième raison d'agir maintenant. De tout ce que contient le CRA, la politique CVD et l'adresse de contact sont les deux éléments visibles depuis l'extérieur de votre organisation. Une autorité de surveillance du marché qui se forge une première impression de votre posture consultera votre site web avant de vous demander le moindre document.

Ce que le bon niveau ressemble à :

• la politique à une URL stable et publique, pas enfouie dans une page juridique
• un fichier security.txt sur votre domaine
• une boîte de réception surveillée avec un responsable nommé et un remplaçant, pas un alias que personne ne lit
• un périmètre déclaré, des délais de réponse attendus, ce qui est autorisé ou non en termes de tests, et la façon dont vous gérez les crédits et la publication
• chaque signalement enregistré, car appliquer la politique est en soi l'obligation

Conseil : Vous n'avez pas à tout inventer. ISO/IEC 29147 et ISO/IEC 30111 sont les normes de référence pour la divulgation et le traitement des vulnérabilités, et la boîte à outils du NCSC en matière de divulgation constitue un excellent point de départ gratuit. Publier quelque chose d'opérationnel en trois semaines vaut mieux que publier quelque chose de parfait en décembre 2027.

4. Vous ne pouvez pas notifier ce que vous ne savez pas nommer

L'étape des 72 heures demande le type et la classification du produit. Cela signifie que vous devez disposer, avant un incident et non pendant, des éléments suivants :

• la liste des produits comportant des éléments numériques que vous mettez sur le marché de l'UE
• pour chacun, s'il est standard, important (annexe III, classe I ou II) ou critique (annexe IV)
• un SBOM dans un format couramment utilisé et lisible par machine

La classification suit la fonction principale du produit ; lorsque plusieurs classes sont applicables, c'est la plus stricte qui s'impose.

Le SBOM est l'élément que les équipes sous-estiment. L'article 14 vous demande de notifier une vulnérabilité dans votre produit. Si votre produit intègre un framework en fin de vie que vous n'avez pas inventorié, vous n'apprendrez pas son exploitation via votre propre télémétrie. Vous l'apprendrez d'un client, ou dans la presse, ce qui est une façon très coûteuse de démarrer une horloge de 24 heures.

Conseil : Faites l'exercice à rebours. Choisissez un composant que vous savez présent dans trois de vos produits. Pouvez-vous produire cette liste en moins d'une heure, aujourd'hui, sans solliciter l'équipe engineering ? Si non, c'est votre premier écart.

5. La plateforme n'est pas opérationnelle. Enregistrez-vous quand même.

Voici ce qui fait de ce sujet une histoire plutôt qu'une note de conformité.

La plateforme de signalement unique, créée par l'article 16 et opérée par ENISA, est prévue pour être opérationnelle le 11 septembre 2026. Pas avant. À la mi-août, l'URL d'accès public n'avait pas encore été publiée. Des courtes vidéos et un webinaire sont annoncés deux semaines avant le lancement.

L'obligation est fixée. L'outil, non. Cet écart est à votre charge, pas à celle du régulateur.

Trois actions ne dépendent pas de l'existence de la plateforme :

Créez les comptes EU Login maintenant. L'inscription se fait via EU Login sur ecas.ec.europa.eu. Vous pouvez créer le compte aujourd'hui. Le faire en plein incident, avec une horloge de 24 heures en cours, est un retard que vous vous infligez vous-même.

Ouvrez deux accès, pas un. Il y a un représentant assigné principal qui s'inscrit en sélectionnant le rôle, en choisissant le CSIRT coordinateur, en acceptant l'accord et en saisissant les informations du fabricant. Le remplaçant, ou AR secondaire, est invité par e-mail, et cette invitation expire après sept jours. Envoyez-la et confirmez sa réception. Une invitation non acceptée n'est pas un remplaçant.

N'attendez pas la validation du CSIRT. La validation de l'AR par le CSIRT coordinateur intervient après l'inscription. Elle se déroule en parallèle et ne bloque pas la notification. Les équipes qui supposent qu'elles ont besoin d'un feu vert avant de pouvoir déposer une notification perdront des heures qu'elles n'ont pas.

Les orientations de ENISA ont déjà évolué deux fois ce mois-ci. Les guides d'inscription et de notification ont été redatés du 3 août, le guide d'interface a paru le 14 août. Tout cela est marqué comme susceptible d'être modifié. Construisez votre processus interne sur la base des champs obligatoires, pas des captures d'écran.

6. Il n'existe pas encore de normes harmonisées

Le 13 août 2026, l'ETSI a soumis 17 projets finals de normes produits CRA à enquête publique. Aucune d'entre elles n'est une norme harmonisée. La période de commentaires se clôt à partir de la mi-septembre, avec une approbation s'étendant jusqu'en novembre selon le secteur.

Les organismes notifiés arrivent en décembre 2026.

Le constat honnête est donc le suivant : l'infrastructure de conformité du CRA est encore en construction, et l'obligation de notification arrive en premier de toute façon.

Si votre plan était « nous démarrerons une fois les normes publiées », vous avez déjà manqué la fenêtre de notification. Les normes vous indiquent comment prouver que votre produit satisfait aux exigences essentielles. Elles ne vous disent pas qui dépose l'alerte précoce un dimanche.

7. Votre notification NIS2 et DORA ne couvre pas cela

Je vois cette hypothèse en permanence, et elle est dangereuse parce qu'elle est presque juste.

Vous disposez peut-être déjà d'un réflexe 24/72 heures issu de NIS2 ou DORA. Bien. Ce n'est pas la même obligation.

Un même événement peut déclencher les deux. Un incident grave dans un produit que vous fabriquez et exploitez également donne lieu à deux notifications, deux destinataires, deux pistes de traçabilité.

Le réflexe à construire maintenant n'est pas un nouveau processus. C'est un point de décision en tête de votre processus existant : quels régimes cet événement active-t-il ? Répondez à cela à la cinquième minute, pas à la vingtième heure.

Anecdote : Je vais être direct sur l'état du marché. Presque aucun de mes clients ne s'interroge sur le CRA en ce moment, parce qu'ils ne prennent pas encore NIS2 suffisamment au sérieux pour en arriver là. Trois semaines avant l'échéance. Voilà le tableau honnête.

L'exemple que je peux vous donner est donc le mien. Chez Mobilexpense, où j'exerce en tant que CISO, c'est exactement ce que nous construisons : un processus de gestion des incidents avec deux branches. Même intake, mêmes premières questions, puis une bifurcation au moment où vous décidez si l'événement relève de l'entité, du produit, ou des deux. La bifurcation est simple à concevoir maintenant. Elle est très coûteuse à improviser à la troisième heure.

8. Ce que vous pouvez réellement finaliser avant le 11 septembre

Trois semaines ne suffisent pas à construire un programme. Elles suffisent à construire la partie qui s'active en premier.

Semaine 1 :

• créer les comptes EU Login, principal et remplaçant
• envoyer et confirmer l'invitation AR secondaire avant son expiration
• identifier votre CSIRT coordinateur
• soumettre la politique CVD à la revue juridique, car c'est l'étape la plus longue

Semaine 2 :

• publier la politique CVD, l'adresse de contact et le fichier security.txt
• figer la liste des produits dans le périmètre, y compris les produits legacy
• attribuer une classification à chacun
• rédiger la définition de « prise de connaissance » et nommer les deux personnes habilitées à la déclarer

Semaine 3 :

• construire l'alerte précoce de 24 heures sous forme d'un court formulaire interne calqué sur les champs obligatoires
• ajouter la question de routage réglementaire en tête de votre processus de gestion des incidents
• le répéter sur papier : un scénario, un samedi soir, un chronomètre

Cette dernière étape est celle que tout le monde esquive, et la seule qui vous indique si les onze autres ont fonctionné.

Réflexion finale

La vérité inconfortable du 11 septembre, c'est que le régulateur arrive avant ses propres outils, et cela ne change rien à votre situation.

Vous ne pouvez pas déposer une alerte précoce avec un certificat ISO 27001. Vous ne pouvez pas classifier un produit avec une politique. Et vous ne pouvez pas démarrer une horloge de 24 heures avec un processus qui n'existe que dans un document que personne n'a jamais exécuté.

Les fabricants qui s'en sortiront bien en septembre ne seront pas ceux qui auront la meilleure analyse d'écarts CRA. Ce seront ceux qui, lorsque le ticket arrive à 19h00 un samedi, disposent d'un interlocuteur nommé qui sait qu'il est autorisé à appuyer sur le bouton.

Tout le reste est une préparation à ce seul moment.

Les sanctions pour manquement aux exigences essentielles et aux obligations des fabricants atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Mais l'amende n'est pas le risque. Le risque, c'est de découvrir, le jour J, que la prise de connaissance n'était la responsabilité de personne.

Si vous souhaitez construire sérieusement le réflexe 24/72 heures (déclencheurs, escalade, preuves et routage réglementaire permettant de déterminer quels régimes un événement active), c'est précisément ce que nous travaillons dans l'ISO/IEC 27035 Lead Incident Manager. Cinq jours, alignés sur DORA, NIS2 et désormais le CRA article 14. Certifié ou remboursé.