A programmable logic controller is an industrial computer used to control machines and processes in factories and other automated environments. It reads inputs from sensors, runs a control program, and drives outputs such as motors, valves, and relays in real time.
What a Programmable Logic Controller Is
A programmable logic controller, or PLC, is a hardened industrial computer built to execute control logic deterministically, often under real-time constraints. It sits between field inputs and machine outputs, translating sensor states into actions that keep physical processes moving safely and consistently.
That role makes the PLC more than a generic computer. It is part controller, part bridge between the digital and physical worlds, and part operational dependency for equipment that may be expensive, safety-relevant, or production-critical.
How PLCs Fit Into Industrial Control Systems
PLCs are central to industrial control systems such as manufacturing lines, utilities, process plants, and building automation. They typically read inputs from switches, sensors, timers, and other devices, then apply logic to drive relays, valves, motors, and alarms. The value of the PLC lies in predictable execution, simple maintenance, and direct interaction with equipment.
In practice, PLCs are often one layer in a wider OT stack that may also include engineering workstations, HMIs, historians, remote access paths, and supervisory systems. An OT Security Guide helps place the controller inside that broader industrial environment, including segmentation, zones and conduits, and the special care needed around industrial protocols.
Why PLC Logic Matters Operationally
The control program is the PLC’s decision-making core. Small changes in logic can alter timing, sequencing, interlocks, and fail-safe behaviour, so the program is not just code, it is operational policy embedded in the machine layer. That is why PLCs are treated as production assets with strict change control, testing, and rollback expectations.
PLCs are also closely tied to engineering trust. Operators assume the controller is running approved logic, receiving valid inputs, and producing expected outputs. When that assumption fails, the impact can be physical process disruption, product quality loss, safety hazards, or unexpected shutdowns.
PLC Security and Control Boundaries
PLC security is about protecting both the controller itself and the trust relationships around it. The main concerns are unauthorised logic modification, weak remote access, exposed programming interfaces, insecure industrial protocols, and uncontrolled use of engineering tools or removable media. In many environments, the issue is not just whether the PLC is online, but whether the right people and systems can alter its behaviour.
Because PLCs can directly influence physical outcomes, security controls need to protect program integrity, access paths, and operational visibility. That includes segmentation between enterprise and OT networks, restriction of write access, monitoring for unexpected download or mode changes, and review of controller logic after maintenance or incident response.
Risk and Threat Considerations
PLCs are attractive targets because compromise can move quickly from digital access to physical consequences. Attackers may try to alter controller logic, disrupt timing, stop processes, or hide abnormal behaviour by manipulating what the controller sees or does.
Failure mechanism: A hostile actor or faulty integration abuses trusted programming access, weak segmentation, or insecure industrial protocols to change ladder logic, force outputs, or interfere with controller state.
Impact: The result can be unsafe operation, equipment damage, production loss, downtime, or a delayed response to a real process fault.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | PLCs often authenticate engineering tools, remote users, or external maintenance access. |
| Recommendation — Require strong authentication for all non-organizational access paths into PLC environments. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | PLC environments depend on segmented industrial networks and tightly governed control paths. |
| Recommendation — Segment OT networks and tightly manage controller-facing communication paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Protective Technology, Least Privilege and Access Control | PLC security depends on limiting who can modify controller logic or interact with privileged functions. |
| Recommendation — Restrict PLC write access and enforce least privilege for engineering and maintenance roles. | ||
| MITRE ATT&CK | T0821 — Modify Controller Tasking | PLC compromise commonly involves changing the controller's tasking or logic to alter process behaviour. |
| Recommendation — Detect and hunt for logic modification attempts against PLC tasking and program state. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network Security | Industrial controllers rely on secure segmentation and controlled communications to reduce exposure. |
| Recommendation — Apply network security controls to isolate PLCs from unnecessary or unsafe connectivity. | ||
Practitioner Guidance
Why practitioners should care: PLCs are operationally simple on the surface, but they carry disproportionate business and safety consequences because they sit so close to the physical process. Treat controller logic, programming access, and remote maintenance paths as high-value assets, not ordinary IT endpoints.
What to watch for: Unexpected logic changes, unplanned mode switches, new engineering connections, and controller behaviour that no longer matches the approved process design all deserve immediate attention. A post-change review should confirm that the running program, the stored program, and the physical process state still align.