If you run a plant, the phrase 'harden the PLC' probably makes you nervous. It should. The controller is the one device in your environment that nobody wants to touch on a Tuesday afternoon, and most advice on PLC security reads as if downtime were free. 

It isn't free. But the last few months have made it much harder to argue that leaving controllers as they are is the safe option. Joint advisories from US agencies have documented attackers walking straight into internet-exposed PLCs from several vendors, rewriting project logic, and altering what operators see on their screens. A newer advisory describes adversaries using AI-generated scripts to probe Siemens S7 controllers. None of it needed an exotic zero-day. 

This Blog covers how to secure PLCs in a way production teams will actually sign off on: twelve controls, ordered roughly by risk reduced per hour of effort, each with a note on how to roll it out without stopping the process. 

Key takeaways 

• The most recent PLC attacks relied on reachability and weak or missing credentials, not on new vulnerabilities. Removing direct internet exposure is still the single highest-value action. 

• The July update to CISA advisory AA26-097A widened targeting from Rockwell Automation to Schneider Electric and Siemens controllers, and added guidance on malicious changes hidden in reusable code modules. 

• Advisory AA26-231A (August) is the first to describe AI-generated exploitation scripts aimed at Siemens S7 PLCs. Siemens says it describes misconfiguration abuse, not new S7 flaws. 

• You usually cannot harden a legacy PLC from the inside. You harden the network around it, the engineering workstation that programs it, and the way you verify what it is running. 

• Almost every control below can be piloted in monitor-only mode or applied during a planned window, so 'without breaking production' is realistic. 

What has changed recently: the latest PLC security developments 

If your last PLC security review predates this year, these are the changes worth knowing about. 

There is a pattern across all of it. Siemens was explicit in its comments on AA26-231A: the advisory does not describe new S7 vulnerabilities, but methods that abuse configurations Siemens' guidance already addresses. The agencies add that PLC targeting is broader than Siemens, and that every PLC owner should apply the relevant mitigations. 

That is good news in a slightly annoying way. The fixes are known. They are mostly architecture and configuration, and most can be done without touching control logic. 

Why PLCs are hard to secure (and why that shapes the approach) 

PLCs were built to run for decades inside physically isolated networks, with availability as the overriding design goal. Many have no meaningful authentication, no encryption on their native protocols, and no way to run an agent. Secure protocol variants exist, such as CIP Security for EtherNet/IP and secured Siemens communication, but they are optional and frequently left switched off. 

So the usual IT playbook fails. You cannot install endpoint protection on a controller, and an aggressive vulnerability scan can knock over a fragile device. NIST SP 800-82 Rev. 3, the Guide to Operational Technology (OT) Security, specifically warns operators to exercise extreme caution with active scanning on an operational network. 

The practical consequence is that PLC hardening is a three-layer job: 

1. Around the PLC: network exposure, segmentation, remote access. 

2. Next to the PLC: engineering workstations, backups, change control, monitoring. 

3. Inside the PLC: the configuration options and secure coding practices the device does support. 

The twelve steps below move through those layers. 

Before you start: three rules that keep production safe 

Rule 1: Observe before you enforce. Run any new control in monitor-only or alert-only mode first. Most firewalls, allowlists and anomaly detectors support it. A week of watching tells you what talks to what, including the undocumented dependency that would have taken down a line. 

Rule 2: Change a copy first. Where you can, test on a spare controller, a vendor simulator or a staging cell. Several of the settings below can interrupt legitimate HMI, historian or MES connections if applied blindly. 

Rule 3: Use the windows you already have. Scheduled shutdowns, shift changes and planned maintenance are free hardening time. Keep a short, pre-approved list of changes that qualify, so you are not renegotiating every time. 

12 ways to harden PLCs without breaking production 

1. Build a real PLC inventory, passively 

You cannot secure controllers you do not know exist. Start with every PLC: make, model, firmware, IP address, network location, the engineering software that programs it, and the systems that talk to it. 

