OT data-path review
Seven questions for every path data takes in or out of the control network — the review that keeps a monitoring project from opening an attack surface.
Ask these of every path in or out of OT.
Most OT exposure is not a dramatic breach — it is a well-meant data path nobody reviewed: a vendor connector, a historian link, an engineering laptop. Answer these for each one before it goes live.
| Review question | What good looks like |
|---|---|
| What data crosses? | The specific tags or files, not 'plant data'. Vague scope is how a read-only telemetry path quietly becomes a tunnel into the control network. |
| Which direction? | Outbound, inbound, or both. Default to outbound-only: the control network publishes; outside systems subscribe. Inbound paths need a much higher bar. |
| Read or write? | A monitoring path should be read-only. Any write capability into a control or safety zone is a design decision that needs explicit justification and ownership. |
| Which zones does it cross? | Name the IEC 62443 zones at each end and every boundary between. A path that crosses from the control zone to the cloud crosses several — each is a conduit. |
| How is the conduit protected? | Brokered through a DMZ, authenticated, encrypted, rate-limited. A direct connection from a PLC to an external service is not a conduit, it is an exposure. |
| Who owns it? | One named person who can say what crosses, why, and can shut it off. Conduits fail in practice exactly when no one owns them. |
| How is it monitored, and how do you shut it off? | If the path behaves abnormally, who sees it and what is the kill switch? An unmonitored conduit you cannot close is an incident waiting to happen. |
Six steps to a defended boundary.
- 01
List every path by which data leaves or enters the OT network — historians, gateways, vendor remote access, cloud connectors, USB and engineering laptops included.
- 02
For each path, answer the seven review questions: what, direction, read/write, zones, conduit protection, owner, monitoring and shutoff.
- 03
Flag every inbound or write-capable path into a control or safety zone for explicit justification or removal.
- 04
Confirm each path is brokered and least-privilege — outbound and read-only by default, never PLC-direct to an external service.
- 05
Assign a named owner and a documented shutoff for every conduit that survives the review.
- 06
Re-run the review on a schedule and whenever a vendor, connector, or remote-access arrangement changes.
Questions teams ask about OT data paths
What is an OT data path review?
A structured check of every way data enters or leaves the operational-technology network, judged against IEC 62443's zone-and-conduit model. For each path you confirm what data crosses, in which direction, read or write, which security zones it traverses, how the conduit is protected, who owns it, and how it is monitored and shut off. It is the review that keeps a monitoring project from becoming an attack surface.
What are zones and conduits in IEC 62443?
A zone is a grouping of assets with common security requirements — for example a control zone, a DMZ, and an enterprise zone. A conduit is a defined, protected communication path between zones. IEC 62443 asks you to partition the plant into zones and treat every zone-to-zone path as a conduit with explicit security requirements, rather than allowing flat, unrestricted connectivity.
Should plant data go directly to the cloud from a PLC?
No. A controller should never hold a direct connection to an external service. The defensible pattern is to broker data outward through a demilitarised layer — read-only and outbound by default — so the control network is never directly exposed and the path can be monitored and closed. NIST SP 800-82 makes the same point: minimise exposure of control systems and broker data outward.