Programmable Logic Controllers (PLCs) Explained: What They Are and Why They Are a Cybersecurity Target

If you have ever wondered what actually runs the physical world, programmable logic controllers are a large part of the answer. PLCs control the conveyor belts in automotive assembly plants, the compressor stations along natural gas pipelines, the dosing pumps at water treatment facilities, and the motor drives at mining operations. They are the execution layer of industrial automation, and there are estimated to be several hundred million of them deployed globally across critical infrastructure.

They are also among the most frequently targeted assets in OT cybersecurity incidents. Stuxnet, the first publicly attributed cyber weapon, targeted Siemens PLCs at Iranian uranium enrichment facilities. The TRITON malware targeted safety instrumented systems built on Triconex PLC architecture at a Middle Eastern petrochemical plant. Volt Typhoon, a Chinese nation-state actor, has been documented conducting reconnaissance against PLC-level assets in US critical infrastructure. According to Dragos' 2025 Year in Review, PLC-targeting malware families are now tracked as a distinct threat category.

Understanding what PLCs are, how they fit into the industrial network, and what makes them difficult to secure is the foundation for any practical OT cybersecurity program.

 

What Is a Programmable Logic Controller?

A programmable logic controller is a ruggedized industrial computer designed to perform repetitive control tasks in real time. Unlike a general-purpose computer, a PLC is built to operate reliably in industrial conditions: high temperatures, vibration, electrical noise, and dust. It reads inputs from field sensors, executes a programmed control logic sequence, and sends output commands to actuators, motors, valves, and other field devices.

The name comes from the original function: replacing banks of hardwired electromechanical relay panels with a programmable device that could be reconfigured without rewiring the physical system. Modern PLCs do this and much more, running complex process control logic, communicating over industrial networks, and integrating with supervisory systems.

How PLCs Work: The Scan Cycle

PLCs operate on a deterministic scan cycle: the processor reads all input states from connected sensors, executes the control logic program from top to bottom, updates all output states to the connected actuators, and then repeats. Scan cycle times are typically measured in milliseconds. This determinism is critical for industrial processes where timing precision directly affects product quality, equipment protection, or process safety.

This is also what makes standard IT security tools dangerous in PLC environments. An active network scan that sends unexpected packets to a PLC can interrupt the scan cycle, cause a watchdog timeout, or force the device into a fault state. For a PLC controlling a live process, that means an unplanned shutdown.

Key PLC Components

 

Component	Function	Security Relevance
CPU (Central Processing Unit)	Executes the control program and manages communications	Firmware vulnerabilities, default credentials, unauthorized program modification
I/O Modules (Input/Output)	Reads sensor signals (inputs) and sends commands to actuators (outputs)	Physical access, signal injection in advanced attacks
Communications Module	Connects PLC to industrial network and engineering software	Protocol vulnerabilities, unauthenticated connections, and remote access exposure
Power Supply	Provides regulated power to PLC components	Physical resilience; cybersecurity impact is indirect
Programming Interface	Port used to upload/download the control program	Primary attack vector for unauthorized logic modification

 

Where PLCs Are Used in Industrial Environments

PLCs are deployed across every major industrial sector. The specific platform, communication protocol, and security capability vary significantly by vendor, age, and application.

 

Industry	Typical PLC Application	Common Vendors
Oil and Gas	Wellhead control, compressor station automation, pipeline SCADA, metering	Allen-Bradley, Siemens, ABB, Emerson
Manufacturing	Assembly line control, robotic cell management, packaging, quality systems	Rockwell Automation, Mitsubishi, Fanuc, Beckhoff
Energy and Utilities	Substation automation, pump station control, generator management, grid switching	Siemens, ABB, GE, Schweitzer Engineering
Pharmaceuticals	Batch process control, clean room HVAC, filling, and packaging automation	Rockwell, Siemens, Emerson, Schneider Electric
Mining	Conveyor systems, crusher control, ventilation, hoist management, remote site automation	Allen-Bradley, Siemens, ABB
Water and Wastewater	Pump control, chemical dosing, filtration, distribution pressure management	Allen-Bradley, Schneider Electric, Siemens

 

Where PLCs Sit in the Industrial Network

