WHY YOUR SCADA NETWORK IS MORE VULNERABLE THAN YOU THINK

1.0 THE THREAT IS NO LONGER THEORETICAL

In December 2023, a water utility in Pennsylvania had its Unitronics PLC remotely accessed and the set-point for chlorination changed by an Iranian-affiliated threat group. No safety system tripped. No alarm fired. The operators found out because a ransom note appeared on the HMI screen. The facility served 2,000 residents.

This was not an isolated incident. According to the 2024 OT/ICS threat intelligence reports published by Dragos and Claroty, there were over 400 confirmed incidents targeting industrial control systems in 2023 alone — a 46% increase on the prior year. More importantly, the nature of those incidents is changing. The early era of ICS attacks was dominated by nation-state actors with very specific targets: Stuxnet was designed to destroy a specific enrichment facility in Natanz. Today's threat landscape includes commodity ransomware gangs who have discovered that operational technology networks offer several highly attractive properties for extortion.

For industrial operators in West Africa specifically, the risk calculus is complicated by three structural factors that we see consistently across the clients we support. First, most OT networks in the region were designed and installed by contractors whose primary expertise was process engineering, not cybersecurity — the network architecture reflects what was convenient to commission, not what is defensible to operate. Second, the pace of remote access adoption during and after the pandemic introduced VPN and RDP connectivity into networks that had no monitoring capability to detect misuse. Third, engineering workstations frequently run end-of-life Windows versions because the ICS software vendor has not certified their platform against newer operating system versions.

The result is a threat surface that is simultaneously expanding and largely invisible to the operators who depend on it.

2.0 HOW MOST ICS NETWORKS ARE ACTUALLY BUILT

Before we can discuss defences, it is worth being precise about what the typical OT network architecture actually looks like — not what the Purdue Model diagram on the wall says it looks like, but what the network scanning tool sees when you plug it in.

In the majority of medium-to-large industrial installations we have audited across the mining, marine, and agricultural processing sectors, the real network topology deviates from the intended design in several consistent and dangerous ways.

The Flat Network Problem

The intended architecture typically separates IT and OT traffic using a DMZ, with the historian server acting as the sole bridge between zones. In practice, we routinely find direct routed connectivity between the corporate network and the process control network — often because an engineer needed to access a piece of software remotely and added a firewall rule that was never removed. We have found rules permitting full TCP access from any corporate IP to the SCADA server in plants that had recently passed an internal security review.

Figure 01 PLC wiring

Fig. 01 — The gap between documented and actual network topology is the single most common finding in our OT security assessments. The DMZ is either absent or bypassed by stale firewall rules in approximately 70% of sites we assess.

End-of-Life Everywhere

Windows 7 reached end-of-life in January 2020. Windows Server 2008 R2 did the same. Yet both remain the dominant operating system versions on SCADA servers and engineering workstations across the industrial sites we support. The reason is straightforward: ICS software vendors validate their applications against specific OS versions, and upgrading the OS can void support agreements, require expensive revalidation, or simply break functionality that the plant depends on. This is a legitimate constraint, not negligence on the part of the operators.

The consequence is that the most critical computers in the facility — the ones with direct write access to the PLC logic controlling physical processes — are running operating systems that have received no security patches for four years and counting. Every CVE published against Windows 7 since January 2020 is permanently open on these systems.

THE THREE ATTACK PATHS WE SEE MOST OFTEN

Based on incident response work and our own assessments, three entry paths account for the vast majority of successful ICS compromises. Understanding these specific mechanisms is more useful than generic frameworks.

Path 1: Exposed Remote Access

The single most common entry point. During the 2020–2021 period, many operations teams enabled direct RDP or VPN access to SCADA systems for remote engineering support. Many of these connections remain active years later, often without multi-factor authentication, and often with accounts shared between multiple contractors who may no longer have a legitimate need for access.

RDP brute-force attacks are fully automated, cheap to run, and scan the entire IPv4 address space continuously. If your SCADA server has TCP port 3389 reachable from the internet with a weak or shared password, it is receiving brute-force attempts right now.

# Search Shodan for your external IP ranges (replace with your CIDRs)
# This shows what attackers can see from the internet
shodan search "port:3389 net:197.255.0.0/16" --fields ip_str,port,org,os

# Also check for exposed Modbus TCP (port 502) — common on older OT networks
shodan search "port:502 net:197.255.0.0/16"

# EtherNet/IP (port 44818) — Rockwell PLCs
shodan search "port:44818 net:197.255.0.0/16"

# Siemens S7 (port 102) — direct PLC access, should NEVER be internet-routable
shodan search "port:102 net:197.255.0.0/16"

# Output: if you get results for ports 102, 502, or 44818 on your ranges,
# stop reading this article and call your network team immediately.

Path 2: Removable Media

USB drives remain a significant vector for ICS environments, precisely because they bypass network-based defences entirely. The Stuxnet worm — still the most technically sophisticated ICS attack ever deployed — used USB media to jump an air gap. More commonly, an engineer brings a USB drive from their home computer to transfer a project file to an isolated SCADA workstation, and inadvertently introduces malware in the process.

Effective USB control in an OT environment is harder than it sounds. Blanket prohibition is often impractical because the same USB ports are used for legitimate maintenance activities. The pragmatic approach is a combination of endpoint controls (USB device whitelisting via Group Policy or endpoint protection software), a dedicated clean-room machine for scanning media before it enters the OT network, and a clear policy that no personal devices enter the control room.

