• Identifying malicious alterations in reusable code modules used within Rockwell Automation PLC
• Broadening the manufacturer scope to Siemen, Schneider Electric and other potentially branded/manufactured PLCs
• Detailing best practices for secure deployment 

The biggest issue here is that most of these organizations simply can’t pause operations while an incident is investigated. Water utilities have to keep providing clean water. Energy providers have to maintain power and fuel availability. Local governments still need to support emergency services and public operations. Even a short disruption can force employees into slower manual processes, delay essential services, and create public safety concerns. Recovery costs can also hit smaller operators especially hard since many are limited by small security staffs, older equipment, or outside vendors having control over parts of their environment.

Protecting these systems starts with knowing every controller in use and who can access it. IT teams, plant operators, integrators, and security partners need a shared response plan rather than separate assumptions about who owns the problem. Trusted backups of PLC logic are critical, as are tested recovery procedures and experienced responders who can contain an intrusion quickly.

A single exposed controller may look like a local weakness. In critical infrastructure, it can become part of a much larger national security problem.

Iranian cyber activity is becoming less dependent on one product and more focused on weaknesses that repeat across operational environments. By targeting controllers from several manufacturers, attackers can reuse the same playbook wherever exposed devices and weak access controls exist.

The ability to alter project logic and disable safeguards raises the stakes considerably. A compromise may no longer stop at unauthorized access. It can interfere with the systems designed to prevent unsafe physical conditions. Organizations therefore can’t treat each exposed controller as an isolated equipment issue.

Disconnecting vulnerable devices is essential, but defenders also need to understand how attackers could move from an internet-facing asset into critical operations. A CTEM program can map those realistic paths and identify the exposures that create the greatest operational risk. Adversarial exposure validation can then determine whether segmentation, access controls, monitoring, and incident procedures hold up against the tactics outlined in the advisory. Defenders need more than a list of weaknesses. They need evidence that the exposures most likely to cause physical disruption have been addressed.

The latest warning moves the Iran-linked threat beyond broad concern and into specific, actionable detail. Security teams now have new indicators, targeted ports, affected device families, and examples of attackers changing PLC logic or disabling critical safeguards. The problem is getting that intelligence into active workflows before the attackers move again.

That’s hard to do when asset data, network alerts, threat intelligence, and incident procedures live in separate systems. Security teams may understand the threat, but still lose valuable time gathering context and determining which exposed devices require immediate attention. Agentic AI Automation, such as that employed by modern AI SOC applications, can bring those signals together, identify affected OT assets, enrich suspicious traffic, and coordinate response across security and operations teams. It can also help prioritize vulnerabilities based on internet exposure and operational importance instead of relying on a generic severity score. Human approval should remain central for any action that could affect physical systems.