Le 11 septembre 2026, le Cyber Resilience Act rend obligatoire le signalement des vulnérabilités activement exploitées, sous 24 heures. Beaucoup d’éditeurs de logiciel se préparent à la mauvaise échéance : ils lisent les articles qui décrivent la conformité complète, s’affolent, et passent à côté du fait que seul le signalement est exigible en septembre. Le reste attend décembre 2027. Voici ce qui s’applique vraiment, et ce qu’il est encore temps de mettre en place.
Qu’est-ce qui devient obligatoire le 11 septembre 2026 ?
Une seule chose : signaler. À partir du 11 septembre 2026, tout fabricant d’un produit comportant des éléments numériques mis sur le marché européen doit déclarer les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de son produit. C’est l’article 14 du règlement (UE) 2024/2847.
Trois délais, qui courent tous à partir du moment où vous avez connaissance du fait.
| Étape | Délai | Contenu attendu |
|---|---|---|
| Signalement précoce | 24 heures | Alerte sommaire : nature du fait, produit concerné, périmètre estimé |
| Notification complète | 72 heures | Gravité, impact, mesures correctives ou palliatives disponibles |
| Rapport final, vulnérabilité | 14 jours après mise à disposition du correctif | Description, gravité, correctif, identification des instances affectées |
| Rapport final, incident grave | 1 mois après la notification | Idem |
Le fait déclencheur est plus étroit qu’on ne le croit. Une vulnérabilité connue mais non exploitée ne déclenche rien. Il faut une exploitation active, avec des indices concrets, ou un incident grave qui touche la sécurité du produit.
Un point que les éditeurs découvrent souvent trop tard : l’obligation couvre aussi les produits déjà sur le marché. Toutes vos versions déployées chez vos clients avant septembre 2026 sont dans le champ. Il n’y a pas de clause d’antériorité.
Qui est fabricant au sens du CRA ?
Est fabricant celui qui met un produit comportant des éléments numériques sur le marché européen sous son propre nom ou sa propre marque. Un logiciel commercial est un produit comportant des éléments numériques. Si vous éditez et distribuez du logiciel sous votre marque, vous êtes fabricant.
La partie qui surprend est ailleurs. L’article 21 du règlement prévoit qu’un distributeur ou un importateur qui commercialise un produit tiers sous sa propre marque est considéré comme fabricant, avec toutes les obligations qui vont avec. Autrement dit, un prestataire qui rebaptise un outil tiers et le vend sous son nom hérite de la responsabilité de signalement, alors même qu’il ne maîtrise pas le code et dépend de son fournisseur pour savoir qu’une faille existe.
Deux conséquences pratiques pour un éditeur.
- Les composants tiers comptent. Une vulnérabilité activement exploitée dans une bibliothèque que vous intégrez, dès lors qu’elle affecte votre produit, déclenche votre obligation. Votre veille ne peut pas se limiter à votre propre code.
- Vos fonctions cloud aussi. Les traitements de données à distance sans lesquels le produit ne remplit pas ses fonctions font partie du produit. Un portail d’administration n’est pas un service séparé qui échapperait au règlement.
Qu’est-ce qui n’est PAS exigible en septembre 2026 ?
Tout le reste. C’est la distinction que la plupart des contenus disponibles ratent, et elle change complètement la charge de travail.
| Échéance | Ce qui s’applique |
|---|---|
| 11 septembre 2026 | Obligations de signalement uniquement (24h, 72h, 14j), y compris pour les produits déjà commercialisés |
| 11 décembre 2027 | Traitement des vulnérabilités, SBOM, politique de divulgation coordonnée, documentation technique, marquage CE, déclaration UE de conformité |
Vous n’avez donc pas à bâtir un processus complet de gestion des vulnérabilités pour septembre. Vous avez à savoir détecter, qualifier et déclarer. C’est un chantier de quelques jours, pas de quelques mois, à condition de ne pas le commencer le 10 septembre.
Où déclare-t-on, et la plateforme est-elle prête ?
La déclaration passe par un point d’entrée unique européen, la Single Reporting Platform gérée par l’ENISA. Vous déposez une fois, et le signalement part simultanément à l’ENISA et au CSIRT coordinateur de votre pays d’établissement principal. Pour la France, c’est le CERT-FR, opéré par l’ANSSI.
Voilà pour la théorie. Au 1er septembre 2026, à dix jours de l’échéance, la plateforme n’est toujours pas en service : son adresse publique n’est pas publiée, la liste officielle des CSIRT coordinateurs non plus, et aucune interface programmatique n’est proposée. L’ENISA a publié ses instructions d’inscription le 31 juillet 2026 et maintient une mise en service au 11 septembre.
Cela ne repousse rien. Les 24 heures courent à partir de votre prise de connaissance, pas à partir de l’ouverture de l’outil. Un éditeur qui détecte une exploitation active le 12 septembre sera sur un compte à rebours de 24 heures, plateforme rodée ou non.
Trois pièges dans la documentation de l’ENISA
La documentation publiée cet été réserve trois surprises qui méritent d’être connues avant d’en avoir besoin.
- Un compte non vérifié plafonne à dix notifications. L’association de votre compte à votre entité est créée au statut « non vérifié », et la demande de validation part au CSIRT coordinateur. La validation n’est pas un préalable pour déclarer, mais le plafond existe. Ouvrez cette conversation avec le CERT-FR hors incident.
- Les brouillons ne sont pas partagés. Le suppléant ne voit pas les brouillons du titulaire. Si celui qui a commencé un signalement à deux heures du matin devient injoignable, le suppléant repart d’un formulaire vide et le chronomètre ne s’arrête pas. Rédigez votre message hors plateforme, dans un document que votre équipe partage, et servez-vous de la plateforme uniquement pour le recopier.
- Une soumission peut être invalidée. L’onglet d’alertes passe au rouge quand un CSIRT rejette un dépôt, et aucun délai réglementaire ne bouge pour autant. Il faut donc quelqu’un qui surveille cet onglet, y compris le week-end, ce qui plaide pour une boîte partagée plutôt que deux adresses personnelles.
Que faire d’ici le 11 septembre 2026 ?
Cinq actions, toutes réalisables sans attendre l’ouverture de la plateforme.
- Créez vos comptes EU Login, pour le titulaire et pour un suppléant. Cette étape ne dépend d’aucune autorité et ne demande aucune attente.
- Désignez ce suppléant et briefez-le. Il doit pouvoir déclencher seul un signalement. Évitez qu’il soit systématiquement au même endroit et sur le même fuseau que vous.
- Ouvrez un point de contact de divulgation, du type
security@votredomaine, et publiez-le. Sans lui, un chercheur qui trouve une faille dans votre produit n’a aucun moyen de vous prévenir. Ne pas avoir de canal d’entrée ne vous protège pas : cela retarde seulement le moment où vous l’apprenez, et probablement par un client. - Écrivez le texte de votre signalement à 24 heures, hors plateforme, dans un document partagé. Réservez-y une ligne pour la date et l’heure exactes de prise de connaissance : c’est elle qui fait courir les trois délais, et elle se perd en quelques heures si personne ne la note.
- Tranchez la classification de votre produit : par défaut, important (Annexe III) ou critique (Annexe IV). C’est un champ demandé par le formulaire, et c’est aussi ce qui déterminera votre route de conformité en 2027.
Sur ce dernier point, les éditeurs d’outils d’administration à distance, d’antimalware, de gestion de réseau ou de SIEM ont intérêt à regarder l’Annexe III de près : plusieurs de ces catégories y figurent en classe I, ce qui vaut le statut de produit « important ». Sans effet sur septembre 2026, mais avec des conséquences réelles sur la procédure d’évaluation applicable en décembre 2027.
Questions fréquentes
Une PME est-elle concernée par le Cyber Resilience Act ?
Oui. Le règlement ne prévoit pas de seuil de taille exonérant les petites entreprises des obligations de signalement. Une PME qui édite et commercialise un logiciel dans l’Union est fabricant au même titre qu’un grand groupe. L’ENISA a prévu un service d’assistance avec une attention particulière aux PME, mais c’est un accompagnement, pas une exemption.
Faut-il signaler une vulnérabilité qui n’est pas exploitée ?
Non, pas au titre de l’article 14 en septembre 2026. L’obligation vise les vulnérabilités activement exploitées et les incidents graves. En cas de doute sur la qualification, mieux vaut déclarer : le signalement précoce est par nature incomplet, il n’engage aucune conclusion, et il peut être corrigé dans la notification à 72 heures.
Que se passe-t-il si on ne signale pas ?
Le règlement prévoit des sanctions administratives significatives, pouvant atteindre plusieurs millions d’euros ou un pourcentage du chiffre d’affaires mondial selon la nature du manquement. Au-delà du montant, le risque commercial est immédiat : un manquement au signalement se découvre en général au pire moment, quand un client demande des comptes.
Le CRA remplace-t-il NIS2 ?
Non, les deux textes coexistent et ne visent pas la même chose. NIS2 porte sur la sécurité des entités et de leurs systèmes d’information. Le CRA porte sur la sécurité des produits mis sur le marché. Un éditeur peut relever des deux, avec des circuits de signalement distincts. C’est une raison de plus pour écrire noir sur blanc quel événement part vers quel canal.
Le calendrier réel, à retenir
Ce qui distingue les éditeurs prêts des autres au 11 septembre ne sera pas la maturité de leur processus de sécurité. Ce sera une chose banale : savoir qui décroche, à quelle adresse, et où se trouve le texte à envoyer. Les trois quarts du travail exigible en septembre tiennent dans un document partagé et deux comptes créés à l’avance.
Cet article décrit l’état du droit et des outils au 1er septembre 2026. Il ne constitue pas un avis juridique : la qualification de votre entreprise et la classification de votre produit méritent une validation par un conseil spécialisé.
Et si le signalement tombait ce mois-ci ?
Les vingt-quatre heures de l’article 14 commencent quand vous avez connaissance de l’exploitation, pas quand vous êtes prêt. NeoOne Expert outille la part qui se prépare à l’avance : la détection sur le parc, la remontée d’alerte, et la trace horodatée de ce qui a été vu et quand. C’est du support opérationnel à la conformité, à savoir détection, reporting et supervision. Ce n’est pas une garantie de conformité juridique : la qualification de votre entreprise et la classification de votre produit relèvent de vous et de votre conseil.
Si vous êtes prestataire IT et que vos clients éditent du logiciel, la question vous revient par ricochet : ce sont vos alertes qui déclenchent leur compte à rebours. Le programme partenaire NeoOne Expert couvre cette chaîne de détection et de remontée pour votre parc.
Si vous voulez confronter votre circuit de signalement au nôtre avant le 11 septembre, écrivez-nous. L’échange dure trente minutes et repart avec votre liste de trous, pas avec un devis.
Sources
- Règlement (UE) 2024/2847, articles 14, 16, 18 et 21, et Annexes I à VIII
- Commission européenne, obligations de signalement CRA
- ENISA, Single Reporting Platform
- ANSSI, Cyber Resilience Act