CRA pour les fabricants de machines après les lignes directrices de la Commission du 27 juillet 2026. Que faut-il réellement mettre en œuvre ?

Pendant des années, la cybersécurité d’une machine se résumait en trois étapes : un automate de marque, un VPN « parce que c’est comme ça qu’on fait » et le classique « le client sécurisera le réseau ». Et si quelqu’un ajoutait un firewall dans l’armoire, le sujet était souvent considéré comme réglé — du moins jusqu’au moment où quelqu’un essayait de vérifier ce qui se passerait lors d’une attaque réelle, et non dans une présentation.

Sauf que la cybersécurité ne circule pas sur PROFINET. Les composants peuvent avoir des certificats, des déclarations et du « secure by design » dans la brochure marketing, la machine dans son ensemble peut malgré tout rester prévisible d’une manière qui n’a rien à voir avec la sécurité. De la même façon qu’un relais de sécurité ne rend pas un système sûr si la logique de commande permet de le contourner, un HMI « sécurisé » ne résout pas les problèmes d’architecture, d’intégration, de droits d’accès, de mises à jour et de ce qui se passe lorsque quelqu’un cesse de demander l’autorisation.

CRA (Cyber Resilience Act, Règlement du Parlement européen et du Conseil (UE) 2024/2847) n’est pas un simple complément pour l’IT. C’est une réglementation produit qui s’impose dans le cycle de vie de la machine sans demander l’avis du service automatisme. Elle couvre la conception de la commande, l’analyse des risques, la chaîne d’approvisionnement, la configuration, les mises à jour, ainsi que le maintien du produit longtemps après la signature du FAT et la sortie de la machine de l’atelier. Et non, l’argument « nous ne l’exposons pas à internet » ne clôt pas le sujet. En pratique, il suffit d’un ordinateur portable de maintenance, d’une clé USB, d’un diagnostic à distance « temporaire » ou d’une intégration au système de l’usine pour que la frontière entre isolement et exposition cesse d’exister.

Les lignes directrices de la Commission du 27 juillet 2026 n’ont pas modifié le règlement lui-même, mais elles ont effectivement réduit la marge d’interprétation qui permettait auparavant de traiter la cybersécurité comme une couche optionnelle. Elles ont notamment précisé la frontière du produit, le rôle du traitement à distance, la responsabilité liée aux modifications après livraison, ainsi que le fait que « ce n’est plus notre problème après le FAT » n’est plus une hypothèse sûre.

Le changement le plus important est toutefois plus fondamental : la cyberattaque cesse d’être un simple événement IT pour devenir un scénario ayant un impact sur la sécurité fonctionnelle de la machine. Si une modification non autorisée du programme peut provoquer le mouvement d’un axe, le contournement d’un verrouillage, la modification des paramètres du procédé ou la perte d’une fonction de sécurité, il ne s’agit plus d’un « incident réseau ». Il s’agit d’un comportement potentiellement non maîtrisé de la machine — que l’origine soit une erreur de configuration, une vulnérabilité logicielle ou une intervention délibérée.

Dans ce contexte, un pentest ponctuel avant le FAT cesse d’être une preuve de conformité et ne devient qu’un instantané de l’état du système à un moment donné. Le CRA exige une approche continue : depuis la conception, en passant par la production et la mise en service, jusqu’aux mises à jour, à la gestion des vulnérabilités, à la réponse aux incidents et au maintien pendant la période de support déclarée.

En pratique, cela signifie abandonner la logique « fait = sécurisé » au profit de « maintenu = maîtrisé ». Sans l’illusion qu’un firewall dans l’armoire, un VPN et le certificat d’un composant règlent le sujet. Et sans supposer que la cybersécurité s’arrête au moment de la signature du procès-verbal de réception.

Dans cet article, nous examinons ce que les lignes directrices du CRA changent réellement pour les fabricants, les intégrateurs et les acteurs de la modernisation des machines — sans réduire tout le sujet au slogan « changeons le mot de passe et ajoutons une case à cocher cybersecurity ».

1. Pour qu’une machine n’entre pas dans le champ du CRA, il faudrait qu’elle soit presque entièrement à base de contacteurs

Dans de nombreux projets, le périmètre du CRA est vérifié à l’aide d’une seule question :

La machine sera-t-elle connectée à internet ?

Non.

Donc le sujet est clos.

Sur le schéma, il y a un PLC, un HMI, quelques variateurs, des entrées et sorties déportées, un îlot de vannes, un scanner de sécurité ainsi qu’un port pour charger le programme. L’automate communique avec le pupitre via PROFINET, échange avec les variateurs des mots de commande et d’état, et les capteurs transmettent les données via IO-Link.

Mais il n’y a pas de routeur avec carte SIM.

Comme chacun sait, les données ne deviennent des données qu’au moment où elles quittent l’atelier de production.

