Cybersécurité pour les fabricants de machines

À partir de 2027, une machine dotée d'un contrôleur, d'un écran opérateur ou d'une connexion de données relève de deux règlements européens. Tous deux partent de la même question : quels logiciels se trouvent sur cette machine, version par version, et que contiennent-ils ?

1. 11 septembre 2026Les obligations de signalement du Cyber Resilience Act pour les vulnérabilités activement exploitées et les incidents graves s'appliquent.
2. 20 janvier 2027Le règlement relatif aux machines, (UE) 2023/1230, s'applique et remplace la directive relative aux machines.
3. 11 décembre 2027Le Cyber Resilience Act, (UE) 2024/2847, s'applique intégralement.

Règlement relatif aux machines

Deux exigences essentielles de santé et de sécurité de l'annexe III portent sur la cybersécurité :

• 1.1.9, protection contre la corruption. La connexion d'un autre dispositif à la machine, directement ou à distance, ne doit pas entraîner de situation dangereuse. Les logiciels et les données essentiels à la conformité de la machine aux exigences essentielles de santé et de sécurité doivent être identifiés et protégés contre toute corruption accidentelle ou intentionnelle. La machine doit identifier les logiciels installés dont elle a besoin pour fonctionner en toute sécurité, et fournir cette information à tout moment. Elle doit aussi recueillir des preuves des interventions légitimes ou illégitimes sur ces logiciels ou sur leur configuration.
• 1.2.1, sécurité et fiabilité des systèmes de commande. Les systèmes de commande doivent résister aux tentatives malveillantes raisonnablement prévisibles de tiers qui conduisent à une situation dangereuse. Au titre du point 1.2.1(f), ils doivent tenir un journal de traçabilité des interventions et des versions des logiciels de sécurité chargées après la mise sur le marché de la machine, pendant cinq ans après le chargement.

Cyber Resilience Act

Une machine dotée d'une connexion de données, ou une partie de celle-ci vendue séparément, est un produit comportant des éléments numériques. Le fabricant doit faire preuve de diligence raisonnable à l'égard des composants tiers qu'il intègre, établir une SBOM couvrant au moins les dépendances de premier niveau, traiter les vulnérabilités pendant la période d'assistance, qui est d'au moins cinq ans sauf si le produit est censé être utilisé moins longtemps, et conserver la documentation technique pendant au moins dix ans ou pendant la période d'assistance, la durée la plus longue étant retenue.

Pas automatiquement. Le Cyber Resilience Act ne confère aucune présomption de conformité au règlement relatif aux machines. Son considérant 53 indique que le respect des exigences essentielles du CRA pourrait faciliter la conformité aux exigences du règlement relatif aux machines en matière de protection contre la corruption et de sécurité et fiabilité des systèmes de commande. Il précise aussi que le fabricant doit le démontrer, par exemple en appliquant des normes harmonisées après une évaluation des risques, et que les procédures d'évaluation de la conformité des deux règlements continuent de s'appliquer.

La norme harmonisée en préparation pour le point 1.1.9 est l'EN 50742, Safety of machinery – Protection against corruption. En novembre 2026, elle en était au projet final, FprEN 50742, qui couvre le point 1.1.9 et les points associés du 1.2.1 ; tant que la référence d'une version définitive n'est pas publiée au Journal officiel de l'UE, elle ne confère aucune présomption de conformité. Elle associe l'appréciation du risque de l'EN ISO 12100 aux concepts de sécurité de l'IEC 62443, et reconnaît l'application cohérente de l'IEC 62443-4-1, de l'IEC 62443-3-3 et de l'IEC 62443-4-2 comme une voie équivalente pour atteindre ses objectifs de protection. L'IEC 62443-4-2 fixe les exigences techniques de sécurité des composants de systèmes de commande, graduées par niveau de capacité de sécurité. En Allemagne, les principes d'essai GS-IFA-M25 de juillet 2026 traduisent la protection contre la corruption en 66 critères d'essai, avec la terminologie du prEN 50742. L'un d'eux, T46, demande que le produit puisse fournir sur demande la version et la configuration du logiciel installé. Pour y répondre pour chaque configuration, il faut un enregistrement de ce que contient chaque version du logiciel.

Le règlement relatif aux machines prévoit sa propre présomption, qui passe par une autre voie : les schémas européens de certification de cybersécurité adoptés au titre du règlement sur la cybersécurité, le règlement (UE) 2019/881. Un certificat ou une déclaration de conformité délivrés dans le cadre d'un tel schéma emportent présomption de conformité aux points 1.1.9 et 1.2.1, dans la mesure où ils couvrent ces exigences.

Une seule évaluation des risques et un seul ensemble de preuves peuvent donc servir aux deux règlements, mais vous démontrez la conformité à chacun d'eux. Si votre machine dispose d'une connexion de données, prévoyez les deux. Les preuves logicielles, c'est-à-dire les SBOM, les enregistrements de vulnérabilités et l'historique des mises à jour, sont la partie qu'ils ont en commun.

