Securing industrial control systems requires a fundamentally different mindset than standard IT server management. On a conventional server, disabling an unused service is a routine hardening task. On a programmable logic controller (PLC), however, the supposedly unused service may carry remote I/O traffic, supply process values to a human-machine interface (HMI), or provide the maintenance team’s only path to diagnostics. Closing it without checking those dependencies can cause the very outage the security team intended to prevent.
Major cybersecurity agencies have recently issued urgent warnings regarding the active targeting of Siemens S7 controllers. They recommend patching, removing internet exposure, strengthening access controls, monitoring S7 communications, and disabling unnecessary services. While every recommendation is sound, several can severely impact production if implemented without a thorough understanding of the plant floor.
### The Danger of the “Unused” Label
The most dangerous word in OT hardening guidelines is “unused.” CISA and partner agencies recommend 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. Qualification must be proven three ways: from the engineering configuration, from representative traffic analysis, and through direct confirmation by the automation and maintenance owners. If those sources disagree, the service remains in scope and must stay online.
### Hardening Measures and Their Operational Risks
When applying security controls, operators must understand the potential blast radius of each action. The following table outlines common hardening measures, what they could break, and how to implement them more safely:
| Hardening Measure | What Could Break | Safer Implementation |
| :— | :— | :— |
| **Restrict TCP port 102** | HMI, engineering, or controller-to-controller traffic | Block 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 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 procedures 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. Agencies recommend 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 always terminate at a managed gateway with individual authentication, a defined time window, and session logging.
The advisory also recommends MAC/IP allowlisting on the controllers themselves. That instruction is not universally implementable. Older CPUs may lack the control, and an incomplete list on a newer installation can break redundant HMI, engineering, or vendor paths. When PLC-side control is unavailable, the desired policy must be enforced at the network boundary instead.
### Treating 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; they are sequential requirements. 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 just ladder logic. An S7 application may include function block diagrams, structured text, data blocks, hardware configurations, and communication settings. The comparison also requires 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.
### A Nine-Step Framework for Operational Defense
To keep a hardening change both secure and operationally defensible, control engineers should walk through a structured evaluation process before touching a live system:
1. **Which exact asset is changing?** Record the CPU, firmware, and process function.
2. **Which attack path will close?** Tie the action to a specific exposure or weakness.
3. **Which legitimate functions depend on it?** Include operations, engineering, and vendor access.
4. **What is the approved starting state?** Capture the configuration and relevant communication paths.
5. **How was the change tested?** Use a representative environment and operating scenario.
6. **What triggers rollback?** Define observable failures rather than a vague “if there is a problem.”
7. **Can the rollback actually be executed?** Confirm tools, credentials, files, hardware, and qualified staff are ready.
8. **How will the process be verified?** Check I/O, HMI values, alarms, interlocks, redundancy, and safety behavior.
9. **What becomes the new baseline?** Archive the result, evidence, and operator acceptance.
### The Correct Sequence for Implementation
Successful PLC hardening follows an outside-in sequence. 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 the issue. The safest sequence moves from the perimeter 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 maintenance window.
Successful OT hardening has two acceptance criteria: the attack path is closed, and the process still behaves exactly as the operator expects.
—
### Frequently Asked Questions (FAQ)
**Q: Why is simply blocking all external traffic not enough to secure PLCs?**
A: Threat actors frequently use AI-assisted scripts and libraries to communicate with PLCs through legitimate protocols like S7comm over TCP port 102, even from inside the network perimeter. Once they bypass the edge, they can read or write PLC memory, configuration data, and control logic if internal segmentation is weak. Defense-in-depth is required.
**Q: What is the safest way to determine if a PLC service is truly “unused”?**
A: A service cannot be considered unused based on a brief network snapshot. To prove it is unnecessary, you must cross-reference the engineering configuration, analyze network traffic over a representative operational cycle (including startup and shutdown sequences), and obtain written confirmation from both the automation engineers and the maintenance technicians.
**Q: Why can’t MAC/IP allowlisting be applied to all PLCs?**
A: Older CPU models often lack the hardware or firmware capability to enforce network-level access controls on the device itself. In these scenarios, attempting to apply PLC-side allowlisting can break legitimate redundant HMI paths or engineering connections. The policy must instead be enforced at the industrial firewall or network boundary.
**Q: What should operators do if a firmware update breaks a third-party module?**
A: PLC updates must be treated as formal OT changes. Before updating, you must validate the exact CPU, firmware, and module combination in a representative test environment. Crucially, you must define a backout route and ensure it works. A project backup may not reverse an update, and firmware downgrading may not be supported by the vendor.
**Q: Is Snap7, a commonly used PLC communication library, a threat?**
A: No. Snap7 and python-snap7 are legitimate tools used for communicating with S7 controllers. The threat lies in their use by unauthorized actors. Context determines whether their use is authorized; network monitoring should flag Snap7 activity originating from an unapproved source or outside of standard maintenance windows.
—
### Conclusion
Securing industrial control systems is a balancing act between cybersecurity and operational continuity. Dismissing the complexity of OT networks by applying standard IT hardening scripts can lead to catastrophic production outages. By proving that services are truly unused, enforcing controls at the network boundary when the PLC cannot support them, treating firmware changes as formal engineering events, and following a disciplined outside-in sequence, organizations can close attack paths without disrupting the processes that keep the plant running. The ultimate measure of success is not just a locked-down controller, but a system that continues to behave exactly as the operator expects.
Thank you for reading
