AI-Assisted Exploitation Reaches the Federal Record
The latest advisory lists seven hardening actions. Completing them is engineering work; proving they were completed is coordination work.
Aug 21, 2026
·Blog
·Jay Goodman
%3Aquality(100)&w=3840&q=75)
On August 19, 2026, the National Security Agency, CISA, the FBI, the Department of Energy, and the Environmental Protection Agency (EPA) issued a joint cybersecurity advisory, AA26-231A, on active threat activity against Siemens S7 Series programmable logic controllers (PLCs). The EPA's inclusion signals that water utilities are a primary audience for this advisory.
Upcoming Webinar: What CI Fortify Doesn't Say About Communications
Be precise about what the advisory reports, because the precision governs what operators should do next. The authoring agencies describe reconnaissance and capability development and assess the activity as persistent reconnaissance intended to prepare for future operational effects. They document read and write access to PLC memory, configuration data, and ladder logic over the S7comm protocol. They do not report loss of service. No utility is being told it has already lost control of a process. The agencies also note that PLC targeting is broader than Siemens and that all PLC owners should apply the relevant mitigations.
The Finding that Changes the Arithmetic
The operationally significant detail is how the tooling is being built. According to AA26-231A, threat actors are pairing publicly available industrial automation libraries, specifically snap7.dll and python-snap7, with AI-assisted scripting to produce custom tools that mimic legitimate OT monitoring software. The agencies assess that this dramatically reduces the technical expertise and time required to develop working ICS exploitation scripts. The activity is mapped to MITRE ATT&CK technique T1588.007, Obtain Capabilities: Artificial Intelligence.
Read that alongside the reconnaissance method: commercial internet scanning services used to locate exposed or insufficiently segmented controllers. Together the two findings describe a targeting model driven by exposure rather than by consequence.
What This Does to Risk-Based Prioritization
Most sector guidance and utility risk registers assume adversary attention scales with the consequence of a successful attack. The belief that smaller utilities attract less attention has persisted largely because the industry lacked clear evidence to challenge it.
AA26-231A supplies evidence. When exposed assets can be found automatically and exploitation scripts generated on demand, adding another utility to the target list becomes almost costless. A utility serving forty thousand people with a three-person operations team is as findable as a chemical plant with fewer people available to respond.
The exposure surface described in the guidance will be familiar to anyone who has audited a small system: controllers reachable from untrusted networks, default or minimally configured authentication, and third-party integrators holding remote access the asset owner may not know exists. The agencies make that point explicitly, warning that asset owners may not realize their systems are exposed through their service providers.
The Mitigation List Is a Coordination Problem
The seven hardening actions are relatively straightforward. Inventory every S7 controller and verify firmware against a known-good copy. Patch, prioritizing internet-facing and DMZ-resident devices. Block TCP port 102 at the perimeter and verify segmentation. Restrict programming access to authorized engineering workstations. Enable device password protection and protection levels. Disable unused protocols and web servers. Engage Siemens for model-specific guidance.
Confirming that the work happened is a different problem. The guidance instructs organizations relying on systems integrators or managed service providers to share the advisory and request implementation. The document concludes with a call to coordinate response across security, engineering, executive leadership, plant operations, and vendor support teams. That is an accountability requirement spanning internal roles and external parties, under time pressure, in organizations that frequently keep no single authoritative roster of who owns which controller.
The challenge is rarely completing the work. It is demonstrating, weeks later, which actions were taken, on which devices, and by whom. Regulators, boards, and after-action reviewers will expect that record to exist.
Seven mitigations, one deadline, and an integrator you do not employ. The engineering is bounded. The accountability is not — and that is where a small utility may lose the window.
A Narrower Point about the Response Conversation
The advisory also raises an operational question. If an actor holds read access to PLC memory and configuration in an environment, the working assumption during a hunt is that parts of that environment are visible to them. The internal discussion of what was found, which devices are exposed, and what will change should not depend on the same infrastructure. Organizations should consider whether response discussions belong on the same infrastructure being investigated. Communications tools do not mitigate PLC vulnerabilities directly, but they can support response coordination and accountability.
Where This Sits Relative to Detection
AA26-231A recommends ICS-aware intrusion detection and includes specific hunt criteria, including anomalous S7comm activity on port 102 outside maintenance windows, sequential scanning behavior, and Python processes importing snap7 libraries on engineering workstations. Detection is a different operational requirement from response. Detection identifies activity. Coordination determines whether response actions can be executed, tracked, and verified.
For many utilities, that accountability layer is managed through a dedicated crisis communications and incident response platform. BlackBerry® AtHoc® carries that second layer: structured notification with confirmed receipt and closed-loop accountability across internal roles and contracted service providers, producing an auditable record of who acknowledged what and when. Where a continuity assumption includes severed external connectivity, that capability depends on the deployment model; on-premises and hybrid options support it and the platform default is cloud-first. BlackBerry® SecuSUITE® provides the certified out-of-band voice and messaging channel for the discussion described above. Both address the coordination layer highlighted in the advisory's conclusion.
The Part Worth Carrying Forward
AA26-231A is short, specific, and answerable, and the seven mitigations are the right list. The operators most exposed to the activity it describes are also the ones least equipped to demonstrate they completed it. The next advisory cycle, rate case, or state inquiry is unlikely to focus on intentions. It will focus on what can be proven.
Related reading:
Water Watch Center Highlights Water Utility Cyber Response Gap
Why CI Security Guidance Keeps Failing Small Utility Operators
Assume Compromise, Then What? Moving Past the Slogan to Operational Requirements
What CI Fortify Asks Utilities to Spend — And the Capability It Never Names
When the Phones Go Down: The Coordination Gap Nobody Plans For
Lessons from the July Water Utility Attacks: What the Joint Advisory Tells Operators to Do Next
AI-Assisted Exploitation Reaches the Federal Record
The latest advisory lists seven hardening actions. Completing them is engineering work; proving they were completed is coordination work.
Aug 21, 2026
·Blog
·Jay Goodman
%3Aquality(100)&w=3840&q=75)
On August 19, 2026, the National Security Agency, CISA, the FBI, the Department of Energy, and the Environmental Protection Agency (EPA) issued a joint cybersecurity advisory, AA26-231A, on active threat activity against Siemens S7 Series programmable logic controllers (PLCs). The EPA's inclusion signals that water utilities are a primary audience for this advisory.
Upcoming Webinar: What CI Fortify Doesn't Say About Communications
Be precise about what the advisory reports, because the precision governs what operators should do next. The authoring agencies describe reconnaissance and capability development and assess the activity as persistent reconnaissance intended to prepare for future operational effects. They document read and write access to PLC memory, configuration data, and ladder logic over the S7comm protocol. They do not report loss of service. No utility is being told it has already lost control of a process. The agencies also note that PLC targeting is broader than Siemens and that all PLC owners should apply the relevant mitigations.
The Finding that Changes the Arithmetic
The operationally significant detail is how the tooling is being built. According to AA26-231A, threat actors are pairing publicly available industrial automation libraries, specifically snap7.dll and python-snap7, with AI-assisted scripting to produce custom tools that mimic legitimate OT monitoring software. The agencies assess that this dramatically reduces the technical expertise and time required to develop working ICS exploitation scripts. The activity is mapped to MITRE ATT&CK technique T1588.007, Obtain Capabilities: Artificial Intelligence.
Read that alongside the reconnaissance method: commercial internet scanning services used to locate exposed or insufficiently segmented controllers. Together the two findings describe a targeting model driven by exposure rather than by consequence.
What This Does to Risk-Based Prioritization
Most sector guidance and utility risk registers assume adversary attention scales with the consequence of a successful attack. The belief that smaller utilities attract less attention has persisted largely because the industry lacked clear evidence to challenge it.
AA26-231A supplies evidence. When exposed assets can be found automatically and exploitation scripts generated on demand, adding another utility to the target list becomes almost costless. A utility serving forty thousand people with a three-person operations team is as findable as a chemical plant with fewer people available to respond.
The exposure surface described in the guidance will be familiar to anyone who has audited a small system: controllers reachable from untrusted networks, default or minimally configured authentication, and third-party integrators holding remote access the asset owner may not know exists. The agencies make that point explicitly, warning that asset owners may not realize their systems are exposed through their service providers.
The Mitigation List Is a Coordination Problem
The seven hardening actions are relatively straightforward. Inventory every S7 controller and verify firmware against a known-good copy. Patch, prioritizing internet-facing and DMZ-resident devices. Block TCP port 102 at the perimeter and verify segmentation. Restrict programming access to authorized engineering workstations. Enable device password protection and protection levels. Disable unused protocols and web servers. Engage Siemens for model-specific guidance.
Confirming that the work happened is a different problem. The guidance instructs organizations relying on systems integrators or managed service providers to share the advisory and request implementation. The document concludes with a call to coordinate response across security, engineering, executive leadership, plant operations, and vendor support teams. That is an accountability requirement spanning internal roles and external parties, under time pressure, in organizations that frequently keep no single authoritative roster of who owns which controller.
The challenge is rarely completing the work. It is demonstrating, weeks later, which actions were taken, on which devices, and by whom. Regulators, boards, and after-action reviewers will expect that record to exist.
Seven mitigations, one deadline, and an integrator you do not employ. The engineering is bounded. The accountability is not — and that is where a small utility may lose the window.
A Narrower Point about the Response Conversation
The advisory also raises an operational question. If an actor holds read access to PLC memory and configuration in an environment, the working assumption during a hunt is that parts of that environment are visible to them. The internal discussion of what was found, which devices are exposed, and what will change should not depend on the same infrastructure. Organizations should consider whether response discussions belong on the same infrastructure being investigated. Communications tools do not mitigate PLC vulnerabilities directly, but they can support response coordination and accountability.
Where This Sits Relative to Detection
AA26-231A recommends ICS-aware intrusion detection and includes specific hunt criteria, including anomalous S7comm activity on port 102 outside maintenance windows, sequential scanning behavior, and Python processes importing snap7 libraries on engineering workstations. Detection is a different operational requirement from response. Detection identifies activity. Coordination determines whether response actions can be executed, tracked, and verified.
For many utilities, that accountability layer is managed through a dedicated crisis communications and incident response platform. BlackBerry® AtHoc® carries that second layer: structured notification with confirmed receipt and closed-loop accountability across internal roles and contracted service providers, producing an auditable record of who acknowledged what and when. Where a continuity assumption includes severed external connectivity, that capability depends on the deployment model; on-premises and hybrid options support it and the platform default is cloud-first. BlackBerry® SecuSUITE® provides the certified out-of-band voice and messaging channel for the discussion described above. Both address the coordination layer highlighted in the advisory's conclusion.
The Part Worth Carrying Forward
AA26-231A is short, specific, and answerable, and the seven mitigations are the right list. The operators most exposed to the activity it describes are also the ones least equipped to demonstrate they completed it. The next advisory cycle, rate case, or state inquiry is unlikely to focus on intentions. It will focus on what can be proven.
Related reading:
Water Watch Center Highlights Water Utility Cyber Response Gap
Why CI Security Guidance Keeps Failing Small Utility Operators
Assume Compromise, Then What? Moving Past the Slogan to Operational Requirements
What CI Fortify Asks Utilities to Spend — And the Capability It Never Names
When the Phones Go Down: The Coordination Gap Nobody Plans For
Lessons from the July Water Utility Attacks: What the Joint Advisory Tells Operators to Do Next
%3Aquality(100)&w=3840&q=75)