Sécurité OT 2026 : pourquoi il faut lire conjointement l’IEC 62443 et l’acte européen sur la cybersécurité

La sécurité OT connaît en 2026 une impulsion réglementaire que beaucoup de fabricants sous-estiment encore. Le Cyber Resilience Act de l’UE exige à partir de juin 2026 un reporting des vulnérabilités pour tous les produits numériques. L’obligation de gestion du cycle de vie entre en vigueur en décembre 2027. La norme IEC 62443 est le seul standard largement répandu qui fournit le cadre technique nécessaire. Pour les équipes de sécurité dans la construction mécanique, l’énergie et l’industrie des procédés, cela signifie : les zones, les conduits et la segmentation basée sur les risques ne sont plus des options.

En relationDORA après 15 mois : enseignements des premiers audits  /  Windows Defender : BlueHammer et RedSun actifs

Ce que la norme IEC 62443 exige réellement sur le plan technique

Qu’est-ce que l’IEC 62443 ? La série IEC 62443 est une norme internationale dédiée à la cybersécurité des systèmes industriels d’automatisation et de contrôle (IACS). Elle définit des rôles (propriétaire d’actifs, intégrateur, fabricant de produits), quatre niveaux de sécurité (SL 1 à SL 4), des concepts de zones avec des conduits entre elles, ainsi qu’un cycle de vie complet allant de l’analyse des risques à l’exploitation. Pour les entreprises soumises au CRA, elle constitue le guide technique sur lequel peuvent être projetées les obligations du CRA.

Le cœur pratique de la norme repose sur deux concepts. Premièrement : les zones. Une zone est un groupe logique d’actifs partageant les mêmes exigences de sécurité. Elle ne doit pas nécessairement s’aligner sur des frontières physiques, mais s’oriente en fonction du profil de risque. Un robot sur la ligne de production A et un robot sur la ligne de production B peuvent appartenir à la même zone s’ils présentent les mêmes besoins de protection. Deuxièmement : les conduits. Toute communication entre les zones passe par un conduit défini, où sont appliqués authentification, filtrage et inspection. Sans conduits, aucune communication autorisée entre les zones.

Les niveaux de sécurité s’emboîtent les uns dans les autres. Le SL 1 couvre les menaces accidentelles, le SL 2 les attaques intentionnelles avec des moyens simples, le SL 3 les attaques utilisant des techniques sophistiquées et des ressources modérées, et le SL 4 les attaquants financés par des États avec des moyens élevés. Chaque actif se voit attribuer un niveau SL cible, dérivé de l’analyse des risques. L’écart entre le SL actuel et le SL cible définit la feuille de route des investissements.

Pourquoi le modèle Purdue atteint ses limites en 2026

Le Purdue Enterprise Reference Architecture Model (PERA) a dominé les discussions sur la sécurité OT pendant des décennies. Cette vision hiérarchique, avec ses niveaux 0 à 5 (processus, contrôle, supervision, opérations, entreprise), constituait un modèle pratique tant que les environnements de production étaient clairement séparés verticalement. En 2026, cette logique ne correspond plus tout à fait à la réalité. Les capteurs IIoT envoient des données directement dans le cloud, sautant plusieurs niveaux. Les accès de maintenance à distance connectent des techniciens externes à des systèmes de niveau 1. Les plateformes de jumeaux numériques extraient des données brutes des couches inférieures pour les agréger dans des systèmes d’analyse supérieurs.

L’IEC 62443 répond à ces enjeux avec le modèle des zones. Les actifs sont regroupés en fonction de leurs besoins de protection, et non selon leur niveau hiérarchique. Cela permet des structures flexibles : une station d’ingénierie peut se trouver dans une zone différente de celle du poste HMI voisin si leurs exigences de sécurité diffèrent. Une passerelle cloud peut rester au sein de la zone réseau de production, à condition que ses conduits soient clairement définis. La mise en œuvre est plus exigeante, mais elle reflète mieux la réalité actuelle.