Sauf que le CRA ne demande pas si la machine a accès à internet.

Il demande si sa destination ou son usage raisonnablement prévisible comprend une connexion de données directe ou indirecte, logique ou physique, avec un appareil ou un réseau. Il ne doit pas nécessairement s’agir d’une connexion au cloud, au serveur du fabricant ou à l’internet public. Elle peut passer par un câble, des ondes radio, une interface logicielle ou faire partie d’un système plus vaste.

Et la question clé est alors la suivante : dans une machine typique, qu’est-ce qui transmet réellement des données ?

Le HMI lit-il les états du PLC et enregistre-t-il les consignes ?

Le PLC envoie-t-il au variateur un mot de commande et reçoit-il en retour la vitesse, l’état et le code défaut ?

L’îlot d’entrées/sorties transmet-il l’image du procédé ?

Le capteur IO-Link envoie-t-il la valeur mesurée, l’identifiant de l’appareil et les données de diagnostic ?

Le safety PLC communique-t-il avec les modules via PROFIsafe ?

Le programme, la configuration matérielle ou le firmware sont-ils chargés depuis un ordinateur portable de maintenance ?

Les recettes, rapports ou mises à jour peuvent-ils être transférés par USB ?

Si la réponse est ne serait-ce qu’une seule fois « oui », il est probable que nous soyons en présence d’une connexion de données.

Et cela ne change rien au fait que :

• la machine fonctionne sur un réseau local,
• elle n’a pas d’adresse IP publique,
• le port Ethernet n’est utilisé qu’au moment de la mise en service,
• seul le service après-vente connecte un ordinateur portable,
• la communication a lieu uniquement à l’intérieur du système de commande,
• le client a promis qu’il ne connecterait jamais la machine à internet.

Le CRA couvre non seulement l’usage décrit dans la notice comme usage principal, mais aussi l’usage raisonnablement prévisible. Un port de service ne cesse donc pas de transmettre des données au seul motif que le schéma porte la mention « SERVICE ONLY ».

Les lignes directrices de la Commission du 27 juillet 2026 introduisent toutefois une distinction importante.

Tout câble et tout signal électrique ne constituent pas nécessairement une connexion de données.

Si un signal sert exclusivement à enclencher, arrêter ou alimenter une fonction donnée et ne transmet pas d’information codée numériquement, la simple présence de deux états électriques ne suffit pas encore à le qualifier de connexion de données.

Un bouton qui applique une tension à la bobine d’un contacteur ne devient pas une interface numérique au seul motif que son état peut être décrit comme zéro ou un.

De même, un fin de course classique intégré dans un circuit à relais et contacteurs peut uniquement ouvrir ou fermer le circuit. Il ne transmet ni numéro d’équipement, ni valeur de process, ni code de diagnostic, ni version de firmware, ni télégramme contenant plusieurs informations.

Mais lorsque ce même état est envoyé vers un équipement intelligent, qu’il est codé, transmis sur un bus, associé à des fonctions de diagnostic et interprété par le récepteur comme une information, la situation change.

La frontière ne passe donc pas entre une machine « en ligne » et « hors ligne ».

Elle passe entre un simple signal de commande et un échange d’informations codées numériquement.

En pratique, une machine qui resterait hors du champ du CRA uniquement en raison de l’absence de connexion de données devrait donc ressembler davantage à une architecture classique avec boutons, fins de course, relais et contacteurs qu’à un projet moderne ouvert dans TIA Portal.

Il ne s’agit évidemment pas d’une exclusion légale applicable aux contacteurs.

On peut construire une machine simple avec un PLC qui, après analyse détaillée, ne remplira pas le critère de champ d’application. On peut aussi ajouter à une architecture à contacteurs un régulateur numérique, une interface de service ou un module de communication et se retrouver exactement de l’autre côté de la frontière.

Le nom du composant ne tranche pas la question.

Ce qui compte, c’est ce que le produit fait réellement et avec quoi il échange des données.

C’est pourquoi, avant de répondre à la question de savoir si une machine donnée relève du CRA, il faut déterminer :

• où se situe la frontière du produit évalué,
• quels équipements et quels éléments logiciels en font partie,
• quelles interfaces physiques et logiques il possède,
• quelles informations y transitent,
• quelles connexions sont directes et lesquelles passent par un système plus large,
• lesquelles interviennent en fonctionnement normal, lors de la mise en service, du diagnostic, de la mise à jour ou du service,
• quels modes d’utilisation sont raisonnablement prévisibles, même si le fabricant préférerait ne pas les envisager.

Tant que nous n’avons pas répondu à ces questions, nous ne savons pas si la machine reste hors du champ du CRA.

Nous n’avons au mieux qu’une formule commode :

« La machine n’est pas connectée à internet ».

