The quiet risk sitting underneath critical infrastructure
Most of the security spend I see in the GCC still goes to the corporate side of the house: email, endpoints, cloud workloads, identity. That is where the audits point and where the headlines land. But the systems that actually keep the lights on, move the water, refine the gas, and run the production line are a different animal, and for years they were treated as someone else's problem. That gap is closing fast, and not always on the operator's terms.
The market data tells the story plainly. IDC put China's industrial ICT spending at roughly 280.8 billion RMB in 2024, on track for 401 billion by 2028 at a 9.3% compound annual growth rate. Inside that, the pieces that matter for defenders are growing even faster in relative terms: the intelligent industrial host and endpoint security market reached about 700 million RMB in 2024, up 11% year on year, and IDC's own survey found that 41.5% of industrial customers planned to increase their budget for that category the following year. The IoT security market crossed 2.13 billion RMB. Industrial control security auditing sat around 850 million RMB. Different countries, different numbers, but the shape is the same everywhere I work: money is finally moving toward operational technology, because the risk stopped being theoretical.
China is not the GCC, and I am not holding up one market as a template for another. What the figures confirm is a direction of travel. Regulators are writing rules, budgets are shifting, and buyers are waking up to the fact that a plant floor running on twenty-year-old controllers is now reachable from a spreadsheet macro. This is a field guide to closing that exposure, written from the perspective of the people who have to keep the process running while they do it.
Why OT does not behave like IT
The first mistake teams make is assuming their IT security playbook transfers cleanly to the plant. It does not, and pretending otherwise gets equipment damaged or people hurt.
Operational technology inverts the priorities most security professionals grew up with. In IT, we protect confidentiality first, then integrity, then availability. On a control network the order flips hard: availability and safety come first, integrity second, confidentiality a distant third. A programmable logic controller that reboots for a patch during a production run is not an inconvenience, it is a stopped line or a tripped turbine. A lot of this gear was commissioned before "cybersecurity" was a line item, speaks proprietary protocols like Modbus, DNP3, OPC UA, Siemens S7 and EtherNet/IP that were never designed with authentication, and runs on operating systems the vendor stopped supporting years ago. You cannot simply push an agent to a safety controller and reboot it on Patch Tuesday.
IDC's analysts made the same point in describing why industrial host and endpoint security became a distinct product category: OT environments carry greater risk precisely because they lean on legacy systems, specialised protocols, and a design philosophy that puts uptime above everything. When that protection is missing, the consequences are not a data breach in the usual sense. They are operational disruption, environmental damage, and threats to physical safety.
Here is how the two worlds compare when you sit down to design controls for each:
DimensionEnterprise ITOT / Industrial Control
Top priority
Confidentiality, then integrity, then availability
Safety and availability, then integrity, then confidentiality
Typical asset lifespan
3 to 5 years
15 to 25 years, sometimes longer
Patching
Frequent, often automated
Rare, scheduled around maintenance windows, sometimes never
Acceptable downtime for a fix
Minutes to hours
Often zero without a planned outage
Protocols
Authenticated, encrypted by default
Modbus, DNP3, S7, OPC, frequently unauthenticated
Impact of failure
Data loss, financial, reputational
Physical damage, environmental, human safety
Endpoint controls
EDR agents, frequent scans
Application allowlisting, passive monitoring, careful scanning
Every control decision downstream flows from this table. When we scope an OT engagement, the first conversation is never about tooling. It is about what "safe state" means for that process and what we are absolutely not allowed to interrupt.
You cannot protect what you have not counted
Ask an operations manager for a current, accurate inventory of everything on the control network and watch the pause that follows. IDC named unclear asset inventory as one of the core problems industrial security auditing exists to solve, alongside vague risk identification, difficulty monitoring user behaviour, and painful incident traceability. In our engagements it is almost always the true starting point, because the drawings are out of date and the tribal knowledge left with an engineer who retired in 2019.
The catch is that you cannot inventory an OT network the way you scan a corporate subnet. An aggressive Nmap sweep can knock a fragile PLC offline. So discovery leans on passive techniques: span or mirror ports feeding a monitoring appliance that fingerprints devices by watching the traffic they already generate, supplemented by careful, vendor-approved active queries only where it is safe. The goal is a living inventory that records make, model, firmware version, protocol, and the zone each device belongs to. Without that, every later control is a guess.
Segment the network into zones and conduits
If you do only one structural thing for an OT environment, segment it. A flat network where the HMI, the historian, the engineering workstation, and the corporate file share can all reach each other is how a phishing email in accounting ends up talking to a turbine.
Two frameworks anchor this work. The Purdue Enterprise Reference Architecture gives you a mental model of the levels, from the physical process and field devices at Levels 0 and 1, through supervisory control at Level 2, site operations at Level 3, up to enterprise IT at Levels 4 and 5, with an industrial DMZ brokering everything that crosses between the plant and the business. IEC 62443, the international standard for industrial automation and control system security, turns that model into something you can engineer and audit: you group assets into zones by risk, define the conduits that connect them, and assign each zone a target Security Level from SL 1 through SL 4 based on the sophistication of attacker it must withstand. NIST SP 800-82, the Guide to Operational Technology Security, ties both back to the broader NIST Cybersecurity Framework so the OT program speaks the same language as the rest of the business.
The diagram below shows the reference shape we deploy from, adapted per site:
The DMZ is the part teams skimp on and regret. No device in enterprise IT should ever talk directly to a device on the control network. Patches, antivirus updates, historian replication, and remote access all terminate in the DMZ and are brokered from there, so a compromise on the business side has to clear an additional, tightly monitored barrier before it can reach anything that moves a physical actuator.
Watch the control network, and keep the evidence
Segmentation slows an attacker down. Monitoring is how you find out they are there. This is the same capability IDC describes as industrial control security auditing, and the reason it grew into its own market: operators need precise, detailed records of communication behaviour to answer four questions that a corporate SIEM alone cannot: what is actually on my network, what does normal look like, who touched this controller, and what happened in the minutes before the fault.
The practical build is a passive monitoring layer that understands industrial protocols. Deep packet inspection tuned for Modbus, DNP3, OPC UA and the rest can flag a controller being reprogrammed, an unexpected engineering command, or a new device appearing on a segment that is supposed to be static. Because OT traffic is far more predictable than corporate traffic, anomaly detection genuinely works here in a way it often does not on the enterprise side. Feed those alerts into your SOC, but keep an OT context so an analyst does not treat a reprogramming command the way they would a failed login. And retain the raw records. When something does go wrong on critical infrastructure, the forensic timeline is not optional, it is what the regulator and often the insurer will ask for first.
Harden the hosts that survive
Some machines on the plant floor are ordinary Windows boxes wearing an industrial hat: HMIs, engineering workstations, historians. They are also frequently the weakest link, running an OS that went end of life while the equipment it controls has another decade of service in front of it. This is the segment IDC found growing at 11% a year, and it is where a lot of practical risk reduction lives.
Traditional endpoint detection that relies on constant cloud lookups and heavy scans is often the wrong fit. The better model for a static industrial host is application allowlisting: the machine runs a fixed, known set of software, and anything outside that list simply does not execute. Pair it with strict control of removable media, which is still a primary infection route on air-gapped-in-name-only networks, disciplined configuration hardening, and port protection. IDC's survey pointed to where buyers are heading next, with more than half of industrial users planning to invest in Zero Trust Network Access for OT and in AI-assisted industrial security. Both are worth watching, but neither replaces the fundamentals of a known-good baseline and tight change control.
Fix remote access before it fixes you
If I had to bet on how the next serious OT incident in the region starts, I would put money on third-party remote access. Vendors need to reach their equipment for maintenance, integrators need to commission new lines, and the fastest path is usually a flat VPN, a shared credential, or a support tool nobody in security signed off on. It is convenient, and it is the door.
Remote access into OT should be brokered, not direct. That means access terminating in the DMZ, individual named accounts rather than a shared vendor login, multi-factor authentication, session recording, and time-boxed access that opens for the maintenance window and closes again. The Zero Trust principle that no connection is trusted by default fits OT well precisely because the population of legitimate remote users is small and knowable. You are not trying to authenticate the whole internet, you are trying to make sure the one contractor logging in tonight is who they claim to be and can only reach the one system they are there to service.
Map it to a framework you will be audited against
None of this survives contact with a board or a regulator unless it maps to a recognised standard. In the UAE, operators of critical national infrastructure across energy, water, telecommunications, transport, healthcare and finance fall under the Information Assurance Standards, originally issued by NESA and now administered through the UAE Signals Intelligence Agency and the Cybersecurity Council. Compliance is not a nice-to-have for these entities, it is mandatory, assessed through structured audits against the control domains with evidence of continuous improvement. Dubai government entities carry the additional weight of the DESC Information Security Regulation. On the OT-specific side, IEC 62443 and NIST SP 800-82 give you the technical depth, while ISO/IEC 27001 and the CIS Controls cover the management system and the baseline hygiene around it.
The work worth doing once is a single control mapping: one set of implemented controls, cross-referenced to every framework you answer to, so a firewall rule or a monitoring capability is documented once and satisfies the UAE IA Standards, IEC 62443 and ISO 27001 simultaneously. That is the difference between a program you can defend in an audit and a pile of point tools nobody can trace back to a requirement.
A starting checklist for OT security
If you are early in this and want a sequence that reflects how these projects actually succeed, work in this order:
- Agree, in writing, what "safe state" means for each critical process and what may never be interrupted for a security action.
- Build a passive asset inventory covering make, model, firmware, protocol and zone for every device on the control network.
- Draw the current network, honestly, and identify every path between IT and OT, including the ones that are not supposed to exist.
- Segment into zones and conduits, and stand up a real industrial DMZ so nothing in IT talks directly to a controller.
- Deploy passive, protocol-aware monitoring and route alerts to your SOC with OT context preserved.
- Harden industrial hosts with application allowlisting, removable-media control and configuration baselines.
- Replace flat vendor VPNs with brokered, MFA-protected, recorded and time-boxed remote access.
- Establish a change-control and patch process built around maintenance windows, not the IT calendar.
- Map every control to IEC 62443, NIST SP 800-82 and your governing regulation, and keep the evidence current.
- Rehearse an OT incident, including the decision to isolate or shut down, before you are forced to make it live.
You will not finish all ten in a quarter, and you should not try. But run them in this order and each step makes the next one cheaper.
How Aydahwa Enterprise can help
We work with operators of critical infrastructure across the UAE and the wider GCC, and OT security is where our infrastructure background and our compliance practice meet. Our team pairs hands-on architecture experience, spanning enterprise networks, cloud, and the plant floor, with formal credentials including ISO/IEC 27001, PCI-DSS, SOC 2, NIST CSF, CIS Benchmarks and the Microsoft Cybersecurity Architect Expert certification, and with delivery experience in banking, telecommunications and critical national infrastructure where downtime is not an option.
A typical engagement starts with a passive assessment that will not disturb your process: an asset inventory, a segmentation and exposure review, and a gap analysis against IEC 62443, NIST SP 800-82 and the UAE Information Assurance Standards. From there we help design the zone architecture, stand up monitoring, harden the hosts that need it, and lock down remote access, then map the whole program to the frameworks your auditors and regulators use. You can read more about our cybersecurity services and our cloud security and migration work, and if you would rather start by finding out where you stand, our free cyber security self-assessment and cybersecurity readiness checklist are a straightforward first step. When you are ready to talk specifics, get in touch and we will scope it around your process, not the other way round.
