PLC Security Hardening:
A Practical Checklist

Back to Blog

Part of the Merobix OT security guide collection - vendor vetting to industry compliance.

Why PLCs Are Soft Targets

PLCs were engineered for determinism, longevity, and environmental abuse - not for adversaries. Most controllers in service will execute any well-formed command from any station that can reach them: stop the CPU, change a value, download a new program. Protocols like Modbus and EtherNet/IP carry no authentication (see our plain-English Modbus guide for why), engineering software historically trusted the network completely, and a controller commissioned in 2012 may run untouched until 2035. Security researchers keep demonstrating the consequences, and government advisories - including CISA's joint advisory on actors exploiting PLCs in US water and wastewater facilities - have repeatedly documented unsophisticated actors manipulating internet-reachable controllers in water and other sectors, often using nothing more advanced than a vendor default password.

The good news: because most PLC weaknesses are configuration and placement problems, most of the fix is configuration and placement too. Newer controller generations add real security features - firmware signing, CIP Security in the Rockwell ecosystem, access protection levels and communication hardening on Siemens S7-1200/1500 - and you should enable what your hardware offers. But the checklist below assumes the fleet you actually have, mixed ages and all.

1. Credentials: Kill Every Default

Default credentials are public documentation - every attacker's first attempt, and the mechanism behind several publicized water-sector incidents. The rule extends beyond the CPU itself:

• Change defaults on every device in the panel: the PLC, the HMI, the ethernet communication module, the serial-to-ethernet converter, the managed switch, and especially the cellular router - the device most likely to face the internet.
• Eliminate shared "engineer" passwords known to every integrator who ever visited. When a contractor relationship ends, rotate what they knew.
• Store credentials properly - a secrets manager or at minimum an access-controlled vault. Not the program comments, not a taped label inside the cabinet door, not a spreadsheet on the shared drive.
• Enable per-user access where the platform supports it - modern engineering environments support individual accounts and permission tiers; use them so changes attribute to people.

2. Firmware: Patch Deliberately, Not Never

"Never touch working firmware" and "patch everything monthly" are both wrong for OT. The defensible middle is a deliberate process: subscribe to vendor security advisories - Siemens ProductCERT and Rockwell Automation's security advisory portal are the canonical feeds for the two biggest PLC ecosystems - and CISA ICS advisories; triage each against your exposure (a vulnerability in a web service you have disabled, on a network no attacker can reach, is a different priority than an authentication bypass on your remote-site cellular link); schedule what matters into planned maintenance windows; test on a spare or non-critical unit first; and record the decision when you consciously defer. Where patching is genuinely impossible - discontinued product, validation constraints - compensate with tighter firewall rules, disabled services, and closer monitoring, and write that down too. A full-fleet firmware review belongs on the calendar at least annually; our vulnerability management guide for SCADA covers the triage discipline in depth.

3. Ports and Services: Shrink What Listens

A modern PLC is quietly a small server. Out of the box it may run an embedded web server, FTP or TFTP for file transfer, SNMP with public community strings, Telnet, and multiple industrial protocol stacks. Every listening service is attack surface - and most were enabled for a commissioning convenience nobody remembers.

• Inventory reality: port-scan each controller (from an authorized machine, during a window, with awareness that fragile older stacks deserve gentle scan settings) and compare what answers against what production requires.
• Disable the unneeded: web servers not used for operations, FTP/TFTP outside firmware-update windows, SNMP you do not monitor with, every legacy remnant.
• Restrict the needed: many controllers and comm modules support allowlists limiting which IPs may connect or write - configure them so only the HMI, the engineering station, and the data gateway qualify.
• Re-verify after firmware updates, which occasionally re-enable default services.

4. Physical and Mode Protection: The Key Switch Is a Security Control

The humble key switch is one of the strongest controls you own, because it is immune to every remote attack ever written. A controller whose switch sits in RUN refuses remote program downloads and mode changes; flipping it requires a human, standing at the panel, holding a key. That converts "attacker with network access reprograms the process" into "attacker needs physical site access" - a massive escalation in difficulty and detectability.

• Adopt RUN as the standing position; turn the key only for scheduled, change-managed work, and return it afterward. The sites that leave controllers in REMOTE permanently are trading away their best control for convenience.
• Alarm on mode changes - an unexpected transition to PROGRAM is a top-tier alert.
• Lock the cabinets, control key issuance, and cover the basics: an unlocked panel in an unmanned remote station is an open controller.

5. Program Protection and Change Management

The logic in the controller is both intellectual property and a safety document - you need to know it is what you think it is:

