If you run an industrial environment, you have probably already deployed or evaluated an OT-native security platform such as Claroty, Dragos or Nozomi. At some point the question comes up: does Cloudflare replace that tool, or does the OT tool make Cloudflare unnecessary? The honest answer is neither. They are not competing products. They operate in different places and solve different problems.
Cloudflare and OT-native platforms such as Claroty, Dragos and Nozomi are not alternatives to each other. OT-native platforms work inside the OT network, where they discover assets, inspect industrial protocols and detect process anomalies. Cloudflare works around it, at the IT/OT boundary, where it controls access, segments zones, filters traffic and absorbs network attacks. Neither does the other's job, and a complete OT security programme uses both.
This article sets the two layers side by side: what each one does, where each one stops, and how they fit together.
Transparency note: Brixio is an Authorized Cloudflare Service Delivery Partner. We deploy the Cloudflare boundary layer and run it alongside whatever OT-native platform a client already uses. Our interest is in the two layers working together, not in replacing your monitoring tool. The comparison below starts from there and does not set out to push Cloudflare in place of OT tools.
What OT-native platforms actually do
They watch inside the OT network. The job is visibility: discovering assets, inspecting industrial protocols and spotting process anomalies.
OT-native monitoring platforms sit below the firewall, close to the controllers, where production runs.
They discover and inventory industrial assets (programmable logic controllers, human-machine interfaces, SCADA servers and the rest of the installed base), often without active scanning, because aggressive probing can disturb fragile equipment. They inspect industrial protocols such as Modbus, DNP3 and S7 in depth, which standard IT tools do not understand. From that baseline they detect process anomalies and known ICS (Industrial Control System) threats, and they feed vulnerability management for the OT estate.
That is a category description, not a ranking. Claroty, Dragos and Nozomi differ in how they go about it, but they share the same purpose: knowing what is inside the OT network and spotting when it behaves abnormally. What none of them is designed to do is secure the way people and systems connect to that network from outside.
What Cloudflare does at the IT/OT boundary
Cloudflare operates at the other end of the problem: the boundary where IT and OT now meet, and the connections that cross it. It does not look inside the OT process; it controls what reaches it.
Five capabilities cover that boundary.
- Cloudflare Access applies Zero Trust Network Access (ZTNA): it verifies identity and device posture on every request and grants access to a specific system rather than the whole network, which replaces the broad trust of a VPN.
- Cloudflare WAN (formerly Magic WAN) segments zones with virtual networks that isolate routing, and filters traffic at layers 3 and 4.
- Cloudflare Gateway filters DNS, network and HTTP traffic for OT-adjacent systems.
- Cloudflare Tunnel removes inbound exposure by making an outbound-only connection, with no public IP address.
- The Web Application Firewall (WAF) virtually patches exposed interfaces by blocking known exploits at the edge.
Beyond access, Cloudflare Magic Transit absorbs volumetric DDoS attacks across a global network that exceeds 500 Tbps of capacity.
The feature-by-feature detail is in our companion article on the five Cloudflare features that secure the IT/OT boundary. The point here is the position: Cloudflare secures the network around the OT environment, not the process inside it.
The gap each layer leaves
Set out plainly, each layer has a blind spot that the other fills.
An OT-native platform does not secure the boundary. It does not:
- provide secure remote and third-party access
- carry network transport between sites
- segment zones and conduits in software
- absorb a volumetric denial-of-service attack.
Those are network-boundary functions.
Cloudflare, in turn, does not look inside the OT process. It does not:
- inspect OT protocols
- discover or inventory industrial assets
- detect process anomalies from an OT baseline.
That requires sensors inside the operational network.
Network boundary security and OT-native monitoring cover two different surfaces: one secures the connections into and around the OT network, the other sees the assets and processes inside it. Neither covers both, which is why they are deployed together rather than chosen between.
Side by side: network boundary vs OT-native monitoring
On every dimension, the two layers complement each other: one sees inside the network, the other secures its perimeter.
The table below sets the two layers against the same set of dimensions. It describes categories, not specific products, and draws on the vendors' published platform documentation, Cloudflare's official product documentation and the IEC 62443 standard.
| Dimension | OT-native monitoring | Cloudflare network boundary |
|---|---|---|
| Where it operates | Inside the OT network, below the firewall | Around the OT network, at the IT/OT boundary |
| What it sees | Assets, industrial protocols, process behaviour | Connections, sessions and traffic at the edge |
| Core function | Asset discovery, inventory, ICS threat detection | ZTNA, segmentation, filtering, virtual patching, DDoS protection |
| How it deploys | Passive or active sensors (SPAN or TAP) | Overlay: agentless at the edge plus a cloudflared connector |
| Touches OT equipment | Monitors it (read only) | No, it sits around it |
| What it does not do | Secure access, transport, inter-zone segmentation, DDoS | Asset inventory, OT protocol inspection, ICS detection |
| Primary outcome | Visibility and anomaly detection | Access control and reduced exposure |
Not sure where your current OT tooling stops and where the network boundary starts? Brixio maps both layers against your environment before any deployment. → Book an OT Boundary Security Assessment
Already running Claroty, Dragos or Nozomi? Add Cloudflare as an overlay
If an OT-native platform is already in place, Cloudflare does not displace it. It is added as an overlay around the existing equipment, without touching the controllers and without interrupting production. The monitoring platform keeps doing what it does well, seeing inside the network, while Cloudflare locks down the access paths and the internet exposure at the boundary. The reverse holds too: a site that starts with Cloudflare at the boundary still needs internal visibility added later.
This pairs naturally with sector work in energy and manufacturing, where converged sites often have monitoring in place but inherit a weak network boundary.
Expert tip: start by mapping what your OT-native platform cannot see, third-party remote access, inter-zone flows and internet exposure. That blind spot is exactly the perimeter the Cloudflare layer is there to lock down.
Reading it through IEC 62443: complementary, not overlapping
Against IEC 62443, the two layers satisfy different foundational requirements. The complementarity holds at the compliance level too.
IEC 62443 is the reference standard for industrial cybersecurity, and it organises security around a set of foundational requirements. Cloudflare addresses the boundary-facing requirements: identification and authentication, use control, restricted data flow, and resource availability. The requirements that depend on seeing inside the OT network, such as system integrity and timely response to events, are where OT-native monitoring contributes.
The two layers map onto different requirements of the same standard, which is the same complementarity seen from the compliance side. The full requirement-by-requirement mapping of Cloudflare to IEC 62443 is in our IEC 62443 compliance guide, and the wider architecture in our IT/OT convergence security solution. The rest of the cluster sets the context: the difference between IT and OT security, how Zero Trust modernises the Purdue model, and what the 2026 threat data shows about where the risk concentrates.
How Brixio integrates both layers
Brixio deploys the Cloudflare layer as an overlay and runs it alongside your existing OT platform, without touching the controllers.
As an Authorized Cloudflare Service Delivery Partner (ASDP), Brixio integrates the Cloudflare boundary layer and makes it coexist with whatever OT-native platform a client already runs. The work follows three phases:
- Audit and discovery: mapping shadow IT, unmanaged devices and real traffic flows.
- Architecture and deployment: adding the boundary controls as an overlay, without disturbing the controllers.
- Continuous operation: adapting the rules as the environment and regulations such as NIS2 evolve.
The goal is not to standardise on a single vendor. It is to make sure the boundary layer and the monitoring layer together cover the whole environment, without leaving gaps or duplicating effort. For organisations that want to measure that gap first, Brixio runs an IT/OT security assessment before any deployment.
FIELD PROOF
What it looks like in production, at our clients.
Across two airports, VPN trust extended to the whole network. The boundary taken back with Zero Trust access, as an overlay.
Four entities, as many boundaries to secure. One unified access layer laid on top, without replacing what was there.
Critical infrastructure to protect on the exposed side, not the OT side. Application security added at the boundary, alongside existing tools.
Frequently asked questions
Yes. Your OT-native platform sees inside the network, but it does not secure remote access, transport or internet exposure at the boundary. Cloudflare adds that layer as an overlay, without replacing the platform you already run.
No. The two operate in different places, around the network versus inside it, and cover different functions. Neither does the other's job, so they are deployed together rather than chosen between.
Cloudflare covers the boundary-facing requirements (authentication, use control, restricted data flow and availability), while the requirements that depend on internal visibility (system integrity, timely response to events) stay with OT-native monitoring. The full requirement-by-requirement mapping is in our IEC 62443 compliance guide.
No. Cloudflare secures the network boundary; it does not discover industrial assets or inspect OT protocols. A complete OT security programme combines the boundary layer with internal monitoring.
Secure both layers of your OT environment
Brixio maps your current monitoring and your network boundary, identifies the gap between them, and designs the control layer before any deployment.
Primary CTA: Book an OT Boundary Security Assessment
Secondary CTA: See our IT/OT deployment methodology
