Why the IT/OT boundary is where trouble starts
Most of the critical infrastructure we walk into was never designed to be on a network at all. The programmable logic controllers, the SCADA historians, the metering concentrators, the RTUs sitting in a substation cabinet — a lot of that equipment was commissioned when the plant network was a physical island. Then the business asked for production dashboards, remote diagnostics, predictive maintenance, and a single pane of glass for the SOC, and someone ran a cable between the plant floor and the corporate network. That cable is the whole security problem in miniature.
The numbers back up what practitioners have felt for years. IDC's future-operations research projects that, driven by rising concern over OT security incidents, industrial organisations will grow their OT security investment by more than 50% by 2027. The same body of research keeps naming the same two root causes: poor visibility into industrial assets, and legacy OT gear that nobody can patch, replace, or in some cases even safely scan. You cannot defend an environment you cannot see, and you cannot harden a controller whose vendor went out of business in 2011.
This article is about the part of the job that actually reduces risk: how to draw the boundary between IT and OT, what controls belong on it, and how to map all of it back to the standards an auditor will ask about. We have delivered this work on smart-metering rollouts and utility networks in the GCC, and the lessons below are the ones that survived contact with a live plant.
Convergence is not the enemy. Uncontrolled convergence is.
There is a temptation, especially after an incident, to declare that IT and OT should never touch. That ship has sailed. IDC's IT/OT convergence survey found that more than 30% of utility operators worldwide are increasing convergence investment specifically to run a unified security strategy across both domains. They are right to. A converged, well-segmented network gives you centralised monitoring, consistent identity, and one incident-response playbook instead of two. The failure mode is not convergence itself. It is convergence without a boundary you can describe on a whiteboard and enforce in hardware.
So the first deliverable in any engagement is not a product. It is a map. We inventory every asset, group it into zones by function and risk, and define exactly which conversations are allowed to cross between zones. That map is what the rest of the architecture hangs off.
The segmentation model that holds up
The reference most OT teams anchor to is the Purdue model, and for good reason. It gives you a shared vocabulary of levels, from the physical process at the bottom to enterprise IT at the top, with a demilitarised zone in between where IT and OT are allowed to exchange data under supervision. IEC 62443 layers the concept of zones and conduits on top of it: a zone is a group of assets that share a security level, and a conduit is the controlled, monitored path between two zones. Nothing crosses a zone boundary except through a conduit you have explicitly designed.
The zones themselves are only half the design. What makes them hold is that the boundary between any two zones is not a passthrough but a chokepoint you own and monitor.
The single most important line on that diagram is the industrial DMZ between Level 3 and Level 4. In a healthy design, no device on the enterprise network ever talks directly to a controller. A historian mirror, a patch-staging server, and a jump host live in the DMZ, and the plant-floor systems talk only to those. When the corporate network is compromised — and you should plan as though it will be — the blast radius stops at the DMZ instead of reaching a turbine.
Two practical notes from the field. First, segmentation that exists only in a firewall rule set and not in the physical topology tends to erode; every "temporary" any-any rule someone adds during a commissioning weekend becomes permanent. Where the process is safety-critical, we prefer a data diode or unidirectional gateway for flows that genuinely only need to go one way, such as telemetry leaving the plant. Hardware that physically cannot carry a return packet is a control an auditor and a plant manager can both understand. Second, do not forget east-west traffic inside a zone. Flat OT networks let one infected engineering workstation reach every PLC on the segment. Micro-segmentation within Level 2 and Level 3 is tedious to build and worth every hour.
The controls that earn their place on the boundary
An industrial control firewall is the obvious centrepiece, but the useful ones do far more than filter IP and port. What separates an OT firewall from a repurposed IT appliance is deep parsing of industrial protocols: Modbus/TCP, DNP3, OPC UA, IEC 60870-5-104, PROFINET, EtherNet/IP. A control that can read a Modbus function code can enforce that a given HMI is allowed to read a register but never write one. That is the difference between an operator query and an attacker issuing a stop command.
The market is pushing these devices well beyond filtering. The capability list vendors now ship, and that IDC tracks as the direction of the category, reads like a small security stack folded into the boundary: intrusion detection and prevention tuned for industrial traffic, protocol-aware auditing, VPN termination, DDoS mitigation, asset identification and inventory, data-leakage prevention, zero-trust network access, and industrial managed detection and response. You will not turn all of it on at once, and you should not. But knowing the boundary device can grow into those roles keeps you from buying a second appliance for every new requirement.
Underneath the firewall sits the control that most programmes underinvest in: passive asset discovery. OT protocols are fragile, and an aggressive IT vulnerability scanner has knocked PLCs offline often enough that many plant managers ban scanning outright. Passive monitoring that reads a span port and fingerprints devices from the traffic they already emit gives you the inventory without touching the process. That inventory is not a nice-to-have. It is the precondition for every other control, because a rule set, a patch plan, and an incident-response playbook are all only as good as the asset list they are built on.
Zero trust in OT, without the marketing
Zero trust arrived in OT conversations a few years after it saturated IT, and a lot of what gets said about it does not survive contact with a plant. You are not going to put an agent on a thirty-year-old relay, and you are not going to prompt an operator for step-up authentication in the middle of an emergency shutdown. What does translate is the underlying principle: stop granting access based on network location alone.
In practice, zero trust for OT means brokered, identity-aware access to plant systems instead of a flat VPN that drops a contractor onto the control network. A vendor logging in to service a compressor should reach exactly that compressor's interface, for a bounded time window, through a monitored session that is recorded and can be killed from the SOC. That model — per-session, per-asset, least-privilege access with full session capture — delivers most of the risk reduction people want from zero trust without pretending the endpoints can enforce policy themselves. Third-party and remote-maintenance access is, in our experience, the single most common way attackers reach OT, so this is where the effort pays back fastest.
Mapping controls to the standards an auditor will name
None of this survives a board conversation or a regulator's visit unless it maps cleanly to recognised frameworks. The good news is that the major OT and general security standards agree with each other far more than they conflict. The table below is the crosswalk we hand clients so the same control counts once and satisfies several obligations at the same time.
Control areaPrimary OT standardGeneral / compliance overlayWhat "good" looks like
Zones and conduits
IEC 62443-3-3 (SR 5.1)
NIST SP 800-82 Rev 3; NIST CSF 2.0 (PR.AA, PR.IR)
Documented zone model with an enforced IT/OT DMZ; no direct enterprise-to-controller paths
Asset inventory
IEC 62443-2-1
CIS Control 1 & 2; ISO/IEC 27001 A.5.9
Passive, continuously updated inventory covering firmware and protocol versions
Remote & third-party access
IEC 62443-3-3 (SR 1.13, SR 2.6)
NIST CSF 2.0 (PR.AA-05); ISO/IEC 27001 A.5.14
Brokered, time-bound, recorded per-asset sessions; no shared VPN to the plant floor
Monitoring & detection
IEC 62443-3-3 (SR 6.1, SR 6.2)
NIST CSF 2.0 (DE.CM); UAE IA Standard (M-series controls)
Protocol-aware IDS feeding a SOC with OT-literate analysts and runbooks
Governance & risk
IEC 62443-2-1
NIST CSF 2.0 (GOVERN); ISO/IEC 27001 Clause 6
Named OT risk owner, documented risk register, board-level reporting
For operators in the UAE, the overlay that matters most is the UAE Information Assurance Standard maintained under the national cyber-security authorities, alongside sector rules from bodies such as the Dubai Electronic Security Center for Dubai-based entities. These are not exotic. They ask for the same asset visibility, segmentation, access control, and monitoring that IEC 62443 and NIST already describe, which is why building to the international standards first tends to get you most of the way to local compliance. NIST CSF 2.0 is worth calling out specifically because its new Govern function forces the question programmes most often skip: who actually owns OT risk, and does the board hear about it.
Where AI helps in OT security, and where it does not yet
The same IDC research that tracks the firewall market points to AI as the next growth driver, and the framing there is sensible rather than breathless. It splits the value into two tiers, and that split matches what we see works.
Smaller machine-learning models, trained on user and asset behaviour, are genuinely useful at the boundary. An industrial network is repetitive in a way a corporate network never is: the same HMI reads the same registers on the same cadence for years. A model that learns that baseline can flag the anomaly — a new source writing to a controller, a command issued outside a maintenance window — far faster than a human watching a wall of alerts. Larger models earn their keep in operations rather than detection: summarising an incident, cutting alert noise, drafting a policy review, generating the report a regulator wants. That maps to a real constraint. The scarcest resource in this field is not tooling, it is people who understand both security and industrial automation. Well-scoped AI assistance is a lever on that talent shortage, not a replacement for the expertise.
The caution is equally real. An AI that can summarise an OT incident should never be wired to take an action on the plant floor. Autonomy near a physical process is a safety question before it is a security one, and the answer, for now, is a human in the loop with the authority and the context to say no. Treat AI as an analyst's force multiplier, keep it on the monitoring and administrative side of the DMZ, and audit what it recommends the same way you would audit a junior engineer.
A rollout sequence that does not break production
The order of operations matters more than the shopping list. This is the sequence we use, and each step produces something the next one depends on.
- Build the asset inventory passively. Before touching a firewall rule, know every device, its firmware, and the protocols it speaks. Do it with passive monitoring so you never risk the process.
- Draw the zone model and get it signed off. Agree the zones, the conduits, and the IT/OT DMZ with both the security team and the plant operators. Operations has to own this, or it will be worked around.
- Stand up the DMZ and cut the direct paths. Move historians, patch staging, and jump hosts into the DMZ. Remove every direct enterprise-to-controller route, one documented flow at a time.
- Replace flat remote access with brokered sessions. Kill the shared plant VPN. Give vendors and engineers per-asset, time-bound, recorded access instead.
- Add protocol-aware detection. Deploy OT-tuned IDS on the conduits and feed it to a SOC that has runbooks written for industrial alerts, not just IT ones.
- Layer in analytics and reporting. Once the baseline is stable, add behavioural anomaly detection and AI-assisted reporting to lift the load on your analysts.
- Test the boundary like an attacker would. Tabletop the "corporate network is fully compromised" scenario and confirm the blast radius actually stops at the DMZ. If it does not, the map is wrong, and better to learn that in an exercise.
How Aydahwa Enterprise can help
Securing operational technology is not a product you install. It is an architecture you design around a specific plant, a specific set of legacy constraints, and a specific compliance obligation. That is the work we do. Aydahwa Enterprise brings hands-on IT-and-OT infrastructure experience from critical-infrastructure and utility environments in the UAE and wider GCC, and we build to IEC 62443, NIST SP 800-82, NIST CSF 2.0, ISO/IEC 27001, and the CIS Benchmarks so the result stands up to both an attacker and an auditor.
If you are starting this journey, a short, honest baseline is the fastest way to know where you stand. Our cyber security self-assessment and cybersecurity readiness checklist are free and give you a concrete picture in an afternoon. When you are ready to design or harden the boundary itself, our cybersecurity services cover OT segmentation, monitoring, and compliance mapping end to end, and our cloud services team handles the secure IT side of a converged estate, from the DMZ up. For the ongoing operational load — monitoring, patch staging, remote-access governance — our managed IT support keeps the controls you built from eroding over time. If you would rather just talk it through with someone who has done it on a live plant, get in touch and we will give you a straight answer.