Sauf que c’est une réponse à une question que le CRA ne pose pas.

PROFINET n’est pas internet. Et pour le CRA, il n’a nullement besoin de l’être.

2. La cybersécurité ne se propage pas par PROFINET

Dans de nombreux projets, la question de la conformité de la machine commence dès la phase achats.

PLC d’un fabricant reconnu.
HMI avec firmware à jour.
Switch administrable.
Routeur industriel avec VPN.
Variateurs avec fonctions de sécurité.
Safety PLC avec le certificat approprié.

Pour chaque équipement, une déclaration de conformité, une notice et plusieurs documents contenant les mots « secure », « encrypted » et « defence in depth ».

Sur le schéma, tout paraît professionnel.

Mais cela ne dit toujours pas si la machine complète est réellement cybersécurisée.

Car la cybersécurité ne « circule » pas sur PROFINET.

C’est un peu comme une serrure sur une porte :
vous pouvez avoir une très bonne serrure dans chaque pièce, certifiée, testée, accompagnée d’une documentation impeccable et d’un hologramme « secure », cela ne garantit toujours pas la sécurité si quelqu’un a laissé la porte d’entrée grande ouverte « parce que c’était plus rapide pour la mise en service ».

Et c’est exactement la même chose ici : les composants peuvent être exemplaires, tandis que le système peut malgré tout rester… ouvert avec créativité.

Le PLC ne « transmet » pas la sécurité au HMI.
Le firewall ne « corrige » pas la logique de l’application.
Le switch ne « met pas de l’ordre » dans les accès utilisateurs.
Et le fait que chaque élément dispose d’un certificat ne signifie pas encore que l’ensemble de la machine n’est pas une immense faille, soigneusement documentée.

PROFINET transmet des données.

Il ne transmet pas la responsabilité.
Et malheureusement, il ne transmet pas non plus le bon sens.

Le CRA couvre à la fois les produits complets et les composants mis sur le marché séparément. Cela signifie qu’un automate, un pupitre opérateur ou un module de communication peuvent être évalués séparément. Mais le fabricant de la machine doit toujours démontrer que l’ensemble fonctionne de manière sûre dans la configuration réelle chez le client — c’est-à-dire dans cette version où quelqu’un « n’a sûrement plus rien modifié… n’est-ce pas ? ».

Et c’est là qu’apparaît l’erreur la plus fréquente.

C’est exactement le même mécanisme que celui que nous connaissons depuis des années en analyse des risques pour la sécurité des machines.

Le rideau immatériel est de niveau PL e.
Le Safety PLC est de niveau SIL 3.
L’entraînement dispose de la fonction STO.

Est-ce que cela signifie que l’ensemble de la machine est automatiquement à ce niveau ?

C’est un peu comme pour un échafaudage : le fait que chaque élément soit conforme aux normes de sécurité ne garantit pas encore que l’ensemble de la structure sera stable.

Non.

Car il faut encore vérifier comment tout cela fonctionne ensemble — autrement dit, passer par cette étape peu populaire qu’est la « pensée système », laquelle n’a malheureusement pas de bouton « auto-certify ».

En cybersécurité, c’est exactement la même chose.

Vous pouvez avoir des composants « sûrs », mais en pratique :

• l’opérateur voit et peut modifier plus de données que nécessaire, parce que « c’était plus pratique comme ça »,
• un seul mot de passe de maintenance fonctionne sur toutes les machines, parce que « de toute façon, le service sait ce qu’il fait »,
• le port de service reste accessible « au cas où », c’est-à-dire pour n’importe quel cas,
• l’accès à distance couvre tout le réseau, parce qu’un jour quelqu’un a dit « ce n’est que du diagnostic »,
• les mises à jour peuvent être chargées sans contrôle, parce que « rien n’est jamais tombé en panne »,
• les équipements « se font confiance » sans aucune restriction, parce que la confiance coûte moins cher que la segmentation,
• et l’intégration part du principe que personne ne fera jamais d’erreur, ce qui est — comme l’histoire le montre — l’hypothèse la plus optimiste de toute l’ingénierie.

Pris séparément, chaque élément peut être correct.

Mais le système, dans son ensemble, peut assembler ces éléments corrects en quelque chose qui fonctionne… sans forcément fonctionner comme prévu.

Et c’est un point essentiel : le risque ne réside pas dans les équipements eux-mêmes, mais dans leur interconnexion, leur configuration et dans ce fameux accès « laissé temporairement ».

Le CRA exige du fabricant de machines bien plus qu’une collection de déclarations accumulées comme des trophées. Il impose de vérifier que ce qui a été assemblé à partir de composants reste sûr en tant qu’ensemble — et pas seulement que « ça présente bien dans le tableau de conformité ».

En pratique, cela se traduit par des questions simples, très concrètes pour l’entreprise :