Do it passively. Mirror switch traffic through a SPAN port or network tap and let a passive discovery tool build the picture. Then cross-check against project files, spare-parts lists and the maintenance team's own knowledge, because the PLC under a stairwell that a contractor installed years ago never shows up in the CMDB. 

Production-safe tip: no packets are sent to the controllers, so nothing can fall over. Record the dependencies too (which HMI, historian or recipe server connects to each PLC), because you will need them for steps 3, 6 and 7. 

2. Take PLCs off the public internet, including the cellular back door 

This is the control the recent advisories keep coming back to. CISA's guidance is plain: disconnect PLCs from the public-facing internet. If remote access is needed, put a proxy, gateway, firewall or VPN in front of the device. 

Exposure is not always where you expect it. Check for: 

• Controllers or HMIs on cellular modems at remote pump stations, lift stations and tank farms, often installed by a vendor and forgotten. 

• Port-forwarding rules left behind after a commissioning visit. 

• Industrial protocol ports reachable from outside, such as TCP 102 (S7comm), 502 (Modbus/TCP) and 44818 (EtherNet/IP). 

• IP ranges belonging to sister sites or acquired companies that were never brought into the same review. 

Run your own public IP ranges and carrier-assigned addresses through internet-scanning services such as Censys or Shodan. Attackers use the same services, and reporting on AA26-231A names Censys and ZoomEye among them. See what they see. 

Production-safe tip: closing an inbound path rarely affects the control loop itself. Do it in a short window, and confirm with whoever uses that path (usually a vendor or a remote engineer) that you are replacing it with the secure method from step 4, not just removing it. 

3. Segment into zones, and enforce it with policy 

Put PLCs in their own zones and control the conduits between them, as IEC 62443 describes. A flat network where a corporate laptop can reach the controller directly is the scenario every recent advisory assumes. 

A few points separate real segmentation from the cosmetic kind: 

• A VLAN name is not a control. Segmentation has to be enforced by routing and firewall policy, not just by labels. 

• Default-deny between zones. Allow only the specific sources, destinations and industrial protocol functions a process needs. 

• Use an industrial DMZ for anything that must pass between IT and OT: historians, patch servers, remote access. 

• Within the cell, isolate safety systems and keep controllers of different criticality apart. 

Production-safe tip: deploy the firewall rules in log-only mode for a week or two. Review what would have been blocked, fix the rule set, then enforce during a maintenance window. Teams that skip this step are the ones who discover the bottling line's recipe server the hard way. 

4. Replace ad hoc remote access with one controlled path 

In the advisories, attackers connected with the same engineering software a technician would use. So the question is not only who can reach the PLC, but who can run a programming tool against it, from where, and who is watching. 

The options CISA lists, in rough order of maturity: a secure gateway or jump host, a site-to-site VPN, a dedicated remote-access VPN with multi-factor authentication, zero-trust network access limited to specific systems, and private cellular access-point networks. A gateway or VPN in front of the PLC can add MFA even when the PLC itself cannot support it. 

For vendor and integrator access in particular: 

• One approved route only. No remote-desktop tool installed on the engineering laptop just for this job. 

• Individual accounts, no shared logins. 

• Access that is time-boxed and approved per session, with the session recorded. 

• Make sure your service providers know about the active threats to internet-connected PLCs. CISA specifically recommends this. 

Production-safe tip: build the new path alongside the old one, migrate vendors one at a time, then close the old route. None of it touches the controller. 

5. Switch off what you do not use, and lock the physical mode 

Every enabled service is attack surface. On many controllers you can disable unused protocols and ports, the embedded web server, FTP, SNMP and spare communication modules. The October Siemens web-server vulnerabilities are a good example: if no one needs that web server, it is an open door with no upside. 

A few specifics worth checking: 

• Mode switch: keep controllers that have a physical key or mode switch in RUN, and alarm if it changes. Rockwell's guidance makes this point, and the PLC Security Top 20 lists monitoring of operating modes as a practice. 

