Aller au contenu
FortaRisks
Retour au blogConformité

Cyber Resilience Act : depuis ce matin, vous avez 24 heures pour déclarer une faille exploitée

11 septembre 2026 · 10 min de lecture

Depuis ce matin, un fabricant qui vend un produit numérique sur le marché européen et qui apprend qu'une de ses vulnérabilités est activement exploitée dispose de vingt-quatre heures pour le déclarer. Pas pour corriger, pas pour comprendre : pour déclarer.

C'est l'article 14 du Cyber Resilience Act, le règlement (EU) 2024/2847, entré en vigueur le 10 décembre 2024 et dont les obligations de signalement s'appliquent à compter du 11 septembre 2026. Le reste du texte, les exigences essentielles de sécurité, le marquage CE, la déclaration de conformité, attendra le 11 décembre 2027. Mais la partie qui se mesure en heures, elle, commence aujourd'hui.

La plupart des commentaires publiés cette année traitaient le CRA comme un sujet de conformité produit, à préparer pour 2027. Ce cadrage vient de tomber. Ce qui entre en application aujourd'hui n'est pas une exigence de documentation, c'est une procédure de réponse à incident avec un chronomètre dessus.

Ce qui s'applique exactement, et à quel rythme

Deux événements sont déclencheurs : une vulnérabilité activement exploitée dans un produit comportant des éléments numériques, et un incident grave ayant un impact sur la sécurité de ce produit.

Une vulnérabilité est réputée activement exploitée lorsqu'il existe une preuve fiable qu'un acteur malveillant l'a exploitée dans un système sans la permission du propriétaire de ce système. La barre n'est pas la publication d'un code d'exploitation, ni une mention sur un forum : c'est une preuve d'exploitation réelle.

Un incident est grave lorsqu'il affecte, ou est susceptible d'affecter, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données sensibles, ou lorsqu'il a conduit, ou est susceptible de conduire, à l'introduction ou à l'exécution de code malveillant.

Le calendrier de déclaration est en trois temps, et il est le même pour les deux.

Vingt-quatre heures : l'alerte précoce. Sans retard injustifié après avoir eu connaissance du fait, et en tout état de cause dans les vingt-quatre heures. L'alerte indique notamment les États membres où le produit est disponible. À ce stade, personne n'attend une analyse : on attend un signalement.

Soixante-douze heures : la notification. Les informations générales disponibles sur le produit, la nature générale de l'exploitation et de la vulnérabilité, ainsi que toute mesure corrective ou d'atténuation prise ou disponible.

Quatorze jours ou un mois : le rapport final. Quatorze jours après la mise à disposition d'une mesure corrective pour une vulnérabilité exploitée, avec la description de la faille, sa sévérité, son impact et, le cas échéant, les informations sur l'acteur malveillant. Un mois après la notification des 72 heures pour un incident grave.

Le destinataire est le CSIRT désigné comme coordinateur dans l'État membre où le fabricant a son établissement principal, c'est-à-dire là où les décisions relatives à la cybersécurité de ses produits sont principalement prises. L'information est transmise simultanément à l'ENISA. Le passage se fait par une plateforme unique, la Single Reporting Platform opérée par l'ENISA, opérationnelle depuis aujourd'hui : on déclare une fois, et la diffusion aux autorités concernées est prise en charge. L'accès suppose un compte EU LOGIN et l'enregistrement préalable d'un représentant désigné. Ce n'est pas le genre de formalité qu'on règle pendant les vingt-quatre heures qui comptent.

S'y ajoute une obligation qu'on oublie de citer et qui sera pourtant la plus visible : le fabricant doit informer les utilisateurs concernés de la vulnérabilité ou de l'incident et, le cas échéant, des mesures d'atténuation et de correction qu'ils peuvent appliquer.

La clause de transition que peu de gens ont lue

C'est ici que le sujet cesse d'être théorique pour beaucoup d'organisations.

Le régime transitoire prévoit que les produits mis sur le marché avant le 11 décembre 2027 ne sont soumis aux exigences du règlement que s'ils font l'objet d'une modification substantielle après cette date. Logique, et rassurant pour un catalogue existant.

Sauf que l'article 69, paragraphe 3, écarte cette exception pour le seul article 14 : les obligations de signalement s'appliquent à tous les produits comportant des éléments numériques mis sur le marché avant le 11 décembre 2027.