To understand PLC security, it is important to understand where PLCs sit in the industrial network architecture. The Purdue Model for OT security places PLCs at Level 1, directly above the field instruments at Level 0 and directly below the SCADA and HMI systems at Level 2. This positioning makes PLCs the execution layer: they receive commands from the supervisory layer above and send commands to the physical process below.

Why Level 1 Is the Highest-Consequence Target

Level 1 PLC compromise is the highest-consequence attack scenario in industrial cybersecurity. An attacker who can modify PLC logic can change how the physical process behaves without triggering any of the IT-layer security controls that might otherwise detect malicious activity. Process data displayed on HMIs and reported to historians comes from the PLC. If the PLC is running compromised logic, the operator may see normal readings while the physical process is behaving abnormally.

This is exactly what Stuxnet achieved: it modified the frequency drives controlling centrifuge motors while reporting normal operating parameters to the operators at Natanz. The most sophisticated ICS attack vectors documented by cybersecurity researchers all converge on this goal: reaching Level 1 to manipulate the physical process.

 

Why PLCs Are Difficult to Secure

Designed for Reliability, Not Security

Most PLCs in operation today were designed and deployed before industrial cybersecurity was a recognized discipline. The design priorities were reliability, uptime, and deterministic performance. Authentication, encryption, and access control were afterthoughts, if they were considered at all. Many legacy PLCs have no user authentication at the programming interface. Anyone who can reach the programming port can read or modify the control logic.

Proprietary Protocols with No Authentication

PLCs communicate using industrial protocols such as Modbus, DNP3, EtherNet/IP, PROFIBUS, and vendor-specific variants. Most of these protocols were designed for reliability over closed networks, not for security over connected ones. Modbus, for example, has no authentication mechanism: any device that can reach the Modbus port can send commands to the PLC. DNP3 added authentication extensions, but many deployed implementations have not enabled them.

Patching Constraints

PLC firmware updates require the engineering software, the correct version, the correct license, a maintenance window, and vendor validation that the update does not affect control behavior. For PLCs managing continuous processes, that window may occur once or twice a year. Vulnerabilities can remain unpatched for years after they are discovered and disclosed. Managing this reality requires a risk-based patching approach that combines compensating network-level controls with a realistic remediation timeline.

Vendor Remote Access

PLC vendors provide ongoing support and maintenance through remote access. These connections are often managed through general-purpose VPN infrastructure rather than OT-specific remote access controls, may use shared credentials across multiple customers, and frequently remain active beyond the duration of a specific maintenance event. Securing vendor remote access to OT environments is one of the most consistently underaddressed vulnerabilities in industrial cybersecurity.

 

Real-World PLC Attacks

Stuxnet (2010)

Stuxnet was the first publicly confirmed cyberweapon specifically designed to damage physical infrastructure. It targeted Siemens S7-315 and S7-417 PLCs controlling frequency drives at the Natanz uranium enrichment facility in Iran. The malware modified PLC logic to cause centrifuge motor speeds to fluctuate in ways that caused physical damage while reporting normal operation to operators. It destroyed an estimated 1,000 centrifuges. Stuxnet demonstrated that PLC-level attacks on industrial systems were a practical threat, not a theoretical one.

TRITON/TRISIS (2017)

The TRITON malware targeted Triconex safety instrumented system controllers at a Middle Eastern petrochemical facility. Its objective was to disable the emergency shutdown system: the last line of defense against a catastrophic process safety failure. TRITON was designed not to sabotage the process directly, but to remove the protection layer that would have stopped a sabotage attempt from becoming catastrophic. It represents the most significant escalation in OT attack sophistication on record.

Ukraine Power Grid Attacks (2015 and 2016)

The Ukraine power grid attacks used Industroyer/Crashoverride malware that directly communicated with substation automation PLCs and RTUs using industrial protocols, including IEC 61850, IEC 60870-5-101, IEC 60870-5-104, and DNP3. The attackers sent commands directly to switching devices, causing outages that affected 230,000 customers. The malware included a wiper component designed to make recovery more difficult.

 

How to Secure PLCs in Your OT Environment

Network Segmentation: Limit Who Can Reach the PLC

The most effective single control for PLC security is limiting network reachability. A PLC at Level 1 that cannot be reached from the IT network, from vendor remote access pathways, or from other OT zones without a controlled conduit is substantially more difficult to attack, even if it has known firmware vulnerabilities. IEC 62443 zone and conduit architecture provides the framework for designing this segmentation. A network segmentation audit identifies the current pathways and the gaps to close.

