Règlement machines et cybersécurité : les exigences 1.1.9 et 1.2.1 expliquées

Le règlement machines (UE) 2023/1230 introduit des exigences de cybersécurité : c’est le premier texte machines qui parle d’attaques malveillantes. À partir du 20 janvier 2027, une machine dont les logiciels, les paramètres ou les interfaces peuvent être corrompus au point de la rendre dangereuse doit être protégée, et le fabricant doit le démontrer. Voici ce que disent exactement les exigences 1.1.9 et 1.2.1 de l’annexe III, comment les traduire en mesures et en preuves, et comment elles s’articulent avec le Cyber Resilience Act. État au 2 novembre 2026.

Que demande le règlement machines en matière de cybersécurité ?

Le règlement (UE) 2023/1230 demande que la machine ne devienne pas dangereuse à cause d’une connexion, d’une manipulation de ses logiciels ou d’une attaque. Ces exigences tiennent dans deux points de l’annexe III, complétés par un troisième sur la perte de connexion.

Exigence	Ce que le texte impose	Référence
Connexion sans danger	Le raccordement d’un autre dispositif, y compris d’un dispositif distant, ne crée pas de situation dangereuse.	Annexe III, 1.1.9, al. 1
Matériel de communication protégé	Le composant qui transmet signaux ou données vers un logiciel essentiel à la sécurité est protégé contre la corruption accidentelle ou intentionnelle ; la machine garde la preuve des interventions sur ce composant.	1.1.9, al. 2
Logiciels et données essentiels	Ils sont identifiés comme tels et protégés contre la corruption accidentelle ou intentionnelle.	1.1.9, al. 3
Identification des logiciels	La machine identifie les logiciels installés dont elle a besoin pour fonctionner en sécurité et fournit cette information à tout moment.	1.1.9, al. 4
Preuve des interventions	La machine recueille la preuve de toute intervention, légitime ou non, sur ses logiciels ou sa configuration.	1.1.9, al. 5
Résistance aux attaques	Les systèmes de commande résistent, lorsque les circonstances et les risques le justifient, aux tentatives malveillantes raisonnablement prévisibles de tiers.	1.2.1 a)
Journal sur cinq ans	Le journal des données d’intervention et des versions de logiciels de sécurité téléchargés après la mise sur le marché est activé pendant cinq ans après chaque téléchargement.	1.2.1 f)
Commande sans fil	Une défaillance de la communication ou une connexion défectueuse ne crée pas de situation dangereuse.	1.2.1, dernier alinéa
Perte du réseau	L’interruption ou le rétablissement de la connexion au réseau de communication ne crée pas de situation dangereuse.	1.2.6

La directive 2006/42/CE ne contenait ni l’exigence 1.1.9, ni les tentatives malveillantes de 1.2.1 a), ni le journal de 1.2.1 f), ni la perte de connexion au réseau de 1.2.6. Elles s’appliquent à toute machine mise sur le marché de l’UE à partir du 20 janvier 2027 (art. 54 et rectificatif du 4 juillet 2023), même si le modèle était déjà vendu en 2026.

Machine connectée : où s'appliquent les exigences 1.1.9 et 1.2.1

Cybersécurité des machines : une exigence de sécurité des personnes

Le règlement machines ne demande pas de protéger le savoir-faire, les données de production ou le réseau du client : il demande que la machine ne blesse personne à cause d’une corruption. Le considérant 25 le dit clairement : les fabricants doivent adopter des mesures proportionnées qui se limitent à la protection de la sécurité du produit, sans exclure l’application d’autres textes consacrés à la cybersécurité.

Deux exemples font la différence :

• un attaquant qui copie les recettes de production d’une machine ne crée pas de danger : ce n’est pas un sujet du règlement machines, mais il peut l’être pour le Cyber Resilience Act ou la protection des données ;
• un attaquant, ou un technicien maladroit, qui modifie la vitesse réduite d’un mode réglage, désactive une barrière immatérielle ou charge un programme d’automate non validé crée une situation dangereuse : c’est exactement ce que visent 1.1.9 et 1.2.1.

Le projet de chapitre du guide d’application de la Commission consacré à 1.1.9 et 1.2.1 (version du 18 octobre 2026, approuvée par le groupe éditorial et soumise au groupe d’experts Machines) va dans le même sens : la section couvre les aspects de sécurité et ne couvre ni la confidentialité des données ni la propriété intellectuelle. Il cite comme expositions typiques l’accès à distance, la connexion au cloud et les interfaces non protégées.

