- Modbus, DNP3 and most Profibus deployments carry no authentication or encryption by design; anyone who can route to the device can command it.
- The breach path into GCC industrial networks is almost always IT first, then lateral movement into OT through a shared domain, a flat VLAN, or an unmanaged remote access box.
- Patching a live PLC or DCS controller is rarely an option; segmentation, monitoring and compensating controls do the work that patch cycles do in IT.
- Assessors care less about the tooling you bought and more about whether you can produce an accurate asset inventory and a network diagram that matches reality.
Why OT security cannot borrow the IT playbook wholesale
An IT breach usually costs data and uptime. An OT breach can stop a desalination train, over-pressure a line, or take safety instrumented systems offline. You cannot reboot a running compressor to apply a patch, and you cannot run an aggressive vulnerability scan against a two-decade-old programmable logic controller without risking a fault state, because the device was never built to handle unexpected traffic gracefully. Availability and safety outrank confidentiality, the opposite priority order from a typical IT security programme, and that changes what "good" looks like at every layer: network design, patching, monitoring, even incident response.
What IT/OT convergence actually changed
Ten years ago the air gap between the plant floor and the corporate network was mostly real, even if never quite total. It is not real anymore. GCC industrial operators have spent the last several years connecting SCADA systems to cloud-based monitoring, adding IIoT sensors for predictive maintenance, and giving vendors remote access for support contracts. Each is a legitimate operational reason. Each also opens a path from a network an attacker can reach into one that was never designed to defend itself. The common pattern is a corporate domain controller that also authenticates engineering workstations, a historian server that bridges both zones, or a vendor support VPN with no time-boxing and no monitoring once approved.
The protocol layer trusts everyone on the wire
Modbus TCP, DNP3 and Profibus were standardised when the assumption was a closed, physically secured network. None authenticate the sender by default, and none encrypt payloads. A device that receives a valid-looking Modbus write command executes it, whether it came from the historian it expects or from an attacker who has reached the same subnet. OPC UA is the exception worth knowing: it supports certificate-based authentication and encryption, but only when the integrator configures it that way, and plenty of OPC UA deployments still run in the default, unsecured mode because turning security on added a compatibility step nobody wanted to troubleshoot during commissioning. The lesson is not that the protocols are flawed. It is that protocol-level trust means your real security boundary has to be the network architecture.
Where these environments actually get breached
The pattern across publicly documented industrial ransomware incidents, including ones involving groups like LockBit, is consistent: initial access through phishing or a stolen credential on the IT side, then lateral movement into OT because nothing stopped it. The specific failures that keep showing up in GCC industrial networks are unglamorous: PLCs and HMIs reachable from the corporate network and still on vendor default credentials, no meaningful segmentation between the corporate LAN and the control network, engineering laptops that carry whatever the corporate side is infected with across zones, and contractor remote access with no multi-factor authentication and no expiry. None of this requires a sophisticated attacker. It requires an unsegmented network and time.
Segmentation is the control that carries the most weight
The Purdue Enterprise Reference Architecture is still the right mental model even though real networks are messier than the diagram: enterprise IT at the top, a demilitarised zone in the middle holding the historian and anything that must talk to both sides, and control zones below it walled off from direct enterprise access. The practical version is zones and conduits: group assets by function and criticality, then force every path between zones through a defined, monitored conduit, usually a firewall pair with rules an OT engineer can actually explain. Where data only needs to flow one way, out of the control zone for monitoring, a one-way gateway removes the return path entirely rather than trusting a firewall rule to hold. Jump hosts for remote and vendor access, with session recording and time-limited approval, close most of the rest of the gap.
Vulnerability management means compensating controls, not a patch cycle
You cannot run OT vulnerability management the way you run it in IT, where a scanner hits every host monthly and a patch goes out on an agreed SLA. Active scanning against fragile embedded controllers can cause outages, and vendors often will not support a patched device until they validate it against their own firmware baseline, a process that can take months. What works starts with an accurate asset inventory, which most sites do not have because assets get added during commissioning and never get logged centrally. From there, passive network monitoring tuned to OT protocols flags anomalous commands and new devices without touching anything live. Unpatched exposure gets managed through compensating controls: an intrusion prevention signature at the conduit, tighter access control on the specific device, and a documented risk acceptance with a review date, rather than an open-ended plan to patch it eventually. A vulnerability management programme built for this asymmetry, not an IT scanning schedule stretched to cover OT, is what survives contact with a live plant.
What assessors and regulators actually check
UAE critical infrastructure operators sit under sector-specific cybersecurity requirements, and the detail varies by industry and by which regulator holds jurisdiction. What is consistent across assessments is the evidence they ask for: a current asset inventory including firmware versions, a network diagram matching the live topology rather than the as-built drawing from commissioning, documented segmentation with the firewall rules to back it up, a remote access policy with MFA and logging, and an incident response plan naming who has authority to isolate a segment without waiting for a committee. Our OT/ICS security FAQ covers the questions that come up most before an assessor asks them directly.
Incident response in OT is not the IT playbook with different logos
Isolating a compromised IT host is usually a clean action: pull the cable, image the disk, move on. Isolating a compromised OT segment can itself cause the outage you are trying to prevent, if it cuts power to a safety system or leaves a process running unmonitored. Effective OT incident response plans define, in advance, who can authorise isolation, which systems must stay powered regardless of compromise status, and how operations continue manually if the control network goes down. That planning has to happen before an incident, with plant operations and safety engineering at the table, not improvised during one. As covered in how GCC teams get OT incident response wrong, the most common gap is treating the OT plan as an appendix to the IT plan instead of its own document with its own decision owners.
Where to put the first budget cycle
Starting from close to zero, the order that produces the most risk reduction per dirham spent is: asset inventory first, because you cannot scope what you cannot list; segmentation second, because it contains most of the failure modes above; passive OT-aware monitoring third, because it buys visibility without the risk of active scanning; and a tested, OT-specific incident response plan fourth, because the first three only buy the time a bad plan wastes. A properly scoped OT-aware penetration test checks whether the segmentation you believe you have actually holds under an adversarial path, usually where the gap between the diagram and the live network becomes visible. Skip that step and you are trusting a document, not a network.
