At a glance
On 22 July 2026, CISA, the FBI, the EPA and other US government partners updated joint advisory AA26-097A, first published in April 2026. The core message has not changed: Iran-linked actors are manipulating programmable logic controllers (PLCs, the small industrial computers that drive pumps, valves and production lines) that are exposed to the internet across water, energy and government. What is new is that the activity now reaches more manufacturers, and that the agencies have released fresh indicators and detection guidance. For an OT leader in Europe this is not a distant story: the same exposure exists here, and NIS2 already turns it into a compliance problem.
The uncomfortable part of the advisory is not sophistication but the opposite. As reported in the CISA statement carried by GlobalSecurity and by ExecutiveGov, the actors needed no zero-day or new vulnerability. They found PLCs reachable directly from the internet, with default or absent credentials, and acted. The full advisory text is available in the IC3 notice. That is the definition of avoidable risk.
And the target is a dangerous one. The activity described in the advisory includes attempting to download malicious project files and manipulating the data shown on human-machine interfaces (HMIs) and on SCADA displays (the supervisory control and data acquisition systems). In other words, it attacks the operator's picture of reality: the control room believes the process is nominal while it is not. Hence the operational disruption and financial loss the advisory attributes to some victims.
What the update actually says
The AA26-097A advisory was published in April 2026 and warned of Iranian activity against internet-connected operational technology (OT) devices. The 22 July revision makes four changes, according to the official statement and its reproduction on GlobalSecurity: new guidance to detect malicious changes in the reusable code modules used within Rockwell Automation PLC programs; additional mitigations; a refreshed set of indicators of compromise; and a broadening of the observed manufacturer scope.
That broadening is what forces the analysis to be reopened. The April version pointed chiefly at Rockwell Automation. The update adds that targeting of Schneider Electric and Siemens PLCs has also been observed, and does not rule out other manufacturers. One point is worth making so the advisory is not misread: naming a manufacturer does not mean its equipment has a flaw. The problem is not the product but how it is deployed — exposed to the internet and with weak authentication — which is exactly how the agencies frame it when they insist on restricting direct internet access.
The anatomy, at a conceptual level
Without anything reproducible, the pattern is easy to follow in three steps. First, discovery: internet-wide scanning locates reachable OT devices — PLCs, HMIs, cellular modems installed for a temporary project and never removed, engineering workstations with dual-homed connections. Second, access: when those devices carry default credentials or ask for no authentication, nothing more is required. Third, manipulation: uploading altered project files and changing what HMIs and SCADA screens display.
The technical detail that matters most for defence is the reusable code modules. On platforms such as Rockwell's, control logic is organised into reusable instructions and blocks invoked from several programs. A change introduced there propagates to everything that uses it and goes unnoticed if no one compares the project running on the controller against a known-good copy. That is precisely the detection gap the update asks defenders to close.
There is a second layer. Manipulating a display's values is not merely sabotage; it is disinformation aimed at the operator. If the HMI says pressure is nominal when it is not, the human response arrives late or moves in the wrong direction. Any serious defence plan must assume the screen can lie.
Why traditional controls are not enough here
Most organisations project their IT controls onto OT and assume the corporate perimeter also covers the plant. It does not. Many industrial networks are flat, vendor remote access is permanently on rather than enabled on request, and visibility into what happens on the control bus is minimal. An endpoint antivirus does not see a logic change on a PLC, and a perimeter firewall does not stop a compromised engineering workstation from talking to the controller beside it.
Treating this as a patching problem does not help either. There is no CVE to apply: the vector is exposure and the weak credential. That is why the classic severity-based prioritisation — useful for exploitable vulnerabilities, as we set out when discussing KEV, EPSS and SSVC — does not capture the real risk of a PLC anyone can reach from the internet. The right question is not which version you run, but who can reach it.
Detection: what to look for in your OT estate
Detection here is mostly about integrity and context, not signatures. The control that closes the gap described in the advisory is to keep a baseline of each controller's project and logic, store it offline, and compare it periodically for unauthorised changes — including those living in reusable code modules.
From there, four signals worth watching at a conceptual level: controller mode changes (a move from RUN to PROGRAM outside a planned maintenance window); project downloads or logic writes that do not correspond to an authorised change; unusual activity from engineering workstations or from vendor remote access; and the asset itself appearing in public device-indexing services, a sign that it is exposed. A managed SOC with OT visibility and threat hunting capability is what turns those signals into real detection.
On the refreshed indicators the advisory publishes: ingest them now, but with realistic expectations. An indicator of compromise expires quickly — infrastructure rotates, hashes change — so it is worth the first few weeks and worth leaning early on behavioural detection and on threat intelligence that gives the pattern context, not just the list.
Practical defence
The underlying mitigation has not changed since April, and agencies and analysts repeat it: PLCs and HMIs should not be reachable from the internet. Translated into concrete controls, start by enumerating every OT device with any path to the internet — including cellular modems and dual-homed machines — and validate that exposure externally by scanning your own address range. In practice this is attack surface management applied to the plant floor.
Then remove or firewall every direct path. Where remote access is genuinely required, route it through an authenticated jump host with MFA, session recording and time-bounded access; vendor access should be enabled on request and disabled by default, not standing. Change every default credential on PLCs and HMIs, and enable controller run/program mode protections where the platform supports them.
As a safety net, keep an offline copy of each controller's configuration and logic: it serves both to detect changes and to recover after an incident. All of this fits the IEC 62443 framework, the reference for industrial automation security, and rests on sound systems hardening. And because the screen can lie, run a tabletop on the specific advisory scenario — displays showing normal values while the process deviates — to surface how your team would recognise it, what independent instrumentation exists, and how manual operation would be initiated. If an incident does land, an incident response service with OT experience is the difference between hours and weeks.
Compliance: why this is also about NIS2
The advisory is American, but the exposure is identical on both sides of the Atlantic. In the EU, NIS2 classifies energy and drinking and waste water as sectors of high criticality; their operators are essential entities, with direct management accountability and short-deadline incident reporting. A water-treatment PLC reachable from the internet is not only a technical risk — it is a breach of obligations waiting to happen.
There is a further dimension worth keeping on the radar. A ComplianceHub analysis notes that adding the US Department of the Treasury as a co-author of the update points to a sanctions angle (OFAC): any extortion payment to a designated entity carries strict-liability exposure, regardless of intent. It is not European case law, but it is a reminder that responding to an incident of this kind has a financial and compliance layer beyond the purely technical.
For government and public bodies — the European equivalent of the “government services and municipalities” the advisory cites — the direction is the same: access control, segmentation and traceability. And it is worth remembering this does not happen in a geopolitical vacuum: activity against critical infrastructure fits the hybrid-threat pattern we analysed for European cybersecurity, and reinforces the impact-first prioritisation we argue for in OT/IT cybersecurity for industry. It also belongs to the supply-chain and third-party risk story that defines much of the current threat landscape.
What does not change
The AA26-097A update does not describe a new technique. It describes the same campaign reaching further, into more manufacturers' equipment, with enough success that the agencies have refreshed the indicators and strengthened the detection guidance. The lesson is not new either, and that is why it stings: the control that stops it — keeping PLCs off the internet — is organisationally hard in sectors of small operators with vendor dependencies and thin staffing, not technically hard. Anyone who assessed their exposure in April and found none should assess again this week. The list of what counts as exposed just got longer.
Note: this article includes detection and hardening guidance applicable to OT environments. Validate it in a controlled environment and adapt it to your architecture and compliance framework before applying it in production.