On a conventional server, disabling an unused service is usually a routine hardening task. On a Siemens S7 controller, the supposedly unused service may carry remote I/O traffic, supply process values to an HMI or provide the maintenance team’s only path to diagnostics. Close it without checking those dependencies and the security team may cause the outage it intended to prevent.
That is the implementation problem inside joint cybersecurity advisory AA26-231A, issued on August 19 by the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency. The agencies warn of active targeting of Siemens S7 programmable logic controllers and recommend patching, removing internet exposure, strengthening access controls, monitoring S7 communications and disabling unnecessary services.
Every recommendation is reasonable. Several can affect production if they are implemented without understanding the plant.
The warning is not a patch notice
The advisory covers all CPU variants in the S7-200, S7-300 and S7-400 series, the S7-1200 compact CPUs listed in the advisory and all S7-1500 variants, including F-series safety controllers. These generations do not provide identical security functions.
Threat actors are using internet-scanning services to find exposed or poorly segmented controllers. According to the agencies, they combine public information with AI-assisted scripts and libraries such as Snap7 and python-snap7. The tools can communicate through S7comm, commonly over TCP port 102, and may read or write PLC memory, configuration data and control logic.
AI accelerates tool development, but it is not the underlying weakness. The advisory says actors are taking advantage of “known vulnerabilities, misconfigurations and other weaknesses.” It does not disclose one new vulnerability shared by every S7 or identify a single patch that resolves the threat.
Siemens made the same distinction in a statement to German trade publication Produktion. The company said AA26-231A does not describe new S7-series vulnerabilities, but methods that may exploit misconfigurations already addressed in its guidance. Siemens’ updated ProductCERT bulletin SSB-104599 directs customers to current software, protected networks, strong passwords and model-specific documentation.
This changes the response: operators cannot wait for one emergency update. They must reduce exposure across controllers with different hardware, firmware and engineering environments.
When I review an OT hardening change, I first need five facts: the exact CPU and communication modules, the firmware, the process and safety function, the legitimate communication partners and the approved recovery route. A control available on one device may not exist on another.
“Unused” must be proved
The most dangerous word in the guidance is “unused.” CISA recommends disabling web servers and protocols such as Modbus TCP and PROFINET if they are not operationally required. The qualification is critical. PROFINET may connect the CPU to distributed I/O, drives or other controllers. Modbus TCP may support a meter, analyzer or third-party package. A web server may be part of the diagnostic workflow even if it carries no continuous traffic.
Ten quiet minutes on a network sensor do not prove that a connection is unnecessary. Some communications appear only during startup, shutdown, failover or maintenance. I ask teams to prove “unused” three ways: from the engineering configuration, from representative traffic and through confirmation by the automation and maintenance owners. If those sources disagree, the service stays in scope.
The same discipline applies to the other measures in the advisory:
| Hardening measure | What could break | Safer implementation |
| Restrict TCP port 102 | HMI, engineering or controller-to-controller traffic | Block it at the perimeter; internally permit only documented communication pairs |
| Disable the web server | Browser-based diagnostics and maintenance | Confirm how it is used; if required, restrict it to a management zone |
| Disable Modbus TCP or PROFINET | Third-party equipment, remote I/O or drives | Verify the project configuration and observe representative traffic first |
| Apply PLC-side MAC/IP allowlisting | Older CPUs may not support it; redundant HMI or failover paths may be excluded | Map primary, secondary and maintenance nodes; enforce the rule at an industrial firewall where PLC-side control is unavailable |
| Limit S7comm sessions | HMI, historian or engineering access may exhaust the available connections | Measure normal and peak use, retain maintenance capacity and apply limits only where supported |
| Enable stronger CPU protection | Legacy partners or emergency maintenance may lose access | Test credentials, compatibility and recovery before deployment |
| Update firmware or engineering tools | Modules, libraries, safety functions or third-party integrations may fail | Validate the exact combination in a representative environment and define the backout route |
The network edge is normally the safest starting point. CISA recommends blocking TCP port 102 at perimeter firewalls. Blocking it indiscriminately inside a cell can interrupt legitimate S7 traffic. Internally, access should be limited to known communication pairs. Remote support should terminate at a managed gateway with individual authentication, a defined time window and session logging.
CISA also recommends MAC/IP allowlisting on the controllers themselves. That instruction is not universally implementable. Older CPUs may not offer the control and an incomplete list on a newer installation can break redundant HMI, engineering or vendor paths. The desired policy may therefore need to be enforced at the network boundary instead of on the PLC.
The advisory is similarly imprecise when it refers to “complete restart protection.” Technicians will not find a universal TIA Portal setting with that exact name. Operators need model-specific guidance instead of a guessed configuration change. Know-how protection can restrict access to selected blocks, but it does not replace network controls or integrity monitoring.
Treat hardening as an OT change
Firmware updates, protection levels and connection limits are changes to a production control system. They require the same engineering discipline as any other modification: an approved starting state, a test, a maintenance window, a rollback decision and operational verification.
“Patch quickly” and “test first” are not opposing instructions. Exposed controllers deserve priority, but an update can affect modules, HMI drivers, third-party libraries, redundancy or safety functions. The relevant unit is the exact CPU, firmware, modules, engineering version and connected environment. A project backup may not reverse an update, and downgrading may not be supported.
The advisory also recommends checking for ladder-logic changes. Operators should compare more than ladder. An S7 application may include function block diagrams, structured text, data blocks, hardware configuration and communication settings. The comparison also needs a trusted reference. An old directory called “final” is not a gold copy merely because it is the only project available.
Unexplained differences do not automatically prove compromise. They may expose a legitimate field change that never reached the master project. Reconcile them, approve the actual state and preserve it as the new baseline. Safety programs require their formal Siemens Safety comparison and acceptance process; a routine online/offline comparison is not sufficient to accept changes to an F-program or F-I/O configuration.
Monitoring should be tied to that baseline and the change process. Useful signals include S7comm from an unapproved source, writes outside a maintenance window, port 102 scans and Snap7 or Python tooling on an unexpected system. Snap7 itself is legitimate; context determines whether its use is authorized.
I use nine questions to keep a hardening change both secure and operationally defensible:
- Which exact asset is changing? Record the CPU, firmware and process function.
- Which attack path will close? Tie the action to a specific exposure or weakness.
- Which legitimate functions depend on it? Include operations, engineering and vendor access.
- What is the approved starting state? Capture the configuration and relevant communication paths.
- How was the change tested? Use a representative environment and operating scenario.
- What triggers rollback? Define observable failures rather than “if there is a problem.”
- Can the rollback actually be executed? Confirm tools, credentials, files, hardware and qualified staff.
- How will the process be verified? Check I/O, HMI values, alarms, interlocks, redundancy and safety behavior.
- What becomes the new baseline? Archive the result, evidence and operator acceptance.
Make one meaningful controller change at a time. If firmware, access levels, protocols and connection limits change together, a failed test gives little indication of which measure caused it. The safest sequence moves from the outside inward: remove public exposure, restrict remote and cross-zone access, establish monitoring, prove dependencies and only then change controller services, protection settings or firmware in a planned window.
Successful PLC hardening has two acceptance criteria: the attack path is closed, and the process still behaves exactly as the operator expects.