OT Hardening at the Device Level

For PLCs that support configuration-level security, a set of hardening actions reduces the attack surface without requiring patching. The OT hardening checklist for industrial control systems covers the specific actions applicable to PLC platforms, including changing default credentials, disabling unused communication interfaces, enabling write protection where supported, and restricting programming port access by source IP address where the firmware supports access control lists.

Passive Vulnerability Assessment

Understanding which PLCs have known CVEs, which firmware versions are current, and which have vendor security advisories outstanding is a prerequisite for risk prioritization. Passive OT vulnerability assessment builds this inventory from observed network traffic without actively scanning devices. The output, cross-referenced against ICS-CERT advisories and vendor security bulletins, tells you which vulnerabilities are present and which are exploitable given your current network architecture.

Remote Access Controls

Every vendor remote access session to a PLC-level system should be identity-authenticated, session-recorded, limited to the specific devices that require access, and terminated as soon as the maintenance activity is complete. Zero Trust principles for OT remote access replace persistent vendor VPN connections with session-governed access that can be audited and revoked without disrupting the vendor relationship.

Backup and Recovery for PLC Configurations

A PLC whose control logic is corrupted or encrypted by ransomware can only be restored from a clean backup of the project file. OT backup and recovery programs for PLCs require offline backups of the control logic, the engineering software version, and the device configuration, along with a tested restoration runbook. Without this, a ransomware attack or deliberate logic modification can result in weeks of manual re-engineering to restore process operations.

 

IEC 62443 and PLC Security Requirements

IEC 62443 provides specific technical requirements for securing PLCs within the broader OT network. Under the zone and conduit model, PLCs at Level 1 typically sit within a production zone that is separated from supervisory systems at Level 2 by a controlled conduit. Security Level assignments define the capability of the zone's defenses against a defined attacker class, from SL 1 (casual attacker) to SL 4 (nation-state-level capability).

For most industrial operators, the target for PLC zones is SL 2: protection against intentional attack using low to moderate sophistication, which is the realistic threat profile for the majority of OT security incidents. Achieving SL 2 for a PLC zone involves network access control to limit which devices can reach the programming interface, authentication for any connection that can modify PLC logic, and logging of all access events. The IEC 62443 explained guide covers Security Level requirements in detail across all OT asset types.

 

Frequently Asked Questions

What is the difference between a PLC and a DCS?

A PLC (programmable logic controller) is typically a standalone controller managing a discrete or sequential process: a single machine, production cell, or process unit. A DCS (distributed control system) is an integrated control architecture designed for large-scale continuous processes, where hundreds of control loops need to be coordinated across a facility. DCS platforms are common in refineries, chemical plants, and power generation facilities. PLCs are more common in manufacturing, packaging, and pipeline operations. Both are OT assets, and both require OT-specific security approaches.

 

Can a PLC be patched like a server or workstation?

Not in the same way. PLC firmware updates are not applied through a patch management platform. They require the vendor engineering software, the correct software license, a physical or network connection to the device, and validation that the update does not change control behavior. In continuous process environments, the update can only be applied during a planned shutdown window. Many facilities run PLCs for years on firmware versions that have known vulnerabilities because no patch window has been available.

 

What should we do if we discover a PLC on our network with no authentication enabled?

Start by assessing reachability: can the PLC be accessed from outside its intended network zone? If yes, the immediate priority is network segmentation to restrict which devices can reach the programming interface. Authentication at the device level should then be enabled if the firmware supports it. If the PLC firmware does not support authentication, document the compensating controls you have implemented, and include them in your vulnerability remediation backlog with a realistic timeline for either firmware upgrade or device replacement.

 

How does IEC 62443 apply to PLC security specifically?

IEC 62443-3-3 defines system security requirements for the zones containing PLCs. These requirements cover access control to programming interfaces, network segmentation between PLC zones and supervisory zones, audit logging of configuration changes, and protection of the control logic against unauthorized modification. IEC 62443-4-2 defines component-level security requirements for PLC manufacturers, specifying what security capabilities PLCs should support in firmware. When procuring new PLCs, IEC 62443-4-2 certification is a meaningful indicator that the vendor has implemented security in the product design rather than treating it as an afterthought.