Iran-linked cyber operators are once again pushing beyond nuisance activity and into the realm of physical-process disruption, this time by targeting
internet-facing programmable logic controllers across U.S. critical infrastructure. The new CISA advisory, issued on
April 7, 2026, says the actors have hit Rockwell Automation/Allen-Bradley PLCs and other OT devices, manipulating project files and tampering with HMI and SCADA displays in ways that have already caused operational disruption and financial loss. That is a stark reminder that the shortest path into a plant, pump station, or utility network is often still the one operators forgot they had left open to the public internet. e especially important is that it is not being framed as a theoretical vulnerability disclosure. CISA, the FBI, NSA, EPA, DOE, and U.S. Cyber Command’s CNMF say they are seeing active exploitation, with the actors using overseas infrastructure, common OT ports, and vendor software such as
Studio 5000 Logix Designer to create accepted connections to exposed controllers. The advisory also suggests the campaign may not stop with one brand; the ports and tradecraft indicate broader targeting of OT environments, including potentially other PLC families and vendors.
Overview
The inems community has long known that PLCs were never designed for the threat model we live with today. They were built for reliability, deterministic operations, and trusted networks, not for constant exposure to hostile internet scans and remote adversaries probing them from leased infrastructure. The April 7 advisory underscores how dangerous that mismatch has become, especially when remote engineering convenience outpaces security discipline.
This warning lands in a broader geopolitys recent Iranian state-sponsored activity includes malicious cyber operations against OT devices by IRGC-affiliated actors, and it has been publicly urging organizations to harden against Iran-linked operations for years. The agency’s Iran threat overview explicitly warns that Iranian-affiliated actors routinely target poorly secured U.S. networks and internet-connected devices, while also emphasizing that control systems should not be connected directly to the public internet.
The current campaign also fits a familiar pattern of Iranian cyber escalation: opportunistic access first, then disruptive effects later. That pattern was visible in earlier campaigns that used compromised perimeter devices, VPN appliances, and exposed services to obtain footholds before moving to ransomware, extortion, or outright disruption. In other words, the current PLC activity is not an isolated anomaly; it looks like an evolution of a well-established playbook.
Rockwell Automation’s own response reinforces the seriousness of the situation. In March 2026, the company published
SD1771, warning customers about potential threat actor activity targeting Rockwell controllers and urging immediate action to ensure controllers are not exposed to the public internet. That vendor guidance lines up almost perfectly with the CISA/FBI message: the security model must move from
reachable anywhere to
reachable only through controlled, monitored paths.
What the Advisory Says Happened
CISA’s advisory describes a campaign that has already crossed the line from reconnaissance into manipulation. According to the agencies, the actors used malicious interactions with project files and altered data shown on
HMI and
SCADA interfaces, which means operators may r intentionally manipulated process information. In OT environments, that sort of deception can be almost as damaging as a full outage because it undermines trust in the control layer itself.
The advisory says some victims experienced
operational disruption and
financial loss, which is the critical point for executives who may still think of PLC compromise as a narrow engineering problem. A malicious change in controller logic or display data can trigger downtime, force manual service continuity, and create cascading business consequences. In a sector where uptime and safety are tightly linked, even “small” compromises can ripple outward fast.
The agencies also call out the attackers’ use of several overseas IP addresses and leased third-party infrastructure. That detail matters because it makes blocking simplistic, one-time indicators less effective than looking for behavior, especially repeated access attempts, unusual login patterns, and unexpecte from foreign-hosted sources. The campaign is not just about one or two bad addresses; it is about an access model that can be reconstituted quickly.
Why this is different from ordinary malware
This activity is less about ransomware-style encryption and more about
operational interference. The advisory’s emphasis on project files, display manipulation, and controller access suggests actors are interested in the control plane itself, not simply stealing data. That distincause OT compromise can remain invisible until a process misbehaves or a human notices that the screen no longer matches reality.
The result is a very different defensive challenge. Traditional enterprise controls often focus on data exfiltration, endpoint malware, and account abuse, but PLC attacks target the logic that keeps pumps, valves, motors, and other physical systems moving correctly. If defenders treat the incident like a conventional IT intrusion, they may miss the need to verify controller state, restore project files, and validate process integrity.
That is where the operational risk becomes truly severe.
Historical Context and Threat Evolution
This advisory is clearly building on the December 2023 activity that CISA and partners attributed to
CyberAv3ngers, the IRGC-affiliated group that targeted Unitronics PLCs and HMIs. That earlier campaign reportedly compromised at least 75 devices across multiple sectors, including water a, and it served as a warning that internet-exposed controllers were becoming explicit geopolitical targets.
The broader lesson from the CyberAv3ngers campaign was not merely that one vendor was vulnerable, but that exposed OT endpoints are attractive precisely because they are sparse, critical, and often poorly monitored. CISA’s earlier guidance about those attacks stressed that internet-accessible PLCs and HMIs can be compromised when basic segmentation and hardening are absent. The 2026 advisory suggests that lesson still has not been fully absorbed across the sector.
More recently, CISA and partners have repeatedly warned that Iranian actors exploit edge devices and exposed services to get their initial foothold. That includes the 2024 ransomware-enablement advisory and the 2024 brute-force/credential-access advisory, both of which show a steady emphasis on externally reachable services, weak authentication, and repeatable access methods. The PLC campaign feels like the OT version of that same philosophy: if the door is open, walk through it.
The strategic pattern
The strategic logic behind these campaigns is easy to miss because the individual incidents look narrow. But viewed together, they reveal a campaign style that prizes
availability impact,
psychological pressure, and
demonstrated reach over stealthy espionage. That makes the threat especially relevant for local governments, water utilities, and energy operators that cannot afford prolonged disruption.
The lesson for defenders is sobering: the adversary does not need exotic zero-days when exposed management surfaces, permissive remote access, and weak segmentation still exist. The attack path is often brutally simple, and that simplicity is what makes it scalable across sectors.
Initial Access: Why Internet Exposure Is the Real Problem
CISA says the actors used internet-facing Rockwell Automation/Allen-Bradley PLCs as the entry point, with exposed devicesogix
and Micro850
controllers. They used Rockwell software in conjunction with leased infrastructure to create accepted connections, which indicates the adversaries were not merely scanning passively; they were interacting with the controllers as if they were legitimate operators.
That is exactly why “we have a firewall” is not enough. If the PLC or engineering interface is reachable from the public internet, the adversary does not need to defeat the enterprise perimeter first. Instead, they can target the OT endpoint directly, bypassing layers of defense that may be designed for office networks rather than control systems.
The advisory’s mention of po,
102,
22, and
502 is also highly revealing. Those ports are associated with common industrial and remote-access protocols, and traffic on them from overseas hosting providers is a major red flag. For defenders, this means logs need to be reviewed for both known indicators and suspicious behavior on protocol-specific ports that should not be exposed broadly.
What defenders should look for
A mature review should not stop at a simple IOC match.d also look for login attempts from unfamiliar geographies, unusual changes to PLC configuration, and new remote-access tooling such as
Dropbear SSH on endpoints that interface with OT devices. The advisory specifically says the actors used Dropbear to enable remote access via port 22, which suggests persistence and remote operational flexibility.
A practical investigative sequence would be:
- Identify every PLC or HMI with public reachability.
- Check logs for access during the advisory’s cited time windows.
- Validate whether any controller project files were changed or downloaded.
- Inspect Windows or engineering workstations for remote-access tools and unauthorized configuration changes.
- Reconcile physical controller state with expected process behavior.
That workflow is
less glamorous than hunting malware and more effective in OT reality.
Impact on PLCs, HMIs, and SCADA Layers
The advisory’s mosthe manipulation of
project files and on-screen data. A PLC’s project file is effectively the blueprint for how the controller behaves, while HMI and SCADA displays are the human operator’s view into that behavior. If an attacker tampers with either layer, the organization loses both control fidelity and situational awareness.
That combination creates a dangerous uncertainty problem. Operators may continue making decisions based on false process readings, or they may detect anomalies only after alarms fail to correspond to reality. In energy and water environments, where small timing changes can matter, even temporary manipulation can cause costly or unsafe outcomes.
This is not merely a cyber issue; it is an operations integrity issue.
The advisory also identifies
Stored Data ManiTT&CK terms, which is the right framing because the attackers are altering operational state rather than simply vandalizing screens. CISA’s mapping also includes Commonly Used Port
and Remote Access Tools**, reinforcing the view that the campaign uses ordinary industrial connectivity in adversarial ways.
Why HMI deception is especially harmful
HMI deception is powerful because it attacks the operator’s trust model. A control room can absorb a network hiccup, but it cannot safely absorb false data if people believe the system is healthy when it is not. That is why tampering with displays can be as operationally disruptive as changing control logic itself.
This makes validation procedures essential. If there is any suspicion of compromise, operators should compare SCADA/HMI readings against independent process measurements and confirm controller logic integrity before restoring normal operations. In OT,
trust but verify is not a slogan; it is a safety requirement.
Ports, Protocols, and the OT Exposure Problem
The advisory’s port list—especially
44818,
2222,
102,
22, and
502—is a concise map of how industrial netwolves when they are too open. Those ports correspond to protocol families commonly used by Rockwell, Siemens, and Modbus-related devices, meaning the same basic exposure pattern can apply across multiple vendor ecosystems. That is why CISA warns that other branded PLCs may also be in scope.
In practice, OT exposure often happens for mundane reasons. Engineers want remote diagnostics, vendors want remote support, integrators want convenience, and operators want quick recovery paths when systems fail. Each of those needs is understandable, but together they can create a brittle architecture where the path of least resistance is also the path of greatest risk. ([rockwellautomation.com](
SD1771 | Security Advisory | Rockwell Automation effectively argue for a new default: no direct internet exposure, ever. Instead, any remote access should go through a secure gateway, jump host, or VPN with MFA and logging, and the controller itself should not be the directly reachable endpoint. That is not just a best practice; in this case it is the difference between defensible OT and an open invitation.
Segment first, expose last
The most important architectural takeaway is that segmentation has to be real, not symbolic. If a PLC can be reached from the public internet, or even from broad enterprise subnets without mediation, the organization has effectively collapsed its trust zones. That collapse makes incident response harder and increases the odds of a physical-world impact.
The stronger model is layered access control: remote users authenticate to a monitored gateway, the gateway brokers traffic, and logs capture who touched what, when, and from where. In an OT context,
the absence of direct exposure is the control.
Mitigations: What Organizations Must Do Now
CISce is unusually direct, and for good reason. The agency says organizations should
disconnect PLCs from the public-facing internet, place physical mode switches into
run position where applicable, create backups of logic and configurations, and block unnecessary traffic on common industrial ports. That is a serious checklist, not a suggestion box.
The guidance also stresses ss, secure gateways or VPNs for remote connectivity, and the removal or disabling of unused services such as Telnet, FTP, RDP, VNC, and web services. These are straightforward controls, but they often fail in the field because security exceptions accumulate over years and become operationally invisible until an incident exposes them.
Rockwell’s own March 2026 advisory echoes the same core actions. Customers are told to ensure controllers are not exposed to the public internet and to enable controller security protections using the System Security Design Guidelines. The vendor and the government are aligned here, which makes inaction much harder to justify.
Practical response priorities
Security teams should treat the mitigation list as a triage framework, not a wishlist. The first priority is to eliminate public reachability, then validate logging and access control, and then restore confidence in controller integrity. Everything else follows from that.
A sensible order of operations would be:
- Remove direct internet exposure.
- Restrict remote access behind MFA-protected gateways.
- Force controllers into safe operating modes when appropriate.
- Back up and verify PLC project files offline.
- Review logs for IOC matches and unusual protocol activity.
- Patch exposed devices during approved maintenance windows.
- Disable unnecessary services ls.
These are
boring controls only until they stop a real incident.
The Enterprise vs. Consumer Impact Divide
For enterprise IT defenders, this story is about perimeter control, identity, and detection coverage. For OT engineers, it is about process integrity, controller state, and safe recovery. Those are overlapping concerns, but they are not identical, and treating them as the same can lead to bad incident decisions.
Consumer-facing security language often focuses on malware, phishing, and stolen credentials. In the industrial world, the danger is that a seemingly mundane controller access event can alter equipment behavior, mislead operators, and threaten continuity of service. That means the righe both cyber containment and physical verification.
The business impact is also different. An office endpoint compromise is serious, but a PLC compromise can affect water delivery, energy operations, or municipal services in ways that directly touch public safety and local trust. The advisory’s focus on Government Services and Facilities, Water and Wastewater Systems, and Energy makes that distinction plain.
Why local governments should pay attention
The inclusion of local municipalities is especially important because many local governments run lean IT and OT teams. They often depend on integrators, aging equipment, and remote support arrangements that were never designed for hostile attention. That creates a perfect storm for exposure.
Municipal operators should assume they are part of the target set even if they have never seen a prior incident. The advisory makes clear that the campaign spans multiple sectors and multiple brands, so the old assumption that “we are too small to matter” no longer holds.
Strengths and Opportunities
CISA’s advisory gives defenders something unusually valuable: a clear, actionable description of how the campaign works and where to look. That means organizations can move from abstract worry to concrete validation, which is often the hardest step in OT security.
The biggest opportunity here is to use the incident as a forcing function for long-delayed architecture fixes. Many organizations have known for years that PLCs should not sit directly on the internet; this advisory creates a strong business case to finally make the change.
- The advisory names specific ports and specific behaviors, making log hunting more actionable.
- The guidance aligns with vendor recommendations, reducing ambiguity.
- The campaign provides a clear mandate to review controller exposure.
- The IOC list allows for historical threat hunting, not just live blocking.
- The incident can justify overdue network segmentation projects.
- The emphasis on offline backups improves resilience even beyond this threat.
- The sector-specific focus helps prioritize high-consequence environments first.
Risks and Concerns
The most obvious risk is that many organizations will underestimate how common direct OT exposure still is. Remote access convenience, third-party support, and legacy engineering practices often create exactly the condition the advisory warns against. That means a lot of vulnerable assets may remain visible long after the warning goes public.
A second concern is false confidence from incomplete detection. If operators only look for the published IPs, they may miss activity from rebuilt infrastructure or adjacent actors using similar methods. The deeper problem is the attack pattern, not just the listed indicators.
- Publicly reachable PLCs may remain unseen until compromise.
- Legacy remote-access setups can defeat otherwise strong IT controls.
- HMI manipulation may delay detection because operators trust the screen.
- Some environments may lack offline backups of project files.
- Segmenting IT and OT may be operationally difficult in older facilities.
- Vendors and integrators may differ on how security features are enabled.
- The same techniques may be reused against other PLC brands.
Another concern is response fatigue. Because many organizations have seen repeated warnings about Iranian activity, there is a risk the new advisory is mentally filed as “more of the same.” That would be a mistake. This campaign explicitly targets the control layer, and that shifts the potential impact from data compromise to process disruption.
Looking Ahead
The next question is whether this advisory marks a one or a broader shift toward sustained OT targeting by Iranian actors. Based on the language of the advisory, the answer may be somewhere in between: active exploitation is underway now, but the infrastructure and tactics suggest the actors are preparing a reusable capability. That means defenders should expect repetition, variation, and probable expansion to other OT brands and environments.
There is also a policy lesson here. The government is repeatedly telling critical infrastructure operators to stop exposing control systems directly to the internet, and vendors are now echoing that advice in their own security notices. That convergence should give boards and plant leadership enough clarity to approve the changes, even when those changes are inconvenient or expensive.
What matters now is execution. The organizations that move quickly on exposure reduction, access control, and recovery validation will be in a far better position than those that wait for a confirmed incident to force action. In OT security, the cheapest time to close the door is before someone walks through it.
- Remove any internet-facing PLC exposure immediately.
- Review logs for the advisory’s ports and IP indicators.
- Verify the integrity of project files and controller logic.
- Test offline backups and restoration procedures.
- Confirm MFA and mediation for all remote access.
- Reassess third-party access paths and vendor support workflows.
- Validate that operators can distinguish real process data from manipulated displays.
Iran-linked actors have now shown, again, that they are willing to move from scanning to disruption in the OT layer. That makes the security question less about whether the threat is real and more about whether critical infrastructure owners will finally treat exposed PLCs as the high-value assets they have always been.
Source: CISA
Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure | CISA