What is SCADA security?

Key takeaways

• SCADA systems aggregate control authority across the plant. A compromise of a SCADA server can affect every line it supervises.
• Most SCADA components run on Windows, often on older versions that cannot be replaced because the SCADA software is validated against them.
• The dominant SCADA threat model at mid-market manufacturers is ransomware reaching SCADA through IT-side compromise, not nation-state targeting.
• Defense relies on segmentation, engineering workstation hardening, backup of SCADA configurations, and physical access controls on SCADA rooms.
• ARG audits SCADA as part of the integrated OT engagement; the SCADA risk profile is inseparable from the broader OT security program.

What is SCADA, and how is it different from a DCS?

SCADA (Supervisory Control and Data Acquisition) is an industrial control architecture that aggregates supervisory visibility and control across distributed assets through PLCs and (in older or geographically distributed systems) RTUs (Remote Terminal Units).

A typical SCADA installation has three layers:

1. Field devices. PLCs, RTUs, sensors, actuators. These execute control logic at individual machines, lines, or remote sites.
2. Communication. Networks that move data and commands between field devices and supervisory systems. Industrial protocols (Modbus, DNP3, OPC UA, EtherNet/IP) dominate; standard TCP/IP is increasingly common as well.
3. Supervisory layer. Servers running SCADA software (Rockwell FactoryTalk View SE, Siemens WinCC, AVEVA Wonderware, Inductive Automation Ignition, Iconics, GE iFIX, etc.) that aggregate, display, log, and supervise. Operators use HMI workstations connected to this layer.

A DCS (Distributed Control System) is the alternative architecture for continuous-process control (refining, chemicals, pulp and paper, large-batch food and beverage). DCS architectures tend toward tighter integration between control and supervisory layers; the security profile is similar to SCADA but the operational model differs.

For mid-market manufacturers, SCADA is the more common architecture. Manufacturing with discrete operations (machined parts, assembly, packaging, electronics) typically uses SCADA-PLC; continuous-process operations use DCS. The same security principles apply.

The most common SCADA architectures in mid-market manufacturing

ARG sees three SCADA architecture patterns repeatedly in mid-market manufacturer environments.

1. Single-server SCADA per line. Each production line has its own SCADA server with HMIs. Servers may be loosely networked but each operates independently. Common in older or smaller installations. Security advantage: blast radius is line-level. Security disadvantage: management overhead, inconsistent posture across lines, often no central monitoring.

2. Centralized SCADA per facility. One SCADA server (or HA pair) aggregates the entire facility. HMIs across the floor connect to the central server. More common in newer installations and after consolidation projects. Security advantage: consistent posture, central monitoring practical. Security disadvantage: full plant blast radius from a single compromise.

3. Multi-facility SCADA. SCADA spanning multiple facilities, often with a central historian and regional supervisory servers. Common in mid-size manufacturers with multiple plants. Security profile inherits the worst of the first two patterns plus inter-facility network exposure.

Each architecture is appropriate for some operational context. Security design needs to match the architecture; transplanting controls from one pattern to another rarely works.

Why SCADA is a high-value target for ransomware and nation-state actors

Three reasons SCADA attracts attention from both commodity and targeted threat actors:

1. Aggregated control authority. A SCADA server with control over multiple PLCs offers high impact per compromise. The economics favor SCADA over individual PLC targeting; the SCADA server is a smaller number of higher-value targets.
2. Windows-based and IT-reachable. Most SCADA servers run on Windows, accept Windows credentials, and live one segment away from the IT network. Standard ransomware tradecraft (credential dumping, lateral movement, encryption) works on SCADA servers if they can be reached.
3. Production-stoppage leverage. Encrypting or disabling SCADA stops production. Production stoppage is a payment lever for ransomware operators; the manufacturer pays to restore operations because every hour of downtime is measurable revenue loss.

For nation-state actors, SCADA is also attractive because supervisory compromise enables targeted physical effects (modifying setpoints, suppressing alarms, manipulating safety thresholds) without modifying every PLC individually. The Stuxnet, BlackEnergy, and Industroyer cases all involved supervisory-layer manipulation.

Examples of SCADA compromises and their operational impact

What the historical record shows.

• Maroochy Water (2000). A disgruntled former contractor used radio access to a SCADA system to release sewage at a wastewater treatment facility in Australia. Demonstrated insider risk and the consequences of weak authentication on SCADA radio links.
• Stuxnet (2010). Modified PLC logic at Iranian uranium enrichment, with the manipulation hidden from the supervisory layer. Demonstrated that supervisory-layer trust can be exploited.
• BlackEnergy / Ukraine (2015). SCADA compromise via IT-side foothold; attackers used the SCADA interface to trip breakers and cause outages. Demonstrated the IT-to-SCADA chain that dominates real-world incidents.
• Industroyer / CRASHOVERRIDE (2016). Protocol-aware malware that interacted directly with SCADA systems through industrial protocols. Demonstrated that targeted SCADA tooling exists in the wild.
• Oldsmar water utility (2021). Remote-access tool compromise allowed an attacker to attempt sodium hydroxide setpoint modification. Caught by an alert operator. Demonstrated that public-utility SCADA is reachable through poorly governed remote access.
• Recurring ransomware events at manufacturers, water utilities, and food processors (2023-2026). A steady cadence of commodity-ransomware incidents that reach SCADA via IT-side compromise. Most realistic threat model for mid-market manufacturers.

The pattern: nation-state SCADA attacks are rare; commodity ransomware reaching SCADA via the IT side is common. The mid-market manufacturer's defending posture should be designed against the second pattern primarily, with the first as a stretch case.