Le mot « corruption » couvre les deux cas : l’erreur, comme une mauvaise version de paramètres chargée par clé USB, et l’acte volontaire, comme une prise de contrôle par la télémaintenance. Le texte vise expressément la corruption « accidentelle ou intentionnelle ».

Ma machine est-elle concernée ?

Presque toutes les machines modernes le sont, parce qu’il suffit d’un logiciel lié à la sécurité et d’un moyen de le modifier. Le premier alinéa de 1.1.9 vise toute connexion d’un autre dispositif ; les alinéas suivants visent les logiciels et données essentiels à la sécurité. L’arbre ci-dessous résume la démarche que nous appliquons.

Exigences 1.1.9 et 1.2.1 : que devez-vous démontrer ?

1La sécurité de la machine repose-t-elle sur du logiciel, des paramètres ou des données ?Automate de sécurité, variateur avec fonctions de sécurité, recettes, seuils, modes de marche

NonSécurité purement électromécanique

Peu à démontrer au titre de 1.1.9, alinéas 2 à 5, sauf liaison radio ou télécommande.

Le noter dans l'appréciation du risque.

OuiLogiciels et données essentiels

Les identifier, les protéger, garder la preuve des interventions.

Passer à l'étape 2.

2Par quels chemins peut-on les modifier ?Réseau, port de maintenance, USB, carte SD, radio, écran opérateur, télémaintenance

Aucun chemin externeMachine isolée

Protection physique (armoire fermée, scellés) et preuve d'intervention, par exemple un scellé rompu.

Réseau local, USB, radioAccès local

Authentification, droits par rôle, intégrité des mises à jour, journal.

Internet, télémaintenanceAccès à distance

Mesures renforcées : séparation des réseaux, accès à la demande, chiffrement, surveillance.

3Une corruption par ce chemin peut-elle créer une situation dangereuse ?Fonction de sécurité dégradée, paramètre modifié, démarrage inopiné, arrêt empêché

NonJustifier et documenter

Par exemple : l'interface ne permet que la lecture de données de production.

OuiMesures et preuves

Éliminer le chemin, sinon le protéger, sinon informer l'utilisateur ; vérifier l'efficacité ; verser les preuves au dossier technique.

Dans tous les cas

• La connexion d'un autre dispositif ne doit pas créer de danger (1.1.9, al. 1).
• Une perte de réseau ou de liaison radio ne doit pas créer de danger (1.2.1 et 1.2.6).

L’exigence 1.1.9 expliquée point par point

L’exigence 1.1.9, « Protection contre la corruption », contient cinq obligations distinctes. Chacune appelle des mesures et une preuve différentes.

La connexion d’un autre dispositif ne crée pas de danger

C’est l’obligation la plus large : brancher un PC, un réseau, une passerelle de télémaintenance ou un équipement voisin ne doit jamais mettre la machine en situation dangereuse, quelle que soit la manière dont cet équipement se comporte. En pratique, on vérifie que les commandes reçues par le réseau ne court-circuitent pas les fonctions de sécurité, qu’un équipement connecté ne peut pas provoquer de démarrage inopiné et que les interfaces inutiles sont désactivées.

Le matériel de communication est protégé

Le composant qui transmet des signaux ou des données vers un logiciel essentiel à la sécurité, par exemple le port Ethernet de l’automate ou le module radio, est protégé de manière adéquate contre la corruption. La machine garde aussi la preuve d’une intervention sur ce composant lorsque c’est pertinent. Selon le cas : port physiquement inaccessible dans une armoire fermée à clé, scellé, désactivation des interfaces de développement comme le JTAG en production.

Les logiciels et données essentiels sont identifiés et protégés

Le fabricant doit dire quels logiciels et quelles données conditionnent la sécurité : programme de l’automate de sécurité, paramètres des variateurs, temps de réponse, zones d’une barrière immatérielle, vitesses réduites. Ils sont ensuite protégés : mot de passe propre à chaque machine, droits d’accès par rôle, signature ou somme de contrôle des programmes, paramètres verrouillés.

La machine identifie ses logiciels de sécurité

