PLC CRA implementation should focus on the controller's real attack surface: programming and engineering access, mode changes, logic integrity, fieldbus and Ethernet services, remote diagnostics, firmware and boot trust, I/O configuration, backup and restore, redundant-controller behavior and long-lived support. Because PLCs can directly influence physical processes, security controls and update procedures should be tested against deterministic control and recovery requirements rather than copied from ordinary IT software practices.
PLCs Are Not a Standalone Annex III Category in the Final CRA
The final Annex III of Regulation (EU) 2024/2847 does not list programmable logic controllers as a generic important-product category. PLCs appeared in the industrial automation and control system category of the 2022 Commission proposal, but that category was not retained in the adopted Annex III. Manufacturers should therefore base classification on the final Regulation and current implementing acts, not on proposal-era tables.
A PLC Can Still Match Another Current Annex III Category
A PLC may include or implement functions that correspond to current Annex III categories, such as an operating system, network interface, network-management function or security-related microcontroller. Article 7 focuses on core functionality and also states that integration of an important product does not by itself reclassify the product into which it is integrated. The manufacturer should therefore document the controller's own core functionality separately from the classification of its internal components.
Protect the Boundary Between Run Mode and Engineering Mode
A PLC often behaves very differently in run, stop, program, service or bootloader modes. Engineering modes can allow logic replacement, firmware changes, memory access or diagnostic commands that are unavailable during normal control. The security design should define who can change mode, which interfaces permit that transition, whether physical presence is required and how unauthorized mode changes are detected or prevented.
Control Logic Needs Its Own Integrity Model
PLC firmware and user control logic are different assets. A controller can run authentic vendor firmware while executing malicious or unauthorized ladder logic, structured text or function blocks. Where appropriate, the product should authenticate engineering sessions, restrict logic downloads, identify the loaded project or logic version and provide mechanisms that help users detect unauthorized changes.
Programming Protocols Are Privileged Attack Surfaces
Vendor programming protocols, engineering APIs, serial services and industrial Ethernet commands can expose read, write, start, stop and firmware functions. These interfaces should be threat-modelled separately from ordinary process I/O. The manufacturer should test malformed messages, unauthorized commands, session handling and privilege checks, and should avoid assuming that access to an industrial network automatically means the requester is trusted.
Scan-Cycle Security Must Preserve Deterministic Behavior
PLCs execute control logic under timing constraints. Security logging, cryptographic verification, access checks and network filtering should be designed so they do not unpredictably disrupt the scan cycle or create unsafe resource exhaustion. Performance testing should include security controls under realistic I/O and communications load, not only functional testing with an idle controller.
Fieldbus and Remote I/O Expand the Controller Trust Boundary
PLCs can communicate with I/O racks, drives, sensors, actuators and peer controllers using fieldbus and industrial Ethernet protocols. The risk assessment should identify which messages can change outputs, configuration or controller state, which protocols provide authentication or integrity and which rely on external network controls. The product should validate received data and constrain privileged protocol functions where technically appropriate.
Remote Diagnostics Should Not Become Permanent Backdoor Access
Remote service tools can be valuable for industrial maintenance but may expose deep controller privileges. Manufacturers should document how remote sessions are enabled, authenticated, authorized, logged and terminated. Service accounts and vendor credentials should be managed in a way that avoids one shared secret exposing an installed fleet.
Firmware Updates Need Predictable Recovery
PLC firmware updates may require stopping control, switching to a redundant controller or entering a maintenance state. The update mechanism should verify image authenticity and integrity and should define recovery after power loss, interrupted transfer or incompatible firmware. Where older firmware contains a known exploitable vulnerability, rollback behavior should be evaluated rather than treated as a purely operational convenience.
Backup and Restore Can Reintroduce Vulnerable State
PLC backups can contain logic, network settings, credentials, certificates, device identities and safety or process configuration. Restore procedures should protect sensitive contents and should not silently return a controller to obsolete insecure settings. The manufacturer should identify which security state is restored with the project and which elements, such as device keys or firmware versions, require separate handling.
Redundant Controllers Need Version and State Compatibility Rules
High-availability PLC pairs can synchronize logic, state and configuration. Security maintenance should define which firmware combinations are supported during rolling updates, how the passive controller authenticates synchronized data and what happens if failover occurs during an upgrade. Evidence should show that security updating does not create a hidden loss of redundancy or configuration integrity.
Long-Lived PLCs Need Hardware-Aware Support Evidence
PLCs can remain in service for many years, sometimes across multiple generations of engineering tools and hardware modules. Support planning should consider component obsolescence, signing-key management, cryptographic ageing, availability of test hardware and compatibility with old project formats. The technical file should connect each supported hardware revision to the firmware and security-update path that remains available for it.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.