" " indicates required fields
On August 19, 2026, five U.S. federal agencies signed the same document. The NSA, CISA, the FBI, the Department of Energy and the EPA released joint Cybersecurity Advisory AA26-231A. It warns owners and operators of industrial control systems about an active threat to Siemens S7 Series programmable logic controllers.
Five signatures is the part people noticed, and the EPA’s presence tells you water and wastewater utilities are a primary audience. The advisory has been covered everywhere this week, from Tom’s Hardware to BleepingComputer to the trade press. But the sentence worth reading twice sits further down, in the technical section, and almost nobody has quoted it.
Threat actors are running reconnaissance and capability development against U.S.-based PLC installations. They use internet scanning services such as Censys and ZoomEye to find controllers that are exposed to the internet or poorly segmented from it. Then they use AI-generated Python scripts, built on the open-source snap7 industrial automation library, to talk to those controllers over the S7comm protocol on TCP port 102. The scripts are dressed up to look like ordinary OT monitoring tools.
That gives them read and write access to PLC memory, configuration data, and ladder logic programs.
The sectors named are Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. The advisory adds the Defense Industrial Base as a further exposure.
The agencies do not attribute the activity to any nation or group. What they do offer is an assessment of intent, and it is the most serious line in the document. They assess the activity is likely intended as persistent reconnaissance: actors using read access to understand target environments and prepare for future write operations. That is pre-positioning, not theft.
The model list in AA26-231A is worth reading on its own. The agencies name the S7-200, the S7-300, the S7-400, the S7-1200 and the S7-1500, including the F-series safety controllers. Every CPU variant in each line.
That is five product generations, from the legacy S7-300 and S7-400 lines through the current TIA Portal generation. The SIMATIC S7 family is one of the most widely installed PLC families in the world, which is exactly why it draws this kind of attention. Ubiquity is the target, not a defect. When a controller family runs a meaningful share of the world’s water treatment, power distribution and factory floors, an adversary looking for reach studies that family first.
It also means the installed base spans design decisions made across decades. A controller specified when industrial networks were assumed to be physically isolated carries a different set of defaults than one specified after Stuxnet. Both are still running in production plants today, and the advisory covers both.
Two clarifications before going further, because both matter.
First, the agencies open the advisory with an unusual note: ongoing PLC targeting is broader than Siemens PLCs, and all PLC owners and operators should apply the mitigations, whoever built the hardware. The Siemens-specific content, they write, should be understood as one subset of a wider threat landscape. This follows an April 2026 advisory on Rockwell Automation and Allen-Bradley controllers, and a summer of reported attacks on water utilities.
Second, the advisory routes operators toward the manufacturer, not away from it. It directs readers to Siemens ProductCERT advisories for known vulnerabilities and workarounds, and to Siemens Industrial Cybersecurity Services for help hardening installed controllers. The vendor is treated as part of the remediation path.
The agencies call the use of AI to generate exploitation scripts an evolution in threat actor capability. In their words, it is “dramatically reducing the technical expertise and time” required to build working ICS exploitation tooling. They add that AI also lets adversaries pick up new attack vectors quickly and adapt to defensive measures.
They mapped this to MITRE ATT&CK technique T1588.007, “Obtain Capabilities: Artificial Intelligence.” AI-assisted exploit development now has its own technique ID in the framework.
Read that carefully, because it is easy to misread as “AI found a new hole.” It did not. Every ingredient here was already public: the vulnerabilities are known and catalogued, the snap7 library is on GitHub, the scanning services are commercial products, the S7comm protocol is documented.
What changed is the cost of assembly. Turning public information into working, targeted, evasive tooling used to require an engineer who understood industrial protocols. Now it requires a prompt and some iteration. The skill floor dropped, and the pool of people who can act on a known weakness got much larger.
For anyone who builds connected products, that changes the planning assumption. You can no longer assume that a documented weakness in your product will sit unexploited because exploiting it is tedious. Tedium was doing a lot of quiet work for you. It is not anymore.
The advisory lists seven hardening actions. Sort them by who can actually perform them and something becomes obvious.
Three are network and facility work, done in a specific building by a specific team. Verify segmentation and get controllers off the internet. Block TCP port 102 at the perimeter. Deploy ICS-aware intrusion detection on the plant floor.
The other four describe conditions that were largely determined long before the equipment reached that building.
Inventory every S7 controller and verify its firmware against a known good copy. Apply the right patches, prioritized by exposure, and check Siemens ProductCERT for model-specific vulnerabilities. Enable PLC password protection and configure protection levels on the device. Disable the built-in web server and any unused protocol, Modbus TCP, and PROFINET included.
Look at what those four actually assume. They assume someone can answer four questions quickly and with evidence. Which units run which firmware? Which components inside that firmware carry known vulnerabilities? Which of those vulnerabilities are reachable in this configuration? And which services are enabled by default that nobody needs?
That is not incident response. That is product security lifecycle work, and if it is not done during development, it turns into an emergency spreadsheet exercise during an advisory. The MITRE technique list includes T1694, insecure credentials, for devices with unconfigured or minimally configured authentication. Default credentials are not an attack. They are a design decision that the attacker later notices.
The four remaining mitigations are the manufacturer’s half of the advisory. They are the conditions that decide whether the operator’s job is a morning of work or a six-month campaign, and they are set during development.
Bridging the gap between the manufacturer and the operator, allowing both sides to quickly resolve an issue that has interdependencies and a regulatory clock, is what C2A Security built.
Knowing what is inside the product, before anyone asks. EVSec Binary Analysis extracts software composition from firmware and binaries in the absence of source code, including stripped and obfuscated images. It also flags embedded credentials, API keys, and cryptographic misconfigurations. EVSec BOM and Vulnerability Management holds the resulting SBOMs, HBOMs, AIBOMs, and CBOMs under version control, ingesting supplier-delivered binaries alongside your own builds. When an advisory names a component or a firmware range, the inventory question is a query rather than a project.
Prioritizing patches by real exposure rather than CVSS score. A controller family spanning five product generations accumulates a CVE list nobody can work through by severity alone. EVSec triages vulnerabilities against actual product understanding, using code-level reachability to separate what is present from what is reachable in the code, but more importantly, what is exploitable in the actual product architecture, understanding the entire attack surface and if it is exploitable in this configuration. This reduces noise by figures reaching 99% and allows focusing on what really matters, and AI can exploit. EVSec Risk Center then runs what-if analysis on the options, so a team can compare patching, disabling a service, or adding a compensating control before committing engineering time and optimizing cost and effort.
Catching default authentication and open services at design time. EVSec Analysis builds a model of components, interfaces, and trust boundaries. An exposed S7comm interface with unconfigured authentication is not a subtle finding in that model. It is an attack path with no control attached to it. Risk Center traces the required control back to a specific engineering ticket. EVSec Attacker then validates in the real implementation that the control works, using intelligent test generation from the product architecture and attack surface rather than generic checklists.
Hardening by default. Mitigation six asks S7 operators to switch off the device web server and any protocol they are not using. Every one of those services is an interface in the product model, and every enabled-but-unused interface is an attack surface carried into the field for no functional reason. That is a design review question with a clear answer, and it is much cheaper to answer before shipment than to do so through a global configuration campaign across the installed base afterward.
Answering “are we affected” in hours. EVSec Threat Intelligence automatically aggregates external feeds and maps them to the product model. A new advisory resolves to a list of affected products and versions. EVSec Fleets extends that to units already deployed, calculating risk across field versions and configurations and comparing remediation strategies: recall, over-the-air update, or configuration change. For teams running a SOC, EVSec SOC Enrichment and Analytics adds product and architecture context to security events. An alert arrives with all the product security information needed to analyze and resolve the ticket.
Providing dynamic and defensible evidence to regulators. As the regulatory clock requires disclosure and resolution, EVSec Compliance Center dynamically creates governed and audit-ready evidence that is both practical in solving the issue and defensible in front of the auditor.
Meeting AI with AI. This is the part that follows directly from T1588.007. If adversaries have compressed exploit development from weeks to hours, defenders cannot keep running threat analysis on a quarterly cycle in a spreadsheet. EVSec AutoSynth AI, including the Claude Inside release announced in May 2026, applies the same class of tooling on the defensive side. It turns architecture inputs into threat models, reasons over product-specific context, and maps engineering evidence to regulatory requirements.
There is a deadline in this that is easy to miss.
From September 11, 2026, the EU Cyber Resilience Act’s reporting obligations begin to apply. Manufacturers of products with digital elements placed on the EU market will need to report actively exploited vulnerabilities on a 24-hour early warning timeline. IEC 62443 already sets expectations for secure configuration and defense in depth in industrial systems.
An advisory like AA26-231A is exactly the scenario those rules were written for. The question “is our product affected, and how do we know” stops being an engineering inconvenience and becomes a regulatory clock. EVSec Compliance Center generates that evidence from live product data across UN R155, ISO/SAE 21434, FDA requirements, the CRA and IEC 62443, rather than from a document assembled after the fact.
The five signatures on AA26-231A are a signal about seriousness. The snap7 detail is a signal about something else: the economics of attacking industrial equipment have shifted, and they shifted for every vendor and every operator at the same time.
Stop treating known vulnerabilities in shipped products as a backlog to be worked through when there is time. Start treating them as a list an adversary can now act on faster than you can triage it manually.
The operators reading this advisory have seven things to do, and they should do all seven. The manufacturers reading it have a longer-term question, which is whether the next product generation will hand operators a shorter list.
We would be glad to talk about that. If your team is working through AA26-231A this week, or preparing for the CRA reporting date, schedule a demo or speak to an expert.
Source: Joint Cybersecurity Advisory AA26-231A, “Defending Against an Active Threat to Siemens S7 Series PLCs,” NSA, CISA, FBI, DOE and EPA, August 19, 2026.