En janvier 2026, des associations du secteur des machines ont demandé le report des points 1.1.9 et 1.2.1(f), puis en mars 2026 leur application à partir de la date du CRA, le 11 décembre 2027. Il s'agit d'une demande, pas d'un texte de loi : en novembre 2026, aucun report n'avait été adopté. Les dates de cette page sont celles des règlements.

• Les machines de construction, de manutention, d'exploitation minière et industrielles relèvent du règlement relatif aux machines, et aussi du CRA lorsque la machine ou ses parties disposent d'une connexion de données.
• Les tracteurs agricoles et forestiers couverts par le règlement (UE) n° 167/2013 sont exclus du règlement relatif aux machines, à l'exception des machines montées sur ces véhicules. La liste des exclusions du CRA ne mentionne pas ce règlement : un tracteur connecté peut donc entrer dans le champ du CRA.
• Les véhicules routiers réceptionnés par type au titre du règlement (UE) 2019/2144 sont exclus du CRA.
• Les composants vendus séparément. Le CRA s'applique aussi aux composants logiciels et matériels mis sur le marché séparément. Un fournisseur qui vend un ECU ou une unité télématique seul est lui-même un fabricant au sens du CRA. Lorsque l'unité est seulement intégrée dans la machine, le fabricant de la machine porte l'obligation pour l'ensemble de la machine et doit faire preuve de diligence raisonnable à l'égard du composant du fournisseur.

Ces informations sont générales et ne constituent pas un avis juridique. Vérifiez la classification de votre propre produit.

Au sein d'une même machine, les logiciels proviennent de sources différentes, et seule l'équipe qui construit un logiciel peut dire de façon fiable ce qu'il contient. D'après ce que nous disent les fabricants de machines, les ECU bare-metal contiennent peu d'open source, tandis que les logiciels Linux, Android et Windows en contiennent beaucoup.

Faibles volumes, grande diversité. Un fabricant de machines peut avoir des centaines de plateformes sur le marché, n'en vendre que quelques unités par an et configurer de nombreuses machines à la commande. Chaque configuration est un ensemble de logiciels différent : une SBOM pour chaque build compte donc davantage qu'une SBOM pour chaque gamme de produits.

De longues durées de vie. Les machines restent en service une décennie ou plus, tandis que les fournisseurs changent ou disparaissent. L'enregistrement de ce qui est entré dans une version logicielle doit être fait au moment du build, car il ne peut pas être reconstitué des années plus tard.

Les logiciels des fournisseurs dominent, et leurs SBOM sont souvent médiocres. On nous parle de SBOM de fournisseurs auxquelles il manque des composants, sans package URL ni CPE, sans licences ni hashes, certaines rédigées à la main et qui échouent à la validation du schéma. L'analyse binaire d'un ECU flashé est une solution d'appoint : elle devine le contenu au lieu de l'enregistrer.

Le risque se situe dans les couches connectées. Une grande partie de la logique des ECU est générée à partir de modèles et contient peu d'open source. L'open source et l'exposition au réseau se concentrent dans les couches Linux, connectivité et applications : concentrez-y vos efforts en premier.

Un exemple illustratif : la pile logicielle d'une plateforme fictive de chargeuse sur pneus, du cloud jusqu'aux ECU.

1. Back-end cloud et application compagnonInterne. Principalement open source et exposé au réseau. Cyber Resilience Act.
2. Passerelle télématiqueLinux embarqué, principalement open source, connectée au réseau mobile. Cyber Resilience Act, et 1.1.9 pour la connexion à distance.
3. Écran opérateurImage Linux embarqué avec un framework d'interface, principalement open source, connectée au bus de la machine et aux outils de maintenance. Cyber Resilience Act et 1.1.9.
4. Contrôleur de la machineApplication interne sur une plateforme fournisseur, pertinente pour la sécurité. 1.1.9 et 1.2.1, et le Cyber Resilience Act lorsqu'il est accessible via une connexion.
5. ECU hydrauliques, de direction et moteurFirmware fournisseur, propriétaire et généré à partir de modèles, peu d'open source, pertinent pour la sécurité. 1.1.9 et 1.2.1 ; le Cyber Resilience Act par l'intermédiaire de la machine.

L'open source et l'exposition au réseau se situent dans les trois couches supérieures, qui sont aussi celles où se trouvent généralement vos propres pipelines de build. Commencez par là.

Les fabricants de machines fixent désormais des exigences de SBOM pour les logiciels qu'ils achètent, comme des package URL ou des CPE, des licences, des hashes et un format qui passe la validation, et renvoient les fichiers non conformes. Si vous construisez sur GitHub Actions, CRACI produit la SBOM à partir du build lui-même : elle liste ce qui est réellement entré dans la release, y compris les composants qu'aucun lockfile ne nomme, avec une package URL et la licence déclarée de chaque composant. Vérifiez l'export par rapport à la liste complète des champs demandés par votre client. En savoir plus sur la réponse aux demandes de SBOM des clients.