Analyse des obligations de déclaration de l’article 14 du règlement européen sur la cyberrésilience

Un ticket de vulnérabilité était autrefois un élément dans une file d’attente. Depuis le 11 septembre, pour les produits comportant des éléments numériques vendus dans l’Union européenne, il peut aussi devenir un compte à rebours réglementaire. Le Cyber Resilience Act attend encore en grande partie en coulisses, et c’est précisément pour cela que l’article 14 compte : une partie de la loi est arrivée en avance, et elle atterrit directement au cœur de la réponse aux incidents. La question pratique n’est pas de savoir si une équipe produit a lu le CRA. C’est de savoir si quelqu’un peut décider, en moins de 24 heures, si une vulnérabilité activement exploitée ou un incident grave doit être signalé, qui le dépose, et quelles preuves l’accompagnent. Les juristes appellent cela une obligation de notification. Les personnes qui construisent les produits devraient y voir un workflow de production avec un régulateur au bout.

La partie du

CRA qui est déjà au calendrier Pearl Cohen décrit le CRA comme étant mis en œuvre en trois phases : les obligations pour les organismes d’évaluation de la conformité à partir du 11 juin 2026, la notification des vulnérabilités au titre de l’article 14 à partir du 11 septembre 2026, et l’ensemble du CRA à partir du 11 décembre 2027. Cybersecurity Time ajoute une correction utile : le règlement est entré en vigueur le 10 décembre 2024, tandis que ses principales obligations s’appliquent plus tard. Cette distinction n’est pas théorique ; elle signifie que des équipes peuvent aujourd’hui être hors du champ des exigences complètes relatives aux produits, tout en étant déjà dans le champ de la notification.

Pearl Cohen indique que le CRA couvre à la fois les produits matériels et logiciels comportant des éléments numériques mis sur le marché de l’UE. C’est la formule que les éditeurs de logiciels devraient souligner, de préférence avant que l’équipe commerciale ne signe un nouveau client européen un vendredi après-midi. Il ne s’agit pas seulement d’un problème de thermostat connecté ; cela peut concerner des produits logiciels s’ils sont des produits couverts comportant des éléments numériques.

Ce que l’article 14 exige réellement

Crowell indique que l’obligation de notification prévue par l’article 14 du CRA s’applique à partir du 11 septembre 2026 et peut être appliquée à compter de cette date, tandis que le reste du CRA s’applique généralement à partir du 11 décembre 2027. Le cabinet précise aussi que les fabricants soumettent une notification unique via la plateforme de notification unique au Computer Security Incident Response Team compétent désigné comme coordinateur, ainsi qu’à l’ENISA. Cette notification est ensuite partagée avec les autres CSIRT concernés le cas échéant, ce qui est heureusement différent des régimes où la carte des dépôts devient elle-même un incident.

Le texte juridique de l’article 14 indique qu’un fabricant doit notifier toute vulnérabilité activement exploitée dans un produit comportant des éléments numériques dès qu’il en a connaissance, simultanément au CSIRT coordinateur et à l’ENISA, au moyen de la plateforme de notification unique. Il exige également une alerte précoce dans les 24 heures suivant la prise de connaissance, puis une notification de vulnérabilité supplémentaire dans les 72 heures, sauf si les informations pertinentes ont déjà été fournies. La notification à 72 heures doit inclure, dans la mesure où elles sont disponibles, des informations générales sur le produit, la nature de l’exploitation et de la vulnérabilité, les mesures correctives ou d’atténuation prises, ainsi que les mesures que les utilisateurs peuvent prendre.

Traduit en opérations, l’article 14 signifie que votre workflow d’incident doit comporter au minimum quatre champs que les tickets de sécurité dispersent souvent entre les discussions, les postmortems et les notes de version. Il vous faut le produit concerné, la description générale de l’exploitation et de la vulnérabilité, ce que l’entreprise a fait, et ce que les utilisateurs peuvent faire. Si ces informations ne peuvent pas être saisies rapidement, le problème de notification est déjà visible.

Qui devrait s’en préoccuper, y compris les vendeurs non européens

Faegre Drinker présente les échéances de septembre 2026 comme s’appliquant aux fabricants de produits connectés et souligne leur portée extraterritoriale pour les entreprises américaines. Le résumé de Pearl Cohen concernant les orientations de la Commission confirme que le CRA s’applique aux produits matériels et logiciels mis sur le marché de l’UE. En clair : être constitué en société en dehors de l’UE n’est pas une cape d’invisibilité magique si le produit y est mis à disposition.

C’est ici que les contrats fournisseurs et la responsabilité interne comptent. Si un fabricant dépend d’un fournisseur de services managés, d’un revendeur, d’un chercheur en vulnérabilités, d’un hébergeur cloud ou d’un fournisseur de composants pour apprendre qu’une exploitation a lieu, l’entreprise a tout de même besoin d’un chemin entre ce signal et la personne qui prend la décision au titre de l’article 14. Les éléments fournis ici ne disent pas que chaque fournisseur doit déposer une notification ; il ne faut donc pas laisser le folklore de la conformité dépasser le texte. Le choix opérationnel le plus sûr est de s’assurer que les contrats exigent une notification de sécurité rapide, des détails techniques exploitables et une coopération sur les communications d’atténuation.

Crowell signale aussi l’importance des représentants autorisés et des processus d’escalade capables de fonctionner avec le compte à rebours de 24 heures. C’est une façon polie de dire que le circuit de notification ne peut pas vivre dans la boîte de réception d’une seule personne. Les équipes produit, sécurité, juridique, support et communication client ont besoin d’un passage de relais répété, car le compte à rebours commence lorsque le fabricant prend connaissance du problème, pas lorsque le brouillon parfait du postmortem est prêt.

Ce qu’il faut opérationnaliser cette semaine

Crowell recommande des exercices sur table, la formation du personnel et des mises à jour des politiques cyber en réponse au compte à rebours de l’article 14. Ce ne sont pas des objets cérémoniels de conformité s’ils testent les bons modes de défaillance : qui identifie l’exploitation active, qui décide de la gravité, qui ouvre le processus de la plateforme de notification unique, et qui approuve le langage d’atténuation destiné aux utilisateurs. Un exercice sur table qui se termine par un accord général pour enquêter davantage n’est pas de la préparation ; c’est une réunion avec des snacks.

La distinction utile se fait entre ce que la loi exige maintenant et ce qu’internet prétendra qu’elle exige. Maintenant : la notification des vulnérabilités activement exploitées et des incidents graves au titre de l’article 14, avec une alerte précoce à 24 heures et un suivi à 72 heures, selon Crowell et le texte de l’article 14. Plus tard : l’ensemble complet des exigences essentielles de cybersécurité du CRA, qui, selon Pearl Cohen, s’applique à partir du 11 décembre 2027.

Pour les équipes qui construisent les produits, le travail immédiat est limité mais impitoyable. Cartographier les produits vendus ou mis sur le marché de l’UE, définir les déclencheurs de prise de connaissance, préparer des modèles de notification, désigner un représentant autorisé si nécessaire, et répéter le chemin vers la plateforme de notification unique. Ensuite, continuer à surveiller l’écart entre l’application de l’article 14 et la date d’application complète du CRA, car les régulateurs ont tendance à apprendre des premiers dépôts bien avant que la première amende n’apparaisse.