The PLC is where cybersecurity stops being abstract: whatever reaches the controller reaches the process. Yet the average PLC in service today runs with the password printed in its manual, firmware from the year it was commissioned, an embedded web server nobody remembers enabling, and a mode switch left in REMOTE so nobody has to walk to the panel. None of that requires a capital project to fix. This guide is a practical hardening checklist for controllers already in the field - credentials, firmware, ports and services, physical mode protection, program protection, network placement, and monitoring - written for the engineer who has a maintenance window and a plan, not an unlimited budget.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
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.
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:
"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.
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.
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.
The logic in the controller is both intellectual property and a safety document - you need to know it is what you think it is:
Every measure above assumes the attacker got network reachability. Deny that, and the whole checklist gets easier:
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 |
Key takeaway: PLC hardening is mostly discipline, not spend. Defaults changed, services disabled, firmware managed on purpose, the key in RUN, programs versioned and protected, controllers unreachable from anything but a short allowlist - and an outbound-only path carrying data to the people who need it. Work the 20 points over a quarter of maintenance windows and your controllers stop being the easiest thing on the network to attack. To see what the monitored, zero-inbound-ports side of that architecture looks like, request a Merobix demo.
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.
PLC hardening is the practice of reducing a programmable logic controller's attack surface through configuration and physical measures: changing default credentials, disabling unused ports and services (embedded web servers, FTP, SNMP with default community strings), applying firmware updates on a deliberate schedule, using the physical key switch or mode protection to prevent remote program changes, enabling program and source protection, restricting which stations can communicate with the controller, and placing the PLC in a segmented network zone that outside systems cannot reach. Hardening does not make a PLC invulnerable - most controllers still execute unauthenticated protocol commands by design - but it removes the easy paths that real incidents actually use.
Because they are public knowledge. Default credentials for PLCs, HMIs, serial-to-ethernet converters, and industrial routers are printed in vendor manuals that anyone can download, and attackers try them first. Government advisories have repeatedly warned that unsophisticated actors compromise internet-reachable industrial devices using vendor defaults - several publicized water-sector incidents involved exactly this. Every device in the panel needs its defaults changed: not just the PLC, but the HMI, the ethernet module, the cellular router, and the engineering software accounts. Store the new credentials in a proper secrets manager, not in the program comments or a shared spreadsheet.
Yes - deliberately, not never and not blindly. Subscribe to your vendors' security advisories and relevant government alerts, triage each advisory against your actual exposure, and schedule updates for vulnerabilities that matter in your architecture during planned maintenance windows, after testing on a spare or non-critical unit where possible. The common failure mode is controllers running firmware that is many years old with well-documented vulnerabilities, because nobody owns the process. Where a patch is genuinely impractical, apply compensating controls - tighter firewall rules, disabled services, closer monitoring - and document the decision. A practical cadence for most sites is an annual review of the full fleet plus out-of-cycle action on critical advisories.
Yes, meaningfully. On controllers with a physical mode switch, leaving it in RUN (rather than REMOTE) blocks remote program downloads and mode changes - an attacker on the network cannot reprogram a controller whose key requires a physical turn on the panel. It converts a remote attack into one requiring site access, which is a major escalation. The trade-off is operational: staff must visit the panel to make program changes, which is exactly the friction that leads sites to leave controllers in REMOTE permanently. A workable policy is RUN as the standing position, with the key turned only for scheduled, change-managed work and returned afterward - and an alert raised whenever a mode change is detected.
Yes, if the architecture keeps all connections outbound. The PLC should never be reachable from the internet or the corporate network; instead, a gateway inside the OT zone polls the controller locally and pushes data out over TLS, so the OT firewall denies all inbound traffic. This is how the Merobix gateway works: it speaks Modbus, EtherNet/IP, OPC UA, and other local protocols to the PLC, authenticates to the platform with unique device credentials, signs telemetry against tampering and replay, and permits writes only to explicitly configured tags within bounds, with every command audited to a named user. The PLC keeps its hardened posture; remote users authenticate to the platform with MFA and role-based permissions instead of touching the controller.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Keep your PLCs unreachable and still see everything - outbound-only gateway, signed telemetry, bounded writes, and a full audit trail on every command.