Autrement dit, la documentation technique, le marquage CE et la déclaration de conformité ne concerneront que ce que vous mettrez sur le marché à partir de décembre 2027. Le chronomètre de vingt-quatre heures, lui, couvre dès aujourd'hui ce que vous avez vendu en 2015, en 2020 et le mois dernier, tant que le produit est encore sur le marché. Un fabricant qui a bâti son plan CRA autour de sa prochaine gamme découvre ce matin que son parc installé était le sujet.

Êtes-vous concerné, depuis le Canada ?

Le règlement est délimité par le marché, pas par la géographie. Un fabricant établi hors de l'Union qui place un produit comportant des éléments numériques sur le marché européen est soumis à l'article 14 dans les mêmes termes qu'un fabricant allemand ou français.

La définition du produit est volontairement large : tout produit matériel ou logiciel capable de se connecter, directement ou indirectement, à un appareil ou à un réseau. Cela couvre un logiciel d'entreprise vendu en licence, une application mobile, un équipement industriel connecté, un produit électronique grand public, un composant réseau. Pour l'écosystème que nous servons au Québec et en Ontario, manufacturiers, énergie, logistique, éditeurs de logiciels B2B, cela signifie trois familles d'organisations concernées.

Vous vendez un logiciel ou un service sous licence à des clients européens. Vous fabriquez un équipement connecté qui part à l'export vers l'Union. Ou vous êtes un sous-traitant dont le composant est intégré dans un produit qui, lui, est mis sur le marché européen, auquel cas la question à trancher avec votre donneur d'ordre est de savoir qui, contractuellement, est le fabricant au sens du règlement et qui déclare.

Le niveau de sanction dit assez ce que le législateur en pense. Le manquement à l'article 14 relève du plafond le plus élevé prévu par le règlement, à l'article 64 : jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. C'est le même plafond que pour un manquement aux exigences essentielles de sécurité. Le régulateur européen place donc le fait de ne pas déclarer au même niveau de gravité que le fait de vendre un produit non sécurisé.

Pourquoi vingt-quatre heures est un problème d'exploitation, pas de juridique

Comparez les horloges. Le RGPD accorde 72 heures pour notifier une violation de données. La Loi 25 demande un avis dans les meilleurs délais en cas de risque de préjudice sérieux. NIS2 impose une alerte précoce en 24 heures, mais à des entités essentielles et importantes, sur leurs propres incidents.

Le CRA vous demande vingt-quatre heures sur un événement qui ne se produit pas chez vous, mais chez vos clients, sur un produit que vous avez vendu. Trois difficultés opérationnelles en découlent, et aucune ne se règle par une clause de contrat.

Détecter. Comment apprenez-vous qu'une faille de votre produit est exploitée chez un client ? Par un chercheur, par une inscription au catalogue KEV de la CISA, par un client qui appelle votre support, par un article de presse. Si ces quatre canaux n'aboutissent pas au même endroit, votre délai de vingt-quatre heures commence à courir sans que personne ne le sache.

Qualifier. La preuve fiable d'exploitation est un jugement, et il doit être rendu vite. Les faits de cette semaine montrent à quel point c'est inconfortable : nous relevions vendredi qu'un éditeur avait écrit à ses clients que sa faille était exploitée, tandis que ses propres notes de version parlaient d'une divulgation responsable sans exploitation confirmée. Deux affirmations, un jour d'écart, le même éditeur. Sous le CRA, cet écart n'est plus une maladresse de communication : c'est le point de départ d'un délai réglementaire, et il devra être justifié.

Déclarer. Le compteur court sur des jours calendaires. Le vendredi soir et le long week-end de la fête du Travail comptent comme le mardi matin. Une procédure qui repose sur une seule personne joignable aux heures de bureau ne tient pas vingt-quatre heures.

Ce que cela demande n'est pas un dossier de conformité. C'est un responsable nommé, une astreinte, un canal unique où convergent les quatre sources de signalement, un critère écrit de qualification, et un compte de déclaration créé et testé à l'avance.

L'autre moitié du sujet : vous êtes aussi acheteur

La lecture fabricant est celle qui inquiète. La lecture acheteur est celle qui rapporte, et presque personne ne la fait.