Path 3: Vendor and Contractor Access

Every ICS installation has a roster of OEM vendors and maintenance contractors who require periodic remote or on-site access. In our experience, access management for these relationships is consistently the weakest link in an otherwise competent security posture. We routinely find shared credentials, accounts that were created for a specific commissioning job and never disabled, and VPN access that has been given to a vendor's subcontractor without the asset owner's knowledge.

The solution is not technically complex: a privileged access management system, time-bounded access grants with automatic expiry, and a periodic access review process. What makes it difficult is organisational rather than technical — it requires a defined owner for third-party access management and the discipline to enforce the process when a vendor calls at short notice needing emergency access to fix a fault.

IEC 62443: WHAT ACTUALLY WORKS IN PRODUCTION

IEC 62443 is the international standard for industrial cybersecurity. It is comprehensive, technically sound, and frequently misunderstood in ways that lead to implementation failures. The most common mistake is treating it as a compliance checklist rather than a risk management framework — the goal is not to tick all the boxes, it is to reduce the probability and impact of a successful attack on your specific system.

The core concept of IEC 62443 that provides the most practical value is zone-and-conduit architecture. A zone is a group of assets with similar security requirements. A conduit is any communication path between zones. The principle is simple: define the zones, define the conduits, and control what is allowed to traverse each conduit.

Defining Zones in Practice

For a typical industrial plant, a zone design that is both defensible and operationally realistic might look like the following. Note that this is a starting point, not a template — your zone design must reflect your actual risk profile and operational requirements.

Conduit Controls That Matter

Once zones are defined, the conduits between them must be explicitly designed. The key principle for each conduit is: only the minimum required protocols, in the minimum required direction, with full logging. This means replacing permissive firewall rules ("allow TCP from Zone 5 to Zone 3 any port") with precise application-layer rules ("allow OPC-UA from historian-replication-server to historian-server on TCP 4840, with certificate authentication").

In practice, implementing precise conduit controls requires a detailed inventory of every communication flow across every zone boundary — which is itself a significant project for a mature installation. We typically run a passive network monitoring tool (Claroty, Dragos, or Nozomi) for 2–4 weeks to baseline the actual traffic before attempting to write restrictive rules. Writing rules without a baseline is how you end up with a firewall change that stops production at 02:00 on a Monday.

FIVE CONTROLS YOU CAN IMPLEMENT THIS QUARTER

The full IEC 62443 implementation is a multi-year programme. But there are high-impact controls that can be deployed relatively quickly and that address the most commonly exploited vulnerabilities. In rough order of impact per unit of effort:

1. Audit and revoke third-party access. Pull a list of every VPN account, RDP account, and remote access credential that has access to any OT asset. If the account has not been used in 90 days, disable it. Require account managers to reaffirm the business need for every active account on a quarterly basis. This costs almost nothing and closes the most common entry point.
2. Deploy network monitoring. You cannot defend what you cannot see. A passive network monitoring tool deployed on a SPAN port of your OT switch will, within days, show you every device on the network, every communication flow, and — once baselining is complete — every deviation from that baseline. The technology has become accessible enough that this is no longer only feasible for tier-one assets.
3. Enforce MFA on all remote access to OT systems. RDP and VPN access to any system in Zone 3 or above should require multi-factor authentication, without exception. If your current remote access solution does not support MFA, replace it. The incremental friction is modest; the reduction in attack surface is substantial.
4. Segment the control network VLAN from the corporate network. Even without a full zone-and-conduit architecture, putting your SCADA and HMI systems on a separate VLAN with a stateful firewall between them and the corporate network dramatically reduces the blast radius of a corporate network compromise. This is a network switch configuration change, not a multi-month project.
5. Implement a USB media policy with technical enforcement. Define which USB ports are permitted on which systems, enforce it at the OS level (Group Policy device installation restrictions or equivalent), and create a clean-room process for any media that needs to enter the OT network. This is particularly effective against the large category of opportunistic malware that spreads via removable media.

WHERE TO START: AN HONEST ASSESSMENT

The honest answer is that most industrial operators in the region are not starting from zero — they have some controls in place, they have some awareness of the problem, and they have operational constraints that make the textbook architecture difficult to implement cleanly. The pragmatic path forward is a risk-based prioritisation of controls, not a wholesale redesign.

That means starting with an honest assessment of your current state: what assets exist, what communication flows exist, what access paths exist, and what your actual exposure looks like from both the internet and the corporate network. From that baseline, a defensible architecture can be designed and a phased implementation plan built that accounts for operational realities.

The alternative — waiting for the threat to become real before acting — is a strategy we see fail repeatedly. The dwell time before detection of an OT network intrusion averages 156 days. By the time the operators knew there was a problem in the Pennsylvania water incident, the threat actors had been inside the network for weeks. The question is not whether your network will be probed. It will be, if it is not already. The question is whether you will have the visibility and the controls to detect it and contain it before it becomes a production impact.

If you want to understand your current exposure, Voltex offers a structured OT security assessment that covers network architecture review, firewall rule analysis, access inventory, and a prioritised remediation roadmap. It is not a red team engagement — it is a practical engineering assessment designed to give operations teams an accurate picture of where they stand and what to do next.