La machine doit pouvoir indiquer à tout moment, sous une forme aisément accessible, les logiciels installés dont elle a besoin pour fonctionner en sécurité. Concrètement : une page de l’écran opérateur ou une fonction de diagnostic qui affiche les versions et les sommes de contrôle du programme de sécurité et des micrologiciels concernés.

La machine garde la preuve des interventions

La machine recueille la preuve de toute intervention, légitime ou non, sur ses logiciels ou sa configuration. Le projet prEN 50742 (article 7.3) précise les interventions à tracer : modification des paramètres de sécurité, mise à jour des logiciels de sécurité, paramétrage de l’écran opérateur lorsqu’il peut créer un danger, et logiciel qui affiche des consignes de sécurité. Quand la preuve numérique n’est pas raisonnablement possible, une preuve physique, comme un scellé rompu, est admise par ce projet.

L’exigence 1.2.1 : résister aux attaques et tenir un journal pendant cinq ans

L’exigence 1.2.1, « Sécurité et fiabilité des systèmes de commande », ajoute deux obligations nouvelles aux règles classiques de sûreté de fonctionnement.

La résistance aux tentatives malveillantes (1.2.1 a). Les systèmes de commande doivent résister, « lorsque les circonstances et les risques le justifient », aux tentatives malveillantes raisonnablement prévisibles de tiers conduisant à une situation dangereuse. La formule impose une analyse : quelles attaques sont raisonnablement prévisibles pour cette machine, dans son environnement d’utilisation prévu ? Une machine pilotée par télémaintenance via internet n’est pas exposée comme une machine isolée dans un atelier fermé. Le projet de guide de la Commission donne des exemples : accès à distance non autorisé à une partie du système de commande liée à la sécurité, modification non autorisée du logiciel ou des paramètres, manipulation des transmissions de données de sécurité, utilisation non autorisée d’un port de maintenance ou d’un support amovible. Il précise que ces tentatives ne passent pas toujours par le réseau : la chaîne d’approvisionnement ou une interface de service accessible peuvent aussi servir.

Le journal des interventions (1.2.1 f). Le journal de suivi des données générées lors d’une intervention et des versions des logiciels de sécurité téléchargés après la mise sur le marché ou la mise en service est activé pendant cinq ans après chaque téléchargement. Il sert exclusivement à démontrer la conformité, sur demande motivée d’une autorité nationale compétente. Le règlement ne fixe ni format ni support. Le projet prEN 50742 demande au minimum le type d’intervention, un moyen de corréler les événements (horodatage ou compteur) et la trace d’une éventuelle suppression du journal, ainsi qu’une explication dans la notice pour lire ces enregistrements.

Deux points complètent 1.2.1 et 1.2.6 : la perte d’une commande sans fil, comme la coupure ou le rétablissement de la connexion au réseau, ne doit pas créer de situation dangereuse. Une machine pilotée depuis une tablette doit donc passer en état sûr si la liaison se dégrade.

Comment démontrer la conformité : la méthode

La démonstration suit la même logique que toute la sécurité machine : appréciation du risque, puis choix des mesures dans l’ordre imposé par l’annexe III, 1.1.2 b) : éliminer, protéger, informer. Le projet prEN 50742 (article 4.3) l’applique à la corruption : éliminer les vulnérabilités qui peuvent mener à une situation dangereuse, sinon les atténuer, sinon donner à l’utilisateur les informations nécessaires pour les compenser.

Démontrer 1.1.9 et 1.2.1 en cinq étapes

Le tableau ci-dessous relie chaque exigence à des mesures courantes et aux preuves attendues dans le dossier technique. Il s’agit d’exemples, à choisir selon l’appréciation du risque.

Exigence	Exemples de mesures	Preuves pour le dossier technique
1.1.9, connexion sans danger	Interfaces inutiles désactivées ; commandes réseau sans effet sur les fonctions de sécurité ; passerelle entre réseau usine et réseau machine	Liste des interfaces, schéma réseau, essais de connexion et d’injection de commandes
1.1.9, logiciels et données essentiels	Mot de passe unique par machine ; droits par rôle ; programmes signés ou contrôlés par somme de contrôle ; paramètres de sécurité verrouillés	Liste des logiciels et données essentiels, description des protections, rapports d’essai
1.1.9, identification des logiciels	Page de diagnostic avec versions et sommes de contrôle	Capture de l’écran, extrait de la notice
1.1.9 et 1.2.1 f), preuves et journal	Journal horodaté non effaçable sans trace ; scellés sur les ports physiques	Spécification du journal, procédure de lecture, essai de conservation
1.2.1 a), tentatives malveillantes	Télémaintenance à la demande et authentifiée ; chiffrement ; séparation des réseaux ; durcissement	Évaluation des menaces, résultats de tests d’intrusion ou de vérification
1.2.1 et 1.2.6, perte de liaison	Chien de garde sur la liaison radio ; état sûr à la perte de réseau	Essais de coupure et de rétablissement

