Article 14 CRA : le jalon de septembre 2026 que beaucoup de fabricants n'ont pas vu venir

Un jalon mal compris

La date de décembre 2027 est celle qui concentre l'attention dans les présentations sur le Cyber Resilience Act. C'est la date de conformité complète : celle à partir de laquelle chaque produit mis sur le marché de l'UE doit respecter l'ensemble des exigences essentielles, disposer d'un dossier technique complet et porter le marquage CE CRA. Cette date est réelle et contraignante.

Mais le Règlement (UE) 2024/2847 prévoit un jalon intermédiaire qui a une nature différente : les obligations de l'Article 14 entrent en application le 11 septembre 2026, soit quinze mois avant la conformité complète. Elles ne concernent pas la conception du produit, ni le dossier technique, ni le marquage CE. Elles concernent la capacité opérationnelle du fabricant à détecter une vulnérabilité activement exploitée et à en notifier les autorités compétentes dans des délais contraints.

Ce qui singularise ce jalon, c'est son caractère rétroactif. Ces obligations s'appliquent à l'ensemble des produits commercialisés, quelle que soit leur date de mise sur le marché. Un fabricant dont les systèmes d'alarme ou les passerelles IoT ont été mis en vente en 2017 est soumis à l'Article 14 dès le 11 septembre 2026, dès lors que des exemplaires sont encore en service chez des clients. Il n'existe aucune clause d'exclusion fondée sur l'antériorité.

La chaîne de notification : trois niveaux, trois délais

L'Article 14§3 du CRA décrit la séquence de notification applicable lorsqu'un fabricant a connaissance d'une vulnérabilité activement exploitée :

• Alerte précoce (Article 14§3 point a) : dans les 24 heures suivant la prise de connaissance. Contenu minimal : confirmation de l'existence de la vulnérabilité, indication de si une correction est en cours, et information préliminaire sur le vecteur d'exploitation ;
• Notification complète (Article 14§3 point b) : dans les 72 heures. Contenu étendu : évaluation préliminaire de la sévérité, produits affectés, version(s), état d'avancement de la remédiation, mesures de mitigation disponibles ;
• Rapport final (Article 14§3 point c) : dans les 14 jours suivant la disponibilité d'un correctif. Contenu complet : description détaillée de la vulnérabilité, analyse de cause racine, mesures correctives déployées, indicateurs d'exploitation connus.

