OT/IT Convergence Security Architecture

Q: Why is OT security different from IT security?

The difference is the priority order and the blast radius. IT security optimises for confidentiality first — patch aggressively, encrypt, force MFA, reimage on suspicion. OT security inverts the CIA triad because the asset is a physical process: availability and safety come before confidentiality, since a programmable logic controller driving a turbine or a filling line closes a control loop in single-digit milliseconds and cannot tolerate an unplanned reboot or a CPU-pausing agent. A "quick" IT action that is routine on a laptop can stop a production line or drive equipment into an unsafe state on the plant floor. The consequence is that many standard IT controls — endpoint agents on control devices, forced patch windows, aggressive scanning — are anti-patterns in OT, and the architecture must achieve the same security goals through segmentation, mediation, and passive monitoring instead. Convergence made this urgent because the OT network is now wired to the IT network for analytics, so the attacker can cross the bridge that was built for data.

Q: What are zones and conduits in IEC 62443?

Zones and conduits are the core design primitive of the ISA/IEC 62443 standard for industrial security. A zone is a grouping of assets that share the same security requirements and trust level — for example the supervisory SCADA/HMI layer, or the process-control layer of PLCs and sensors. A conduit is the defined, controlled communication path between zones, and every crossing must pass through one; there is no flat address space where any host can reach any other. Each zone is assigned a target Security Level (SL 1 through SL 4) reflecting the strength of attacker it must resist, and the conduits enforce what protocols and directions are allowed between zones. Mapped onto the Purdue Enterprise Reference Architecture, zones align with Purdue levels (enterprise, DMZ, operations, supervisory, process control) and conduits are the monitored links between them. The model turns "one perimeter firewall" into internal segmentation, so a foothold in one zone does not grant access to the whole plant. NIST SP 800-82 Revision 3 explicitly adopts this zone-and-conduit approach and aligns it to the Cybersecurity Framework functions.

Q: What is an OT DMZ and why is Purdue Level 3.5 so important?

An OT DMZ, sitting at Purdue Level 3.5 between the enterprise IT network (Levels 4–5) and the operations network (Level 3 and below), is the single highest-value control in a converged plant. Its job is to ensure there is no direct network route from the enterprise to the control system: the historian data that needs to reach the cloud is replicated to a server in the DMZ, patches destined for OT are staged there, and remote access lands on a jump host there — so enterprise-to-OT traffic is terminated and brokered rather than routed straight through. This matters because the most common intrusion path is exactly the one it removes: a phished user on a Level 4 laptop who, on a flat network, can route directly to a Level 1 PLC. By forcing every crossing to terminate and be inspected at the DMZ, you break that path without giving up the analytics and patching that convergence was supposed to deliver. Establishing the DMZ is the floor — the minimum viable segmentation — for any converged industrial environment in 2026.

Q: What is a data diode and when should I use a unidirectional gateway?

A data diode, or unidirectional gateway, is a device that makes data flow physically one-way: information can leave the process network but nothing can flow back in, and this is enforced at the hardware level rather than by firewall rules that can be misconfigured or bypassed. You should use one wherever the business need is to export data — historian telemetry, sensor readings, process metrics up to a cloud analytics or data-lake platform — because it delivers that value with literally zero inbound attack surface. The trade-off is that you cannot push commands, configuration, or patches back down that path, which is correct by design: those changes should go through a separate, monitored, human-gated conduit in the OT DMZ, not through the analytics pipe. The anti-pattern a diode prevents is the "convenient" bidirectional link that quietly becomes the inbound path an attacker uses. Data diodes are especially appropriate at the boundary of safety-critical or high-consequence process zones, where the acceptable inbound risk is effectively zero and a firewall that merely filters is not a strong enough guarantee.

Q: How should I patch OT systems when I cannot take the process offline?

You invert the IT patch model. Maintenance windows on a production process may occur only once or twice a year, and PLC vendors may void support if you deviate from a validated firmware baseline, so aggressive patching is often impossible and sometimes unsafe. Instead, prioritise by exploitability-in-context: a vulnerability is only urgent if the affected asset is reachable from a routable path. A critical CVE on a PLC that sits behind a data diode on an isolated conduit, unreachable from any network an attacker can touch, is a lower real risk than a medium-severity CVE on a dual-homed engineering laptop that bridges IT and OT. Where you cannot patch, apply a compensating control — tighten the conduit rule, isolate the asset further, restrict the protocol — and schedule the actual patch for the next validated maintenance window, staging it in the DMZ first. "Mitigate, do not patch" is frequently the correct engineering answer in OT, and CVSS score alone is the wrong prioritisation signal; reachability and compensating controls decide the order.

Q: Is OPC UA secure by default?

No. OPC UA is a significant improvement over legacy industrial protocols like Modbus because it actually has a security model — it supports message signing, encryption, and authentication of clients and servers — but those features must be explicitly configured, and the default or hastily deployed endpoint frequently runs with none of them enabled. An unauthenticated, unencrypted OPC UA endpoint is effectively an open command-and-monitoring channel into the process. The correct posture is to treat every OPC UA endpoint on a protocol gateway with the same rigour as a public-facing API: require authentication, enable signing and encryption, restrict which clients may connect, and monitor the traffic. This is the OT analogue of enforcing signed artefacts and admission control in a software supply chain, with one critical difference: a security control that fails on the plant floor can cause a safety event, so the gate must be designed to fail safe rather than fail open. Verifying that OPC UA security is actually turned on is a common and high-value finding in OT assessments.

Q: How does MITRE ATT&CK for ICS help defend OT networks?

MITRE ATT&CK for ICS is a knowledge base of adversary behaviour specific to industrial control systems, and it gives OT defenders a shared vocabulary and a coverage map the way the enterprise ATT&CK matrix does for IT. It enumerates 12 tactics and 90 techniques observed in real attacks on control environments, including tactics that have no IT equivalent — "Inhibit Response Function" (disabling the safety and protection systems that would stop a dangerous condition) and "Impair Process Control" (manipulating the physical process itself) — because IT has no physical process to impair. Defenders use it to assess detection coverage: for each technique, can our monitoring see it, and if not, what telemetry would we need? Because deploying active agents on control devices is often impossible, that telemetry usually comes from passive network monitoring at the zone boundaries rather than host logs. Mapping an OT security operations capability to ATT&CK for ICS turns "we monitor the OT network" into a specific, measurable claim about which adversary techniques you can and cannot detect, and it drives where to invest next.

Q: What is the biggest OT security mistake in converged environments?

The flat network combined with the dual-homed engineering workstation. When IT and OT share address space behind a single perimeter firewall, the first foothold — usually a phished enterprise user — can reach anything, including the PLCs, because there is no internal segmentation to stop lateral movement. The dual-homed engineering laptop makes it worse: a single machine with one network interface on the IT side and another on the OT side is a literal bridge across the boundary, and it is the path many real intrusions use, especially when that laptop also reads email and browses the web. The fix is architectural, not a product: establish the OT DMZ so there is no direct enterprise-to-control route, segment the interior into zones and conduits so a foothold is contained, dedicate engineering hosts to OT with no email or web access, and build a passive asset inventory below the IT/OT line so you can actually see what talks to what. You cannot segment or monitor an asset you never knew was bridged, so discovery is the prerequisite, not an optional later step.