Dans son approche A (article 7.4.2), le projet prEN 50742 propose en outre de fixer pour chaque fonction de sécurité un niveau de protection, de SRSL 0 (système de sécurité totalement isolé) à SRSL 3 (potentiel d’attaque significatif, par exemple une connexion à internet), choisis selon l’évaluation des menaces. Ce texte reste un projet : ses niveaux et ses exigences peuvent changer avant publication.

N’oubliez pas les autorités : l’annexe IV, partie A, point m), prévoit que le code source ou la logique de programmation des logiciels dédiés à la sécurité soit mis à disposition sur demande motivée d’une autorité nationale compétente.

Quelles normes appliquer ?

Au 2 novembre 2026, aucune norme ne donne de présomption de conformité pour 1.1.9 et 1.2.1, faute de norme harmonisée au titre du règlement 2023/1230. Trois documents servent de référence.

Document	Statut	Ce qu’il apporte
prEN 50742:2025, Protection contre la corruption (CLC/TC 44X)	Projet ; publication visée pour octobre 2026 selon le groupe d’experts Machines, non confirmée ; non harmonisé	Écrit pour 1.1.9 et 1.2.1 ; deux voies : approche A sans IEC 62443, approche B fondée sur l’IEC 62443
IEC 62443-3-3 et IEC 62443-4-2 (avec 62443-3-2 pour l’analyse de risque et 62443-4-1 pour le développement)	Normes publiées, non harmonisées au titre du règlement machines	Exigences de sécurité des systèmes et des composants industriels, niveaux de sécurité
ISO/TR 22100-4:2018	Rapport technique	Lignes directrices pour intégrer la sécurité informatique dans l’appréciation du risque selon l’ISO 12100

Le règlement prévoit une autre voie : une machine certifiée, ou couverte par une déclaration de conformité, au titre d’un schéma européen de certification de cybersécurité (règlement (UE) 2019/881) dont les références sont publiées au Journal officiel est présumée conforme à 1.1.9 et 1.2.1, dans la mesure où le certificat les couvre (art. 20, par. 9). Vérifiez au moment de la mise sur le marché si un tel schéma est applicable à votre machine.

Pour une machine de l’annexe I, l’absence de norme harmonisée couvrant 1.1.9 impose l’intervention d’un organisme notifié : toujours pour la partie A, et pour la partie B dès que les normes appliquées ne couvrent pas toutes les exigences (art. 25, par. 2 et 3). Pour les autres machines, la conformité se démontre directement : le dossier technique cite les spécifications appliquées et explique, exigence par exigence, comment elles sont satisfaites (annexe IV, partie A, points e et f). Les catégories de l’annexe I et les organismes disponibles sont présentés dans notre article sur l’annexe I et l’organisme notifié.

Règlement machines et Cyber Resilience Act : faut-il respecter les deux ?

Oui : une machine qui comporte des éléments numériques et une connexion de données est aussi un produit au sens du Cyber Resilience Act (règlement (UE) 2024/2847), qui n’exclut pas les machines. Le considérant 53 du CRA et la FAQ de la Commission (version 1.4, points 2.4.1 à 2.4.3) sont nets : il faut satisfaire aux deux textes, la conformité à l’un ne vaut pas automatiquement conformité à l’autre, et chaque procédure d’évaluation de la conformité doit être suivie.

	Règlement machines (UE) 2023/1230	Cyber Resilience Act (UE) 2024/2847
Objectif	La sécurité des personnes : la corruption ne doit pas rendre la machine dangereuse	La cybersécurité du produit : confidentialité, intégrité, disponibilité, gestion des vulnérabilités
Exigences	Annexe III, 1.1.9 et 1.2.1	Annexe I, parties I et II
Application	20 janvier 2027	11 décembre 2027 ; signalement des vulnérabilités activement exploitées et des incidents graves depuis le 11 septembre 2026 (art. 14 et 71)
Évaluation de la conformité	Art. 25	Art. 32
Suivi après vente	Journal des interventions sur 5 ans	Gestion des vulnérabilités pendant la période d’assistance

