OT Security

PLC

A Programmable Logic Controller is a ruggedized industrial computer that executes control logic in a continuous, deterministic scan cycle to automate physical processes.

Where you will see it: Relevant in industrial environments, critical infrastructure, and wherever IT networks connect to operational technology systems.

What it is

A PLC is a specialized industrial computer designed to control machinery and processes reliably in real time. Unlike a general-purpose computer, a PLC runs a fixed program in a continuous loop, interfaces directly with field devices through I/O modules, and is engineered to operate without failure in environments with vibration, temperature extremes, and electrical noise. PLCs are found wherever industrial processes need precise, repeatable automation: manufacturing lines, water treatment plants, power grids, oil pipelines, and building management systems.

Key points

Executes logic in a repeating scan cycle: read inputs, run program, write outputs.
Designed for determinism and reliability in harsh environments, not for flexibility or connectivity.
Programmed using IEC 61131-3 standardized languages, most commonly Ladder Diagram.
Communicates with SCADA systems and HMIs to receive setpoints and report process data.
Compromising a PLC means compromising the physical process it controls.

How it works in broad strokes

The PLC continuously executes a scan cycle: first it reads all physical input signals into an input image table in memory, then it executes the control program using that snapshot, and finally it writes the results to an output image table which drives physical outputs.
Physical field devices connect to I/O modules. Digital inputs might be switches or proximity sensors. Analog inputs might be temperature or pressure sensors. Outputs drive relays, solenoids, motors, or indicator lights.
Control logic is written on an engineering workstation using a programming environment and then downloaded to the PLC over a serial or network connection. The PLC stores the program in non-volatile memory and executes it independently from that point forward.
The PLC communicates upward to SCADA systems and HMIs, reporting process values and accepting setpoints or commands. This communication uses industrial protocols such as Modbus, EtherNet/IP, or Profinet depending on the vendor and era.
Scan cycle times are typically between one and one hundred milliseconds. This determinism is what makes PLCs suitable for time-critical control tasks where a delayed response could damage equipment or create a safety hazard.

Concrete example

A water treatment plant uses PLCs to control the dosing of chlorine into the water supply. The PLC reads a flow sensor to determine how much water is passing, calculates the required chemical dose, and drives a pump accordingly. If an attacker can reach the PLC and modify the setpoint thresholds in its control logic, they can cause the pump to operate outside safe limits without triggering any alarm, because the PLC will continue to report normal operation to the SCADA system. The physical process changes while the monitoring layer shows green.

Why it matters

PLCs directly control physical processes. An attacker who can modify PLC logic or manipulate setpoints can cause equipment to behave dangerously, damage assets, injure workers, or trigger process shutdowns. Stuxnet demonstrated that PLC-level compromise is achievable and can produce real physical consequences.

Security angle

Many PLCs were designed before network connectivity was standard and have no authentication on their communication ports. Any device on the same network segment can send commands.
The engineering workstation used to program PLCs is a critical attack surface. Compromising it is often the final step before an attacker can modify control logic.
Network segmentation is the primary defense. PLCs should never be directly reachable from corporate networks, and engineering workstation access should be restricted by VLAN and firewall rules.
Logic integrity verification is important but rarely implemented. Comparing the running program against a known-good baseline is one of the most effective OT security controls available.
Vendor remote access features, often left enabled by default, create persistent connectivity paths into OT networks that bypass normal access controls.

Common pitfalls

Treating PLCs like IT systems and expecting standard patch cycles. PLC firmware updates require vendor coordination, process downtime, and extensive testing.
Assuming air gaps are real. Historian servers, remote access tools, USB transfers, and vendor connections often create undocumented paths into supposedly isolated PLCs.
Leaving default credentials in place. Many PLCs ship with factory default passwords or no password at all, and these defaults are publicly documented.
Connecting PLCs directly to flat networks during commissioning or troubleshooting and then forgetting to restore the segmentation.

DEEP DIVE

▾

The scan cycle: the heartbeat of a PLC

The scan cycle is the fundamental operating model that distinguishes a PLC from every other kind of computer. A PLC does not wait for events and does not handle interrupts in the way that an operating system does. Instead, it executes the same sequence repeatedly, as fast as the hardware allows, for as long as it is powered on. That sequence is: read all inputs into a memory snapshot called the input image table, execute the entire control program using that snapshot, and then write the results to an output image table which is immediately reflected on physical output terminals.

The reason this matters is determinism. In a general-purpose operating system, tasks compete for CPU time, network interrupts arrive unpredictably, and execution time is variable. A PLC's scan cycle is bounded and predictable. A process engineer can state that the control loop will respond to a sensor change within a specific number of milliseconds, and that guarantee can be verified empirically. This is not a minor operational detail. In many industrial processes, a delayed response to a sensor reading is not just a performance problem but a physical safety problem.

The scan cycle also explains why PLC security is fundamentally different from IT security. A general-purpose computer can run security software alongside application software. A PLC's CPU is fully occupied running its deterministic scan cycle, and adding overhead has real consequences. Security functions that are routine in IT environments, such as TLS handshakes, certificate validation, and logging to remote systems, must be evaluated carefully in PLC contexts because they can affect scan cycle timing and therefore process control quality.

IEC 61131-3 programming languages and the Ladder Diagram tradition

PLCs can be programmed in several languages defined by the IEC 61131-3 international standard. The five languages are Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, and Sequential Function Chart. Each language was designed for a specific style of control problem and a specific audience. Ladder Diagram, by far the most widely used, was designed to look like the relay logic diagrams that electrical engineers were already drawing before PLCs existed. The intention was to make PLC programming accessible to people who understood electrical systems but not software.

