When CISA updates an advisory to expand the list of targeted manufacturers, it's more than a data refresh. It's a sign that your assumptions about operational technology security might be flawed.
These myths persist because they're comfortable. They let you believe that internet-exposed programmable logic controllers (PLCs) are someone else's problem, that vendors will fix it, or that your firewall configuration from 2019 still works. Meanwhile, Shodan shows 4,278 Rockwell devices globally exposed to the internet, with almost two-thirds in the United States. The advisory now includes observed targeting of Schneider Electric, Siemens, and possibly other manufacturers across U.S. water and wastewater, energy, and local government facilities.
The attacks have already resulted in operational disruption and financial loss. The myths below are what's keeping your team from acting.
Myth 1: "Our PLCs aren't on the internet, so we're safe"
Reality: You don't know what's exposed until you've checked from the outside.
PLCs are designed for closed networks. Many don't require authentication because they were never meant to face the public internet. But deployment reality differs from design intent. Third-party service providers install cellular modems for remote monitoring. Contractors connect devices during commissioning and never disconnect them. Network segmentation projects get 80% done and stall.
The proof is in the numbers. Of the 4,278 exposed Rockwell devices visible today, roughly half show IP addresses belonging to Verizon, not the asset owner. That means the exposure often comes through a cellular connection managed by a vendor or service provider. The water utility running the treatment plant may not even know their PLC is reachable from the internet.
Your first step isn't a policy document. It's an external scan using the same tools attackers use. If you can find your devices on Shodan, so can they.
Myth 2: "The manufacturer will patch this"
Reality: Most exposed PLCs can't be patched because the vulnerability isn't in the software.
These devices lack authentication by design. A valve controller programmed to open when a tank reaches a certain level doesn't ask for credentials before accepting that command. It's a feature, not a bug, when the device operates on a secure, isolated network.
The problem isn't a CVE you can remediate with a firmware update. It's architectural exposure. Even PLCs with physical settings that prevent reprogramming remain vulnerable to denial-of-service attacks. If a PLC takes 30 seconds to reset after being flooded with traffic, that's 30 seconds your system doesn't run as intended. In water treatment, that's not an inconvenience. It's a safety incident.
Waiting for a vendor patch misunderstands the threat. You need network controls that make the device invisible to external actors, not software updates that harden a device never meant to be internet-facing.
Myth 3: "CISA advisories mean the government will notify us directly"
Reality: CISA issues warnings, but direct notification at scale is a resource problem without a clear solution.
The expectation is reasonable. If federal agencies can identify exposed devices by IP address, shouldn't they contact the owners? The challenge is that IP addresses don't reliably map to asset owners in operational technology environments.
When the IP address belongs to a cellular carrier, you'd need a subpoena or carrier cooperation to identify the customer. Even then, the customer might be a product vendor or third-party integrator, not the facility operator. The water utility that owns the PLC may not appear anywhere in the chain.
CISA works regularly to identify vulnerable internet-facing devices and notifies owners when possible. But "when possible" is doing a lot of work in that sentence. With nearly 3,000 devices exposed from just two manufacturers, scale becomes the constraint. Small town water utilities without security personnel aren't reading federal advisories. They're responding to alarms and managing day-to-day operations.
You can't wait for a phone call. Treat the advisory itself as the notification.
Myth 4: "We have a firewall, so our PLCs are protected"
Reality: Firewalls work only if they're between the PLC and the internet, and configured correctly for OT protocols.
The fact that millions of Rockwell devices operate in the U.S. with only a small percentage exposed suggests that most organizations do deploy firewalls. But "having a firewall" and "having PLCs behind a firewall" are different states.
Devices connected through cellular modems often bypass your perimeter entirely. Remote access solutions configured for convenience create direct paths. Flat network architectures mean a compromise in the IT environment can reach OT assets. The ANSI/ISA-62443 series provides specific guidance on zone segmentation and conduit protection for industrial automation and control systems, but implementation requires understanding both IT and OT network behavior.
Your firewall logs should show zero inbound connections to PLC IP addresses from external networks. If you can't verify that right now, you're operating on assumption, not evidence.
Myth 5: "This is an IT problem, not an OT problem"
Reality: The exposure is an OT problem that requires OT-specific controls, not just IT security tools.
IT security teams know how to scan for vulnerabilities and apply patches. They don't necessarily know that resetting a PLC during production can halt a physical process or that some OT protocols don't support encryption. OT teams know the operational impact of downtime but may not understand how Shodan works or what a denial-of-service attack looks like in practice.
The Iranian-affiliated threat actors targeting these devices across multiple critical infrastructure sectors aren't exploiting zero-days. They're taking advantage of the gap between IT security practices and OT operational reality. Successful attacks have already caused operational disruption and financial loss.
This requires joint ownership. IT provides the network security expertise. OT provides the operational context and change management process. Neither team can solve this alone.
What to do instead
Start with visibility. Use the same search tools attackers use to identify your exposed devices. Shodan and similar platforms will show you what's reachable from the internet before an adversary exploits it.
Establish a cross-functional team with both IT and OT representation. Map every PLC, SCADA system, and industrial control device to a network zone. Document which devices have legitimate reasons for internet connectivity (very few) and which are exposed through legacy configurations or third-party access.
Implement defense in depth following ANSI/ISA-62443 principles. That means network segmentation, not just perimeter firewalls. It means remote access through jump hosts or VPNs, not direct connections to devices. It means monitoring for unexpected traffic patterns that indicate reconnaissance or attack activity.
Review your third-party vendor contracts. If a service provider needs remote access to perform maintenance, define exactly how that access works, when it's enabled, and who approves it. Cellular modems installed for convenience are security liabilities unless they're behind your security architecture.
The advisory updates will keep coming as attackers expand their targeting. Your response can't be reading the next bulletin. It has to be making your devices invisible to the search tools that make targeting possible in the first place.
