PLC Security: Hardening Programmable Logic Controllers
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
PLC Security: Hardening Programmable Logic Controllers
Programmable logic controllers are the execution layer of industrial automation: they receive sensor inputs, execute control logic, and drive actuators that move physical processes. A compromised PLC doesn't just generate a security event. It can damage equipment, produce unsafe process conditions, or cause production loss that costs hundreds of thousands per hour. Dragos identified PLC-targeting capabilities in 11 distinct threat groups in 2024, up from 6 in 2022, reflecting the growing sophistication of adversaries pursuing PLC access (Dragos, 2024).
Key Takeaways
- PLCs execute physical control logic; their compromise can cause equipment damage, unsafe conditions, and production loss.
- Primary PLC attack vectors: engineering workstation compromise, network-direct protocol attacks, and supply chain firmware manipulation.
- Hardening priorities: disable unused ports/protocols, restrict network access, implement firmware integrity verification, and control engineering software access.
- Most PLCs can't support MFA or encryption natively; compensating controls at the network level are essential.
- 11 threat groups had documented PLC-targeting capabilities in 2024, up from 6 in 2022 (Dragos, 2024).
PLC hardening differs fundamentally from IT system hardening. IT systems run operating systems that accept security configurations: enable firewall, disable services, apply patches. PLCs run proprietary firmware that often provides no security configuration options. The hardening strategy for PLCs is therefore a combination of the limited device-level controls available and the network-level controls that compensate for the device's security limitations.
[UNIQUE INSIGHT: PLC security programs typically focus on the PLC itself, but the engineering workstation used to program the PLC is the more practical hardening target. Every PLC in a facility is programmed from one or a small number of engineering workstations. A compromised engineering workstation has write access to all PLCs it can reach, making it a more consequential target than any individual PLC. PLC security starts with engineering workstation security.]
What Are the Main PLC Attack Vectors?
PLC attacks follow three primary paths. Engineering workstation compromise: attackers compromise the Windows workstation used to program PLCs, then use legitimate engineering software to modify PLC logic or parameters. This was the Stuxnet approach: compromise engineering workstations, modify PLC logic through Siemens Step 7 software, hide the modification from HMI displays. Network-direct protocol attacks: attackers with network access to the PLC use industrial protocols (Modbus write, EtherNet/IP tag writes, PROFINET I/O) to modify PLC outputs directly without engineering software. Firmware manipulation: supply chain attacks that compromise PLC firmware before installation, or attacks that exploit firmware update mechanisms to deploy modified firmware.
The network-direct protocol attack is now the most common PLC attack vector in Dragos incident data, because it doesn't require engineering software or specialized PLC knowledge. Writing a Modbus coil register to 1 or 0 requires only network access to TCP port 502 and knowledge of the register address. Attackers increasingly use open-source tools like ModbusPal and EtherScan to interact directly with PLCs without needing proprietary engineering software.
Engineering Workstation as Attack Pivot
Engineering workstations typically run Windows and have network connectivity to all PLCs in the facility, making them high-value targets for attackers seeking PLC access. They often run legacy versions of Windows (Windows 7, Windows XP) because the engineering software hasn't been validated on newer operating systems by the PLC vendor. They may have internet access for software licensing and updates. They are frequently shared among multiple engineers, making individual accountability for actions difficult. This combination makes engineering workstations among the most exploitable entry points to PLC access in industrial environments.
How Do You Harden PLC Device Configuration?
PLC hardening at the device level varies by manufacturer and model but consistently includes several configuration actions. Disable unused communication ports on the PLC CPU: most PLCs have multiple Ethernet ports; ports not required for production communication should be disabled. Disable the PLC web server if not operationally required: most modern PLCs include a built-in web server for diagnostics; if it's not used, disable it to remove a web application attack surface. Enable PLC-level password protection where available: many PLCs support passwords for program download, online change, and memory protection; enable them all and store credentials in the privileged access management system.
Change default credentials on all PLCs before deployment. Dragos found default credentials still in use on 53% of PLCs assessed in their 2024 environment reviews. Default credentials are publicly documented in vendor manuals, making PLC networks with default credentials trivially accessible to any attacker who has reached the OT network. Default credential remediation is the highest-priority PLC hardening action and can usually be completed without production downtime.
[IMAGE: PLC hardening checklist infographic showing device-level and network-level controls for PLCs with manufacturer-specific notes - search terms: PLC security hardening checklist industrial controller cybersecurity Siemens Allen-Bradley]
Firmware Integrity Verification
PLC firmware integrity verification ensures that the firmware running on a PLC is the authorized version and has not been tampered with. This requires establishing a firmware baseline for each PLC model and version: documenting the authorized firmware version, its cryptographic hash, and the authorized source. Before deploying firmware updates, verify the update package against the vendor's published hash. After deployment, verify that the PLC reports the expected firmware version. Tools like Claroty and Dragos can passively detect firmware version anomalies across all PLCs in a monitored network, flagging devices running unexpected firmware versions for investigation.
Citation Capsule: Dragos identified 11 distinct threat groups with PLC-targeting capabilities in 2024, including groups associated with nation-state actors targeting critical infrastructure. This represents an 83% increase from 6 groups identified in 2022, reflecting accelerating adversary investment in industrial control system attack capabilities (Dragos, 2024).
Need expert help with plc security: hardening programmable logic controllers?
Our cloud architects can help you with plc security: hardening programmable logic controllers — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
How Do You Control Access to PLCs?
PLC access control operates at two layers. Network access control: which devices and workstations can reach the PLC's communication ports? Logical access control: which users can connect to the PLC and what actions can they perform? Network access control is the more enforceable layer for most PLCs, since many don't support granular logical access control natively.
Network-level PLC access control is implemented through industrial firewalls, VLAN segmentation, and network access control lists. The firewall rule set for a PLC zone should permit only specific source IP addresses (identified engineering workstations, SCADA servers, historian) to reach PLC communication ports, on specific protocols required for that PLC's operation. All other traffic to PLC ports should be denied and logged. This limits PLC access to authorized systems even if an attacker has reached the broader OT network.
Engineering Software Access Controls
Engineering software access (Siemens TIA Portal, Rockwell Studio 5000, Schneider EcoStruxure) should be controlled through privileged access management (PAM). Engineers should access PLC programming software through a PAM system that authenticates them individually, limits access to PLCs within their assigned scope, records all programming sessions, and generates alerts for unusual programming actions (after-hours access, large logic downloads, setpoint modifications outside normal ranges). PAM integration for engineering software is offered by vendors including CyberArk and Delinea, with OT-specific workflows that account for the operational context of programming activities.
How Do You Isolate PLCs from Network-Direct Attacks?
Network isolation for PLCs means placing them in dedicated zones with tightly controlled conduits. A PLC zone should receive only the specific protocol communications it requires for operations: read commands from the SCADA historian, write commands from authorized SCADA servers, and programming connections from authorized engineering workstations. All other traffic is denied. This isolation is enforced by industrial firewalls at the zone boundary, configured with protocol-aware rules that inspect Modbus function codes, EtherNet/IP service types, and DNP3 application layer content.
Micro-segmentation within the PLC zone further limits lateral movement. If an attacker compromises one PLC or an engineering workstation with access to one PLC group, VLAN segmentation within the zone prevents that foothold from being used to reach adjacent PLCs. The communication matrix for micro-segmentation at this level is usually developed with process engineers who know which PLCs communicate with each other for interlocking, coordination, and data exchange purposes.
Frequently Asked Questions
Can PLCs be patched like IT systems?
PLC firmware updates are more constrained than IT patching. Vendor validation of firmware updates can take 6-12 months. Updates require engineering validation to ensure production logic operates correctly with the new firmware. Production downtime is required for the update. These constraints mean that PLC firmware is typically updated 1-2 times per year during scheduled maintenance shutdowns, not on the monthly cycle of IT patching. Virtual patching at the network level compensates for unpatched PLC vulnerabilities between firmware update cycles ([NIST SP 800-82r3, 2023](https://doi.org/10.6028/NIST.SP.800-82r3)).
What is safe-state logic for PLC security?
Safe-state logic defines the default behavior of actuators and outputs when the PLC loses communication or detects an invalid command. Properly configured safe states ensure that if a PLC is compromised or communication is disrupted, the physical process moves to a defined safe condition rather than an unpredictable one. Safe-state configuration is a joint responsibility of process engineers and control system designers, and security reviews should verify that safe-state logic is present and correctly configured for all critical PLC outputs.
How do you detect PLC compromises?
PLC compromise detection requires three capabilities: network monitoring that detects unexpected connections to PLC ports; protocol analysis that identifies unauthorized function codes or register write operations; and configuration monitoring that detects changes to PLC logic, setpoints, or parameters outside the change management process. OT monitoring platforms including Dragos, Claroty, and Nozomi compare current PLC program hashes against established baselines and alert when unauthorized logic changes are detected. This detection capability is one of the highest-value controls for ICS security programs.
Conclusion
PLC security requires accepting the device's limitations and building security around it rather than into it. Most PLCs can't support MFA, encryption, or advanced access controls natively. But every PLC can be isolated by network controls, every PLC programming session can be managed through PAM, and every PLC's logic can be monitored for unauthorized changes by passive OT monitoring tools.
The organizations whose PLCs survive sophisticated attacks are not those with the most sophisticated PLCs. They are those that applied the available device hardening, built strong network isolation around the device, controlled all access to PLC programming tools, and deployed monitoring capable of detecting protocol-layer attacks and logic modifications. These four controls, applied consistently across all PLCs in the environment, create a defensible PLC security posture regardless of the device's native security capabilities.
Related Articles
About the Author
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
