The latest U.S. joint cybersecurity advisory on Iranian-affiliated cyber activity is more than another threat bulletin. It is a direct reminder that operational technology security failures now translate quickly into real-world service disruption, financial loss, and erosion of trust in critical infrastructure operations.

According to the advisory issued by the FBI, CISA, NSA, EPA, DOE, and U.S. Cyber Command’s Cyber National Mission Force, Iranian-affiliated threat actors have been targeting internet-facing operational technology devices, including programmable logic controllers manufactured by Rockwell Automation / Allen-Bradley. The reported activity has already resulted in disruptions across multiple U.S. critical infrastructure sectors, including government services and facilities, water and wastewater systems, and energy.

What makes this campaign important is not only the attribution. It is the operating model.

This is not simply a case of attackers finding a single software flaw and exploiting it. It is an example of adversaries taking advantage of direct OT exposure, inadequate segmentation, weak remote access discipline, and insufficient control over engineering pathways into PLC environments. In other words, this is as much an architecture problem as it is a threat intelligence problem.

What the Campaign Tells Us

The advisory states that the attackers targeted internet-facing PLCs and used overseas-based infrastructure together with configuration software to establish accepted connections to victim devices. In the Rockwell context, that included the use of Studio 5000 Logix Designer software, with CompactLogix and Micro850 devices specifically referenced.

That detail matters.

It indicates that the threat is not limited to brute-force disruption or generic internet scanning. The actors appear to understand enough about industrial environments to interact with controllers in a way that can produce operational effect. The advisory also notes that victims experienced malicious interaction with project files and manipulation of data displayed on HMI and SCADA systems. In some cases, this led directly to operational disruption and financial loss.

From a defender’s perspective, this shifts the conversation away from availability alone. If HMI and SCADA data can be manipulated, the issue is not just whether a process stays online. It is whether operators can trust what they are seeing. That turns an OT cyber incident into an integrity and safety concern, not just an uptime concern.

Why Internet-Exposed PLCs Remain a Critical Failure Point

The most important lesson in this case is also the simplest one: internet-facing PLCs remain one of the most avoidable forms of critical infrastructure exposure.

The advisory explicitly recommends removing PLCs from direct internet exposure by using secure gateways and firewalls. That recommendation may sound basic, but that is precisely the issue. Many OT incidents still begin with exposure patterns that should have been eliminated years ago.

In industrial environments, direct exposure often exists for practical reasons: vendor maintenance, integrator convenience, distributed operations, urgent commissioning workflows, or long-standing legacy decisions that were never formally reviewed. Over time, these exceptions become normalized. Once that happens, remote engineering access starts to look operationally necessary rather than strategically dangerous.

Threat actors benefit from that normalization.

When PLCs are accessible from the public internet, the attacker does not need an elaborate intrusion chain to create operational impact. The attack path becomes shorter, quieter, and easier to operationalize. That is especially dangerous in sectors such as water, energy, and municipal services, where process disruption can have outsized public consequences.

The Technical Indicators Are Narrow, but the Defensive Implication Is Broad

The advisory highlights suspicious inbound activity on ports associated with OT protocols and remote access, including 44818, 2222, 102, 22, and 502. These port references are operationally useful for threat hunting, particularly where defenders are reviewing logs for historical signs of targeting.

The document also notes that the actors deployed Dropbear SSH software on victim endpoints to establish remote access through port 22. That is another important signal. It suggests that defenders should not limit their review to PLC telemetry alone. They also need to examine adjacent systems, engineering hosts, remote access workflows, and any endpoint that could support persistence or interactive access in the OT environment.

This is where many organizations still struggle. OT monitoring tends to focus on asset availability and protocol visibility, while endpoint and access-path monitoring remain uneven. But in modern OT incidents, the pathway matters as much as the payload. If a threat actor can reach the engineering layer, leverage configuration software, and manipulate project files or operator displays, the security boundary has already failed.

This Is Also a Visibility Problem

One of the most overlooked dimensions of OT security is the difference between asset awareness and operational visibility.

Many organizations can say they know which PLCs they own. Fewer can say, with confidence, which PLCs are internet-reachable, which engineering workstations can communicate with them, which integrator accounts retain access, which firewall rules were added as exceptions, and which remote sessions would actually generate usable logs during an incident.

That gap is where campaigns like this become effective.

The advisory’s guidance to query logs for indicators of compromise is necessary, but mature defenders should go further. They should treat this case as a trigger for an exposure review across the full OT access chain:

• Which controllers are directly reachable from untrusted networks?
• Which HMIs or SCADA servers have trust relationships with those controllers?
• Which engineering tools can initiate accepted controller connections?
• Which third-party or vendor pathways bypass core segmentation controls?
• Which events would be visible in firewall, VPN, endpoint, and controller-related logs?

Without that level of visibility, organizations may detect noise but still miss the real attack path.

The Strategic Context Matters

The advisory also places this activity in the context of broader Iranian-affiliated cyber operations and notes similarities to earlier campaigns associated with CyberAv3ngers, an actor tied to Iran’s Islamic Revolutionary Guard Corps Cyber Electronic Command. The earlier 2023 campaign targeted PLCs and HMIs in U.S.-based infrastructure, including the water and wastewater sector.

That history is significant because it shows continuity rather than anomaly.

Critical infrastructure defenders should not treat this campaign as a one-off spike driven only by geopolitical tension. The more durable lesson is that PLCs, HMIs, and exposed OT access pathways have become repeatable targets for state-linked disruption activity. Once a method proves operationally effective, adversaries tend to revisit it.

What Security Leaders Should Do Now

Security and OT leadership teams should take three immediate actions.

First, validate exposure, not assumptions. It is not enough to believe that controllers are isolated. Confirm whether any PLC, HMI, engineering workstation, or remote maintenance path is reachable from the internet or from weakly controlled external access points.

Second, tighten engineering access. The advisory makes clear that accepted controller connections and project-file interaction are part of the threat model. That means engineering software usage, jump hosts, remote maintenance channels, privileged access, and integrator workflows all need to be governed much more rigorously.

Third, investigate integrity risk alongside availability risk. If operator displays can be manipulated, then the security problem extends into decision support, process confidence, and possibly safety. OT incident response should therefore account for display tampering, project-file review, and controller state validation, not just service restoration.

The most useful way to read this advisory is not as a narrow story about one country, one actor set, or one PLC brand. It is a case study in what happens when operational technology remains exposed, remotely reachable, and insufficiently governed.

The real takeaway is simple: in OT, exposure is often the vulnerability.

Organizations that continue to treat PLC connectivity as an operational convenience rather than a strategic security boundary are leaving themselves open to exactly the kind of disruptive activity this advisory describes. For critical infrastructure operators, the time to revisit that assumption is now.