How to assess SCADA security gaps

A SCADA-specific gap assessment covers seven areas.

1. Asset and software inventory. Every SCADA server, HMI workstation, historian, and accessory documented with vendor, version, OS, location, function.
2. Network position. Where the SCADA components sit relative to the IT/OT boundary. Whether the SCADA network is segmented from other OT zones. Where the historian sits. What traffic crosses the boundary.
3. Authentication and access. Named accounts on SCADA servers and HMIs. Shared accounts that should be eliminated. Vendor accounts. MFA coverage where the SCADA software supports it.
4. Patching state. Windows version and patch level on each SCADA server and HMI. SCADA-software version and patch level. End-of-life status for both.
5. Backup state. SCADA configuration backed up. Historian data backed up. Backup restoration tested. Offline copies maintained.
6. Physical access. Control room and SCADA-server-room access controls. Engineering workstation placement. Visibility from public or semi-public areas.
7. Monitoring and detection. Whether SCADA-relevant events feed into the broader security operations function. Whether anomalous SCADA activity would surface in time to act.

The assessment produces a prioritized remediation list. For most mid-market manufacturers starting from minimal SCADA-specific maturity, the first three items (inventory, segmentation, account hygiene) drive the largest near-term gain.

Best practices for SCADA hardening

1. Segmentation between SCADA and the rest of the OT network. SCADA servers and HMIs sit in their own segment, with explicit allowlist rules for the protocols and endpoints they need. The segment is enforced at a firewall, not just by VLAN.
2. Application allowlisting on SCADA servers and HMIs. Where the SCADA vendor supports it. Where they do not, document the compensating control (host-based firewalls, USB restrictions, change control).
3. Named accounts on SCADA software. Shared "operator" or "engineer" accounts replaced with named accounts. Activity attributable to specific people. MFA where the platform supports it.
4. Vendor access bastion. Vendor remote access into SCADA routed through a controlled jump server with MFA, session recording, and time-bounded access.
5. Backup of SCADA configurations and projects. Configuration files, HMI projects, alarm databases, and recipe data backed up to offline media. Restoration tested at least annually.
6. Physical security on SCADA spaces. Control rooms, SCADA server rooms, and engineering rooms protected with appropriate access controls. See What is a physical security audit?.
7. Patching with vendor coordination. Windows patching cadence aligned with SCADA vendor guidance. Out-of-band emergency patching path documented for critical CVEs.
8. OT-aware monitoring on the SCADA segment. Passive monitoring with industrial-protocol understanding. Alerts on anomalous control commands, unauthorized writes, and unusual operator activity.
9. Incident response readiness for SCADA scenarios. Playbooks covering SCADA encryption, SCADA loss-of-view, vendor compromise, and operator-account compromise.

SCADA security FAQs

Is SCADA the same as ICS?

No. SCADA is one architecture within the broader ICS category. SCADA refers specifically to supervisory systems that monitor and control distributed assets through PLCs and RTUs. DCS is another ICS architecture used for continuous-process control. PLCs by themselves are not SCADA; they are controllers that SCADA supervises. See What is an industrial control system (ICS)?.

Can SCADA systems be air-gapped from the internet?

Pure air gaps are rare in practice. SCADA systems typically need data flow to historians, reporting tools, and (frequently) vendor remote-access systems. The realistic security posture is governed connectivity, not air-gap, with documented controls for each path that crosses the boundary. See What is the IT/OT convergence problem?.

What is the typical age of SCADA infrastructure?

Ten to twenty years is common. The SCADA platform may have received software updates, but the underlying hardware and Windows OS hosting it often have not. A SCADA HMI running Windows Server 2012 on a 2014 server is normal at mid-market manufacturers in 2026.

How does ransomware reach SCADA networks?

Almost always through the IT side. An employee opens a phishing email; ransomware deploys; it moves laterally to reach the historian or the SCADA server; it encrypts what it can reach. Direct attacks against SCADA from outside the organization are rare; IT-to-OT pivots are the dominant real-world attack pattern.

How ARG tests SCADA exposure during physical and digital audits

SCADA testing is part of ARG's integrated on-site audit at manufacturing clients. The work runs across physical, IT, and OT surfaces inside a single engagement.

The on-site audit is conducted by David Ashby, drawing on a manufacturing background at Quality Electrical Systems. The auditor inventories SCADA assets, observes operations enough to understand the actual data flows, and interviews engineering and IT staff about the supervisory architecture and vendor access patterns.

Where the engagement permits, controlled exercises validate specific attack paths during on-site weeks:

• Physical access to SCADA spaces. Pretexted entry to SCADA server rooms and control rooms. See What is a physical security audit? and What is a covert entry assessment?.
• Engineering workstation pivot. Demonstration that a spear-phished engineering workstation can reach SCADA configuration files or HMI databases.
• Vendor remote-access verification. Confirming that vendor accounts route through controls, MFA fires, and sessions are recorded.
• SCADA account hygiene. Identifying shared accounts, dormant accounts, and accounts with stale passwords.
• Backup restoration walk-through. Walking the engineering team through restoring a SCADA configuration from offline backup to confirm the procedure works.

Live SCADA control commands and modifications to running configurations remain out of scope. The path to those capabilities is testable; the actual exercise is not.

Findings consolidate into the engagement report alongside the broader OT security audit. Remediation prioritizes vendor-access governance, engineering-workstation hardening, account hygiene, and backup validation. Re-engagement on a one- or two-year cadence retests the closed paths.

Apply as a founding client or see how the engagement works for the full delivery cycle.