• chaque utilisateur dispose-t-il uniquement des accès dont il a réellement besoin, et non de droits conservés « au cas où cela serve un jour »,
• l’accès à distance est-il limité au strict minimum, ou plutôt poussé au maximum du confort,
• la maintenance n’a-t-elle pas « tous les droits partout » parce que quelqu’un a estimé que cela faisait gagner du temps,
• le réseau n’est-il pas une seule surface commune, parce que la segmentation « complexifie le projet »,
• les mises à jour sont-elles maîtrisées, ou bien « on les pousse et on croise les doigts »,
• peut-on identifier rapidement quelles machines sont exposées, ou bien faudra-t-il « vérifier après l’incident »,
• la défaillance d’un seul élément n’ouvre-t-elle pas tout le système, parce que « c’est comme ça que l’intégration a été faite ».

Ce ne sont pas des questions techniques « réservées aux ingénieurs qui traitent les sujets compliqués ».

Ce sont des questions de risque métier : arrêts de production, coûts, responsabilité et ce petit détail selon lequel la production doit quand même fonctionner.

C’est pourquoi il ne suffit pas de dire :

« tous les composants sont conformes »

Car cela ne répond toujours pas à la question suivante :

la machine complète est-elle sûre en conditions réelles d’utilisation, ou seulement dans le PowerPoint de revue de projet ?

La déclaration du fournisseur est importante.

Mais elle ne concerne qu’un seul élément — celui qui a précisément été testé en laboratoire, et non dans un environnement « quelque part dans l’atelier, avec un VPN, une clé USB et la pression du temps ».

Elle ne couvre pas la manière dont il a été utilisé.
Elle ne couvre pas la configuration.
Elle ne couvre pas l’intégration.
Elle ne couvre pas les décisions prises « dans l’urgence pendant la mise en service, parce que le client attendait ».
Elle ne couvre pas ce qui se passe après des années d’exploitation, lorsque plus personne ne se souvient pourquoi quelque chose était « temporairement ouvert ».

C’est pourquoi l’évaluation ne peut pas s’arrêter à une liste d’équipements.

Il faut regarder le système dans son ensemble :

• qui a accès à quoi, et pourquoi (et non « parce qu’il l’a toujours eu »),
• ce qui est réellement nécessaire, et ce qui a simplement été « laissé en place parce que cela ne gênait pas »,
• où les données peuvent sortir du périmètre de contrôle parce que quelqu’un a estimé que « ce n’est que du diagnostic »,
• ce qui se passe si quelqu’un utilise un accès légitime de manière illégitime (autrement dit, exactement comme le font les attaques),
• à quelle vitesse il est possible de réagir lorsqu’un problème survient, et non « lors de la revue trimestrielle ».

Tant qu’il n’y a pas de réponse à ces questions, on n’a qu’un ensemble de composants très corrects.

On n’a pas encore une machine sûre.

La conformité des composants ne crée pas automatiquement la conformité du système. La conformité de la machine doit être conçue, vérifiée et — le plus difficile — maintenue malgré la tentation de « ne plus rien toucher puisque ça marche ».

3. N’ajoutez pas la cyberattaque à la liste des dangers. Reliez les deux analyses au bon endroit

Sur le marché des machines, une analyse des risques formelle en cybersécurité reste encore davantage une exception qu’un élément standard du projet.

Le plus souvent, il y a un routeur industriel.

Il y a un VPN.

Il y a un mot de passe sur le PLC.

Parfois, il y a un switch administrable que plus personne n’administre ensuite.

Dans une version plus ambitieuse, le fabricant reçoit du fournisseur une présentation sur la « defence in depth » et considère qu’il vient justement d’achever l’analyse des risques de cybersécurité de la machine entière.

Ce n’est pas le cas.

Il a acheté quelques mesures techniques.

Ce n’est pas encore une analyse.

Il n’a donc aucun sens de décrire le problème comme si, dans chaque projet, deux évaluations professionnelles étaient systématiquement réalisées — l’une selon ISO 12100, l’autre en cybersécurité — et qu’elles n’avaient simplement pas été reliées entre elles par hasard.

Le plus souvent, une seule est réalisée.

Analyse des risques de la machine.

Et l’analyse de cybersécurité du produit n’est pas réalisée du tout.

L’analyse des risques de la machine selon ISO 12100 ne consiste pas à inscrire dans un tableau :

défaillance du capteur → mouvement inattendu → écrasement.

Cela peut constituer un fragment d’un scénario précis, mais ce n’est pas le point de départ.

Il faut d’abord définir les limites de la machine.

À quoi est-elle destinée ?

Quelles sont les phases de son cycle de vie ?

Qui va l’utiliser ?