• Siemens S7-1200 and S7-1500: review the protection level and the setting that permits PUT/GET access from remote partners. 

• Rockwell Logix: use the available controller security and change-detection features, and follow the hardening measures in Rockwell advisory SD1771, which CISA references. 

• Cabinets: lock physical ports and removable media access, or at least log it. 

Production-safe tip: a service that nothing uses is safe to disable, but 'nothing uses it' needs proof from the dependency map in step 1, not a guess. Disable during a planned stop, with the previous configuration saved. 

6. Fix default and weak credentials, with a rollout plan 

One analysis of the AA26-097A update made a point worth repeating: the actors did not need a zero-day. They found controllers and HMIs reachable from the internet with default credentials or no authentication at all. 

So the action is unglamorous. Enable authentication wherever the controller supports it, change the defaults, use unique passwords per device or per role, and keep them in a vault rather than on a sticky note inside the panel. Use role-based access where available, so operators and engineers are not treated as equals. 

The risk to production is that a changed password breaks every system that authenticates to the PLC. That is why the dependency map matters. 

Production-safe tip: change credentials in the same window as the HMI and SCADA connection updates, one cell at a time, and keep a break-glass procedure for when something fails to reconnect. Do not rotate everything on a Friday evening. 

7. Turn on the secure features you already paid for 

Many current controllers ship with security capabilities that are not enabled by default: authentication and role-based access, encrypted communication such as CIP Security, secured Siemens engineering and HMI communication, firmware validation, and OPC UA with signing and encryption. 

When the PLC cannot do it, put something in front of it that can. Tunnel legacy protocols such as Modbus/TCP through a secure gateway, so the traffic is protected between zones even though the device itself speaks in the clear. 

Production-safe tip: enabling secure communication can break older HMIs, drives and third-party systems that do not support it. Pilot on one non-critical cell, confirm every connected device, and prefer a transition mode (secure and non-secure side by side) where the platform allows it. 

8. Treat the engineering workstation as the real crown jewel 

Every PLC in a plant is typically programmed from one or a few engineering workstations (EWS). Whoever controls that machine can write to every controller it can reach. For many plants, securing the EWS is a more practical and more valuable project than any individual PLC. 

For each EWS: 

• Dedicated use. No email, no general browsing, no personal USB sticks. 

• Application allowlisting, so only the programming suite and approved tools run. 

• Authorized EWS hosts only, enforced at the firewall, so a random laptop cannot download to a controller. 

• Multi-factor authentication for logins, patches that fit the validated software versions, and endpoint monitoring. 

• A clean, documented process for contractors' laptops: scan, restrict, or provide a managed loaner. 

Production-safe tip: none of this touches the running process. Application allowlisting does need a learning period, so run it in audit mode first. 

9. Verify what the PLC is running: golden backups and integrity checks 

The July update to AA26-097A makes this step urgent. Attackers modified and deleted logic in project files, including Add-On Instructions, and CISA added guidance on malicious changes inside reusable code modules: shared blocks of logic dropped into many programs at once. A tampered shared block is an efficient way to compromise many controllers together. 

What to do: 

• Keep a known-good, offline, versioned backup of every PLC program and configuration. A backup stored on the same network as the PLC is a backup the attacker can also reach. 

• Hash the backups, and on a schedule compare the logic running in the live device with the golden copy. Treat an unexplained difference as an incident, not a curiosity. 

• Review shared libraries, AOIs and function blocks as code. Who changed them, when, and who approved it? 

• Where the platform supports cryptographic code signing or checksums, use them. The PLC Security Top 20 also recommends integrity checks for PLC code. 

• Require change control with a second pair of eyes before any download to a production controller. 

This is also your recovery plan. If the worst happens, a trusted backup and a rehearsed restore turn a day of downtime into an hour. 

Production-safe tip: comparisons are read operations. Run them during low-activity periods, and test the restore procedure on a spare, not on the line. 

10. Make sure operators can trust what they see 

