Key takeways
Forescout found thousands of internet-exposed Rockwell PLCs, with more than 70% of those identified in the US associated with mobile carrier networks.
The 2026 water-utility attacks highlight that cellular connectivity does not automatically protect remote industrial equipment from public internet exposure.
For renewable-energy and distributed operators, Netcelero i-ctrl can place a controlled security boundary in front of PLCs, RTUs and SCADA systems while firmware, credentials and device hardening remain the asset owner’s responsibility.
Netcelero covered internet-exposed PLCs at water utilities in May, in “When PLCs Become Public”. This is a follow-up, not a restatement, because one important figure published in August was not available at the time: Forescout Vedere Labs found that more than 70% of the internet-exposed Rockwell controllers it observed in the United States were associated with mobile carrier networks.
That matters beyond the water sector. Renewable-energy O&M teams, distributed enterprises and other operators increasingly rely on 4G and 5G connectivity to reach PLCs, RTUs, SCADA equipment, turbine controllers and other industrial systems at remote sites. Cellular connectivity is not inherently insecure, but it does not, by itself, guarantee that the industrial device is protected from internet reachability.
On 30 July 2026, the FBI and the US Environmental Protection Agency issued a joint public service announcement warning that malicious actors were targeting internet-facing programmable logic controllers at water and wastewater utilities. The advisory named Rockwell Automation and Allen-Bradley MicroLogix 1100 and 1400 series controllers. According to the advisory, actors reached exposed controllers and changed IP addresses and passwords, leaving operators unable to monitor or control connected equipment. Incidents had been reported in at least seven states.
The largest disclosed cluster was in Minnesota, where the state’s IT organisation reported that more than 30 community water systems were targeted across 26 and 27 July. Later reporting expanded the number of states in which incidents had been reported.
What Forescout found
On 3 August, Forescout’s Vedere Labs scanned the internet for the affected controller families on port 44818, the EtherNet/IP service port, and published its findings on 6 August. It identified 4,407 exposed Rockwell Automation and Allen-Bradley controllers worldwide, including 2,844 in the United States. MicroLogix 1400 accounted for about half of the exposed devices, with CompactLogix 1769 and other controller families making up much of the remainder.
Forescout also identified 22 exposed devices in cities where attacks had been reported. Nineteen of those 22 were associated with the same mobile carrier network. Forescout’s scan did not establish that any of those individual devices had been compromised, so exposure in a city where an incident occurred is not evidence that a particular scanned device was involved.
The same research also highlighted devices running firmware versions associated with CVE-2017-16740, a stack-based buffer-overflow vulnerability affecting certain Rockwell MicroLogix 1400 firmware versions. That is an important finding, but it should not be confused with evidence that the vulnerability was used in the reported attacks. Public reporting has not established a specific vulnerability as the access vector.
Exposure is the documented common factor. Exploitation is not.
That distinction matters. The public evidence supports a much narrower and more useful conclusion: internet reachability created a condition in which an exposed controller could be reached remotely. It does not establish that exposure alone caused every incident, or that CVE-2017-16740 was exploited in the reported attacks.
Forescout’s assessment is that the publicly described effects did not necessarily require exploitation of a software vulnerability. If a controller is reachable and accepts changes to its network configuration or credentials, direct exposure can itself become a material security weakness. The evidence therefore supports treating public reachability as an attack-surface issue, while keeping firmware, credentials and device hardening as separate responsibilities.
Why the mobile-carrier finding matters
The significance of the carrier finding is not that cellular networks are inherently insecure. It is that a cellular connection can still result in an industrial controller being directly reachable from the public internet.
A 4G or 5G connection will often sit behind carrier-grade NAT, which normally prevents unsolicited inbound connections. But operators sometimes need inbound access for remote engineering or monitoring. That can be achieved through a publicly routable address, an APN or carrier configuration that provides inbound reachability, or by forwarding the controller’s engineering service through the site router. Once that is done, the controller can become visible to internet-wide scanning – regardless of whether the underlying connection is fibre, DSL or cellular.
Rockwell has separately warned against exposing industrial control systems directly to the internet. Forescout’s longer-term data also shows that internet-exposed Rockwell controllers have remained a persistent issue rather than disappearing altogether.
What this means for a remote solar, wind or distributed site
A solar or wind site with a controller on a 4G or 5G connection, or a distributed estate with RTUs behind mobile routers, can have the same basic exposure path as any other internet-connected industrial site. The important question is not simply “Is the site using cellular?” It is “Can an unsolicited connection from the public internet reach the industrial controller?”
That check should have two parts. First, test from outside the site whether the controller is reachable on services such as EtherNet/IP on TCP 44818 or Modbus TCP, rather than assuming that cellular connectivity is inherently private. Second, separately verify that the controller’s firmware is current and that default or weak credentials are not in use. One check does not replace the other.
Where Netcelero fits
Netcelero’s role is to address the connectivity and network-exposure part of that problem, not to claim that it secures the PLC itself.
The i-ctrl sits between the site and its underlying connectivity, including 4G, 5G, Starlink, DSL or fibre. It provides a static public IPv4 address from the Netcelero network together with configurable firewall protection and VPN-based access. With an appropriately configured firewall policy, an internet-wide scan reaches the Netcelero-controlled security boundary rather than exposing the controller’s engineering service directly to the internet.
That architectural distinction is important. The public IP does not have to terminate on the PLC or on a simple port-forwarded controller service. Access can instead be controlled at the network boundary, with source restrictions and certificate-based VPN authentication where the deployment requires it.
None of this touches the controller itself. Netcelero does not patch CVE-2017-16740 or other firmware vulnerabilities, rotate PLC credentials, or disable industrial protocols that the equipment owner does not need. Those remain responsibilities of the asset owner and should be addressed alongside network exposure. The FBI and EPA guidance likewise emphasises measures such as strong, unique passwords and restricting which devices are permitted to communicate with the controller.
The practical lesson
The lesson from the 2026 water-utility incidents is not that cellular connectivity is unsafe, nor that one networking product can solve OT security. It is simpler: remote access should not require the industrial controller itself to be publicly reachable.
For renewable-energy O&M teams and distributed operators, the architecture matters. If a PLC, RTU or SCADA system needs remote access over 4G or 5G, the security boundary should sit in front of the industrial device, with access explicitly controlled. Firmware, credentials and device hardening then remain part of the asset owner’s OT-security programme.
For renewable energy O&M and distributed operators
For teams running PLCs, RTUs or SCADA over cellular connections in the UK, Ireland, Europe or the US, the i-ctrl can remove the need for a publicly addressed or port-forwarded controller. It addresses network exposure; it does not patch device firmware or rotate credentials. Those controls stay with the equipment owner.
Contact Netcelero today if you have any questions relating to this article, or security of your remote sites.
Editorial note. The incidents discussed in this article were not Netcelero deployments, and the available public reporting does not establish that internet exposure was the specific cause of any individual incident. The comparison is about attack surface and network architecture: publicly reachable industrial controllers present a different risk profile from controllers placed behind a controlled security boundary.