La Commission ajoute que la conformité au CRA peut faciliter celle du règlement machines, à condition que le fabricant le démontre par une évaluation des risques couvrant ces risques. En pratique, une seule analyse des menaces bien construite, qui distingue les scénarios ayant un effet sur la sécurité des personnes, alimente les deux dossiers. Voir notre article sur l’analyse de risque cyber (TARA) et celui sur les exigences essentielles du CRA.

Pour une machine soumise à un examen UE de type, l’attestation fondée sur 1.1.9 et 1.2.1 vaut aussi, temporairement, pour le CRA (art. 69, par. 1). Selon les lignes directrices de la Commission sur le CRA (C(2026) 5252, points 255 à 257), une attestation d’examen UE de type délivrée sur la base de 1.1.9 et 1.2.1 reste valable pour les risques de cybersécurité qu’elle couvre, au plus tard jusqu’au 11 juin 2028. Les risques supplémentaires identifiés par l’évaluation des risques du CRA restent à traiter selon le CRA.

Attention au calendrier : l’obligation de signaler les vulnérabilités activement exploitées et les incidents graves s’applique déjà, y compris aux produits mis sur le marché avant le 11 décembre 2027 (CRA, art. 14 et art. 69, par. 3).

Et en Suisse ?

Une machine suisse vendue dans l’UE doit respecter 1.1.9 et 1.2.1 dès le 20 janvier 2027, comme toute autre machine. Pour le marché suisse, l’ordonnance sur les machines (OMach, RS 819.14) reprend aujourd’hui la directive 2006/42/CE, qui ne contient pas ces exigences.

Le projet de révision totale de l’OMach, mis en consultation le 19 septembre 2025, reprend le règlement (UE) 2023/1230 par renvoi, y compris ses exigences de cybersécurité, avec une entrée en vigueur prévue le 20 janvier 2027. À notre connaissance, le texte n’était pas encore adopté au 2 novembre 2026. Le détail figure dans notre article sur le règlement machines en Suisse.

Le Cyber Resilience Act n’a pas encore d’équivalent suisse : le Conseil fédéral a chargé le DDPS de préparer d’ici juin 2027 un projet de loi fédérale sur la cybersécurité qui s’en inspire. Concevoir dès maintenant selon les deux textes européens reste la voie la plus simple pour un fabricant qui exporte. Voir aussi ce qui change pour un fabricant suisse.

Par où commencer d’ici janvier 2027

Pour être prêt le 20 janvier 2027, commencez par lister les interfaces et les logiciels de sécurité, puis complétez l’appréciation du risque. Sept actions permettent de couvrir 1.1.9 et 1.2.1 sur un modèle existant :

1. Lister les interfaces de la machine : réseau, ports de maintenance, USB, cartes mémoire, radio, télémaintenance, écran opérateur.
2. Identifier les logiciels et données essentiels à la sécurité et les versions installées.
3. Compléter l’appréciation du risque avec une évaluation des menaces sur ces interfaces et ces logiciels.
4. Choisir les mesures dans l’ordre éliminer, protéger, informer, en commençant par fermer les interfaces inutiles.
5. Mettre en place l’identification des versions et le journal des interventions et des mises à jour, actif cinq ans.
6. Vérifier par essais, revue de configuration ou tests d’intrusion, puis compléter la notice : conditions de raccordement, réseau prévu, lecture du journal.
7. Mettre à jour le dossier technique et la déclaration UE de conformité, et préparer en parallèle le dossier CRA si la machine est connectée.

Säfeli accompagne les constructeurs de machines sur ce volet : évaluation des menaces selon l’IEC 62443, mesures, essais et rédaction des preuves pour le dossier technique. Voir notre page cybersécurité des machines. Pour former vos équipes, la formation Conformité machine consacre un chapitre aux exigences cyber du règlement et du CRA. Une mise à jour logicielle peut aussi constituer une modification substantielle, et les systèmes à apprentissage automatique sont traités dans règlement machines et intelligence artificielle. Säfeli accompagne ; le fabricant reste responsable de la conformité de son produit.