In an office network, a security incident costs data and downtime. In a plant, a pumping station or a substation, it can cost physical damage and put people at risk. OT security starts from that difference.
Operational technology covers the systems that monitor and control physical processes: SCADA, distributed control systems, programmable logic controllers, safety instrumented systems and the networks that connect them. Saudi Arabia's energy, petrochemical, water, utilities and manufacturing sectors depend on them, and they are increasingly connected to corporate networks, cloud services and remote vendors.
That connectivity brings efficiency and new risk. Many OT environments were designed when isolation was assumed, so devices often lack authentication, run old operating systems and cannot be patched without a planned shutdown. Securing them needs a different approach from IT security, and a clear place to start.
The frameworks that guide the work
ISA/IEC 62443 is the international series of standards for securing industrial automation and control systems. It defines responsibilities for asset owners, system integrators and product suppliers, and introduces two ideas worth adopting early: grouping assets into zones with similar security needs, and controlling the conduits that connect them. It also defines security levels that describe how strong protection in a zone needs to be.
The NCA Operational Technology Cybersecurity Controls (OTCC) set national requirements for organisations that operate industrial control systems as part of critical national infrastructure. They build on the Essential Cybersecurity Controls and add OT-specific expectations.
The two fit together well. OTCC tells you what is required in the Kingdom, and 62443 gives you a detailed, internationally recognised method for designing and building it.
Step 1: find out what you have
Almost every OT programme we see begins with an incomplete inventory. You cannot segment, monitor or patch what you do not know exists.
- Use passive network monitoring to discover devices, protocols and communication paths without sending traffic to fragile equipment.
- Record each asset's function, location, firmware version, vendor and criticality to the process.
- Map the connections between OT and IT, including the ones nobody documented, such as a vendor's cellular modem in a control cabinet.
Avoid active scanning on live control networks unless it has been tested and approved with operations. Ordinary IT scanners have crashed PLCs and stopped production.
Step 2: segment into zones and control the conduits
Flat networks, where an infected laptop in the office can reach a controller on the plant floor, are still common. Using your inventory:
- Separate IT and OT with a demilitarised zone for anything that must be shared, such as historians or patch servers.
- Group OT assets into zones by function and criticality, keeping safety systems in their own tightly controlled zone.
- Allow only the specific traffic each conduit needs, and document why.
Step 3: lock down remote access
Remote access, especially by vendors and integrators, is one of the most common ways attackers reach OT. Replace direct connections and shared accounts with:
- A single, controlled entry point, such as a jump server in the demilitarised zone.
- Individual accounts with multi-factor authentication for every person, including vendor staff.
- Access granted only for approved maintenance windows, with sessions recorded.
Step 4: deal with patching realistically
You often cannot patch OT on the IT schedule. Instead, assess each vulnerability for real exposure. Where patching must wait for a planned outage, apply compensating controls: tighter segmentation, restricted protocols, application allowlisting and closer monitoring. Track the exceptions with owners and review dates so they do not become permanent.
Step 5: monitor with OT awareness
Deploy monitoring that understands industrial protocols, so it can spot a controller being reprogrammed, unusual commands or new devices appearing. Feed alerts into a SOC team that knows the difference between a maintenance task and an attack, and that will not take containment actions that endanger the process.
Step 6: plan incidents with operations and safety
An OT incident response plan must be written with operations and safety engineers, not just the security team. Decide in advance who can authorise isolating a network segment or shutting down a process, how you will run manually if needed, and how you will restore controllers. Keep secured, tested backups of PLC logic, configurations and engineering workstation images.
Step 7: build security into suppliers and projects
Set security requirements in contracts with integrators and suppliers, ideally referencing the relevant parts of 62443. New projects and upgrades are the cheapest moment to design in segmentation, secure remote access and monitoring, rather than retrofitting them later.
Common mistakes
- Applying IT tools and procedures unchanged to OT.
- Shared and default passwords on controllers and HMIs.
- Unmanaged USB use for transferring files to the plant floor.
- Assuming an "air gap" exists without verifying it.
- Leaving operations out of decisions that affect their systems.
OT security rewards steady, well-coordinated progress over big-bang projects. Our IoT and OT team works with asset owners in the Kingdom on assessments, segmentation design and OT-aware monitoring, always alongside the people who run the process.