Quelles tâches seront effectuées pendant le transport, le montage, la mise en service, la production, le réglage, le nettoyage, le déblocage, la maintenance, le diagnostic et le démontage ?

Dans quels modes la machine peut-elle fonctionner ?

Où se trouve l’opérateur lors de chacune de ces opérations ?

Quelles parties de la machine restent alors sous tension, sous pression, sous charge ou en mouvement ?

Quels usages ne sont pas conformes à la notice, tout en restant raisonnablement prévisibles ?

Ce n’est qu’ensuite, pour une tâche ou une opération donnée, que l’on identifie notamment :

• la source de danger,
• le type de danger,
• la zone dangereuse,
• la personne exposée,
• la situation dangereuse,
• l’événement dangereux, s’il apparaît dans le scénario considéré,
• les conséquences possibles et le type de dommage.

C’est ainsi que se présente l’analyse des risques d’une machine.

On ne part pas du composant.

On part de la personne qui exécute une tâche déterminée sur une machine se trouvant dans un état donné. ISO 12100 établit précisément cette méthode d’identification des dangers ainsi que d’estimation et d’évaluation du risque pendant les phases pertinentes du cycle de vie de la machine.

Prenons un exemple simple.

L’opérateur retire une pièce bloquée à l’intérieur d’une cellule de palettisation.

Nous avons donc :

Tâche : suppression du blocage.

Phase d’utilisation : exploitation, intervention après arrêt du processus.

Mode de fonctionnement : manuel ou maintenance.

Personne exposée : opérateur ou technicien de maintenance.

Zone dangereuse : l’intérieur de la cellule, en particulier l’espace entre le préhenseur, la pièce et la structure de la machine.

Source de danger : l’énergie mécanique du robot, de l’axe linéaire ou du préhenseur pneumatique.

Situation dangereuse : une personne se trouve dans la zone alors qu’un mouvement reste possible.

Événement dangereux : mouvement inattendu d’un axe, fermeture du préhenseur ou libération d’énergie accumulée.

Conséquence possible : choc, écrasement, fracture ou amputation.

Ce n’est qu’à ce stade que l’on peut évaluer le risque et définir les mesures de réduction appropriées.

Un interverrouillage de protecteur peut être nécessaire.

Un arrêt sûr peut être nécessaire.

Il peut être nécessaire d’empêcher tout redémarrage intempestif.

Il peut être nécessaire d’évacuer l’énergie pneumatique.

Il se peut aussi qu’en mode manuel, le mouvement ne puisse avoir lieu qu’au moyen d’un dispositif d’autorisation et à vitesse limitée en sécurité.

Il s’agit toujours d’une analyse classique des risques de la machine.

Où la cybersécurité intervient-elle ?

Pas comme une nouvelle ligne à côté des dangers mécaniques, électriques et thermiques.

Le « hacker » n’est pas une source de danger mécanique

Ajouter dans le tableau ISO 12100 la ligne :

Danger : cyberattaque

apporte peu de valeur.

Une cyberattaque n’est ni un arbre en rotation, ni une arête vive, ni une température élevée, ni une énergie pneumatique.

Ce n’est pas non plus une zone dangereuse distincte.

L’opérateur n’est pas écrasé par une vulnérabilité CVE.

Il l’est par un élément de la machine qui s’est mis en mouvement alors qu’une personne se trouvait au mauvais endroit.

En revanche, une cyberattaque peut modifier l’état du système de commande, les données, le programme, la configuration ou le mode d’action d’une mesure de protection.

Elle peut donc devenir :

• la cause d’un événement dangereux,
• une voie supplémentaire menant à une situation dangereuse,
• la cause de la perte d’efficacité d’une mesure de réduction du risque,
• ou un moyen de contourner les hypothèses retenues lors de la conception des fonctions de sécurité.

Et c’est là le véritable point de contact.

Pas la liste des dangers.

Le comportement de la machine.

L’analyse de cybersécurité doit être réalisée séparément

Pour une machine ou un système d’automatisation, l’analyse de cybersécurité aura une structure différente de l’analyse des risques selon ISO 12100.

Pour un système d’automatisation industrielle, le cadre le plus naturel est fourni par IEC 62443-3-2.

La norme exige notamment :

• de définir le système soumis à l’analyse, c’est-à-dire le SUC,
• de diviser le système en zones et en canaux de communication,
• d’évaluer le risque pour chaque zone et chaque canal,
• de définir les niveaux de sécurité cibles SL-T,
• de documenter les exigences de sécurité.

Le point de départ est donc totalement différent de celui d’ISO 12100.

Dans IEC 62443, on se demande notamment :

Qu’est-ce qui relève exactement du système analysé ?

Quels actifs faut-il protéger ?

Quels équipements, applications et interfaces se trouvent dans le système ?

Quels éléments doivent appartenir à une même zone ?

