PLC Security Guide: Hardening Controllers, Logic Integrity and Engineering Access

Programmable logic controllers execute whatever logic they are given, and many will accept a new program from anyone who can reach them on the network. A PLC rarely checks who is downloading code, whether the code is the approved version, or whether the change was planned. That is why the 2023 attacks on Unitronics controllers in US water utilities needed nothing more than an internet connection and a default password. This guide covers controller hardening, operating mode and key switch control, logic and firmware integrity, engineering workstation access, secure PLC coding and detection. It is written for OT engineers, control system integrators and the security teams who support them, and assumes the wider OT programme is covered elsewhere.

Key takeaways

• Most PLC compromises need no exploit. Default or absent passwords, internet exposure and unprotected program download explain most real incidents, including the CyberAv3ngers campaign against at least 75 Unitronics devices.
• The key switch is a security control. With a Rockwell ControlLogix in RUN, online edits, program downloads and firmware updates are blocked; leaving controllers in REM or PROG removes that barrier.
• Integrity has to be verified, not assumed. Hash or checksum the running logic, compare it with a known-good baseline, and alarm on any change outside a maintenance window.
• The engineering workstation is the real attack path. Whoever controls the station that holds the project files and programming software can change the process, so protect it like a privileged admin system.
• Secure coding makes the PLC a last line of defence. The Top 20 Secure PLC Coding Practices use the controller itself to validate inputs, monitor its own state and detect manipulation.

Why PLCs are different to secure

A PLC is an embedded device running a deterministic scan cycle: read inputs, execute logic, write outputs, repeat. Security functions compete with timing, and many controllers in service today were designed when the plant network was assumed to be trusted. IEC 62443-4-2 classifies PLCs, DCS controllers and IEDs as embedded devices, with their own Embedded Device Requirements (EDRs) alongside the common Component Requirements (CRs). Those requirements describe what a controller should support; older installed controllers often support little of it.

• Industrial protocols trust the network: many PLC programming and data protocols were built without authentication. PLC-Blaster, a research worm shown at Black Hat USA 2016, copied itself between Siemens S7-1200 controllers over TCP 102 by mimicking the TIA Portal program transfer, and the researchers noted that port could only be closed by an external firewall.
• Protection features are often off by default: the same research found that S7-1200 access protection (password-based write protection) would stop the worm, but it was disabled by default. Know-how and copy protection did not help because they were enforced in the engineering software, not in the controller.
• Patching is slow: firmware updates need downtime, regression testing and sometimes vendor sign-off, so a controller may run vulnerable firmware for years. Compensating controls carry the load in the meantime.
• Consequences are physical: a modified program can change setpoints, disable alarms or defeat safety logic. ATT&CK for ICS records these as impacts such as T0831 Manipulation of Control and T0880 Loss of Safety.

For the plant-wide view, see the OT Security Guide and the Top 10 OT Security Risks.

How attackers change controllers

The techniques below are taken from MITRE ATT&CK for ICS v20. Each row pairs the technique with the controller-level control that blocks or reveals it.

Controller hardening baseline

Apply this baseline at commissioning and recheck it at every maintenance outage. The setting names vary by vendor, so map each line to the controller documentation.

• Credentials: set a unique password on every protection function the controller offers. CISA's 2023 advisory on the Unitronics campaign listed the separate upload, INFO mode, TCP/IP and SD card passwords, and the related ICS advisory adds passwords on PCOM-enabled sockets and role control through SDW10. One default left in place is enough.
• Access protection level: enable the strongest write or access protection the application allows, for example Siemens access levels or Rockwell controller protection, so that downloads and online edits need a credential that is checked by the controller.
• Unused services: disable embedded web servers, FTP, SNMP write, unused fieldbus ports and remote programming where the application does not need them (Top 20 practice 13; ATT&CK mitigation M0942 Disable or Remove Feature or Program).
• Restricted data interfaces: define each data connection and limit it to read or write as the transfer requires, and use dedicated register blocks for external writes so an HMI or SCADA client cannot overwrite arbitrary memory (practices 10 and 14).
• Network position: controllers belong in a Level 1 or 2 zone behind a conduit that allows only the engineering workstation and named servers to reach programming ports. See the Network Segmentation Guide.
• Firmware currency: track firmware against vendor advisories and the CISA KEV catalogue. CVE-2023-6448 (Unitronics Vision and Samba insecure default password, CVSS 9.8) is in KEV; the fix was VisiLogic 9.9.00 with updated controller OS.
• Backups and spares: keep offline copies of logic and configuration and know the factory reset and redeploy procedure. The CyberAv3ngers advisory also recommended spare hardware, because restoring a wiped controller may be faster than recovering it.