De nombreuses PME ont, ces dernières années, construit un mélange de terminologie Purdue et d’analyses de risques ponctuelles, par manque de ressources. Avec le CRA et la NIS2, cette approche hybride deviendra un obstacle à la conformité en 2026. Les échanges avec les autorités de surveillance porteront sur des définitions claires de zones, et non sur des diagrammes de niveaux. Sans une cartographie des zones, des faiblesses documentées apparaîtront dans les rapports d’audit.

La bonne nouvelle : la transition du modèle Purdue vers les zones IEC 62443 ne nécessite pas un recommencement complet. Les segments réseau existants peuvent être traduits en zones dès lors que les besoins de protection par actif sont documentés. Le changement conceptuel réside dans la manière de penser : au lieu de regrouper par hiérarchie, on regroupe par profil de risque. C’est cette approche qui fait la différence lors des audits et dans la réaction aux incidents concrets, car les attaquants ne procèdent que rarement de manière hiérarchique. Ils cherchent des vulnérabilités là où elles se trouvent.

Ce que signifie l’héritage de l’air gap dans la pratique

La promesse de l’air gap s’est évaporée ces cinq dernières années dans la plupart des usines de production allemandes. Les raisons sont claires : la maintenance prédictive nécessite des flux de données vers le cloud. Le support à distance des fabricants exige un accès aux installations. Le contrôle qualité numérique extrait les données de mesure des lignes. Et la comptabilité industrielle a besoin des données de consommation et de production en temps réel. Chacune de ces connexions dissout un peu plus l’air gap.

La réalité est que les réseaux OT modernes sont connectés aux systèmes informatiques et aux partenaires externes via de nombreuses interfaces. La ligne de démarcation ne passe plus entre l’IT et l’OT, mais entre différentes zones de risque au sein d’un réseau commun. La mission des équipes de sécurité consiste à définir explicitement ces zones, à surveiller les conduits entre elles et à détecter précocement les attaques qui traversent ces zones.

Le processus de gestion des correctifs spécifique à l’OT est l’un des facteurs de succès sous-estimés. Les correctifs IT classiques sont déployés à un rythme hebdomadaire, ce que les systèmes OT ne supportent pas. Une ligne de production en activité, patchée tous les sept jours, risque des problèmes de qualité et de disponibilité. L’approche IEC-62443 consiste à intégrer les correctifs dans les fenêtres de maintenance, à renforcer les mesures compensatoires (segmentation, surveillance) en cas de vulnérabilités critiques et à documenter les décisions de gestion des risques. Le contre-exemple est d’appliquer des correctifs urgents sans concertation avec les responsables de production.

Comment les équipes sécurité peuvent amorcer le processus dès maintenant

Pour les équipes sécurité qui seront soumises en 2026 à la pression du CRA ou tenues de s’inscrire au titre de NIS2, un plan en quatre phases s’est imposé. Première phase : l’inventaire des équipements. Identifier qui possède quels appareils, leurs niveaux de firmware, leurs connexions réseau, ainsi que leurs dépendances vis-à-vis de partenaires externes. Sans cette base, toute décision ultérieure tombe à plat. Deuxième phase : l’analyse des risques par groupe d’actifs. Quels scénarios de menace sont réalistes ? Quelles pannes auraient un impact sur l’activité ? Quel niveau de sécurité est requis ? Troisième phase : la conception des zones et la définition des conduits. C’est ici que les concepts IEC-62443 sont appliqués concrètement à l’environnement propre à l’entreprise. Quatrième phase : la mise en œuvre technique et l’exploitation continue.

La troisième phase constitue souvent un goulot d’étranglement, car elle exige un langage commun entre les spécialistes de la sécurité IT, les ingénieurs OT et les responsables de production. La sécurité IT pense en termes de pare-feux et de politiques d’accès, l’OT en termes d’interfaces et de rythmes de maintenance. Les responsables de production, eux, pensent disponibilité et débit. Un format d’atelier commun réunissant ces trois groupes s’avère être la méthode la plus pratique. Il faut généralement trois à cinq jours de travail ciblé, complétés par deux à quatre semaines de suivi, pour établir une première cartographie de zones fiable.