Comment la communication s’effectue-t-elle entre les zones ?

Qui peut obtenir un accès ?

Depuis quel endroit ?

Au moyen de quelle interface ?

Quelles vulnérabilités peuvent être exploitées ?

Quelles données, fonctions ou quels composants peuvent être modifiés ?

Par quel chemin un attaquant peut-il passer du routeur de maintenance au PLC, à l’IHM, au variateur ou au poste d’ingénierie ?

Quelles seront les conséquences d’une perte de confidentialité, d’intégrité ou de disponibilité ?

Quelles protections sont nécessaires ?

Pour le processus de développement sécurisé du produit ainsi que pour les exigences applicables aux composants eux-mêmes, d’autres parties de la série sont également importantes, en particulier IEC 62443-4-1 et IEC 62443-4-2. IEC 62443-3-3 structure quant à elle les exigences techniques de sécurité au niveau du système.

À ce jour, le CRA n’impose pas au fabricant d’indiquer en couverture de l’analyse « réalisée conformément à IEC 62443 ».

IEC 62443 ne remplace pas non plus la démonstration de conformité aux exigences du CRA.

Pour un système d’automatisation industrielle, il constitue toutefois un point de référence bien plus logique que d’essayer d’ajouter quelques scénarios de piratage dans un tableau ISO 12100.

Car ces deux méthodologies ne répondent pas aux mêmes questions.

ISO 12100:

Au cours de quelle tâche, à quel endroit, à partir de quelle source et à la suite de quel événement une personne peut-elle subir un dommage ?

IEC 62443:

Qui, par quel vecteur et en exploitant quelle vulnérabilité peut agir sur le système, ses données ou ses fonctions ?

Ce n’est qu’ensuite qu’il faut vérifier si la réponse issue de la seconde analyse modifie le scénario de la première.

Un même scénario, deux analyses différentes

Revenons à l’opérateur qui retire une pièce bloquée.

L’analyse des risques selon ISO 12100 a montré que la personne pénètre dans une zone où elle peut être écrasée par le mouvement du robot ou du préhenseur.

La mesure de réduction du risque repose sur un protecteur interverrouillé, une fonction d’arrêt de sécurité et un réarmement local placé hors de la zone dangereuse.

Nous réalisons maintenant l’analyse de cybersécurité du système.

Nous identifions :

• le routeur utilisé pour la maintenance à distance,
• le compte de maintenance,
• l’ordinateur portable d’ingénierie,
• l’IHM,
• le PLC standard,
• le PLC de sécurité,
• les variateurs,
• l’interface de programmation,
• le réseau PROFINET et la communication PROFIsafe,
• les mécanismes de chargement du programme et de la configuration.

Nous examinons le scénario suivant :

La compromission du compte de maintenance permet un accès à distance au PLC standard et l’envoi d’une commande de mouvement alors qu’une personne est présente dans la cellule.

Ce scénario conduit-il à un événement dangereux ?

Il est impossible d’y répondre sur la seule base de la compromission du PLC.

Il faut vérifier l’architecture des fonctions de sécurité.

Si l’ouverture du protecteur est surveillée par le PLC de sécurité, si la fonction coupe en sécurité le couple des variateurs, si le réarmement est exclusivement local et si le PLC standard ne peut pas rétablir le mouvement indépendamment de l’état de la fonction de sécurité, alors la compromission de l’automate standard peut arrêter la production ou perturber le process.

Mais elle ne devrait pas provoquer de mouvement avec le protecteur ouvert.

Dans ce cas, l’analyse cyber met en évidence une attaque.

L’évaluation des risques de la machine met en évidence un danger mécanique.

Une fonction de sécurité correctement conçue coupe toutefois le lien entre les deux.

Passons maintenant à une deuxième variante.

Le mode maintenance est sélectionné depuis une IHM standard.

La valeur de vitesse limitée provient du PLC standard.

Le mainteneur à distance peut effectuer le réarmement.

Le même compte d’ingénierie permet de modifier le programme standard et la configuration safety.

La copie du programme safety n’est pas rattachée à une version précise de la machine.

Personne ne vérifie la somme de contrôle après l’intervention.

Les paramètres du variateur peuvent être modifiés à distance.

Dans cette architecture, la compromission du compte ne signifie plus seulement une perte de confidentialité ou un arrêt de courte durée.

Elle peut modifier les conditions sur lesquelles reposait la réduction du risque.

Elle peut conduire à :

• la sélection d’un mode inadapté,
• la modification d’un paramètre de mouvement sûr,
• un réarmement non autorisé,
• le chargement d’une configuration non approuvée,
• ou l’affaiblissement de la fonction censée empêcher un démarrage intempestif.

Et dans ce cas, le scénario cyber doit être relié à un scénario concret de sécurité machine :

