What is a PLC (programmable logic controller) attack?

Key takeaways

• A PLC is the controller that executes the actual process logic. Manipulating it manipulates the physical process.
• The dominant attack vector against PLCs is the engineering workstation, not the PLC itself. The IT-side compromise reaches the PLC through the legitimate programming path.
• PLC attacks can cause physical damage to equipment, scrap product, or create unsafe operating conditions.
• Defense centers on engineering workstation hardening, network segmentation, and (where supported) authenticated programming sessions.
• For mid-market manufacturers, direct PLC attacks are rare; ransomware reaching the engineering workstation surface is common.

What is a PLC, and how is it controlled?

A programmable logic controller (PLC) is a ruggedized industrial computer that executes control logic for a specific machine or process. It reads inputs from sensors (temperature, pressure, position, presence), executes a program (often in ladder logic or a similar formal language), and drives outputs to actuators (motors, valves, heaters, lights).

PLCs come from a handful of major vendors: Rockwell Automation (Allen-Bradley), Siemens, Schneider Electric, Mitsubishi, Omron, ABB, and Beckhoff dominate the installed base. Each vendor has its own programming environment, its own communication protocols, and its own ecosystem of accessories.

A PLC is programmed through three principal paths:

1. The engineering workstation. A Windows PC running vendor-specific programming software (Rockwell Studio 5000, Siemens TIA Portal, Schneider EcoStruxure Control Expert, etc.) connects to the PLC and uploads programs.
2. The network protocol. Most modern PLCs accept programming over Ethernet using vendor-specific or open protocols (Modbus TCP, EtherNet/IP, S7, Modbus RTU over Ethernet, OPC UA).
3. The physical programming port. Many PLCs have a serial or USB programming port for direct local programming. Physical access to the PLC enables programming through this path.

Each path is a potential attack vector. Most real-world PLC attacks reach the PLC through the first path (the engineering workstation); some sophisticated attacks use the second (protocol-aware) or third (physical) paths.

The four main PLC attack vectors

ARG categorizes PLC attack vectors as four: engineering workstation, network, firmware, and supply chain.

1. Engineering workstation. The dominant real-world vector. The attacker compromises the Windows PC that programs the PLC, typically through spear phishing, drive-by download, or USB media. Once the workstation is compromised, the next legitimate programming session pushes attacker-controlled logic to the PLC. The PLC has no way to distinguish authorized programming from malicious programming when both come through the same workstation. See What is the IT/OT convergence problem?.

2. Network protocol. The attacker reaches the PLC over the network (after lateral movement from the IT side or via direct OT-network access) and uses the PLC's programming protocol to interact with it. Most older PLCs accept programming requests without authentication; some newer models require authentication or hardware-based authorization but enforcement is uneven. Protocol-aware attack tooling (Industroyer, CRASHOVERRIDE, INCONTROLLER/PIPEDREAM) demonstrates the upper limit of this vector.

3. Firmware. The attacker manipulates the PLC's firmware, either through the legitimate update mechanism (if the update path can be hijacked) or through a vulnerability that allows firmware writes. Firmware attacks are more persistent and harder to detect than program attacks because they survive even a complete reprogramming.

4. Supply chain. The attacker compromises the PLC at the vendor, distributor, or integrator stage. The PLC arrives at the manufacturer already containing modified firmware or hidden capabilities. Low frequency for general-purpose attacks; higher frequency for targeted attacks against high-value targets. See What is a supply chain attack?.

For a mid-market manufacturer, the engineering workstation vector is the realistic threat. Most defending investment should go there. The network, firmware, and supply chain vectors are real but require more sophisticated attackers; the controls against them (segmentation, vendor management) overlap with controls for other OT threats.

Why PLC attacks can cause physical damage to equipment

PLCs control physical actuators directly. The attacks Stuxnet pioneered demonstrated that small modifications to control logic can produce material physical effects:

• Equipment damage. Running a motor outside its rated speed, operating a heater above safe temperature, opening or closing valves at the wrong moment, operating mechanical systems beyond their design envelope.
• Process upset. Producing out-of-specification product, scrapping batches, causing reactor instability, creating environmental excursions.
• Safety incidents. Modifying control logic in ways that defeat or delay safety interlocks. The TRITON case demonstrated that safety logic itself can be a target.
• Hidden manipulation. Subtle changes that produce gradual effects: a slight calibration drift, a small change in dwell time, a modified setpoint. Detection through process metrics alone is unreliable because the change is within normal variability.

The consequences are physical and often expensive. A PLC attack that damages a multi-million-dollar machine is not the same magnitude as ransomware that encrypts a server. The recovery cost can include equipment replacement, environmental remediation, safety investigation, and regulatory response.

Examples of PLC-targeted attacks

The historical record provides the threat model.

• Stuxnet (2010). The most famous case. Attackers modified PLC logic at Iranian uranium enrichment to damage centrifuges while reporting normal operation to the SCADA layer. Demonstrated that PLC manipulation can be covert, durable, and produce physical effect.
• TRITON / TRISIS (2017). Targeted attack against Triconex safety instrumented systems at a petrochemical facility. The attackers attempted to modify safety logic to allow physical damage. Demonstrated that safety systems are attack targets.
• Industroyer / CRASHOVERRIDE (2016). Protocol-aware malware that interacted directly with industrial protocols. Demonstrated that protocol-level attack tooling exists.
• INCONTROLLER / PIPEDREAM (2022). Toolset identified before deployment that targeted Schneider Electric PLCs, Omron PLCs, and OPC UA servers. Demonstrated that protocol-aware tooling against major vendors is an active development effort.
• Various ICS-CERT advisories. Continuous cadence of vulnerability disclosures against major PLC vendors. Most do not produce documented incidents but indicate the underlying surface.
• Limited public mid-market PLC incidents. Mid-market manufacturers rarely disclose PLC-specific incidents. The dominant pattern in this segment is ransomware reaching engineering workstations, with PLC programming integrity disturbed as a side effect; targeted PLC modification is rare here.

The pattern: targeted PLC attacks happen, are extreme in consequence, and are relatively rare against mid-market manufacturers. The realistic threat is collateral damage from broader incidents reaching the engineering workstation surface.

How to harden PLC environments without breaking production

Hardening sequence for a mid-market manufacturer starting from minimal PLC-specific maturity:

1. Inventory. Every PLC documented: vendor, model, firmware version, location, function, programming workstation that owns it, last program backup date.
2. Engineering workstation segmentation. Workstations that program PLCs sit on a dedicated network segment with documented egress and ingress rules. Web browsing and email do not happen on the programming workstation; another workstation handles those.
3. Engineering workstation hardening. Application allowlisting, removable-media controls, account hygiene, EDR where the PLC vendor supports it.
4. Network access control on PLC programming protocols. Firewall or access control list permits the programming workstation to reach the PLC; other devices on the OT network cannot.
5. Program backup and checksums. PLC programs backed up to offline media after every authorized change. Periodic comparison of running program checksum to backed-up checksum identifies unauthorized modifications.
6. Physical access to PLCs. Control cabinets locked with appropriate access control. The physical programming port is not accessible without controlled access.
7. Vendor management for firmware updates. Updates scheduled, validated, and applied through documented procedure. Field updates without backup and validation are not permitted.
8. OT-aware monitoring on PLC programming protocols. Alerts on programming-protocol traffic from unexpected sources or at unexpected times.

The sequence assumes the engineering workstation is the highest-leverage target. For most mid-market manufacturers, this is correct.

Best practices for engineering-workstation security

The engineering workstation is the most exploitable PLC-adjacent asset. Best practices specific to it:

