Why PLCs Are the Highest-Value Target in OT
A Programmable Logic Controller is not just another networked device. It is the physical embodiment of your production process translated into executable logic. It reads sensors, evaluates conditions, and drives actuators, in milliseconds, without human intervention, continuously. Compromise a corporate workstation and you gain access to data. Compromise a PLC and you gain control of a physical process: a motor, a valve, a pump, a chemical dosing sequence, a safety interlock.
This is why nation-state actors and sophisticated threat groups invest heavily in PLC-specific capabilities. The ability to modify PLC logic without triggering alarms gives an attacker the power to damage equipment, release hazardous materials, disrupt production, or bypass safety systems, while operators see nothing unusual on their HMI screens.
Understanding PLC-specific threats and defenses is no longer optional for organizations operating industrial environments.
From Stuxnet to PIPEDREAM: The Evolution of PLC-Targeted Attacks
Stuxnet (2010): The Proof of Concept
Stuxnet established that nation-state actors could target PLCs with surgical precision. The malware specifically targeted Siemens S7-315 and S7-417 controllers running centrifuge control logic at the Natanz uranium enrichment facility in Iran. It modified the ladder logic running on the PLC to cause centrifuges to spin outside safe speed parameters while simultaneously replaying normal sensor readings to the operators monitoring the process. The machines destroyed themselves while the control room showed all-green.
The lasting impact of Stuxnet was not the specific attack, it was the demonstration that PLC-targeted malware was achievable. The techniques it pioneered have influenced every subsequent OT attack development effort.
TRITON/TRISIS (2017): Targeting Safety, Not Production
TRITON targeted Safety Instrumented Systems (Triconex controllers) at a Middle Eastern petrochemical facility. The attackers attempted to modify SIS logic to disable safety functions while a separate attack was presumably planned on the DCS. Though the attempt ultimately failed due to a coding error that triggered a safety shutdown, TRITON demonstrated the intent to neutralize safety protections before causing a physical event.
PIPEDREAM/INCONTROLLER (2022): The Industrial Attack Toolkit
PIPEDREAM, disclosed by CISA and the Department of Energy in 2022, represented the most sophisticated publicly known ICS attack framework to date. It included modular components targeting Schneider Electric MODICON PLCs, OMRON Sysmac controllers, OPC UA servers used to manage communications across heterogeneous OT environments, and Codesys runtime environments running on a broad range of industrial controllers.
What made PIPEDREAM genuinely alarming was not just its breadth, but its method. It did not rely on exotic exploits. It could scan for target devices, brute-force credentials, upload modified ladder logic, and execute denial-of-service attacks against PLCs, all through legitimate protocol communications that most OT monitoring tools would not flag as inherently suspicious. An attacker armed with PIPEDREAM looks, at the network level, like an authorized engineer doing authorized work.
The disclosure of PIPEDREAM confirmed what security researchers had long warned: that adversaries have developed attack capabilities against PLCs that are readily deployable against energy and critical infrastructure targets.
Why PLCs Are Structurally Difficult to Secure
Several characteristics of PLCs make them uniquely challenging to protect:
No authentication on control protocols. Many industrial protocols used to communicate with PLCs require no authentication whatsoever. Any device on the same network segment can send read or write commands to a PLC. There is no credential to steal, no account to brute-force. Network access equals control access.
No integrity checking on logic. Standard engineering workflows allow PLC logic to be downloaded without any cryptographic verification that the logic matches an authorized, tested version. An attacker who gains network access to an engineering workstation can modify logic downloads without detection.
No logging of control commands. Most PLCs do not maintain audit logs of who wrote to their inputs, who downloaded logic, or what configuration changes were made. When an incident investigator asks "was the PLC configuration modified?", the honest answer is often "we don't know."
Long lifecycles and infrequent firmware updates. A PLC installed a decade ago may be running firmware with multiple known vulnerabilities that can never be patched because the process cannot tolerate the downtime required for a firmware upgrade, or because the vendor no longer supports that hardware generation.
Operational constraints on testing. In IT, you can test a security control in a staging environment. In OT, the production PLC often is the only environment. Testing security measures against PLCs that control running processes carries operational and safety risk.
Authentication Gaps in Common PLC Protocols
The lack of authentication at the protocol level is the most fundamental PLC security weakness, and it is worth understanding why this gap exists before discussing how to compensate for it.
Most industrial protocols were designed decades ago for closed, serial-connected environments where the only device that could talk to a PLC was the dedicated engineering workstation sitting in the same control room. Modbus, for example, dates to 1979. The idea of an adversary on the same network segment was simply not part of the design space. When these protocols were later adapted for Ethernet and TCP/IP, the transport changed but the zero-security model generally did not.
The result is that standard industrial communications, Modbus, EtherNet/IP, PROFINET, and many proprietary DCS protocols, carry no meaningful sender authentication. A device that can reach a PLC on the network can read its registers, write to its outputs, and in many cases download modified logic. Newer controller generations from Siemens and Rockwell have begun addressing this with optional authentication and encryption extensions, but adoption requires upgrading both controller firmware and engineering software, and large portions of the installed base will never support these features.
The implication is not that protocol authentication is unimportant, but that network controls, specifically restricting which devices can communicate with PLCs at all, become the primary compensating defense for environments where protocol-level authentication is unavailable.
PLC Hardening Strategies
Despite the structural challenges, meaningful security improvements are achievable without requiring major capital investment or operational disruption. In our work at Beacon Security, the following controls consistently deliver the most impact.
1. Network Isolation and Micro-Segmentation
The most impactful control for PLC security is limiting which devices can communicate with controllers at all. PLCs should reside in dedicated control zones with industrial firewalls enforcing communication restrictions:
- Only authorized engineering workstations should be able to initiate connections to PLCs on engineering protocol ports
- SCADA servers should be restricted to the specific read/write operations required for process control, blocked from making logic downloads or configuration changes
- No direct communication should be permitted between corporate IT networks and PLCs
- Vendor remote access should be restricted to a jump server in the industrial DMZ, with session recording enabled
2. Enable Native Security Features Where Available
Newer Siemens S7-1200 and S7-1500 PLCs support access protection at multiple levels, from HMI access that allows operator read/write but not program changes, to know-how protection that encrypts program blocks, to certificate-based authentication for engineering connections on the latest firmware versions.
Rockwell Automation ControlLogix and CompactLogix controllers support controller-level access permissions and, in recent firmware versions, a Source ID feature that adds session-based authentication to CIP communications.
Enable these features on every controller that supports them. For older controllers without native security features, compensating network controls become essential.
3. Logic Integrity Monitoring
One of the most valuable and underutilized controls is automated comparison of PLC logic against a known-good baseline. This means capturing and storing signed, versioned backups of all PLC logic after every authorized change, then using automated tools to periodically poll controller logic and compare it against that baseline. Any discrepancy between the deployed logic and the authorized baseline version should generate an immediate alert.
Logic integrity monitoring is the control most likely to detect a PIPEDREAM-style attack. Beacon Security has helped clients implement this capability across mixed-vendor environments, and the operational overhead is far lower than most teams expect once the initial baseline process is established.
4. Firmware Management
Maintain an inventory of firmware versions for every PLC in your environment. Monitor vendor security advisories for firmware vulnerabilities, plan firmware updates within scheduled maintenance windows, and for PLCs with critical vulnerabilities and no available patches, apply maximum network isolation and increase monitoring sensitivity for that zone.
5. Physical Security
PLCs are physical devices, and physical access has historically been an attack vector. Lock cabinets containing PLCs. Disable or control USB ports, they are a vector for removable media attacks. Ensure programming ports are not accessible without authorization.
Vendor-Specific Considerations
Siemens S7 Family: The S7-300/400 generation has minimal native security capabilities and should be compensated with strict network isolation and logic integrity monitoring. S7-1200 and S7-1500 offer substantially better security capabilities, and all new deployments should have access protection, TLS for HMI connections, and know-how protection enabled.
Rockwell Automation (Allen-Bradley): ControlLogix and CompactLogix controllers have improved significantly in recent generations. CIP Security with DTLS provides authentication and encryption for controller connections when both the controller and the connecting device support it. For older platforms, compensating network controls are the primary defense.
Schneider Electric (Modicon): The M580 generation introduced Ethernet security features including access control lists and secure communication modes. PIPEDREAM specifically targeted M340/M580 controllers, and all organizations running these should review whether the relevant firmware mitigations have been applied.
Emerson (DeltaV, PACSystem): DeltaV Mark Plus controllers include enhanced authentication and encryption capabilities in newer releases. Consult Emerson's security documentation for your specific release and apply available hardening configurations.
Building a PLC Security Program
Protecting PLCs is not a single project. It is an ongoing operational discipline. At Beacon Security, we frame this as a sequence of capabilities that build on each other rather than a checklist to complete and file away.
Start with inventory: you cannot protect what you cannot see. Know every controller in your environment, its vendor, model, firmware version, and network location. Then map communication exposure for each PLC, determining which devices communicate with it, over which protocols, and whether those communications require any form of authentication.
From that foundation, implement network controls that restrict PLC communications to authorized sources and eliminate direct paths from IT networks to controllers. Enable every native security feature available on each controller. Establish logic baselines and automated comparison. Deploy passive OT monitoring to detect unauthorized communications and unusual protocol activity.
Then, critically, test and validate. Periodically verify that your controls are working. Confirm that alerts fire when expected. The adversaries targeting PLCs are patient, technically capable, and motivated. The defense requires the same qualities.
Beacon Security provides PLC security assessments, hardening implementations, and logic integrity monitoring programs for industrial environments across all sectors and vendor platforms. Contact us to assess the security posture of your control systems.