Un élément souvent négligé dans la troisième phase est la documentation des conduits. Toute communication entre zones doit être répertoriée, avec protocole utilisé, fréquence, équipements concernés et responsabilités associées. Cette liste est explicitement exigée par les auditeurs et constitue la base de toute extension ultérieure. Celui qui ne documente pas ses conduits perd le contrôle de ses surfaces d’attaque dès qu’apparaissent de nouvelles connexions. Une liste vivante est plus importante qu’un schéma esthétique ponctuel, car la réalité OT évolue en continu et de nouvelles connexions s’ajoutent régulièrement.

Sur le plan technologique, la situation s’est nettement assouplie en 2026. Des pare-feux dédiés à l’OT, des systèmes de détection d’intrusion réseau (NIDS) et des SIEM sont disponibles, souvent compatibles avec les protocoles OT courants (Modbus, OPC UA, PROFINET, EtherNet/IP). Des éditeurs comme Claroty, Nozomi Networks, Dragos, Tenable OT ou Cisco Cyber Vision répondent à ces besoins. Le choix dépend de l’infrastructure existante et de la taille du périmètre OT. Pour les PME disposant d’un nombre limité d’installations, une solution intégrée suffit souvent ; les grands groupes optent généralement pour une stratégie multi-fournisseurs.

Ce qui comptera entre le CRA et la pression du marché d’ici 2026

Les échéances du CRA transforment la discussion sur la sécurité OT d’un simple atout à une obligation de marché. À partir de juin 2026, tous les produits numériques sur le marché de l’UE devront disposer de voies de signalement des vulnérabilités et documenter les failles découvertes dans des délais définis. À partir de décembre 2027, l’obligation de support tout au long du cycle de vie entrera en vigueur. Les fabricants devront fournir des mises à jour pendant une période déterminée, tandis que les propriétaires d’actifs devront prouver qu’ils les déploient. La norme IEC 62443 offre le seul cadre technique largement accepté permettant d’opérationnaliser ces obligations.

Pour les acheteurs de systèmes OT, cela signifie que les appels d’offres évolueront en 2026. Les certifications IEC 62443 des fabricants seront exigées, la conformité au CRA devra être démontrée, et les processus de gestion des vulnérabilités devront faire partie de l’offre. Les fabricants incapables de fournir cette documentation seront exclus des appels d’offres. Les propriétaires d’actifs qui n’exigeront pas ces preuves rencontreront des difficultés lors de leurs propres audits, car ils devront compenser ce que le fabricant ne fournit pas.

Un autre aspect concerne le rôle des prestataires externes. De nombreuses entreprises industrielles allemandes externalisent la maintenance, le support à distance et même une partie de leur surveillance de sécurité auprès de tiers. Ces fournisseurs relèvent des clauses de la chaîne d’approvisionnement de la directive NIS2 si leurs services sont critiques pour l’exploitation d’installations essentielles. Les propriétaires d’actifs doivent examiner les pratiques de sécurité de leurs prestataires et les documenter dans des avenants contractuels. Ceux qui ne le font pas de manière proactive hériteront, lors des audits, des vulnérabilités de leurs fournisseurs.

Par ailleurs, le paysage des certifications évolue. Le CRA sera renforcé par la European Cybersecurity Certification Group (ECCG) avec ses propres schémas, tandis que la norme IEC 62443 dispose de certifications ISA-Secure pour les produits et les installations. Ces preuves seront exigées dans les contrats B2B. Les fabricants qui ne disposeront pas des certifications appropriées d’ici fin 2026 perdront des appels d’offres. Les propriétaires d’actifs qui n’exigeront pas ces certifications prendront des risques de conformité cachés.

Un dernier aspect concerne la dimension des chaînes d’approvisionnement. Les systèmes OT se composent de centaines, voire de milliers de composants provenant de différentes sources. La Software Bill of Materials (SBOM) deviendra un artefact standard en 2026 pour assurer la transparence sur les composants utilisés. Les équipes de sécurité qui traitent correctement les SBOM et les comparent aux flux de vulnérabilités détecteront plus rapidement les failles dans leur propre parc. Sans une discipline rigoureuse en matière de SBOM, les nouvelles CVE dans les composants OT peuvent rester invisibles pendant des semaines, voire des mois.

Questions fréquentes

Chaque question est verrouillée. Un clic déverrouille la réponse.

Plus d’articles du réseau MBF Media