What is an industrial control system (ICS)?

Key takeaways

• ICS covers the equipment that moves the plant: controllers, operator interfaces, supervisory systems, engineering workstations, safety systems, and historians.
• ICS components have lifecycles of decades, run on validated software stacks, and tolerate disturbance poorly. The IT security playbook does not transfer directly.
• The most exploitable parts of a typical ICS are the IT-adjacent components: Windows-based HMIs, engineering workstations, and historians, not the PLCs themselves.
• Major historical attacks (Stuxnet, Triton, Industroyer, CRASHOVERRIDE) demonstrate the upper limit; the more common reality at mid-market manufacturers is ransomware reaching ICS via the IT side.
• ARG audits ICS in the context of the full plant: physical, IT, and OT in a single engagement.

What components make up an industrial control system?

A typical ICS in a mid-market manufacturing environment combines six categories of component, each with its own security profile.

1. Programmable logic controllers (PLCs). The controllers that execute the actual control logic for individual machines, lines, or processes. Hardware-specific firmware; vendor-specific programming environments (Rockwell Studio 5000, Siemens TIA Portal, Schneider EcoStruxure, Mitsubishi GX Works). The PLC itself usually has limited security features; defense relies on access control to the programming environment. See What is a PLC attack?.

2. Human-machine interfaces (HMIs). Operator screens that display process state and accept operator input. Often Windows-based, frequently running older OS versions that are no longer supported. The HMI software is vendor-specific (Rockwell FactoryTalk, Siemens WinCC, Wonderware/AVEVA, Inductive Automation Ignition).

3. SCADA systems. Supervisory aggregation across PLCs and HMIs, often spanning multiple lines or facilities. Combines historian, alarm management, reporting, and supervisory control. See What is SCADA security?.

4. Distributed control systems (DCS). Continuous-process control (refining, chemical, pulp and paper). More integrated than SCADA-PLC architectures; same general security profile as SCADA.

5. Safety instrumented systems (SIS). Independent logic that initiates a safe state when process variables exceed safe limits. Traditionally separated from the control network for both safety and security reasons; convergence pressure has eroded the separation in some installations.

6. Engineering workstations. The Windows PCs used by engineers to write and modify PLC, HMI, and SCADA programs. Almost always the most exploitable system in the ICS, because they bridge IT and OT, run Windows, and are the direct programming path to the PLCs.

A real installation also includes historians, alarm managers, batch managers, MES, recipe managers, and various vendor-specific accessories. The list above is the security-relevant minimum.

ICS architecture in a typical manufacturing environment

A representative mid-market manufacturing ICS architecture, simplified:

Plant floor sensors and actuators (Level 0)
        |
        v
PLCs (Level 1) ---- Safety instrumented systems
        |
        v
HMIs and local supervisory (Level 2)
        |
        v
SCADA / DCS / Historian (Level 3)
        |
        v
[Industrial DMZ]
        |
        v
Office IT / ERP / Reporting (Levels 4-5)

This is the simplified Purdue Model view. Real installations diverge from it in specific ways: dual-homed engineering workstations, vendor remote-access tools that bypass levels, historian-mirror servers that sit in both worlds. The architecture diagram and the real wiring usually do not match.

Security-relevant architecture decisions for a mid-market manufacturer:

• Where is the IT/OT boundary actually enforced. A firewall between Levels 3 and 4 is the textbook answer; the actual enforcement is often through firewall rules with documented exceptions.
• Where do engineering workstations live. A workstation that is sometimes on the OT network and sometimes on the IT network is a different risk profile than one that is permanently dual-homed.
• How is vendor remote access scoped. Vendor-by-vendor named accounts versus shared accounts; MFA versus no MFA; session recording versus none.
• Where is the historian and how is it accessed. Often the historian is the lateral pivot in real-world incidents.
• What network protocols cross the boundary. Modbus, EtherNet/IP, OPC UA, custom vendor protocols. Boundary controls need to understand them.

