If you run an industrial site, IEC 62443 eventually lands on your desk, often through a customer contract, an insurer, or a regulator. And once it does, the marketing claims start to blur together. Vendor after vendor describes a product as "IEC 62443 aligned" without saying what, precisely, it covers. For the person who has to answer an auditor, that is the wrong altitude.
IEC 62443 is a standard for an entire system, not for any single tool. So the useful question is narrower: when you add a network security layer like Cloudflare at the IT/OT boundary, which of the standard's requirements does it actually contribute to, and which ones remain someone else's job?
A Cloudflare boundary architecture contributes to four of IEC 62443's seven foundational requirements: FR1 (identification and authentication control), FR2 (use control), FR5 (restricted data flow) and FR7 (resource availability). System integrity (FR3) and timely response to events (FR6) depend on visibility inside the OT network and stay with OT-native monitoring. No product, Cloudflare included, is "IEC 62443 compliant" on its own.
This article maps each requirement to where it is actually addressed, and is honest about where Cloudflare stops.
What IEC 62443 actually requires: the seven foundational requirements
IEC 62443 is the international standard for the cybersecurity of industrial automation and control systems (IACS). Rather than prescribe products, it organises security around two ideas: zones (groups of assets that share the same security needs) and conduits (the controlled communication paths between those zones). The standard then defines seven foundational requirements that any secure industrial system has to satisfy:
- FR1, Identification and authentication control: identify and authenticate every user, process and device before granting access.
- FR2, Use control: enforce what an authenticated entity is allowed to do, and nothing more.
- FR3, System integrity: protect the integrity of the IACS software and firmware against unauthorised change.
- FR4, Data confidentiality: protect the confidentiality of information, in transit and at rest.
- FR5, Restricted data flow: segment the system into zones and conduits, and control the flows between them.
- FR6, Timely response to events: detect security events and respond before they escalate.
- FR7, Resource availability: keep the control system available, including under attack.
Each requirement is then assigned a target Security Level (SL 1 to 4), depending on how determined an attacker you need to resist. The level is set for the system as a whole, never for a single product.
Why "IEC 62443 compliant" is a claim to read carefully
A product cannot, by itself, be "IEC 62443 compliant." The standard certifies systems and the processes that build and operate them, against a defined Security Level. A firewall, a monitoring platform or a network layer can *support* specific requirements at a given level, but compliance is a property of the whole system: people, process and technology together.
This distinction is not pedantic. It is the difference between a defensible audit position and a claim that falls apart on the first question. When a vendor says "we make you IEC 62443 compliant," the honest reading is "we contribute to some of the requirements." The value is in knowing exactly which ones.
Which foundational requirements a Cloudflare boundary architecture supports
A Cloudflare deployment at the IT/OT boundary contributes to four foundational requirements. The mapping below is deliberately conservative: it claims only what a network and access layer can genuinely demonstrate.
FR1, Identification and authentication control. Cloudflare Access applies Zero Trust Network Access (ZTNA): it verifies identity and device posture on every request before granting access to a specific system, and supports mutual TLS (mTLS) for machine-to-machine authentication. At the boundary, every connection into the OT-adjacent environment is identified and authenticated, which is exactly what FR1 asks for at that layer.
FR2, Use control. Access grants reach to one authorised system rather than to the network, which is least-privilege by design. Combined with Cloudflare Gateway policies that constrain what authenticated traffic can do, this enforces the "authorised use only" intent of FR2 on traffic crossing the boundary.
FR5, Restricted data flow. This is where the zone-and-conduit model lives. Cloudflare WAN (formerly Magic WAN) uses virtual networks to keep traffic isolated between environments, defining conduits in software rather than in physical cabling. Cloudflare Tunnel makes the connection outbound-only, so a site exposes no inbound port at all. Together they implement restricted data flow at the boundary, the literal subject of FR5.
FR7, Resource availability. Cloudflare Magic Transit absorbs volumetric distributed denial-of-service (DDoS) attacks across a network that exceeds 500 Tbps of capacity, keeping the boundary reachable when it is targeted. This addresses the availability of the network path, which is one part of what FR7 requires.
A Cloudflare boundary architecture contributes to FR1, FR2, FR5 and FR7 of IEC 62443 at the network boundary. It does not, and should not be claimed to, satisfy these requirements inside the OT equipment itself.
For the capability-level detail behind each of these, see our breakdown of how Cloudflare secures the IT/OT boundary, feature by feature.
Which requirements stay outside the network boundary
Being precise about what Cloudflare does means being equally precise about what it does not.
FR3, System integrity concerns the integrity of the IACS software and firmware: the code running on programmable logic controllers, on engineering workstations, on the control system itself. That is a device-level property. A network boundary protects the transport between systems; it does not verify the integrity of what runs inside them. Cloudflare does not address FR3, and a careful audit position should not claim it.
FR4, Data confidentiality is partially and indirectly touched. Traffic crossing Cloudflare is encrypted in transit, which is supportive. But FR4 is broader than transport: it covers confidentiality of data at rest and on the equipment, which sits outside a boundary layer. We treat the FR4 contribution as accessory, not as coverage.
The two requirements that a network boundary cannot reach, FR3 and FR6, are precisely the ones that depend on visibility *inside* the OT network. As an analytical reading (not a vendor's published certification), this is the territory of OT-native monitoring platforms: they discover assets, inspect industrial protocols such as Modbus, DNP3 and S7, and detect process anomalies and intrusions, which is what FR3 (detecting unauthorised system change) and FR6 (timely detection and response) require in practice. Where each layer fits is the subject of our comparison of Cloudflare and OT-native vendors.
The seven foundational requirements, mapped to a Cloudflare boundary
The table below summarises the full picture. It is a contribution map, not an attestation of compliance: it shows where a Cloudflare boundary architecture helps, where it is accessory, and where the gap stays with another layer.
| Foundational requirement | What the requirement asks for | Cloudflare boundary contribution | Where the gap remains |
|---|---|---|---|
| FR1 Identification and authentication control | Authenticate every access | Access (ZTNA) and mTLS verify identity and posture per request | Authentication internal to the controllers |
| FR2 Use control | Restrict privileges to authorised use | Access least-privilege plus Gateway policies | Application-level use control on the device |
| FR3 System integrity | Protect IACS software and firmware integrity | Not addressed (outside the boundary) | OT-native monitoring (analytical reading) |
| FR4 Data confidentiality | Protect data confidentiality | Encryption in transit (accessory only) | Confidentiality at rest and on the device |
| FR5 Restricted data flow | Segment zones and control conduits | Cloudflare WAN virtual networks plus outbound-only Tunnel | Physical segmentation inside a zone |
| FR6 Timely response to events | Detect and respond to security events | Not addressed (requires internal visibility) | OT-native monitoring (analytical reading) |
| FR7 Resource availability | Maintain availability under attack | Magic Transit absorbs volumetric DDoS | Physical resilience of the process |
A note on the table: "OT-native monitoring (analytical reading)" reflects how these platforms typically work, not an official IEC 62443 mapping published by any specific vendor.
Expert tip: document each IEC 62443 conduit as a Cloudflare WAN virtual network from the design stage. The mapping then becomes audit evidence rather than something reconstructed afterward from switch configurations.
Need to show an auditor exactly which IEC 62443 requirements your network layer covers? Brixio produces the mapping as part of the deployment. → Request an IEC 62443 compliance mapping
IEC 62443 and NIS2: how the two reinforce each other
For industrial operators in the European Union, IEC 62443 rarely arrives alone. The NIS2 Directive sets the regulatory obligation to manage cybersecurity risk for essential and important entities, but it does not prescribe the technical detail of how. IEC 62443 supplies that detail on the OT side: it is the recognised technical reference for securing industrial control systems.
In practice, the two work as a pair. NIS2 defines what you are accountable for; IEC 62443 gives you a defensible technical framework to demonstrate it. A Cloudflare boundary that documents its FR1, FR2, FR5 and FR7 contributions feeds directly into the evidence an organisation needs for NIS2 compliance, and is particularly relevant for regulated sectors such as manufacturing, energy and transport.
How Brixio builds an IEC 62443-aligned Cloudflare boundary
As a Cloudflare Authorised Service Delivery Partner (ASDP), Brixio deploys the boundary layer as an overlay: it sits around the existing equipment without modifying the controllers and without interrupting production. The method runs in four phases:
- Audit and discovery: map the real zones, conduits and traffic flows, including the unmanaged devices and shadow connections that the documentation misses.
- Architecture: translate the IEC 62443 zones and conduits into Cloudflare policy, so segmentation is enforced in software rather than inferred from hardware.
- Documentation and mapping: produce the requirement-by-requirement mapping that supports an audit, with the boundaries stated honestly.
- Continuous operation: keep the policies aligned as the environment and the regulations evolve.
The limit stays clear throughout. Brixio delivers the network and access controls, and the traceability behind them. Full IEC 62443 certification is a programme that spans people, process and the OT equipment itself, not the network layer alone. For the wider picture, see our IT/OT convergence security solution. Within the cluster, this complements the difference between IT and OT security, how Zero Trust modernises the Purdue zones and conduits, and what the 2026 threat data shows about where the risk concentrates.
Frequently asked questions
No. IEC 62443 applies to the complete industrial automation and control system and to the processes that build and run it, against a target Security Level. A product supports specific requirements at a given level; it is not "compliant" in isolation. Compliance is a property of the whole system.
Four of the seven, at the network boundary: FR1 (identification and authentication control), FR2 (use control), FR5 (restricted data flow) and FR7 (resource availability).
No. Both depend on visibility inside the OT network: detecting unauthorised changes and process anomalies. That is the role of OT-native monitoring, which operates alongside the boundary layer rather than being replaced by it.
They are complementary. NIS2 sets the regulatory obligation to manage cyber risk; IEC 62443 provides the recognised technical framework, on the OT side, to meet it.
Map your IEC 62443 boundary
Brixio assesses your zones and conduits and documents exactly which IEC 62443 requirements your Cloudflare boundary covers, before any deployment.
Primary CTA: Request an IEC 62443 compliance mapping
Secondary CTA: Book an industrial security assessment