opération de déblocage → personne dans la zone dangereuse → modification non autorisée du système de commande ou de la fonction de protection → mouvement inattendu → écrasement.

La source du danger n’a pas changé.

Il s’agit toujours de l’énergie mécanique de la machine.

La zone dangereuse n’a pas changé.

Elle se situe toujours à l’intérieur de la cellule.

La conséquence possible n’a pas changé.

Il s’agit toujours d’une blessure de l’opérateur.

Ce qui a changé, c’est le chemin menant à l’événement dangereux.

Toutes les vulnérabilités n’ont pas vocation à figurer dans l’ISO 12100

Cette distinction est tout aussi importante.

Supposons qu’une vulnérabilité dans l’IHM permette de lire des données historiques de production.

Cela peut constituer un problème important du point de vue du CRA.

Cela peut porter atteinte à la confidentialité des données.

Cela peut nécessiter une mise à jour, une évaluation d’impact, des actions vis-à-vis des utilisateurs et, dans certaines circonstances, également un signalement.

Mais si elle n’a aucun effet sur le comportement de la machine, ne modifie aucune mesure de protection et ne peut pas conduire à une situation dangereuse, il n’y a aucun sens à l’intégrer de force dans l’évaluation des risques selon ISO 12100.

De la même manière, une attaque qui ne provoque que l’indisponibilité des rapports de production peut constituer un problème métier ainsi qu’un problème de conformité au CRA.

Elle ne crée toutefois pas nécessairement un risque pour l’opérateur.

À l’inverse, la possibilité apparemment anodine de modifier une seule valeur de consigne peut avoir peu d’impact sur la confidentialité des données, mais des conséquences majeures sur la sécurité physique.

Par exemple lorsque cette valeur détermine :

• la vitesse maximale d’un axe,
• la force de serrage,
• la température du procédé,
• la pression,
• la position d’arrêt,
• le temps d’ouverture d’une vanne,
• ou encore la limite admissible en fonctionnement avec protecteur ouvert.

Nous ne classons donc pas une cybermenace en fonction de sa seule apparence technique.

Nous examinons ce qu’elle peut réellement faire à la machine.

Le règlement machines impose ce lien

Ce rapprochement ne relève pas uniquement d’une bonne pratique d’ingénierie.

Le point 1.2.1 de l’annexe III du règlement machines exige que les systèmes de commande soient conçus et réalisés de manière à prévenir les situations dangereuses, y compris celles résultant de tentatives malveillantes raisonnablement prévisibles de tiers.

De son côté, le CRA indique que ses exigences essentielles de cybersécurité peuvent contribuer à démontrer la conformité notamment aux exigences 1.1.9 et 1.2.1 du règlement machines.

Mais cela ne se fait pas automatiquement.

Le fabricant doit démontrer ce lien sur la base d’une analyse des risques. L’évaluation de la conformité au titre du CRA et l’évaluation de la conformité au titre du règlement machines restent deux processus distincts.

Autrement dit, il ne suffit pas de préparer :

• une analyse des risques ISO 12100,
• une analyse IEC 62443,
• deux rapports séparés,
• et d’espérer que la similitude des numéros de normes crée entre eux une piste d’audit.

Il faut établir un lien explicite.

Pour chaque scénario cyber significatif, il convient de déterminer :

1. quel composant ou quelle fonction peut être pris en main ou modifié,
2. quel comportement de la machine cela peut provoquer,
3. si ce comportement conduit à une situation dangereuse ou à un événement dangereux,
4. quelle tâche et quelle zone dangereuse sont concernées,
5. quelle conséquence possible a été identifiée dans l’analyse ISO 12100,
6. quelle mesure de réduction du risque doit interrompre le développement du scénario,
7. si cette mesure reste efficace après la prise de contrôle du composant attaqué.

Ce dernier point est le plus important.

Car si l’attaque et la protection dépendent :

• du même automate,
• du même compte,
• du même réseau,
• du même poste d’ingénierie,
• ou du même programme,

alors il est possible que nous n’ayons pas deux couches de protection indépendantes.

Nous avons une seule couche décrite dans deux documents.

Nous n’avons donc pas besoin d’un tableau unique et gigantesque intitulé :

« analyse des risques safety & cybersecurity ».

Nous avons besoin de deux analyses correctes, réalisées avec les méthodes appropriées, ainsi que d’un point d’interface maîtrisé entre elles.

ISO 12100 doit décrire la personne, la tâche, la source de danger, la zone, la situation dangereuse, l’événement dangereux et le dommage possible.

IEC 62443 doit aider à décrire le système, ses zones, ses canaux de communication, ses actifs, ses menaces, ses vulnérabilités, ses chemins d’attaque et les protections requises.

Et le fabricant doit démontrer si le scénario issu de la seconde analyse peut déclencher le scénario de la première ou priver d’efficacité la mesure censée l’arrêter.