Why ICS environments are uniquely difficult to secure

Five structural challenges that make ICS security different from IT security:

1. Long equipment lifecycle. Equipment installed in 2008 is still running in 2026. Original vendor support has ended; firmware updates have ceased; the equipment cannot be replaced without rebuilding the line.
2. Validated software stacks. Many ICS components have vendor-validated software stacks. Patching breaks validation; running an unvalidated configuration introduces operational and (in regulated industries) compliance risk.
3. Real-time constraints. Control logic depends on deterministic timing. Security controls that add latency, jitter, or processing overhead can break the control loop.
4. Safety entanglement. Changes to control systems can have safety implications. Engineering review is required before changes; security alone cannot drive change.
5. Specialized protocols. Modbus, DNP3, EtherNet/IP, S7, MMS, OPC, vendor-proprietary protocols. Standard IT security tools do not understand them well enough to inspect, alert, or block meaningfully.

The combination forces ICS security toward different controls than IT: segmentation rather than agents, application allowlisting rather than antivirus, change control rather than continuous deployment, passive monitoring rather than active scanning, vendor management rather than tenant-wide policy.

Examples of real-world ICS attacks

The historical record provides the threat model.

• Stuxnet (2010). Targeted attack against Iranian uranium enrichment. Modified PLC ladder logic to damage centrifuges while reporting normal operation. Demonstrated that PLC code can be modified covertly and that physical damage is achievable through cyber means.
• BlackEnergy / Ukraine 2015. Attackers compromised IT-side Ukrainian electricity distribution companies via spear phishing, pivoted to SCADA, and tripped breakers to cause widespread outages. The IT-to-OT chain was the entire attack.
• Industroyer / CRASHOVERRIDE (2016). Tailored malware that understood industrial protocols (IEC 61850, IEC 60870-5-101/104, OPC DA). Demonstrated that adversaries can build protocol-aware tooling for targeted ICS attacks.
• TRITON / TRISIS (2017). Targeted attack against Triconex safety instrumented systems at a petrochemical facility. The attackers attempted to modify safety logic in a way that would have permitted physical damage to the facility while bypassing the safety interlock. Demonstrated that safety systems are not exempt from targeted attack.
• Colonial Pipeline (2021). Ransomware on the IT side caused a precautionary OT-side shutdown. The OT systems were not compromised, but operational dependence on IT systems forced the stoppage. Most realistic incident pattern for mid-market manufacturers.
• JBS Foods (2021). Ransomware shut down meat processing at multiple plants. Industrial-scale demonstration of ransomware's reach into manufacturing operations.
• Numerous water-utility and food-processor incidents (2023-2026). Steady cadence of mid-market industrial operators compromised through commodity ransomware that reaches OT-adjacent IT. The dominant real-world threat model for mid-market manufacturers.

The pattern across these incidents: targeted attacks are rare; their consequences when they happen are extreme. Commodity ransomware reaching OT through IT is common; consequences range from days of downtime to weeks of recovery. A mid-market manufacturer's program is mostly defending against the second pattern.

How to assess ICS security maturity

A maturity assessment covers six dimensions, each scorable from "absent" to "robust".

1. Asset inventory. Every PLC, HMI, SCADA component, engineering workstation, historian, and safety system documented with vendor, model, firmware, location, function.
2. Network architecture and segmentation. IT/OT boundary, internal OT segmentation by Purdue level or equivalent, documented exceptions and time-bounding.
3. Identity and access. Named accounts for OT systems; vendor access governance; engineering workstation privilege model; key control for physical assets.
4. Patching and lifecycle management. Documented patching cadence aligned with vendor and safety constraints; end-of-life equipment identified and compensated.
5. Detection and monitoring. OT-aware monitoring on the OT network; integration with the broader security operations function; alerting that produces action.
6. Incident response and recovery. OT-specific scenarios in the incident response plan; tested backup and restore for HMIs, SCADA configurations, and historian data; documented decision-making for production stoppage.

