Quand on exploite un site industriel, la norme IEC 62443 finit toujours par s'imposer : un cahier des charges client, un assureur, ou le régulateur la mettent sur la table. Et dès qu'elle arrive, les arguments commerciaux se brouillent. Un éditeur après l'autre présente son produit comme « aligné IEC 62443 » sans jamais préciser ce qu'il couvre réellement. Pour qui doit répondre à un auditeur, ce niveau de discours ne suffit pas.
IEC 62443 est une norme qui s'applique à un système complet, pas à un outil isolé. La vraie question est donc plus précise : lorsqu'on ajoute une couche de sécurité réseau comme Cloudflare à la frontière IT/OT, à quelles exigences de la norme contribue-t-elle concrètement, et lesquelles restent du ressort d'un autre dispositif ?
Une architecture de frontière Cloudflare contribue à quatre des sept exigences fondamentales d'IEC 62443 : FR1 (contrôle d'identification et d'authentification), FR2 (contrôle d'utilisation), FR5 (restriction des flux de données) et FR7 (disponibilité des ressources). L'intégrité système (FR3) et la réponse aux événements (FR6) dépendent d'une visibilité à l'intérieur du réseau OT et relèvent de la supervision OT native. Aucun produit, Cloudflare compris, n'est « conforme IEC 62443 » à lui seul.
Cet article situe chaque exigence là où elle est réellement traitée, et reste franc sur les limites de Cloudflare.
Ce que la norme IEC 62443 exige vraiment : les sept exigences fondamentales
IEC 62443 est la norme internationale de cybersécurité des systèmes d'automatisation et de contrôle industriels (IACS). Plutôt que de prescrire des produits, elle organise la sécurité autour de deux notions : les zones (groupes d'actifs partageant les mêmes besoins de sécurité) et les conduits (les canaux de communication contrôlés entre ces zones). La norme définit ensuite sept exigences fondamentales (Foundational Requirements, FR) que tout système industriel sûr doit satisfaire :
- FR1, contrôle d'identification et d'authentification : identifier et authentifier chaque utilisateur, processus et équipement avant d'accorder un accès.
- FR2, contrôle d'utilisation : appliquer ce qu'une entité authentifiée a le droit de faire, et rien de plus.
- FR3, intégrité du système : protéger l'intégrité du logiciel et du micrologiciel de l'IACS contre toute modification non autorisée.
- FR4, confidentialité des données : protéger la confidentialité de l'information, en transit comme au repos.
- FR5, restriction des flux de données : segmenter le système en zones et conduits, et maîtriser les flux entre eux.
- FR6, réponse en temps utile aux événements : détecter les événements de sécurité et réagir avant qu'ils ne s'aggravent.
- FR7, disponibilité des ressources : maintenir le système de contrôle disponible, y compris sous attaque.
Chaque exigence se voit ensuite attribuer un niveau de sécurité cible (SL 1 à 4), selon la détermination de l'attaquant face auquel il faut tenir. Ce niveau se fixe pour le système dans son ensemble, jamais pour un produit isolé.
« Conforme IEC 62443 » : une formule à lire avec prudence
Un produit ne peut pas, à lui seul, être « conforme IEC 62443 ». La norme certifie des systèmes et les processus qui les construisent et les exploitent, par rapport à un niveau de sécurité défini. Un pare-feu, une plateforme de supervision ou une couche réseau peuvent *contribuer* à des exigences précises à un niveau donné, mais la conformité est une propriété de l'ensemble : personnes, processus et technologie réunis.
La distinction n'a rien d'un détail. C'est ce qui sépare une position d'audit défendable d'une affirmation qui s'effondre à la première question. Quand un éditeur dit « nous vous rendons conforme IEC 62443 », la lecture honnête est « nous contribuons à certaines des exigences ». Toute la valeur tient à savoir lesquelles, exactement.
Les exigences fondamentales qu'une architecture de frontière Cloudflare prend en charge
Un déploiement Cloudflare à la frontière IT/OT contribue à quatre exigences fondamentales. Le mapping ci-dessous est volontairement prudent : il ne revendique que ce qu'une couche réseau et d'accès peut réellement démontrer.
FR1, contrôle d'identification et d'authentification. Cloudflare Access applique l'accès réseau Zero Trust (ZTNA) : il vérifie l'identité et la posture de l'équipement à chaque requête avant d'accorder l'accès à un système précis, et prend en charge le TLS mutuel (mTLS) pour l'authentification entre machines. À la frontière, chaque connexion vers l'environnement adjacent à l'OT est identifiée et authentifiée, ce qu'exige précisément FR1 à ce niveau.
FR2, contrôle d'utilisation. Access donne accès à un seul système autorisé, et non au réseau : c'est le moindre privilège par construction. Combiné aux politiques de Cloudflare Gateway qui encadrent ce que le trafic authentifié peut faire, il applique l'intention « usage autorisé uniquement » de FR2 sur le trafic qui franchit la frontière.
FR5, restriction des flux de données. C'est là que vit le modèle zones et conduits. Cloudflare WAN (anciennement Magic WAN) utilise des réseaux virtuels pour isoler le trafic entre environnements, définissant les conduits en logiciel plutôt qu'en câblage physique. Cloudflare Tunnel rend la connexion sortante uniquement : le site n'expose plus aucun port entrant. Ensemble, ils mettent en œuvre la restriction des flux à la frontière, l'objet même de FR5.
FR7, disponibilité des ressources. Cloudflare Magic Transit absorbe les attaques par déni de service distribué (DDoS) volumétriques sur un réseau qui dépasse 500 Tbit/s de capacité, maintenant la frontière joignable lorsqu'elle est visée. Cela traite la disponibilité du chemin réseau, qui est une partie de ce qu'exige FR7.
Une architecture de frontière Cloudflare contribue à FR1, FR2, FR5 et FR7 d'IEC 62443 à la frontière du réseau. Elle ne satisfait pas, et il ne faut pas le prétendre, ces exigences à l'intérieur des équipements OT eux-mêmes.
Pour le détail capacité par capacité, voir notre analyse de la sécurisation de la frontière IT/OT par Cloudflare, fonctionnalité par fonctionnalité.
Les exigences qui restent hors de la frontière réseau
Être précis sur ce que fait Cloudflare suppose de l'être tout autant sur ce qu'il ne fait pas.
FR3, intégrité du système porte sur l'intégrité du logiciel et du micrologiciel de l'IACS : le code qui tourne sur les automates programmables, sur les postes d'ingénierie, sur le système de contrôle lui-même. C'est une propriété au niveau de l'équipement. Une frontière réseau protège le transport entre systèmes ; elle ne vérifie pas l'intégrité de ce qui s'exécute à l'intérieur. Cloudflare ne traite pas FR3, et une position d'audit rigoureuse ne doit pas le revendiquer.
FR4, confidentialité des données n'est touchée que partiellement et indirectement. Le trafic qui passe par Cloudflare est chiffré en transit, ce qui aide. Mais FR4 va au-delà du transport : elle couvre la confidentialité des données au repos et sur l'équipement, qui se situe hors d'une couche de frontière. Nous traitons la contribution à FR4 comme accessoire, pas comme une couverture.
Les deux exigences qu'une frontière réseau ne peut pas atteindre, FR3 et FR6, sont justement celles qui dépendent d'une visibilité *à l'intérieur* du réseau OT. En lecture analytique (et non comme une certification publiée par un éditeur), c'est le territoire des plateformes de supervision OT natives : elles découvrent les actifs, inspectent les protocoles industriels comme Modbus, DNP3 et S7, et détectent les anomalies de procédé et les intrusions, soit ce qu'exigent en pratique FR3 (détecter une modification non autorisée du système) et FR6 (détection et réponse en temps utile). La place de chaque couche fait l'objet de notre comparatif Cloudflare et éditeurs OT natifs.
Les sept exigences fondamentales, mappées sur une frontière Cloudflare
Le tableau ci-dessous résume l'ensemble. C'est une carte des contributions, pas une attestation de conformité : il montre où une architecture de frontière Cloudflare aide, où elle est accessoire, et où le vide reste à combler par une autre couche.
| Exigence fondamentale | Ce que l'exigence demande | Contribution frontière Cloudflare | Où le vide subsiste |
|---|---|---|---|
| FR1 Contrôle d'identification et d'authentification | Authentifier chaque accès | Access (ZTNA) et mTLS vérifient identité et posture à chaque requête | Authentification interne aux automates |
| FR2 Contrôle d'utilisation | Restreindre les privilèges à l'usage autorisé | Moindre privilège Access et politiques Gateway | Contrôle d'usage applicatif sur l'équipement |
| FR3 Intégrité du système | Protéger l'intégrité logiciel et micrologiciel de l'IACS | Non traité (hors frontière) | Supervision OT native (lecture analytique) |
| FR4 Confidentialité des données | Protéger la confidentialité des données | Chiffrement en transit (accessoire) | Confidentialité au repos et sur l'équipement |
| FR5 Restriction des flux de données | Segmenter les zones, maîtriser les conduits | Réseaux virtuels Cloudflare WAN et Tunnel sortant uniquement | Segmentation physique au sein d'une zone |
| FR6 Réponse en temps utile aux événements | Détecter et répondre aux événements de sécurité | Non traité (exige une visibilité interne) | Supervision OT native (lecture analytique) |
| FR7 Disponibilité des ressources | Maintenir la disponibilité sous attaque | Magic Transit absorbe les DDoS volumétriques | Résilience physique du procédé |
Une précision sur le tableau : « supervision OT native (lecture analytique) » décrit le fonctionnement habituel de ces plateformes, et non un mapping IEC 62443 officiel publié par un éditeur donné.
Conseil d'expert : documentez chaque conduit IEC 62443 comme un réseau virtuel Cloudflare WAN dès la conception. Le mapping devient alors une preuve d'audit, et non quelque chose à reconstruire après coup depuis les configurations des commutateurs.
Besoin de montrer à un auditeur les exigences IEC 62443 que votre couche réseau couvre exactement ? Brixio produit le mapping dans le cadre du déploiement. → Demander un mapping IEC 62443
IEC 62443 et NIS2 : comment les deux se renforcent
Pour les exploitants industriels de l'Union européenne, IEC 62443 arrive rarement seule. La directive NIS2 fixe l'obligation réglementaire de gérer le risque cyber pour les entités essentielles et importantes, mais elle ne prescrit pas le détail technique de la mise en œuvre. IEC 62443 apporte ce détail côté OT : c'est la référence technique reconnue pour sécuriser les systèmes de contrôle industriels.
En pratique, les deux fonctionnent en binôme. NIS2 définit ce dont vous êtes responsable ; IEC 62443 fournit un cadre technique défendable pour le démontrer. Une frontière Cloudflare qui documente ses contributions à FR1, FR2, FR5 et FR7 alimente directement les preuves attendues au titre de la conformité NIS2, et concerne particulièrement les secteurs régulés comme l'industrie, l'énergie et le transport.
Comment Brixio construit une frontière Cloudflare alignée IEC 62443
En tant qu'Authorized Service Delivery Partner (ASDP) Cloudflare, Brixio déploie la couche de frontière en surcouche (overlay) : elle s'installe autour des équipements existants, sans modifier les automates ni interrompre la production. La méthode se déroule en quatre phases :
- Audit et découverte : cartographier les zones, conduits et flux réels, y compris les équipements non gérés et les connexions cachées que la documentation oublie.
- Architecture : traduire les zones et conduits IEC 62443 en politiques Cloudflare, pour que le cloisonnement soit appliqué en logiciel plutôt que déduit du matériel.
- Documentation et mapping : produire le mapping exigence par exigence qui appuie un audit, avec des limites énoncées franchement.
- Exploitation continue : maintenir l'alignement des politiques à mesure que l'environnement et la réglementation évoluent.
La limite reste claire d'un bout à l'autre. Brixio livre les contrôles réseau et d'accès, et la traçabilité qui les accompagne. Une certification IEC 62443 complète est un programme qui couvre les personnes, les processus et les équipements OT eux-mêmes, pas la seule couche réseau. Pour le cadre d'ensemble, voir notre solution de sécurité de la convergence IT/OT. Dans la série, cet article complète la différence entre sécurité IT et OT, la façon dont le Zero Trust modernise les zones et conduits de Purdue, et ce que les données de menace 2026 révèlent sur la concentration du risque.
Questions fréquentes
Non. IEC 62443 s'applique au système d'automatisation et de contrôle industriel complet et aux processus qui le construisent et l'exploitent, par rapport à un niveau de sécurité cible. Un produit prend en charge des exigences précises à un niveau donné ; il n'est pas « conforme » isolément. La conformité est une propriété de l'ensemble du système.
À quatre des sept, à la frontière du réseau : FR1 (contrôle d'identification et d'authentification), FR2 (contrôle d'utilisation), FR5 (restriction des flux de données) et FR7 (disponibilité des ressources).
Non. Les deux dépendent d'une visibilité à l'intérieur du réseau OT : détecter les modifications non autorisées et les anomalies de procédé. C'est le rôle de la supervision OT native, qui opère aux côtés de la couche de frontière au lieu d'être remplacée par elle.
Elles sont complémentaires. NIS2 fixe l'obligation réglementaire de gérer le risque cyber ; IEC 62443 fournit, côté OT, le cadre technique reconnu pour y répondre.
Cartographiez votre frontière IEC 62443
Brixio évalue vos zones et conduits et documente exactement les exigences IEC 62443 que votre frontière Cloudflare couvre, avant tout déploiement.
CTA principal : Demander un mapping IEC 62443
CTA secondaire : Demander un diagnostic sécurité industrielle
