Qui devrait lire ceci : toute entreprise qui vend du logiciel, un objet connecté ou un produit contenant du logiciel sur le marché européen. Si vous consommez de la technologie sans en expédier, celui-ci ne vous concerne pas.
Le 11 septembre 2026, la première obligation contraignante du règlement sur la cyberrésilience entre en vigueur. C’est une obligation de notification, elle tourne sur un chronomètre de 24 heures, et elle vise les fabricants et non les utilisateurs.
Ce que dit l’obligation
À compter du 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent signaler deux choses :
- les vulnérabilités activement exploitées dans leur produit
- les incidents graves affectant la sécurité de leur produit
Les délais sont courts et s’empilent :
| Étape | Délai |
|---|---|
| Alerte précoce | 24 heures à compter de la connaissance |
| Notification complète | 72 heures |
| Rapport final, vulnérabilité exploitée | au plus tard 14 jours après la disponibilité d’une mesure corrective |
| Rapport final, incident grave | un mois |
Les signalements passent par un canal unique, la plateforme de notification unique du CRA, vers le CSIRT désigné dans l’État membre de votre établissement principal, et sont partagés avec l’ENISA. Ce CSIRT les diffuse ensuite aux autres CSIRT des pays où le produit est disponible. La plateforme doit être opérationnelle à la date même où l’obligation démarre.
Le reste du CRA, les exigences essentielles de cybersécurité, l’évaluation de la conformité et le marquage CE, s’applique à partir du 11 décembre 2027. Cela vous laisse quinze mois sur les exigences produit. Cela ne vous laisse aucun délai sur la notification.
Pourquoi cela surprend
Trois raisons, à nommer car chacune produit un type d’erreur différent.
C’est une réglementation de produit, pas d’organisation. NIS2 demande si votre entreprise est sécurisée. Le CRA porte sur ce que vous vendez aux autres. Une entreprise peut être entièrement hors du champ de NIS2 et pleinement dans celui du CRA, avec des régulateurs, des obligations et des chronomètres différents.
« Produit comportant des éléments numériques » est plus large que « logiciel ». Cela couvre le logiciel, le matériel embarquant du logiciel, et les solutions de traitement de données à distance intégrées au produit. Un capteur connecté, un automate industriel, un routeur, un micrologiciel embarqué, un composant SaaS livré avec le produit. Beaucoup d’entreprises qui ne se voient pas comme éditeurs sont des fabricants au sens de cette définition.
La connaissance déclenche le chronomètre, et vous ne la maîtrisez pas. Les 24 heures courent à partir du moment où vous avez connaissance qu’une vulnérabilité de votre produit est activement exploitée. Cette information vient souvent de l’extérieur : un chercheur, un client, un avis de CERT, une divulgation publique. Si personne chez vous ne surveille les canaux d’arrivée, le chronomètre tournait déjà quand vous l’apprenez.
Les deux choses à mettre en place avant vendredi
Vous ne construirez pas un programme de gestion des vulnérabilités en deux jours. Vous pouvez mettre en place les deux éléments qui transforment un délai manqué en délai tenu.
1. Nommez la personne, et donnez-lui un canal. Quelqu’un doit être autorisé à décider qu’un signalement est requis et à le déposer, sans attendre une réunion. Dans une entreprise de quarante personnes, cela fait une personne nommée et une suppléante. Écrivez qui elles sont et comment les joindre hors heures. C’est la mesure la moins chère de cette page et la plus souvent absente.
2. Sachez comment vous l’apprendriez. Où arrive l’information. Une adresse de contact sécurité sur votre site que quelqu’un lit. Une veille sur les flux CVE de vos composants. Une relation avec le CERT de votre établissement principal. Un chemin pour qu’un client vous signale un problème sans passer par une file de support généraliste où il dormira une semaine.
C’est sur ce second point que se concentre le risque, et il faut être direct sur la raison. Un chronomètre de 24 heures n’est pas difficile à tenir si vous savez à l’heure zéro. Il est impossible à tenir si vous l’apprenez au neuvième jour.
Ce qu’il faut construire dans les mois qui suivent
Une fois la brèche immédiate refermée, le travail qui rend cela tenable est ordinaire et familier.
Une politique de divulgation coordonnée des vulnérabilités. Un moyen publié pour que chercheurs et clients vous signalent quelque chose, avec un engagement de réponse. C’est aussi une attente de NIS2, traitée dans le cadre de divulgation des vulnérabilités NIS2.
Une nomenclature logicielle, et l’habitude de la surveiller. Vous ne pouvez pas évaluer si une vulnérabilité affecte votre produit sans savoir ce qu’il contient. La plupart des vulnérabilités pertinentes pour le CRA se trouveront dans des composants que vous n’avez pas écrits.
Un processus d’incident qui produit un rapport, pas une discussion. La notification à 72 heures demande des éléments précis. Décider quoi dire pendant que le chronomètre tourne est la façon dont on manque un délai.
Des preuves qui s’accumulent. Le rapport final et toute supervision ultérieure demanderont ce que vous saviez et quand. Des enregistrements créés sur le moment y répondent. Des enregistrements assemblés après coup, non, un argument développé dans les preuves qui s’assemblent seules.
Si vous vendez aussi à des clients régulés, notez que ces obligations se superposent au lieu de se remplacer. Un fournisseur télécom peut relever du CRA pour son produit et des obligations de chaîne d’approvisionnement NIS2 de son client en même temps, décrites dans la sécurité de la chaîne d’approvisionnement sous NIS2. Un fournisseur aéronautique peut relever du CRA et de l’évaluation d’interface Part-IS de son client, décrite dans ce que Part-IS signifie pour les fournisseurs de l’aéronautique. La réponse efficace à tout cela est un référentiel de mesures unique sur lequel projeter les cadres, l’argument de faire ISO 27001 et NIS2 une fois plutôt que deux.
Ce que ce n’est pas
À dire clairement, car il y a beaucoup de bruit autour de cette date.
Ce n’est pas le CRA complet. Évaluation de la conformité, documentation technique et marquage CE sont des sujets de décembre 2027, et vous avez le temps de les préparer correctement.
Ce n’est pas une certification. Rien n’est audité vendredi. Aucun certificat à obtenir, aucun évaluateur en visite, aucun schéma à rejoindre.
Ce n’est pas votre sécurité informatique interne. C’est la sécurité de ce que vous expédiez.
Et cela ne concerne pas tout le monde. Si vous ne mettez pas sur le marché européen un produit comportant des éléments numériques, vous n’êtes pas un fabricant au sens de ce règlement. Déterminez de quel côté de la ligne vous êtes avant de dépenser quoi que ce soit, car un nombre non négligeable d’entreprises vont passer le mois qui vient à préparer une obligation qui ne les vise pas.
La réalité technique : le rapport est la moitié facile
L’obligation de notification est procédurale. Nommer une personne, surveiller les bons canaux, déposer dans la fenêtre. C’est faisable en une semaine.
La question plus difficile se tient derrière, et le règlement ne la pose pas. Quand vous déposerez la notification à 72 heures indiquant qu’une vulnérabilité de votre produit est activement exploitée, la question suivante de chaque client sera depuis combien de temps elle était là et combien d’entre eux sont touchés. Y répondre suppose un inventaire de ce que contient votre produit, un enregistrement de la version exécutée par chaque client, et un moyen de savoir ce qui s’est passé dans votre propre environnement.
Le règlement vous demande de signaler ce que vous savez. Il ne vous fait rien savoir. Les entreprises capables de répondre à la question suivante auront construit cette capacité pour leurs propres raisons, et celles qui ne le peuvent pas découvriront l’écart en public, chronomètre en marche. Un audit de sécurité structuré est un moyen raisonnable de savoir dans quel camp vous êtes avant vendredi plutôt qu’après un incident.