The assessment produces a roadmap with sequenced investments. For most mid-market manufacturers starting from minimal ICS-specific maturity, the sequence is asset inventory and architecture documentation first, segmentation and engineering-workstation hardening second, monitoring third.

Best practices for ICS protection

1. Segmentation aligned to Purdue with documented exceptions. Network architecture that follows the Purdue Model as a defensible structure.
2. Engineering workstation hardening. Application allowlisting, removable-media controls, restricted network access, EDR where vendor-supported. The engineering workstation is the most exploitable ICS asset.
3. Vendor remote access governance. Bastion-routed, named accounts, MFA, session recording, time-bounded. See What is the IT/OT convergence problem?.
4. Application allowlisting on Windows-based HMIs and historians. Where the vendor supports it; where they do not, document the compensating control.
5. Backup and restore validation. PLC programs, HMI projects, SCADA configurations, historian data backed up to offline media; restore tested quarterly or semi-annually.
6. Physical security for ICS spaces. Control rooms, network closets, and engineering rooms have physical access controls and visitor management appropriate to their criticality. See What is a physical security audit?.
7. Documented coordination with safety engineering. Changes to ICS that could affect safety logic are reviewed jointly. Safety-system isolation is preserved.
8. OT-aware monitoring. Passive monitoring with OT-protocol understanding, integrated with the broader security operations function.
9. Insurance and compliance alignment. Document ICS-specific controls for cyber insurance underwriting and (where applicable) NIST CSF 2.0 or CMMC compliance.

ICS FAQs

Is an ICS the same as an OT system?

ICS is a major subset of OT, not a synonym. OT also includes building automation, environmental monitoring, physical access control, and other operational equipment outside process control. In manufacturing context, the two terms are often used interchangeably because the dominant OT is the ICS. See What is operational technology (OT) security?.

Do ICS systems run on Windows?

HMIs, engineering workstations, and historians frequently run on Windows, often older versions (Windows 7, Windows Server 2008, even Windows XP) because they were validated against specific OS versions when the equipment was commissioned. PLCs and similar controllers run vendor-specific firmware, not general-purpose operating systems. The Windows components are usually the most exploitable from an IT-side perspective.

How long are ICS systems typically in service?

Ten to twenty-five years is normal for the physical equipment; the controllers and HMIs often run that long without replacement. The result is that a security program in 2026 needs to defend hardware and software designed in 2005 to 2015 against today's threats.

Why can't ICS environments use standard antivirus?

Standard antivirus can break ICS systems by consuming real-time resources, blocking legitimate OT processes, or disabling vendor-installed software during scans. Many ICS vendors explicitly disallow standard antivirus on their equipment; some allow specific ICS-aware variants. The right answer is application allowlisting, change control, and OT-aware monitoring rather than dropping IT antivirus into the environment.

How ARG approaches ICS in physical and digital audits

ARG audits ICS as part of an integrated engagement that covers physical, IT, and OT in a single program. The on-site work is conducted by David Ashby, drawing on a manufacturing background at Quality Electrical Systems and the operator experience that comes with it.

The audit covers the six maturity dimensions described above. Asset inventory and architecture review run in the first days of the on-site engagement; segmentation, identity, and patching assessment follow; detection and monitoring evaluation closes the technical assessment. Throughout, the auditor coordinates with the client's engineering team because ICS findings depend on engineering judgment.

Where the engagement permits, controlled exercises validate specific ICS-relevant attack paths during on-site weeks: pretexted access to engineering rooms, badge cloning where the technology permits, controlled demonstration of IT-to-OT pivot through engineering workstations. Live PLC control logic and safety systems are not directly tested; the path to the boundary is.

For founding clients, ICS audit and continuous monitoring (where the client tooling supports it) are part of the on-site engagement weeks and the continuous simulation retainer. The output supports NIST CSF 2.0, CMMC, and cyber insurance underwriting evidence requirements.

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