Operating mode and the key switch

Many controllers expose a physical mode switch, and on several platforms it is the only control that a remote attacker cannot override in software. Rockwell documents that with a ControlLogix 5590 keyswitch in RUN, online editing, program downloads and firmware updates are prohibited; REM allows the programming software to change mode remotely; PROG is for program changes. Schneider Electric Triconex safety controllers have RUN, PROGRAM, STOP and REMOTE positions.

The Triconex case shows why this matters. In the 2017 TRISIS (also called TRITON) attack on a safety instrumented system, Dragos notes the key was in Program mode, which allowed project downloads from a compromised engineering workstation, and argues that the attack would not have succeeded with the key in Run.

• Key custody: remove keys after use, store them under control with a sign-out log, and treat a controller left in REM or PROG as an open change.
• Mode monitoring in logic: Dragos describes reading the controller mode with a GSV instruction inside a password-protected Add-On, alarming on Program and Remote, and using the EnableIn parameter as a tamper alarm. Note that the key state must be initialised after a download before detection works.
• Visibility for operations and the SOC: send mode changes to the HMI and the security monitoring platform and compare them with maintenance windows. An unplanned mode change is a high-fidelity alert.
• Where there is no key: rely on controller passwords, mode change logging and network restrictions on programming ports, and say so in the risk register.

Logic and firmware integrity

Integrity monitoring answers one question: is the controller running what we approved? It maps to NIST SP 800-53 SI-7 Software, Firmware, and Information Integrity and CM-5 Access Restrictions for Change.

1. Establish the golden baseline. After commissioning or an approved change, export the program, record the controller's own checksum or signature value where the platform exposes one, and store the project in a versioned repository with the change ticket.
2. Verify on a schedule and on events. Compare the running logic with the baseline at least daily and after every mode change, restart or controller fault. Top 20 practice 5 recommends cryptographic hashes or checksums of the code with an alarm on change.
3. Track firmware versions. Collect firmware versions from CPUs and communications modules and alert on unexpected changes, including downgrades. The CyberAv3ngers actors set an older software version to lock out engineering workstations.
4. Prefer signed firmware. Where the controller verifies firmware signatures (ATT&CK mitigation M0945 Code Signing; SI-7(6) Cryptographic Protection), keep it enabled and obtain firmware only from the vendor portal with hash verification. See the Firmware and Boot Security Guide.
5. Watch for upload as well as download. T0845 Program Upload lets an attacker copy logic to study the process; unexplained uploads are worth investigating.
6. Prove restore. Test that a backup can be loaded onto spare hardware and produce the same checksum. A backup that has never been restored is an assumption.

Engineering workstation and programming access

The engineering workstation (EWS) holds project files, programming software and often stored controller passwords. Compromising it gives an attacker everything needed to change logic in a way that looks like normal engineering. IEC 62443-4-2 treats engineering stations as host devices, with their own Host Device Requirements.

• Dedicated and hardened: use the EWS only for engineering, with application allowlisting, no email or web browsing, and removable media control.
• Named accounts: no shared engineering logins; separate engineer and operator roles so that only named engineers can download logic (ATT&CK M0801 Access Management, M0804 Human User Authentication).
• Programming path control: allow programming protocols to controllers only from approved EWS addresses (M0807 Network Allowlists; M0937 Filter Network Traffic), and block them from the IT network entirely.
• Remote engineering: route vendor and engineer remote sessions through a brokered, recorded path with MFA, never directly to the EWS or controller. See the OT and ICS Identity and Access Guide and the Privileged Session Management Guide.
• Project repository: keep project files in a version-controlled store with access logging, so that a tampered file (T0873 Project File Infection) can be spotted by comparing it with the last approved version.
• Transient assets: integrator laptops must pass a scanning station and connect only to defined ports, with the session logged.

Where identity fits

Controller passwords are shared secrets used by people and by software (HMIs, SCADA servers, historians). Vault them, record who used them, rotate them when staff or contractors leave and after every incident, and never leave them in project files or engineering notes. See the Identity for OT Environments Guide.

Secure PLC coding: the Top 20

The Top 20 Secure PLC Coding Practices were released on 15 June 2021 by admeritia and the ISA Global Cybersecurity Alliance, with volunteer contributors, and are published at plc-security.com. They use features already in the PLC to make it harder to manipulate and easier to see manipulation. The practices group naturally:

• Start with practices 2, 5, 8 and 13: mode monitoring, integrity checks, PLC-side input validation and disabling unused services give the largest security gain for little engineering effort.
• Put security code in its own routine: Dragos recommends separating security functions from control logic and keeping them in the PLC rather than in HMI scripts, which are easier to alter unnoticed.
• Review like safety code: logic changes should be peer reviewed against the change request, with the diff stored alongside the ticket. The CWE Top 25 Guide covers the general weakness classes (input validation, boundary errors) that practices 8 to 10 address.

Detection and measurement

Controllers produce few logs, so detection combines PLC-side signals with passive network monitoring of industrial protocols. See the OT Asset Visibility Guide.

• Signals to collect: operating mode changes; program download, upload and online edit commands seen on the network; logic checksum mismatches; firmware version changes; controller restarts and faults; new connections to programming ports from hosts other than the EWS; failed controller password attempts where the platform records them.
• Correlate with change management: every download or mode change should match an open change ticket and maintenance window. Unmatched events go straight to an investigation.

Rolling it out without stopping the plant

1. Inventory and rank: list every controller with make, model, firmware, location, protection features available and the process it controls. Rank by consequence (safety, environment, production).
2. Close exposure first: remove internet and IT network paths to programming ports and put any required remote path behind a gateway with MFA. This needs no controller change and addresses the most common attack route.
3. Fix credentials: change defaults and set protection passwords, starting with the highest-consequence controllers. Record the old configuration so you can roll back if an HMI or SCADA client loses access.
4. Baseline integrity: capture logic and firmware baselines and start daily comparison, initially as reporting only.
5. Lock modes: agree key custody with operations, move controllers to RUN and add mode alarms. Pilot on one line or unit first.
6. Add secure coding at the next change: introduce Top 20 practices in new projects and planned modifications, tested on a simulator or test rig before deployment, never on a running process.
7. Roll back safely: every change has a documented back-out (previous program, previous protection settings) and is made in an approved window with operations present.

• Small sites (a few controllers, no OT team): focus on exposure, passwords, backups and keys in RUN. These four steps would have prevented the Unitronics incidents.
• Large estates: add automated integrity checking, protocol monitoring and change correlation, and write PLC security requirements (for example IEC 62443-4-2 capability) into procurement for new controllers.

Common failure patterns

• Controller on the internet with a default password: the CyberAv3ngers campaign brute-forced Unitronics Vision devices on TCP 20256, erased the ladder logic, disabled upload and download, changed the port to 20257 and defaced the HMI. At the facility in CISA's first alert, the water authority moved to manual operation.
• Keys left in PROG or REM: convenient for engineers, but it removes the one control software cannot bypass, as the TRISIS case showed.
• Protection features never switched on: access protection that is off by default stays off unless commissioning checklists require it.
• Trusting engineering software checks: know-how or copy protection enforced in the programming tool is not the same as authentication enforced by the controller.
• No known-good copy: without a verified backup and spare hardware, a wiped controller means a long outage. See the Backup Security and Immutable Backup Guide.
• Integrators with permanent remote access: standing vendor connections to the EWS or controller bypass change control entirely.

Framework mapping

NIST SP 800-82 Rev. 3 (September 2023) remains the main US OT security guide and names PLCs explicitly; NIST has opened a draft Revision 4 for comment. See the NIST SP 800-82 OT Security Guide.

Practitioner checklist

• Confirm no controller or programming port is reachable from the internet or the IT network.
• Replace every default controller and HMI password, including upload, socket and media passwords.
• Enable the strongest access or write protection each controller supports.
• Keep keys in RUN outside approved windows, with custody logged and mode changes alarmed.
• Baseline logic and firmware and compare them daily and after every mode change or restart.
• Restrict programming to named engineers on hardened engineering workstations with allowlisted addresses.
• Vault controller credentials used by people and by HMI or SCADA software, and rotate them after staff changes.
• Apply Top 20 practices 2, 5, 8 and 13 at the next planned change.
• Test restore of logic to spare hardware for every critical controller each year.
• Match every download and mode change to an approved change ticket.

Standards and references

• CISA and partners: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors (AA23-335A)
• CISA: Exploitation of Unitronics PLCs used in Water and Wastewater Systems
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• ISA: ISA/IEC 62443 Series of Standards
• ISA: ISA Global Cybersecurity Alliance and admeritia announce Top 20 Secure PLC Coding Practices
• MITRE ATT&CK: Change Operating Mode (ICS)
• Rockwell Automation: ControlLogix 5590 Controller User Manual, Change the Operation Mode
• Black Hat USA: PLC-Blaster, A Worm Living Solely in the PLC (white paper)

Related NHI Mgmt Group resources: OT Security Guide · Water and Wastewater Cybersecurity Guide · OT Incident Response Guide · OT Penetration Testing Guide