1. Dedicated machine for PLC programming. Not a general-purpose laptop. Locked-down, application-allowlisted, with no email or browsing.
2. Air-gapped or controlled USB transfer. Programs and updates move between the engineering workstation and the rest of the network through controlled USB media, with malware scanning at the transfer point. Direct network connectivity between the engineering workstation and the IT network is minimized.
3. Application allowlisting. Only the vendor programming software and required accessories run. Everything else is blocked.
4. Removable-media controls. Only approved, scanned media. Unknown USB devices are rejected at the OS level.
5. EDR where vendor-supported. Some vendors allow specific EDR products on engineering workstations; some do not. Where allowed, deployed. Where not, the compensating controls (allowlisting, network restriction, USB control) are stricter.
6. Account hygiene. Named accounts for each engineer. Shared "engineer" accounts replaced. MFA where the OS and PLC software support it. Privileged accounts restricted to specific times and tasks.
7. Patching cadence aligned with vendor. Windows patches applied on schedule. Vendor software updates applied on the vendor's recommended cadence. The cadence is documented; emergency out-of-band patching has a documented path.
8. Physical security on the workstation. The engineering workstation is in a secured area (engineering office, control room) with appropriate physical access controls. The screen is not visible from public or semi-public space.
9. Logging and monitoring. Workstation activity logged. Anomalous behavior (off-hours access, unusual program downloads, unexpected USB events) surfaces in the broader security operations function.
10. Backup and recovery. Workstation imaged regularly. PLC programs backed up after every change. Recovery tested annually.

PLC attack FAQs

Can a PLC attack be detected in production?

Sometimes. A subtle modification to control logic can be hard to detect from process telemetry alone, especially if the attacker also modifies the supervisory reporting (as in Stuxnet). Periodic comparison of PLC program checksums against known-good baselines, change-control discipline, and OT-aware network monitoring on PLC programming protocols give the best chance of detection.

Do PLC firmware updates introduce risk?

Yes, in two ways. The update process itself opens a window during which the PLC accepts new code. The update content (firmware from the vendor) carries supply chain risk if the vendor is compromised. The right practice is scheduled, vendor-coordinated, validated updates rather than informal field updates.

How is PLC programming usually secured?

Through access control on the engineering workstation that programs the PLC, physical access control on the PLC and its programming port, network segmentation that prevents unauthorized devices from reaching the PLC programming protocol, and (where the PLC supports it) authentication and integrity protection on the programming session itself.

What is the difference between a PLC attack and an HMI attack?

A PLC attack modifies the controller that executes control logic. An HMI attack modifies the operator interface that displays state and accepts commands. PLC attacks change what the process does; HMI attacks change what the operator sees or can command. Sophisticated attacks combine both to make changes harder to detect.

How ARG assesses PLC attack surface during on-site engagements

PLC attack-surface assessment is part of ARG's integrated on-site audit at manufacturing clients. The assessment is conducted by David Ashby with engineering-team participation, drawing on a manufacturing background at Quality Electrical Systems for the engineering credibility required to ask the right questions.

The assessment covers:

• Inventory of PLCs and engineering workstations. Vendor, model, firmware, location, programming workstation ownership.
• Engineering workstation security state. Hardening status, network position, account hygiene, physical placement.
• Network access to PLC programming protocols. Which devices can reach each PLC's programming protocol; whether the controls match the documented design.
• Program backup discipline. Backup cadence, offline storage, restoration testing, checksum baseline maintenance.
• Physical access to PLCs. Cabinet locks, control room access, programming port accessibility.
• Vendor remote-access scope. Which vendors program PLCs remotely, through which controls, with what authentication and logging.

Where the engagement permits, controlled exercises validate specific paths during on-site weeks: pretexted access to engineering rooms, badge cloning where the technology permits, controlled demonstration that a spear-phished engineering workstation would reach the PLC programming surface. Live PLC modification is not performed.

Findings consolidate into the engagement report. The remediation backlog prioritizes engineering workstation hardening, network segmentation around PLC programming protocols, and program backup discipline. 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.