Siemens S7 PLCs exposed – NO patch available – Architect a solution

On August 19, 2026, five U.S. agencies – the NSA, CISA, the FBI, the Department of Energy, and the Environmental Protection Agency – jointly released Cybersecurity Advisory AA26-231A, “Defending Against an Active Threat to Siemens S7 Series PLCs.” The headline is alarming. The details are worse.

This is not a theoretical risk. The advisory is explicit about that. Threat actors are actively scanning for Internet-exposed Siemens S7 programmable logic controllers – the S7-200, S7-300, S7-400, S7-1200, and S7-1500 families, including F-series safety controllers – and using AI-generated exploitation scripts to compromise them. The scripts are built on the open-source snap7 library and are disguised to look like legitimate monitoring tools. They give attackers read/write access to PLC memory, configuration data, and ladder logic over the S7comm protocol on TCP port 102.

The most targeted sectors are Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. The Defense Industrial Base is on the list too. If you run S7 PLCs in any of these sectors, this advisory applies to you today.

The first thing to understand: there is no single CVE to patch

When a security advisory lands, the instinct is to look for a patch. This one is different. The advisory is not about one vulnerability in one Siemens product. It is about how PLCs are exposed – and the fix is architectural.

The threat actors are not breaking into well-segmented plants. They are using Internet scanning services like Censys and ZoomEye to find PLCs that are reachable from the Internet, running outdated software, or protected by default or minimally configured credentials. The AI-generated scripts lower the technical barrier to exploitation dramatically. What used to require a skilled attacker and weeks of work can now be scripted in hours.

Patching matters, and the advisory says so: apply Siemens ProductCERT updates, test them in a development environment first, and keep firmware current. But patching alone does not fix exposure. A fully patched PLC that is reachable from the Internet is still a target. The advisory’s top mitigations are architectural:

• Ensure PLCs are NOT accessible from the Internet.
• Block S7comm (TCP port 102) at perimeter firewalls entirely.
• Implement a DMZ architecture that separates OT and IT networks.
• Deploy unidirectional gateways for data historian connections where appropriate.
• Require multi-factor authentication for all remote access to OT networks.
• Deploy ICS-aware intrusion detection and monitor for anomalous S7comm activity.

Notice what is missing from that list: “connect your PLCs to more things.” The direction of travel is the opposite. The advisory tells owners to stop exposing their PLCs – and to move data across the boundary through controlled, monitored, one-way-or-authenticated paths.

The second thing to understand: the attack vector is S7comm itself

The advisory’s detection guidance is worth reading carefully. It tells organizations to watch for anomalous S7comm behavior, connections from non-engineering workstations, snap7.dll library usage outside approved engineering workstations, Python scripts with S7comm functionality, and write operations outside change windows.

In other words, the protocol itself – S7comm on port 102 – is the attack surface. Every place S7comm crosses a network boundary is a place the advisory tells you to look.

This is where the architectural fix gets concrete. If S7comm never crosses the boundary at all, the advisory’s primary attack vector disappears. PLCs stay on the OT network. Data moves out through a different, controlled path.

How Cogent DataHub software answers the advisory

Cogent DataHub software connects to Siemens S7 PLCs through OPC UA and OPC DA – for example, the built-in OPC UA server on S7-1200 and S7-1500 controllers, or a SIMATIC NET or third-party OPC server. A DataHub instance does not implement the proprietary S7comm protocol. In the current threat environment, that is a feature, not a gap: DataHub never introduces S7comm at the network edge.

From there, DataHub software implements the advisory’s architectural mitigations directly:

Isolate. A DataHub instance makes outbound-only connections from the plant. All inbound firewall ports stay closed, and no VPN is required. There is no listening port for an attacker to find, scan, or exploit. Zero attack surface at the plant edge.

Segment. The advisory – and NIST SP-800-82, NIS2, and NIST CSF 2.0 – point to DMZ architecture as the standard for OT/IT separation. DataHub is built for exactly that. Its tunnel/mirror connections daisy-chain cleanly across an OT-DMZ-IT architecture, mirroring the full data set at every hop with guaranteed consistency. If a link drops, data quality changes to Disconnected at every downstream node immediately – no silent staleness. This is something OPC UA and MQTT, the common alternatives, do not do well across a DMZ.

One-way where required. For protecting mission-critical networks, DataHub tunnelling data diode mode ensures absolutely no data passes back into the OT system. It works as a software-only option or with data diode hardware.

Authenticate and encrypt. Each DataHub instance provides TOTP multi-factor authentication, LDAP integration, and user permissions configurable by connection source (IP/CIDR), protocol, and data set. Every connection – including remote access by integrators and third-party service providers, which the advisory specifically calls out – is authenticated, authorized, and encrypted with TLS, including post-quantum cryptography support.

An honest note about what DataHub software is not

DataHub software enables the secure data path. It is not a replacement for the rest of the advisory. Patch your PLCs. Enable PLC password protection and protection levels. Deploy ICS-aware intrusion detection such as Claroty, Dragos, or Nozomi, and alert on S7comm activity outside maintenance windows. Follow Siemens’ own hardening guidance. DataHub software works alongside all of it – and it is the piece that lets you keep your data flowing while you stop exposing your PLCs.

What to do this week

1. Inventory. List every S7 PLC and its firmware version. Confirm none is reachable from the Internet.
2. Block port 102 at the perimeter firewall. Audit firewall rules for any exposed S7comm service.
3. Verify remote access. Ask your integrators what access they hold and how it is secured. Require MFA on every remote path into OT.
4. Move data through a secure path. If process data currently crosses the boundary via exposed protocols, move it behind an outbound-only, DMZ-ready data path like a DataHub tunnel/mirror connection.
5. Monitor. Deploy ICS-aware monitoring and alert on anomalous S7comm activity, off-hours connections, and snap7.dll artifacts on engineering workstations.

The advisory is clear: this is an active threat, and the mitigations are architectural. The plants that act this quarter will be the ones that were not on the scanning list next quarter.

Cogent DataHub software is not endorsed by CISA, NSA, or any government agency. The advisory explicitly disclaims endorsement of commercial products. This article responds to the advisory’s mitigations; it is not a statement of compliance with it.