The AA26-097A update is a reminder that an attack on the controller can also be an attack on the picture. Actors manipulated data shown on HMI and SCADA displays, so personnel could not easily see that anything was wrong. 

A few defenses that need no exotic technology: 

• Cross-check critical values against an independent source: a separate sensor path, the historian, a local gauge, or a second controller. 

• Keep safety instrumented systems independent of the basic process control network, with their own logic and, where appropriate, their own physical protections. 

• Use the PLC itself as a sensor. The PLC Security Top 20 suggests trending cycle times, uptime, hard stops and memory use on the HMI, and trapping false negatives and positives for critical alerts. A sudden shift in cycle time after a logic change is a signal worth chasing. 

• Define manual-operation procedures for loss of view or loss of trust, and rehearse them. 

Production-safe tip: most of this is configuration on the HMI and historian side. It adds visibility without changing how the process is controlled. 

11. Add passive monitoring that understands industrial protocols 

You will not notice a malicious program download from a firewall log alone. You need monitoring that reads industrial protocols and can tell a read from a write, and a status poll from a program upload. 

Useful detections for PLCs: 

• Program downloads, uploads or online edits from a host that is not an approved EWS. 

• Mode changes (RUN to PROG or STOP) outside a maintenance window. 

• S7comm, EtherNet/IP or Modbus write commands from unexpected sources, including scripted, high-frequency probing of a controller. 

• Connections to a PLC from addresses that are not in the inventory. 

• New or unexpected services on a device. In one documented incident, actors used Dropbear SSH for remote access. 

Production-safe tip: use a network tap or mirror port so inspection is entirely passive. Start with read-only monitoring on isolated test cells, and avoid active scanning on production networks unless the vendor has approved it for that device. 

12. Patch with a plan, and use compensating controls when you cannot 

Patching a PLC is not like patching a laptop. It needs vendor validation, testing against the process, and a window. That is why most plants lag, and why attackers keep finding old firmware. 

A workable approach: 

• Subscribe to your vendors' advisories (Siemens ProductCERT, Rockwell's Trust Center, Schneider Electric's security notices) and to CISA ICS advisories. Map each one against your inventory. 

• Prioritize by exposure and exploitation, not just CVSS. A KEV-listed flaw on an exposed or poorly segmented controller jumps the queue. CISA's own guidance says known exploited vulnerabilities may need patching outside the normal downtime window. 

• Test on a spare or simulator, and schedule everything else into the next planned stop. 

• When no fix exists, or you cannot take the outage, compensate: restrict access to the affected function, disable the vulnerable service, add a firewall rule, and increase monitoring. Advisory entries marked 'no fix planned' are the reason this skill exists. 

Production-safe tip: patch the exposed and the exploited first, and record the rest as accepted risk with compensating controls and a review date. A defensible, written decision beats an unpatched controller nobody has thought about. 

Quick reference: effort, downtime and risk reduced 

A 30-60-90 day plan you can take to your plant manager 

First 30 days: stop the obvious exposure. Complete the passive inventory (1), find and close internet and cellular exposure (2), move vendors onto one remote-access route (4), put controllers in RUN mode where supported and disable unused services (5), and replace default credentials on exposed or critical devices (6). 

Days 31 to 60: build the guard rails. Roll out segmentation in monitor-then-enforce stages (3), harden engineering workstations (8), take offline golden backups with hash comparison and put change control around downloads (9), and deploy passive monitoring (11). 

Days 61 to 90: raise the ceiling. Pilot secure communication where supported (7), add independent verification for critical process values (10), put the risk-based patch process in place (12), and run a tabletop exercise that includes restoring a PLC from backup. 

Common mistakes that cause outages or false confidence 

• Scanning production with IT tools. Active scans can crash fragile controllers. Use passive discovery. 

• Calling a VLAN a security zone. If no policy is enforced between zones, you have a labeling exercise. 

• Assuming the air gap. The recent cases involved cellular modems, remote-access software and vendor connections that nobody had listed as internet exposure. 