Une cyberattaque n’a pas besoin de créer un nouveau danger. Il suffit qu’elle ouvre une nouvelle voie vers un accident déjà connu.

4. Un pentest avant le FAT est une photo. Le CRA exige un film

Dans de nombreux projets, la cybersécurité n’apparaît que deux semaines avant le FAT.

Un pentest est commandé.

Un rapport est produit.

Les vulnérabilités critiques sont corrigées, les vulnérabilités moyennes sont acceptées, puis le document est classé dans le dossier du projet.

La machine est cybersécurisée.

Jusqu’au mardi suivant.

Un pentest peut constituer un élément de vérification très utile. Il montre toutefois l’état d’une version précise du produit, dans une configuration donnée et au moyen de scénarios de test déterminés.

Il ne répond pas à la question de savoir ce que fera ensuite le fabricant.

Or le CRA exige une approche continue sur l’ensemble du cycle de vie du produit. L’analyse du risque de cybersécurité doit influencer la planification, la conception, le développement, la production, la livraison et la maintenance du produit. Après sa mise sur le marché, le fabricant doit traiter les vulnérabilités pendant la période de support déclarée.

Revenons à la machine d’emballage de légumes.

La machine a passé le FAT.

Le pentest n’a révélé aucune vulnérabilité critique.

Huit mois plus tard, le fabricant du routeur de service publie une information sur une vulnérabilité permettant la prise de contrôle de l’équipement.

Et c’est là que le vrai travail commence.

Quelles machines livrées sont équipées de ce modèle de routeur ?

Quelle version du firmware a été installée sur chaque exemplaire ?

L’accès à distance est-il actif ?

La vulnérabilité est-elle exploitable dans la configuration réelle ?

La prise de contrôle du routeur donne-t-elle accès uniquement au diagnostic, ou aussi à l’HMI, au PLC, aux variateurs et au safety PLC ?

Est-il seulement possible de lire les données, ou aussi de modifier le programme ou les paramètres ?

L’attaque peut-elle affecter une fonction de sécurité ?

Le fournisseur a-t-il mis à disposition un correctif ?

La mise à jour du routeur modifiera-t-elle les certificats, les règles de communication ou la manière d’établir le tunnel ?

Après une mise à jour, faut-il revérifier le service à distance, la communication et une partie des fonctions de sécurité ?

Quels clients faut-il informer ?

Et la situation remplit-elle les critères de déclaration d’une vulnérabilité activement exploitée ou d’un incident grave ?

Le rapport de test d’intrusion réalisé avant le FAT ne répond à aucune de ces questions.

Il décrit une machine qui n’existe déjà plus.

Car depuis l’évaluation, les versions logicielles, les configurations, l’environnement utilisateur et l’état des connaissances sur les vulnérabilités ont changé.

C’est pourquoi le fabricant n’a pas seulement besoin d’un test, mais d’un processus :

• identifier les versions du matériel, du firmware et du logiciel dans chaque exemplaire livré,
• surveiller les informations relatives aux vulnérabilités,
• évaluer leur exploitabilité dans l’architecture réelle,
• vérifier les conséquences possibles pour le procédé et la sécurité de la machine,
• préparer et tester les mises à jour,
• informer les utilisateurs,
• documenter les décisions prises,
• gérer les déclarations requises.

À compter du 11 septembre 2026, les fabricants auront l’obligation de déclarer les vulnérabilités activement exploitées ainsi que les incidents graves ayant une incidence sur la sécurité des produits comportant des éléments numériques. Une alerte préliminaire devra être transmise dans les 24 heures, puis la déclaration complète dans les 72 heures.

Cela signifie qu’après la détection d’un problème, il ne sera plus temps de commencer à chercher :

« Qui a fabriqué ce routeur, au juste, et où avons-nous la liste des machines dans lesquelles nous l’avons installé ? »

IEC 62443-4-1 montre bien la différence entre la sécurisation ponctuelle d’un produit et un cycle de développement sécurisé. Elle couvre non seulement la conception et la vérification, mais aussi la gestion des défauts, des correctifs et de la fin de vie du produit.

Le FAT peut donc clore une phase du projet.

Il ne clôt pas le cycle de vie du produit.

Il ne met pas fin à la période de support.

Il ne met pas fin à la surveillance des vulnérabilités.

Et il ne fige pas la configuration du jour de la réception pour les quinze années suivantes.

La machine peut emballer des légumes pour des supermarchés pendant longtemps.

Mais le fabricant ne peut pas emballer sa cybersécurité avec la notice, la filmer sous plastique et considérer qu’elle a été livrée une fois pour toutes.

Le test d’intrusion peut clore un point de la liste FAT. Le CRA ouvre un processus qui dure jusqu’à la fin de la période de support du produit.