• Enable source and block protection where offered (program passwords, know-how protection, signed program features on newer platforms) to raise the bar for reading or modifying logic.
• Version-control the program. Every change gets an author, a date, a reason, and a stored copy - whether via a dedicated PLC version-control product or a disciplined repository. The recovery question after any incident is "what should be running on this controller?" and you must be able to answer it.
• Audit online changes. Compare the running program against the golden copy on a schedule; unexplained drift is either broken process discipline or an intrusion, and both need attention.
• Gate changes through management of change. A program download to a production controller should trail a paper (or digital) authorization, not just an engineer's judgment at 4:45 PM.

6. Network Placement: The Control That Multiplies the Others

Every measure above assumes the attacker got network reachability. Deny that, and the whole checklist gets easier:

• No PLC is ever internet-reachable. Ever. Not behind a port forward "temporarily," not on a cellular router's public IP. Internet scanning services index exposed industrial devices continuously.
• Segment the OT zone so corporate machines cannot route to controllers, with firewalled conduits allowing only known stations - the zones-and-conduits architecture defined in the ISA/IEC 62443 series and covered in our secure SCADA for OT networks guide.
• Make remote data access outbound-only. This is the pattern the Merobix gateway implements: it sits inside the OT zone, polls the PLC locally over Modbus, EtherNet/IP, OPC UA, or another of its drivers for major industrial protocols, and pushes data outbound over TLS - zero inbound firewall rules, unique registered credentials per gateway, and signed telemetry with replay detection. Remote users authenticate to the platform with MFA and role-based permissions; nobody remote ever touches the controller itself. Writes, where enabled at all, pass an explicitly configured writable-tag list with setpoint bounds checking and land in an immutable audit trail. The full design is on the security page.

7. Monitor What the Controller Does

Hardening without monitoring is a locked door nobody watches. The high-value, low-effort signals: unexpected mode changes, program downloads outside change windows, communication from unknown stations, repeated failed connections, and telemetry that goes stale or starts contradicting physical reality. Platform-side monitoring helps here - Merobix tracks telemetry freshness and flags suspicious control activity, delivering alerts durably by SMS, email, webhook, or SIEM - and a passive network sensor on the OT segment covers what the platform cannot see. Detection turns a hardening failure from a silent compromise into a Tuesday-morning investigation.

Hardening Measure	Primarily Defends Against	Typical Effort	Requires Downtime?
Change default credentials	Opportunistic access, commodity attacks	Hours per site	No
Disable unused ports/services	Remote exploitation of forgotten services	Hours per controller	Brief, per device
Firmware update process	Known CVE exploitation	Ongoing program	Planned windows
Key switch in RUN + cabinet locks	Remote reprogramming, unauthorized changes	Policy + minutes per panel	No
Program protection + version control	Logic tampering, IP theft, unrecoverable loss	Days to set up, minutes thereafter	No
Segmentation + outbound-only gateway	Entire remote attack classes at once	Days, with network planning	Brief cutover
Monitoring and alerting	Silent compromise of any of the above	Days	No

The 20-Point PLC Hardening Checklist

1. Inventory every controller, comm module, HMI, converter, and router - you cannot harden what you have not listed.
2. Change every default credential on every device in every panel.
3. Rotate credentials known to departed staff and former contractors.
4. Store credentials in an access-controlled secrets store.
5. Enable individual user accounts and permission tiers in engineering software where supported.
6. Subscribe to vendor and CISA ICS security advisories for every product in the inventory.
7. Triage advisories against actual exposure; schedule patches that matter into maintenance windows.
8. Document deferred patches with their compensating controls.
9. Port-scan controllers (carefully) and disable every service production does not need.
10. Configure connection/write allowlists where the hardware supports them.
11. Re-verify services and settings after every firmware update.
12. Keep mode switches in RUN; require change-managed authorization to move them.
13. Alarm on controller mode changes and program downloads.
14. Lock cabinets; control physical keys; secure unmanned sites.
15. Enable program/source protection features on capable controllers.
16. Version-control PLC programs with author, date, and reason for every change.
17. Periodically compare running logic against the golden copy.
18. Verify no controller is reachable from the internet or the corporate LAN.
19. Route all remote data access through an outbound-only gateway with platform-level authentication.
20. Review this checklist annually and after every incident, audit, or major project.

Hardened controllers still need a secure path to the outside world - see how edge gateway security with device identity and signed updates completes the picture.

Frequently Asked Questions

Sources & Further Reading

• AA23-335A - IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities (CISA)
• Cybersecurity Alerts & Advisories (ICS Advisories) (CISA)
• Siemens ProductCERT - Security Advisories (Siemens)
• ISA/IEC 62443 Series of Standards (International Society of Automation)