• Hardening the PLC and forgetting the laptop that programs it. One compromised engineering workstation undoes everything else. 

• Keeping backups on the same network. If an attacker can reach the PLC, they can often reach the backup too. 

• Assuming small sites are safe. Commentary on AA26-231A makes the point that smaller operators are targeted because they are easy, not because they are interesting. 

• Doing everything at once. A phased, monitored rollout is both safer and easier to get approved. 

Frequently asked questions 

Can you secure legacy PLCs that do not support authentication or encryption? 

Yes, but not on the device. For controllers that cannot authenticate users, encrypt traffic or run an agent, you add the missing controls around them: firewalls and segmentation, a gateway or VPN with multi-factor authentication for remote access, restricted engineering workstations, protocol-aware monitoring and trusted backups. A gateway can enforce MFA even when the PLC has no concept of it. 

What is the first thing to do to secure a PLC? 

Make sure it cannot be reached from the public internet, and that includes cellular modems and forgotten port-forwarding rules. In the recent advisories, exposed controllers with default or missing credentials were the common starting point for attackers. 

Is a firewall enough to protect a PLC? 

No. A firewall reduces who can reach the controller, but it does not stop a compromised engineering workstation, a vendor's remote session, or a tampered shared code block from changing logic. You also need access control, integrity verification of the program, and monitoring. 

Should PLC firmware be patched, given the risk of downtime? 

Patch, but with a plan. Prioritize flaws that are actively exploited or that sit on exposed or poorly segmented controllers, test on a spare or simulator first, and use planned maintenance windows. Where a patch is not available or not possible, use compensating controls such as disabling the vulnerable service and restricting access. 

How do you detect that someone changed PLC logic? 

Compare the logic running in the controller against a hashed, offline golden copy on a schedule. Combine that with monitoring that alerts on program downloads, online edits and mode changes from non-approved hosts, and with review of shared libraries and Add-On Instructions. 

Which standards and guides apply to PLC security? 

IEC 62443 provides the zone-and-conduit model and the security-level framework for industrial automation. NIST SP 800-82 Rev. 3 is NIST's guide to OT security, including tailored guidance for NIST SP 800-53 controls. The PLC Security Top 20 list, hosted by the ISA Global Cybersecurity Alliance, gives practical secure coding practices that use the controller's own capabilities. Vendor hardening guides, such as Rockwell's and Siemens', cover product-specific settings. 

How Shieldworkz helps secure PLCs without disrupting operations 

Hardening controllers is rarely a technology problem alone. It is a coordination problem between security, engineering and operations, and the plants that get it right treat it as an operations project with security outcomes. 

Shieldworkz is an end-to-end industrial OT cybersecurity company, offering the platform, services and solutions in one place for critical infrastructure and industrial operators. For PLC security that typically means: 

• Visibility first: passive discovery of your controllers, firmware levels and communication paths, so hardening decisions start from facts, supported by the OThello platform. 

• Exposure and risk assessment: finding the internet-facing, cellular and vendor connections the latest advisories describe, and ranking what to fix first. 

• Architecture and segmentation design: zones, conduits and remote-access models aligned to IEC 62443 that your operations team can live with. 

• OT-aware patch and vulnerability management: prioritization that reflects exposure and exploitation, with testing before anything reaches the line. 

• Monitoring and response: protocol-aware detection and playbooks, including restoring a controller from a trusted backup. 

If you want to know how exposed your controllers really are today, talk to the Shieldworkz team about a PLC exposure and hardening assessment.

Additional resources:

Comprehensive Guide to Network Detection and Response NDR in 2026 here
NERC CIP-015 Internal Network Security Monitoring Readiness Checklist for Electric Utilities here
OT SOC Foundational Guide here
Managed SOC Service here
OT Cyber Threat Intelligence Advisory - Middle East here
NIS2 Directive Achieving NIS2 Compliance Through IEC 62443 here
What Is Removable Media? Risks, Policies, and Industrial OT Security Solutions here
Free Removable Media Policy Template for OT and IT Teams here