CRA impose aux fabricants de déclarer sous 24 heures

Le 11 septembre 2026, l’article 14 du Cyber Resilience Act entrera en vigueur. À partir de cette date, les fabricants devront signaler les vulnérabilités exploitées activement et les incidents de sécurité graves dans des délais stricts. Pour les DSI et les CDO, l’information clé réside dans l’approvisionnement : l’obligation de signalement incombe au fabricant. Les entreprises qui s’approvisionnent auprès de fabricants dont les processus ne sont pas encore opérationnels recevront trop tard, voire pas du tout, l’information concernant une vulnérabilité exploitée activement dans leur propre infrastructure.

Articles associésPourquoi la facture cloud ne diminue jamais  /  Règlement sur l’IA : jusqu’à 3 % du chiffre d’affaires du groupe

Quatre semaines avant l’article 14 : la situation pour les achats

Le Cyber Resilience Act est entré en vigueur le 10 décembre 2024. Les principales obligations prendront effet le 11 décembre 2027. Entre ces deux dates se situe le jalon qui préoccupe désormais les entreprises : l’article 14 entrera en vigueur le 11 septembre 2026. Dans les grandes organisations, les DSI, les CDO et les stratèges IT gèrent les budgets, les relations fournisseurs et les décisions architecturales. C’est précisément là que se situe l’impact de l’obligation de signalement, même si l’organisation elle-même n’est généralement pas soumise à cette obligation.

Qu’est-ce que le Cyber Resilience Act ? Le Cyber Resilience Act est un cadre juridique européen pour la cybersécurité des produits dotés d’éléments numériques. Il impose aux fabricants des exigences de sécurité tout au long du cycle de vie des produits, ainsi que des obligations de signalement en cas de vulnérabilités exploitées activement ou d’incidents de sécurité graves. Le CRA est entré en vigueur le 10 décembre 2024. L’article 14 s’appliquera à partir du 11 septembre 2026, et les principales obligations prendront effet le 11 décembre 2027.

Pour le DSI, l’attribution des obligations constitue le message central. L’obligation de signalement incombe au fabricant. L’exploitant achète des produits qui fonctionnent dans les réseaux, les systèmes de contrôle et les applications métiers. Si le fabricant ne maîtrise pas ses voies de signalement et d’information, l’entreprise ne sera pas informée à temps d’une vulnérabilité exploitée activement dans son propre système. La perspective d’action réside donc dans les contrats, les entretiens avec les fournisseurs et la gestion de la chaîne d’approvisionnement.

Qui déclare, à qui et pour quoi le fabricant est responsable

Les fabricants doivent déclarer simultanément au CSIRT coordinateur et à l’ENISA. Une plateforme commune de déclaration est prévue à cet effet. Les détails techniques de cette plateforme ne sont pas encore publics. Pour l’exploitation, c’est la procédure dans la relation de livraison qui compte : le fabricant reste le destinataire de l’obligation de déclaration et l’interlocuteur pour l’acheteur.

La responsabilité ne s’arrête pas à la nomenclature du fabricant. Celui-ci reste responsable de l’ensemble du composant, même s’il achète des pièces. Les délais de 24 et 72 heures s’appliquent au fabricant. Ils ne s’appliquent pas automatiquement à chaque fournisseur de la chaîne. Si vous êtes DSI et gérez une chaîne d’approvisionnement à plusieurs niveaux, vous devez donc clarifier comment les informations parviennent du sous-traitant au fabricant, puis du fabricant à votre entreprise.

L’arrêt du support ne modifie que partiellement l’attribution des responsabilités. En cas d’arrêt du support d’un composant, le fabricant reste responsable de la correction des vulnérabilités pendant au moins cinq ans. Pour les architectures à longue durée de vie, cela signifie : un produit qui sort du support actif ne sort pas pour autant de la responsabilité de sécurité du fabricant. Dans les décisions d’achat, cette fenêtre temporelle doit être intégrée à l’évaluation du cycle de vie du produit et de la stratégie de remplacement.

Délais, contenus des déclarations et sanctions

L’article 14 distingue deux cas : les vulnérabilités activement exploitées et les incidents de sécurité graves. Les deux procédures commencent par une alerte précoce dans les 24 heures. Les délais s’adressent au fabricant. Pour l’exploitant, ces heures ne constituent pas une obligation légale de déclaration au titre de l’article 14. Elles marquent néanmoins la rapidité avec laquelle les informations doivent circuler dans l’environnement du fabricant si votre propre parc est concerné.

En cas de vulnérabilités activement exploitées, des informations complémentaires doivent être fournies dans les 72 heures, et un rapport final dans les 14 jours suivant la disponibilité d’une mesure corrective. En cas d’incidents de sécurité graves, la déclaration de l’incident doit intervenir dans les 72 heures, et le rapport final dans le mois qui suit la déclaration de l’incident. Si vous êtes DSI et discutez avec des fabricants des processus liés aux incidents et aux vulnérabilités, ces étapes constituent une base de discussion : quand le client est-il informé de l’alerte précoce, de la déclaration suivante, de la mesure corrective ?

Le Règlement sur la cybersécurité prévoit des amendes pouvant aller jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial. La sanction vise le destinataire des obligations, c’est-à-dire le fabricant dans la logique de déclaration de l’article 14. Pour le DSI acheteur, le montant de l’amende modifie le rapport de force : un fabricant aux processus flous représente un risque réglementaire qui se traduit dans la relation d’approvisionnement par un risque de défaillance, de retard et d’information. Les prévisions concernant la pratique de contrôle des autorités ne doivent pas être intégrées dans la planification, car elles ne sont pas étayées. En revanche, les délais, les destinataires et le cadre des sanctions sont bien documentés.

