A Green HMI Is Not a Safety Signal
A refreshed U.S. advisory ties altered PLC logic and manipulated operator displays to disruption across critical infrastructure.
The most dangerous screen in an industrial environment may be the one telling an operator that everything is fine.
A joint U.S. cybersecurity advisory, refreshed on July 22, describes Iranian-affiliated APT actors reaching internet-connected programmable logic controllers across government, water and wastewater, and energy environments. The agencies say some victims experienced operational disruption and financial loss.
This was not limited to watching a process or stealing a configuration. The observed activity included interaction with PLC project files, changes to controller logic, and manipulation of data shown on human-machine interface and SCADA displays.
When the control logic and the operator's view can both be changed, a green dashboard stops being evidence of a safe process.
The advisory connects public reachability to two integrity failures: altered controller logic and an altered operator view.
The controller trusted the tool
The advisory does not center on a newly disclosed software flaw. It describes actors using overseas-hosted infrastructure and legitimate engineering software to connect to internet-facing controllers.
Patch status is not the boundary here. A trusted programming tool can perform exactly the actions it was designed to perform: retrieve a project, edit reusable logic, send changes back, and interact with the live controller. The security questions are whether the device should have been reachable, whether the engineering session was authorized, and whether anyone could prove which logic was running before and after the connection.
The agencies observed access involving Rockwell Automation equipment and expanded the July update to cover targeting involving Schneider Electric, Siemens, and potentially other PLC manufacturers. The inventory problem now spans multiple equipment families. An exposure review limited to one vendor or one industrial protocol can produce a clean report while leaving the same control path open elsewhere.
The path uses normal engineering functions; the anomaly is who reached them, from where, and what changed.
The display became another data surface
At one victim, forensic analysis found a malicious project file that preserved downstream ladder-logic behavior while adding logic that overrode instructions responsible for safe operating parameters. Elsewhere in the observed activity, changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators. The advisory also describes modification or deletion of reusable logic alongside manipulation of HMI and SCADA data.
An operator console is useful because it compresses thousands of signals into a manageable view. It becomes dangerous when the same intrusion can affect both the process and that view.
Availability is not the only industrial objective under pressure here. Logic integrity, display integrity, and the independence of safety signals all become incident-response questions at the same time.
Three views of the same process should agree. A mismatch is evidence, not noise.
The July update widens the equipment boundary
The advisory was first published in April and updated in July with broader manufacturer scope and new guidance for detecting malicious changes in reusable PLC code. The update turns a vendor-specific review into an environment-wide one.
Start with reachability, not the asset register. Identify every controller, modem, gateway, remote-maintenance path, and engineering workstation that can expose an industrial protocol or management service beyond its intended trust boundary. Then compare that live view with approved architecture.
The agencies call out suspicious traffic involving common OT and remote-access ports, including 44818, 2222, 102, 502, and 22. Those numbers are useful as hunting pivots, but a port list is not a control. The stronger evidence is an unexpected engineering connection, a project-file transfer outside a change window, a logic revision without a work order, or traffic from infrastructure with no operational reason to touch the site.
The unit of detection is the unauthorized change, not merely the packet.
Treat logic as production code
PLC programs often sit between two governance models. Operations treats them as plant configuration; security treats the controller as an appliance. Attackers benefit from the gap.
Building from those agency mitigations, a defensible internal baseline should answer four questions:
Approved logic: Which project and reusable logic modules belong on this controller?
Authorization: Who can retrieve, edit, and deploy them?
Change evidence: What independent record proves a change was authorized?
Recovery: How quickly can the site restore a known-good version without creating a new safety hazard?
Make the baseline operational with versioned project files, offline known-good backups, change records tied to named engineering sessions, and alerts when the live controller diverges from the approved baseline. Where supported, physical or software run-state controls should prevent remote programming during normal operations.
It also requires restraint during response. An industrial controller cannot always be isolated or restarted like an office endpoint. Capture the live logic and relevant logs, involve the process owner, and use the site's engineered safe-state procedure before changing device state.
Build a second source of truth
The immediate priority is removing PLCs from direct internet exposure behind properly controlled gateways and firewalls, as the agencies recommend. Remote engineering access should be explicit, time-bounded, strongly authenticated, and logged.
Operational teams can extend that guidance with independent validation.
Compare HMI values with controller diagnostics, historian data, physical instrumentation, and separate safety-system signals where the architecture allows it. Reconcile project hashes and logic revisions against the approved repository. Review engineering sessions and remote-access logs together rather than in separate queues.
Recovery begins by proving reachability, logic, display data, and physical process state independently.
If those views disagree, do not let the prettiest screen win.
The fresh reporting gives this campaign a geopolitical label. The government evidence gives defenders a more durable frame: a controller accepted a legitimate tool, its project could be changed, and its operator display could not be trusted on its own.
That is a control-integrity problem. It should be hunted as one.