Ladder Diagram represents logic as rungs on a ladder. Each rung is a logical condition that, when true, energizes an output coil. Contacts on the rung represent inputs or internal memory bits. The visual metaphor maps directly to relay ladder logic, which is why it became the default language for PLC programming and why it remains dominant decades later. Structured Text, by contrast, looks like a high-level programming language and is preferred for complex mathematical calculations. Function Block Diagram suits signal processing and control loop design. Sequential Function Chart is used for processes that move through defined states in sequence.

Understanding these languages matters for security for two reasons. First, anyone reviewing or auditing PLC logic must be able to read the program and understand what it does. A malicious modification to a Ladder Diagram rung that alters a setpoint or disables a safety interlock may not be obvious to someone unfamiliar with the language. Second, the programming environment on the engineering workstation is the point of entry for logic changes, which makes it a high-value target for attackers who want to influence what a PLC does without touching the PLC itself.

I/O modules and the interface with the physical world

A PLC's connection to the real world runs through its I/O modules. These are plug-in modules that attach to the PLC chassis and provide the actual electrical terminals where field wiring connects. Digital input modules detect whether a voltage is present or absent, translating an on or off signal from a switch, button, or proximity sensor into a binary bit in the input image table. Digital output modules work in reverse, driving relays, solenoids, or indicator lights based on bits in the output image table. Analog modules handle continuous signals, converting a 4 to 20 milliamp current or a 0 to 10 volt signal from a pressure transmitter or temperature sensor into a numeric value the program can use.

The physical design of I/O modules reflects the industrial environment where PLCs operate. They must tolerate wide temperature ranges, high humidity, vibration, and significant electrical noise from nearby motors and switching equipment. They also include electrical isolation between field wiring and the PLC's internal circuitry to protect the CPU from voltage spikes and ground faults. This ruggedization is one reason PLCs are not simply replaced with embedded PCs or IoT devices in critical applications, even when those alternatives are cheaper.

From a security standpoint, I/O modules represent the physical consequence layer of any PLC attack. Modifying logic in a PLC changes what signals the output modules drive. An attacker who can alter the program to override an output that controls a pressure relief valve, a circuit breaker, or a dosing pump is not modifying a data record. They are issuing commands to physical hardware that can produce immediate and potentially irreversible physical effects. This is the distinction that makes ICS security fundamentally different from most of cybersecurity.

PLC communication in modern ICS architectures

PLCs were originally programmed and operated in isolation, communicating only through physical signals and, later, proprietary serial protocols. Modern industrial architectures have changed this significantly. Today, PLCs are increasingly connected to plant-wide networks using Ethernet-based industrial protocols such as EtherNet/IP from Rockwell Automation, Profinet from Siemens, and Modbus TCP, which is a TCP/IP adaptation of the original Modbus serial protocol. This connectivity enables centralized SCADA monitoring, historian data collection, and remote troubleshooting, all of which have real operational benefits.

The connectivity also expands the attack surface in ways that the original designers did not anticipate and for which the protocols were not designed. Industrial protocols were built for reliability and interoperability in isolated networks, not for operation in environments where adversaries might be present. Most lack authentication mechanisms, encryption, or any means of verifying that a command comes from a legitimate source. A Modbus TCP device that receives a correctly formatted write command will execute it without questioning who sent it or whether they should be permitted to do so.

The practical security architecture for PLC communication depends on network segmentation rather than protocol-level security. PLCs should be placed in a dedicated control network zone that is isolated from both the corporate IT network and the internet. Communications between zones should pass through a demilitarized zone with firewalls and, where possible, data diodes or unidirectional gateways that allow data to flow upward to SCADA systems without allowing any commands to flow back down. This architecture does not fix the protocol weakness, but it limits who can reach the protocol in the first place.

Why PLCs are high-value attack targets

Stuxnet, discovered in 2010, remains the clearest demonstration of what a sophisticated attack against PLCs looks like. It targeted Siemens S7-315 and S7-417 PLCs controlling centrifuges in an Iranian uranium enrichment facility. The malware intercepted and manipulated Profibus commands to vary centrifuge speeds in a pattern designed to cause mechanical stress and failure. Simultaneously, it intercepted sensor readings and fed the monitoring systems recorded normal values, so the SCADA displays showed no anomaly while the physical machines were being damaged. The combination of logic manipulation and false telemetry made Stuxnet effective for a significant period before the damage became too obvious to miss.

The Stuxnet model reveals the two main attack vectors against PLCs: logic modification, where the program running on the PLC is changed to alter how it controls the process, and sensor spoofing or data manipulation, where the information flowing from the PLC to operators is altered to prevent detection. Both vectors require access to either the PLC network or the engineering workstation, which is why both are targets in sophisticated ICS intrusions. Attackers who gain access to a corporate network first will often spend considerable time moving laterally through historian servers, jump hosts, and vendor access channels before reaching the control network.

Defending PLCs therefore requires more than technical controls on the PLCs themselves. It requires understanding the full path an attacker would take to reach them, from initial access through the corporate network, through any shared infrastructure, through vendor connections or remote access tools, to the engineering workstation, and finally to the PLC. Each step in that path is a detection opportunity and a place where access can be denied. The goal is not to make PLCs impenetrable in isolation but to ensure that reaching a PLC requires defeating multiple independent controls, any one of which might trigger detection before the attacker can execute their objective.