L'obligation d'informer les utilisateurs concernés signifie que vos fournisseurs de logiciels et d'équipements présents sur le marché européen vous doivent désormais une information, en connaissance de cause, quand un de leurs produits que vous utilisez est activement exploité. Pour une organisation canadienne qui achète des produits également vendus en Europe, et c'est le cas de l'essentiel des outils de votre parc, une transparence qu'aucun contrat ne vous garantissait devient une obligation réglementaire pesant sur le fournisseur.

Trois choses en découlent pour votre gestion du risque tiers, à faire avant votre prochaine campagne d'évaluation.

Ajoutez la question au questionnaire : vos produits sont-ils mis sur le marché de l'Union européenne, et à ce titre êtes-vous soumis aux obligations de signalement de l'article 14 du CRA ? Une réponse affirmative vous donne une base pour exiger la même information, dans les mêmes délais.

Alignez votre clause de notification sur ce nouveau plancher. Beaucoup de contrats prévoient une notification d'incident sous 72 heures. Un fournisseur soumis au CRA produira une alerte en 24 heures pour l'autorité européenne : il n'y a pas de raison que son client canadien l'apprenne trois jours plus tard, ni par la presse.

Et vérifiez que l'information arrivera quelque part. Une notification de fournisseur qui atterrit dans la boîte générique d'un service achats ne déclenche rien. C'est le même angle mort que celui décrit dans notre article sur les onze vulnérabilités tierces qu'aucun questionnaire ne voit : l'information existe, elle n'atteint pas la personne qui décide.

Cinq choses à faire cette semaine

  1. Tranchez si vous êtes fabricant au sens du règlement. Listez les produits et logiciels que vous placez sur le marché européen, directement ou par un intégrateur. Pour chacun, nommez qui est le fabricant au sens du CRA. Si la réponse est incertaine sur un composant intégré, c'est une question à poser au donneur d'ordre cette semaine, pas en 2027.
  2. Si vous l'êtes, ouvrez le compte maintenant. Identifiez votre CSIRT coordinateur, créez le compte EU LOGIN, enregistrez le représentant désigné sur la Single Reporting Platform. Faites-le à froid.
  3. Écrivez le critère de qualification. Une demi-page : ce qui constitue pour vous une preuve fiable d'exploitation active, qui la constate, qui décide de déclarer, et quel est le comportement par défaut en cas de doute. Le doute doit pencher vers la déclaration.
  4. Faites converger les quatre canaux. Support client, boîte de divulgation de vulnérabilités, veille sur les catalogues d'exploitation active, presse. Un seul point d'arrivée, une astreinte qui couvre les fins de semaine.
  5. Côté acheteur, ajoutez la question CRA à votre registre de fournisseurs et alignez vos clauses de notification. C'est le gain le plus rapide de toute cette affaire, et il ne dépend de personne d'autre que vous.

Si vous ne savez pas aujourd'hui quels de vos fournisseurs sont soumis à cette obligation, ni où arriverait leur notification, notre questionnaire de sécurité fournisseur gratuit contient déjà les sections sous-traitants et notification d'incident où cette question vient se greffer. Et pour relier une faille inscrite au catalogue d'exploitation active à ce que vous exposez réellement, c'est le travail des modules surface d'attaque et risque tiers de la plateforme.

Un dernier mot sur le calendrier. Le CRA rejoint une série que nous suivons depuis un an : NIS2 et DORA en Europe, le projet de loi C-8 et le PCCC au Canada. Le mouvement est le même partout : le délai de réaction devient une obligation chiffrée, et la responsabilité est nommée. Un fabricant canadien qui saura déclarer en vingt-quatre heures à Bruxelles saura le faire à Ottawa.

Sources : Règlement (UE) 2024/2847, texte de l'article 14 · Commission européenne, obligations de signalement du CRA · Commission européenne, synthèse du règlement · Texte de l'article 69, régime transitoire · Freshfields, entrée en application au 11 septembre 2026 · The National Law Review, point de départ des obligations de signalement

30 minutes pour savoir quoi corriger en premier.

Un membre de notre équipe vous guide dans FortaRisks sur des menaces pertinentes pour votre secteur, et vous repartez avec vos priorités. Sans chatbot.