Ce qu’il faut désormais inclure dans les contrats et les échanges avec les fournisseurs

Une simple déclaration générale de conformité à la loi ne suffit pas. Les contrats avec les fournisseurs doivent intégrer des preuves, des voies de signalement, des mises à jour et une date de fin de support définie. Ces exigences sont documentées. Il n’existe pas de modèles officiels de clauses contractuelles précises. Les services Achats, Juridique et Sécurité doivent transposer ces exigences dans leur propre langage contractuel et les appliquer aux relations existantes avec les fournisseurs.

Les preuves permettent de vérifier si le fabricant maîtrise effectivement les processus pertinents pour le CRA. Les voies de signalement clarifient comment l’exploitation active d’une faille est détectée par l’exploitant et qui, en interne, reçoit l’information. Les mises à jour précisent comment les mesures correctives sont fournies et documentées. Une date de fin de support définie indique à partir de quand le support actif prend fin et comment la responsabilité de la correction des failles, pendant au moins cinq ans après la fin du support, est intégrée dans la relation contractuelle.

Lors des échanges avec les fournisseurs, un cadre d’évaluation simple est utile. Qui, au sein de l’entreprise fabricante, est responsable du signalement au CSIRT coordinateur et à l’ENISA ? Comment l’information parvient-elle en parallèle au canal client ? Quels sous-traitants interviennent dans le composant global dont le fabricant reste responsable ? Quelle est la durée du support et comment l’obligation de correction est-elle organisée ensuite ? Ces questions restent dans le cadre des exigences documentées et évitent les spéculations sur les pratiques administratives ou les coûts de mise en œuvre.

Les décisions architecturales dépendent des mêmes points. Les produits dont la date de fin de support est floue, les chemins de mise à jour peu clairs ou les voies de signalement absentes augmentent le risque opérationnel. L’article 14 oblige le fabricant à signaler les failles activement exploitées et les incidents graves au CSIRT coordinateur et à l’ENISA. Les utilisateurs concernés doivent être informés en parallèle. La fin du support et les chemins de mise à jour relèvent d’autres aspects du CRA. Le DSI gère le risque via le choix des solutions, la conception des contrats et les voies d’escalade, même si l’obligation légale de signalement incombe au fabricant.

Le point de vue opposé : le fardeau pesant sur les petits et moyens fabricants

La DIHK met en garde contre les charges importantes que l’application du CRA impose aux petites et moyennes entreprises. De nombreux petits fabricants ignorent si le CRA s’applique à eux. Certains envisagent de retirer leurs produits du marché. Pour le DSI, il ne s’agit pas d’un simple rapport sur la situation des PME. C’est un problème d’approvisionnement dès qu’un fournisseur de niche se retire ou ajuste son portefeuille.

Dans les grandes organisations, on trouve souvent des composants spécialisés : modules de commande, capteurs, logiciels sectoriels, systèmes embarqués. Si un petit fabricant estime que les obligations du CRA sont trop lourdes et décide d’arrêter un produit, cela entraîne un manque de solutions de remplacement, de savoir-faire et de chemins de migration. La perspective d’action consiste à identifier tôt les fournisseurs de niche critiques, à évaluer leur capacité à respecter le CRA et à préparer des alternatives ou des stratégies de transition.

Ce point de vue opposé doit donc figurer dans chaque échange avec des fournisseurs plus petits. La question est de savoir si le fabricant pourra assumer les processus de signalement et de sécurité d’ici au 11 septembre 2026, ainsi que les principales obligations à partir du 11 décembre 2027. Si la réponse reste floue, le risque de retrait du produit augmente. L’exploitant en subira alors les conséquences sur l’architecture et la continuité opérationnelle, même s’il n’est pas lui-même soumis à l’obligation de signalement.

Alignement sur la directive BSI TR-03183 et prochaines étapes

La directive technique BSI TR-03183 regroupe les exigences en trois parties : exigences générales, liste des composants logiciels et signalements de vulnérabilités. Les parties 1 et 3 sont disponibles en version 1.0.0. La partie 2 est disponible en version 2.1.0. La première phase de commentaires s’est achevée le 30 novembre 2024. Depuis, le BSI considère la partie 1 comme un document vivant, tandis que la partie 3 est parue en septembre 2025. Les versions 0.9.0 et 2.0.0 ne sont plus disponibles que dans les archives.

Pour les DSI et les stratèges IT, cette directive constitue un cadre de référence lors des échanges avec les fabricants livrant des produits intégrant des éléments numériques. Les exigences générales, la liste des composants logiciels et les signalements de vulnérabilités forment les thèmes sur lesquels s’appuient les preuves et les processus. Connaître les versions permet d’éviter les attentes erronées : les trois parties sont validées, la partie 1 étant régulièrement mise à jour en tant que document vivant.

Les prochaines semaines, jusqu’au 11 septembre 2026, sont idéales pour organiser une tournée ciblée auprès des fournisseurs. Privilégiez les produits à haute criticité opérationnelle et à longue durée de vie. Exigez des preuves, des voies de signalement, des engagements de mises à jour et une date de fin de support définie. Clarifiez les rôles dans la chaîne, car les délais de 24 et 72 heures concernent le fabricant, qui reste responsable de l’ensemble du composant. Surveillez les petits fournisseurs pour détecter d’éventuels signes de retrait de produits du marché. Ainsi, vous maîtriserez les risques avant l’application de l’article 14 et avant que les principales obligations n’entrent en vigueur à partir du 11 décembre 2027.

Foire aux questions

Plus du réseau MBF Media

Source de l’image : Générée par IA (août 2026)