Pour les incidents graves (Article 14§3 point c, renvoi à l'Article 14§3 alinéa 2), le rapport final est dû dans le mois suivant la notification complète, délai plus long mais exigences de documentation en conséquence plus étendues.

Ce qui définit un incident grave mérite une attention particulière. L'Article 3 du CRA définit un incident de sécurité grave comme tout événement ayant un impact réel ou potentiel sur la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité des données ou des services, ou ayant conduit, ou susceptible d'avoir conduit, à l'exécution de code malveillant sur le produit ou dans son environnement opérationnel. Cette définition, lue strictement, englobe potentiellement tout incident de sécurité ayant conduit à une compromission partielle ou complète d'un exemplaire du produit. Les fabricants doivent documenter leurs critères internes d'identification d'un incident grave, sous peine de n'identifier et notifier que les cas les plus grossiers.

Ce que signifie « activement exploitée »

La notion de vulnérabilité activement exploitée est centrale à l'Article 14. Elle n'est pas équivalente à vulnérabilité publiée ou vulnérabilité ayant un score CVSS élevé. Une vulnérabilité est activement exploitée lorsqu'il existe des preuves de son utilisation réelle dans des attaques : corrélation avec des rapports de menaces, alertes du CERT-EU, publications dans la base EUVD (European Vulnerability Database) ou équivalent avec signalement comme exploitée.

En pratique, cela signifie que le fabricant doit maintenir une veille active sur les vulnérabilités affectant ses composants. Une vulnérabilité publiée dans la NVD (National Vulnerability Database) ou l'EUVD avec le statut « exploitée dans la nature » ou équivalent déclenche l'obligation dès lors que le fabricant en a connaissance, y compris s'il l'apprend via un tiers ou un chercheur en sécurité.

Le standard de preuve pour la « prise de connaissance » n'est pas défini avec précision dans le texte du règlement. Le document d'orientation de la Commission (consultation publique mars 2026) précise cependant qu'un fabricant ne peut pas s'abriter derrière une organisation défaillante pour prétendre ne pas avoir eu connaissance d'une vulnérabilité exploitée qui était publiquement documentée et affectait ses produits. La veille sur les bases de données de vulnérabilités (EUVD, NVD) et la corrélation avec le SBOM sont la démonstration pratique d'une diligence raisonnable.

L'infrastructure minimale nécessaire avant septembre 2026

Tenir la chaîne de notification, en particulier le délai de 24 heures, suppose une infrastructure organisationnelle et technique qui ne s'improvise pas. La liste minimale pour être opérationnel à la date du 11 septembre 2026 est la suivante :

1. Un SBOM à jour et corrélable

Le SBOM (Software Bill of Materials) est le prérequis technique du délai de 24 heures. Sans SBOM complet et à jour, il est impossible d'évaluer en quelques heures si une vulnérabilité publiée affecte un produit en service. Pour un fabricant gérant dix familles de produits avec des générations successives, l'identification manuelle des composants affectés peut prendre plusieurs jours, délai incompatible avec l'Article 14.

Le format du SBOM doit être lisible par machine pour permettre la corrélation automatique avec les bases de vulnérabilités. Les deux formats reconnus par l'EUVD sont CycloneDX et SPDX. Le contenu minimum requis par le CRA (Annexe VII §3f) comprend les dépendances de premier niveau avec leur nom, version, fournisseur et identifiant de licence.

2. Une fonction PSIRT désignée

Un PSIRT (Product Security Incident Response Team) n'est pas nécessairement une équipe dédiée. Dans une PME, ce peut être une fonction distribuée sur deux ou trois personnes ayant des rôles complémentaires : un expert technique pour le triage des vulnérabilités et l'évaluation CVSS, un profil procédural pour la documentation et la notification aux autorités, et un backup pour la continuité. Ce qui est nécessaire, c'est que le rôle soit désigné, formalisé, et que les personnes concernées aient reçu une formation sur les délais et les obligations de l'Article 14.

L'expérience des démarches menées dans le secteur montre que la principale cause de dépassement des délais de notification n'est pas technique. C'est l'absence de processus décisionnel clair sur qui valide la notification et sous quel délai. La procédure interne de traitement des vulnérabilités doit documenter explicitement ce circuit de décision.

3. Une politique CVD publiée

La politique CVD (Coordinated Vulnerability Disclosure) est un document public qui engage le fabricant sur son processus de réception, de traitement et de divulgation des vulnérabilités signalées par des tiers. Elle est exigée par l'Annexe I Partie II du CRA et doit être accessible publiquement avant le 11 septembre 2026.

Le contenu minimal d'une politique CVD conforme au CRA et à la norme prEN 40000-1-3 (traitement des vulnérabilités, §5.3.3) comprend : un ou plusieurs mécanismes de contact accessibles (adresse dédiée de type security@, formulaire web), les attentes du fabricant en matière de contenu d'un signalement, les délais de réponse et d'accusé de réception que le fabricant s'engage à respecter, la stratégie d'embargo (délai pendant lequel la vulnérabilité ne sera pas divulguée publiquement pour permettre la remédiation), et les conditions de reconnaissance publique des chercheurs.

Un aspect souvent négligé est la clause de non-poursuite judiciaire (safe harbour). Une politique CVD qui expose les chercheurs à des poursuites pour divulgation non autorisée décourage les signalements et laisse le fabricant aveugle à ses propres vulnérabilités. La plupart des politiques CVD de référence (ISO/IEC 29147, CERT Coordination Center) incluent un engagement explicite de non-poursuite à l'égard des chercheurs qui se conforment aux règles de la politique. Une révision juridique externe de ce point est recommandée avant publication.

4. Un canal de signalement opérationnel

Le canal de signalement doit être accessible et fonctionnel avant le 11 septembre 2026. Sa mise en place est techniquement simple : une adresse courriel dédiée (security@) et, pour les fabricants disposant d'un site web produit, un fichier /.well-known/security.txt conforme à la RFC 9116. Ce fichier contient les informations de contact, les éventuelles clés de chiffrement, et l'URL de la politique CVD.

Le security.txt est une convention qui permet aux chercheurs en sécurité d'identifier rapidement le canal de signalement au lieu de chercher des contacts sur le site web. Il n'a pas de valeur réglementaire propre, mais son absence est un signal négatif dans un écran de conformité.

5. Une inscription sur la plateforme de notification ENISA

L'Article 14 prévoit que les notifications sont transmises à l'ENISA via une plateforme de notification unique. Sa mise en service est attendue avant le 11 septembre 2026. Les fabricants établis en France transmettent également leurs notifications à l'ANSSI, conformément à l'article 14§8 qui prévoit que les autorités compétentes (CSIRTs nationaux) peuvent recevoir ces informations. La démarche d'inscription sur la plateforme ENISA doit être anticipée et non laissée à la date limite.

Le problème des produits legacy

La rétroactivité de l'Article 14 pose une question de fond aux fabricants : que faire des produits qui ne sont plus en développement actif, dont le support technique est réduit ou inexistant, mais dont des exemplaires sont encore installés chez des clients ?

Le texte du CRA ne prévoit pas d'exemption pour les produits anciens. L'obligation de notification s'applique dès lors qu'un exemplaire du produit est « mis à disposition sur le marché », notion qui couvre les produits en service chez des utilisateurs finaux, que le fabricant les commercialise encore ou non (considérant 43 et article 3(22)). La seule sortie réglementaire claire est d'avoir documenté formellement que la période d'assistance est terminée, avec une justification raisonnable liée à la durée de vie utile du produit.

La démarche recommandée pour les fabricants disposant d'un portefeuille de produits anciens est la suivante :

1. Établir la liste de tous les produits dont des exemplaires sont potentiellement encore en service chez des clients ;
2. Pour chaque produit ou famille, évaluer si une période d'assistance raisonnable est encore en cours, en tenant compte de la durée de vie attendue, des engagements contractuels, des contrats de maintenance ou de télésurveillance actifs ;
3. Pour les produits dont la période d'assistance est raisonnablement épuisée : documenter formellement cette décision et ses justifications, la communiquer aux clients lorsque c'est possible ;
4. Pour les produits encore en période d'assistance : intégrer leur périmètre dans la veille SBOM/EUVD.

Ce dernier point est le plus exigeant pour les fabricants dont les produits les plus anciens ont été développés avant que la pratique du SBOM ne soit répandue. Pour les firmware embarqués des années 2010, la liste des composants n'est souvent pas formalisée. Une analyse rétrospective est nécessaire : inventaire des bibliothèques incluses dans le build du firmware, identification des versions, corrélation avec les CVE publiées. C'est un exercice laborieux, mais inévitable si des exemplaires de ces produits sont encore en service.

Ce qu'une autorité de surveillance du marché cherche

Les obligations de l'Article 14 ne créent pas seulement des obligations de notification : elles créent aussi une traçabilité que les autorités de surveillance du marché peuvent exploiter. Une notification à l'ENISA enregistre l'existence d'une vulnérabilité, la date de prise de connaissance du fabricant, et l'état de la remédiation. Si une autorité de surveillance du marché (MSA) est ultérieurement saisie d'une plainte d'utilisateur ou d'un incident lié à ce produit, la notification sera le premier document qu'elle examinera.

Les questions que pose une MSA lors d'un contrôle sur l'Article 14 sont les suivantes :

• Le fabricant disposait-il d'un SBOM couvrant ce produit au moment de la notification ? Si non, comment pouvait-il évaluer en 24 heures l'impact de la vulnérabilité ?
• La politique CVD était-elle publiée avant la date de notification ? Un fabricant qui publie sa CVD le jour même où il notifie une vulnérabilité expose son dossier à la critique ;
• Le délai entre la date de publication de la vulnérabilité (ou de sa présence dans les flux de threat intelligence) et la notification au fabricant est-il cohérent avec une veille active sur ses composants ? Un délai de plusieurs semaines entre la publication d'un exploit connu et la notification soulève des questions sur la diligence raisonnable ;
• Le correctif déployé était-il accompagné d'une communication aux utilisateurs, et les utilisateurs pouvaient-ils appliquer le correctif par un mécanisme de mise à jour décrit dans la documentation produit ?

Ces questions ne sont pas théoriques. Elles sont, pour l'essentiel, les mêmes que celles posées dans les contrôles actuels au titre de la Directive RED pour la gestion post-commercialisation des non-conformités de sécurité. Le CRA formalise et durcit un cadre qui existait déjà partiellement dans la pratique des MSAs les plus actives.

Ce qui est encore incertain à ce stade

Trois inconnues opérationnelles restent à lever avant septembre 2026 :

1. La plateforme de notification ENISA : sa mise en service, son interface, et les exigences de format des notifications. L'ENISA a communiqué sur son calendrier de déploiement, mais les fabricants qui n'ont pas lancé de démarche de test d'inscription précoce risquent une surprise de dernière minute ;
2. La définition opérationnelle des produits couverts : le règlement d'exécution (UE) 2025/2392 précise les catégories de l'Annexe III, mais des zones grises subsistent sur la qualification « importante » ou « standard » de certains produits hybrides. Une demande d'avis préalable auprès de l'autorité nationale compétente (en France, l'ANSSI ou l'ANFR selon le secteur) est envisageable pour les cas litigieux ;
3. La position des autorités nationales sur la lecture de « prise de connaissance » : le document d'orientation de la Commission apporte des clarifications, mais l'interprétation nationale peut varier. La pratique décisionnelle des premières notifications traitera ces incertitudes.

Ces inconnues ne justifient pas d'attendre pour mettre en place l'infrastructure de conformité. SBOM, PSIRT, CVD et canal de signalement sont des prérequis non litigieux que chaque fabricant avisé doit avoir en place avant l'échéance.