Cyber Resilience Act : ce que l’obligation de signalement impose aux éditeurs de logiciel

Le Cyber Resilience Act est entré dans sa première phase le 11 septembre 2026. Depuis, tout éditeur de logiciel doit signaler sous 24 heures les vulnérabilités activement exploitées dans ses produits, et la plateforme de l’ENISA qui reçoit ces signalements tourne. L’échéance est passée, l’obligation est là, et beaucoup d’éditeurs n’ont toujours pas de circuit prêt pour le premier incident. Seul le signalement est exigible aujourd’hui, le reste attend décembre 2027. Voici ce qui s’applique, qui est concerné, y compris le prestataire IT qui revend un outil sous sa marque, et ce qu’il faut avoir en place avant d’en avoir besoin.

Qu’est-ce qui est obligatoire depuis 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 exigible qu’en décembre 2027 ?

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 tout de suite un processus complet de gestion des vulnérabilités. 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 lancer le jour de l’incident.

Où déclare-t-on une vulnérabilité exploitée ?

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.

La plateforme est en service depuis le 11 septembre 2026, à l’adresse portal.cra-srp.enisa.europa.eu. L’accès se fait par EU Login avec double authentification. Au lancement, les formulaires sont en anglais et aucune interface programmatique n’est proposée.

Une plateforme jeune ne repousse rien. Les 24 heures courent à partir de votre prise de connaissance, pas à partir du moment où vous maîtrisez l’outil. Mieux vaut créer son compte et parcourir les formulaires avant d’en avoir besoin.

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, et l’ENISA conseille de ne la lancer qu’au moment de notifier. Gardez simplement le plafond en tête si un même produit enchaîne les incidents.
• 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 mettre en place pour être prêt à signaler ?

Cinq actions, à boucler avant d’avoir un premier incident à déclarer.

1. 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.
2. 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.
3. 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.
4. É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.
5. 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 le signalement, mais avec des conséquences réelles sur la procédure d’évaluation applicable en décembre 2027.

Et pour un MSP infogéreur qui revend un outil sous sa marque ?

Un MSP (Managed Service Provider) infogéreur qui installe chez ses clients des outils signés par leur éditeur n’est pas fabricant : c’est l’éditeur qui signale. La situation change dès que l’outil porte votre nom. L’article 21 traite comme fabricant le distributeur qui commercialise un produit tiers sous sa propre marque, et lui transfère l’obligation de signalement, alors que vous n’avez pas la main sur le code.

Si vous revendez une plateforme en marque blanche, trois questions méritent une réponse écrite avant le premier incident. Votre offre vous fait-elle fabricant, au vu de ce que voit réellement le client final ? Ce point se tranche avec votre conseil. Sous quel délai l’éditeur vous transmet-il une vulnérabilité activement exploitée, sachant que vos 24 heures courent dès que vous en avez connaissance ? Et qui, de lui ou de vous, dépose le signalement ? Nous détaillons ce que la marque blanche engage dans notre guide de la plateforme MSP infogérance française.

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. 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 n’est pas la maturité de leur processus de sécurité. C’est une chose banale : savoir qui décroche, à quelle adresse, et où se trouve le texte à envoyer. Les trois quarts du travail exigible aujourd’hui tiennent dans un document partagé et deux comptes créés à l’avance.

Article publié le 1er septembre 2026, dernière mise à jour le 19 octobre 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 demain ?

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, é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