What happened
US agencies updated an April advisory on 22 July with new victim evidence and a wider device scope. At one US victim, actors downloaded a malicious project file to a targeted PLC using legitimate configuration software. Analysis found additional logic that overrode instruction sets responsible for safe operating parameters. Agencies also observed modification or deletion of reusable logic and manipulation of HMI and SCADA data, including changes that disabled critical shutdown and alarm functions.
The advisory now identifies observed targeting of Rockwell Automation CompactLogix and Micro850, Schneider Electric BMX P34 or Modicon M340, and Siemens S7-1200 devices, while warning that other internet-exposed PLCs may also be targeted. Activity since at least March 2026 has caused operational disruption and financial loss in several US critical-infrastructure sectors. The actors used leased infrastructure, industrial programming tools and traffic to common PLC protocol ports.
Why this matters now
The update documents a direct challenge to process-safety assumptions: controller logic can be changed while operator displays are manipulated to conceal the resulting condition. Availability monitoring or a normal-looking HMI is therefore not sufficient evidence that the physical process remains within safe limits.
This activity does not depend on a newly disclosed product vulnerability. It exploits exposed devices, insecure deployment, remote engineering paths and legitimate tools. Smaller utilities and distributed facilities with contractor-managed controls, weak inventories or limited round-the-clock OT monitoring are particularly exposed.
The decision for security leaders
Make internet exposure an executive exception, not an accepted operating model. Require the OT owner and integrator to identify every path by which engineering software can reach a controller and remove uncontrolled routes.
Prioritise integrity verification over broad malware scanning. Compare project files and reusable modules with known-good versions, review engineering-download history and test safety functions against independent measurements.
If exposure or unauthorised changes are found, involve the process-safety authority before remediation. An uncontrolled upload, reboot or isolation action can itself create operational risk, so cyber containment must follow approved plant procedures.
Evidence of closure
- External testing proving that PLC protocols and maintenance interfaces are not directly internet-reachable.
- Cryptographically recorded project files and reusable logic modules matched to an approved engineering baseline.
- A witnessed functional test showing that alarms, shutdown logic, interlocks and independent process measurements operate as designed.
- Access logs demonstrating that engineering downloads and configuration-software connections originate only from authorised systems and users.
The Security.io assessment
The July update materially changes the April warning by providing evidence that malicious logic was designed to override safe operating instructions and by confirming observed targeting across three major PLC ecosystems. This is not a reason to assume every Schneider, Siemens or Rockwell controller is compromised; it is a reason to treat direct exposure and unverifiable project logic as urgent safety defects.
The most important control is architectural: PLCs should not accept connections directly from public infrastructure. The second is engineering integrity: owners need approved project files, recorded hashes or signatures, controlled downloads and functional testing of shutdowns and alarms. Conventional IT evidence alone cannot establish closure if the controller logic or physical process has not been validated.
Confidence is high because the update is jointly authored by operational, intelligence, law-enforcement and sector agencies and describes victim-derived observations. Escalation should depend on local exposure, unauthorised engineering activity, logic differences or process anomalies rather than unverified claims that all internet-connected industrial devices are under active attack.
Questions for the morning meeting
- Can operations prove that safety is maintained independently of the HMI display and primary controller logic?
- Who can authorise an emergency controller download, and is that activity independently logged?
- Do integrators maintain copies of project files or credentials outside the asset owner’s governance?
- How long would it take to operate safely or shut down if controller logic and displays could not be trusted?