When organizations begin building an operational technology (OT) security program, the conversation almost always starts at the supervisory layer: servers, historian systems, HMIs, and SCADA platforms. These are visible, familiar, and governed by IT teams who understand how to protect them. What sits below that layer, the programmable logic controllers (PLCs) and the ladder logic running on them, rarely enters the conversation until something goes wrong.
That omission is one of the most consequential gaps in industrial cybersecurity today.
The code that runs production
A PLC isn’t just hardware. It’s the execution environment for the logic that governs industrial processes: the sequencing of an assembly line, the temperature of a controlled reaction, the pressure tolerances in a pipeline, the movement of a robotic arm. That logic, written by controls engineers and deployed directly to the device, is what keeps a facility operating within safe and productive parameters.
In most organizations, that code exists in one place: the device itself. There’s no consistent version history, no centralized repository, and no verified restore point. If the device fails, the code is often gone. If a change is made and something breaks, the path back to a stable state depends on whether someone happened to save a copy, and whether that copy was recent enough to be useful. In highly distributed environments with dozens or hundreds of sites, the probability that any given device has a reliable, current backup drops considerably.
Two types of attack, one unprotected target
When threat actors target PLC-level assets, they have two primary options, and both expose the same underlying vulnerability.
The first is code wipe. An attacker who gains access to a PLC can delete the logic running on it, halting production immediately. There’s no failsafe, no graceful degradation, and no automatic recovery. The facility stops. The question of how long it stays stopped depends entirely on whether a backup exists, how current it is, and how quickly it can be deployed. In environments with no backup infrastructure at that layer, the answer is often measured in days, not hours.
The second is code manipulation. This is a more deliberate and dangerous attack vector. Rather than deleting the logic, the attacker modifies it: adjusting a threshold, reversing a control condition, or introducing a subtle error that produces incorrect output without triggering an immediate alarm. The consequences range from product quality failures and regulatory violations to physical damage and, in critical infrastructure environments, safety incidents. The challenge with manipulation is that the attack may not be visible until damage has already occurred. Without a verified restore point and a comparison against a known-good version, identifying what changed and when becomes a forensic problem rather than a recovery one.
Why this gap persists
The persistence of this vulnerability isn’t a result of negligence. It reflects the historical separation between IT and OT, and the specialized nature of PLC programming environments. Controls engineers work in vendor-specific development tools, often disconnected from broader IT infrastructure, and backup practices that are standard in server environments were never designed with these devices in mind.
The result is that organizations invest in perimeter security, network segmentation, and endpoint protection at the supervisory layer while leaving the actual process logic unprotected and unversioned. The adversary who bypasses or circumvents those controls finds an asset with no backup, no audit trail, and no recovery path.
Treating ladder logic with the same care as server data
The same principles that govern data protection in IT environments apply directly to PLC code. Every version should be captured. Every change should be attributed to a specific user, at a specific time, with a record of what was modified. Recovery shouldn’t depend on memory, manual exports, or the hope that someone saved a file before the incident occurred.
Applying these principles to industrial automation environments means giving engineering teams a centralized, version-controlled repository for PLC logic across all vendors and sites. When an incident occurs, whether the result of a cyberattack, a failed change, or a hardware failure, the path to a verified restore point should be documented, current, and accessible, not dependent on whether someone thought to export a file before things went wrong.
The first step toward closing this gap is straightforward: establish a reliable backup of every critical PLC in your environment, and verify that it’s current. That single action converts the most overlooked vulnerability in OT security into a managed, recoverable asset.
Watch the OT Resilience Blueprint webinar to see how organizations are addressing this gap across the full Purdue model: Watch the webinar.
