Critical Infrastructure Operators: Remove PLCs From Direct Internet Exposure Now

A programmable logic controller that runs a water system, an energy process, a municipal facility, a manufacturing line, or a maritime terminal should not be reachable from the public internet. That is not a theoretical position. Federal agencies have documented active targeting of internet-connected operational technology and real operational disruption and financial loss at United States organizations as a result. Remote access to industrial equipment is often operationally necessary. Direct internet exposure is not the same thing as controlled remote access, and that distinction is the subject of this brief.

What Happened

On April 7, 2026, the Federal Bureau of Investigation, the Cybersecurity and Infrastructure Security Agency, the National Security Agency, the Environmental Protection Agency, the Department of Energy, and U.S. Cyber Command's Cyber National Mission Force jointly published Cybersecurity Advisory AA26-097A. The advisory warns that Iranian-affiliated advanced persistent threat actors are exploiting internet-connected operational technology devices, including programmable logic controllers, across U.S. critical infrastructure. The agencies updated the advisory on July 22, 2026, adding the Department of the Treasury as a co-author, expanding the list of observed equipment manufacturers, and publishing new detection guidance and indicators of compromise.

A short set of definitions helps here. A programmable logic controller, or PLC, is a ruggedized industrial computer that directly controls physical equipment such as pumps, valves, motors, and breakers. Operational technology, or OT, is the general term for the hardware and software that monitors and controls physical processes, in contrast to information technology, or IT, which handles business data and communications. Operators typically interact with these systems through a human-machine interface, or HMI, which is the screen showing process conditions, and through supervisory control and data acquisition systems, or SCADA, which collect and supervise process data across a facility or region.

The advisory describes targeting of PLCs manufactured by Rockwell Automation, including the Allen-Bradley product line, with the July update expanding the observed scope to Schneider Electric, Siemens, and potentially other manufacturers. The affected sectors identified in the advisory include government services and facilities, local municipalities, water and wastewater systems, and energy. Reported activity includes access to internet-facing PLCs, theft of PLC project files, modification or deletion of controller logic, manipulation of the information displayed through HMI and SCADA systems, operational disruption, and financial loss.

The manufacturer list should not be treated as exhaustive. The core problem is not a specific PLC brand. The core problem is direct or inadequately controlled internet access to operational technology. Any controller that can be reached from the internet is a candidate for the same activity, regardless of the logo on the faceplate.

The named sectors should not be treated as exhaustive either, although utility infrastructure operators should note that the advisory names their world directly through the water, wastewater, and energy sectors. The same families of controllers run terminal cranes, cargo handling systems, ballast and fuel transfer equipment, and shipyard machinery at ports and aboard vessels, and they run CNC support systems, material handling, and process equipment on aerospace and defense manufacturing floors. For maritime operators subject to the Coast Guard's cybersecurity requirements under 33 CFR Part 101 Subpart F, and for manufacturers and federal contractors with safeguarding obligations under DFARS 252.204-7012 or their contract terms, an internet-exposed controller is both an operational hazard and a condition that is difficult to reconcile with those regulatory commitments.

Why This Is Different From an Ordinary IT Incident

When an office computer is compromised, the consequences are serious but familiar: stolen data, ransomware, interrupted administrative operations, financial loss. When a PLC is compromised, the consequences move into the physical world, because the attacker is now touching the device that decides how equipment behaves. Potential consequences include unexpected equipment operation, loss of process visibility, false information displayed to operators, disabled or modified alarms, altered process logic, production interruption, equipment damage, and safety and environmental consequences. The advisory documents confirmed operational disruption and financial loss; the broader physical consequences listed here are potential outcomes of this class of compromise, not events the advisory attributes to this campaign. Responsible planning accounts for both.

There is also a quieter consequence: loss of confidence. Once controller logic or displayed data may have been manipulated, operators can no longer automatically trust the PLC program or what the HMI or SCADA screen shows them. An operator watching a normal-looking screen while the underlying logic has been altered is in a worse position than one looking at an obvious fault. Restoring trust in the control system, not just restoring connectivity, becomes the recovery objective.

Actions for Today

1. Identify every PLC, HMI, SCADA component, engineering workstation, gateway, router, remote-access appliance, and cellular modem that may be accessible from the public internet.
2. Review firewall rules, network-address-translation rules, port forwarding, public IP addresses, cloud-management dashboards, vendor-installed appliances, remote-maintenance platforms, cellular modems, and any temporary remote-access arrangements that were never removed.
3. Remove PLCs from direct public-internet exposure through a planned and controlled change. Coordinate that change with operations personnel, controls engineers, IT and OT staff, system integrators, equipment manufacturers, affected vendors, and safety personnel where applicable.
4. Disable unnecessary inbound services and unnecessary remote-access paths.
5. Change default, shared, reused, or poorly controlled passwords on PLCs, gateways, modems, remote-access systems, vendor accounts, engineering workstations, and network devices.
6. If compromise is suspected, preserve available logs, device configurations, and forensic evidence before making major changes.

Actions Within 72 Hours

1. Place necessary remote access behind an approved security architecture: a secure remote-access gateway, a properly configured firewall, a virtual private network, a bastion host or jump server, or a privileged-access platform appropriate for the environment.
2. Require multifactor authentication for remote access wherever the architecture and equipment support it.
3. Restrict remote connections by approved user, source IP address, destination, protocol, port, device, permitted time window, and business justification.
4. Review vendor and integrator access. Determine who can connect, from where, through which device or service, with which credentials, whether those credentials are individually assigned, whether access is logged and approved, and whether access remains enabled when it is not in use.
5. Review traffic involving the OT-related ports identified in the federal advisory, including TCP or UDP port 44818, TCP or UDP port 2222, TCP port 102, TCP port 502, and port 22 on associated modems or gateways. This port list is an investigative starting point, not a substitute for reviewing the complete network architecture and every remote-access path.
6. Compare current PLC project files and logic against a known-good engineering baseline.
7. Review connected systems for evidence of lateral movement, including HMIs, engineering workstations, SCADA servers, gateways, modems, historian systems, remote-access servers, and administrative workstations.

Actions Within Seven Days

1. Produce and validate a complete IT and OT asset inventory.
2. Create or update a network diagram showing IT networks, OT networks, network boundaries, firewalls, remote-access systems, cellular connections, vendor connections, internet gateways, engineering workstations, and the data flows between IT and OT.
3. Verify that IT and OT environments are properly segmented. Connections into the OT environment should be denied by default unless specifically approved and technically required.
4. Create known-good backups of PLC logic, PLC project files, HMI configurations, SCADA configurations, network-device configurations, engineering workstation configurations, and gateway and modem configurations.
5. Store recovery copies separately from the production environment, and test restoration in a controlled setting. A backup should not be considered reliable merely because a file exists.
6. Establish monitoring and alerting for changes to PLC programs, unauthorized engineering-software connections, unexpected remote logins, new or unrecognized devices, unusual foreign traffic, changes to firewall rules or remote-access configurations, failed authentication attempts, and new administrative accounts.
7. Update the incident-response plan to cover PLC manipulation, compromised HMI displays, altered process logic, loss of confidence in OT data, loss of remote visibility, recovery from known-good controller configurations, and manual or degraded operating procedures.

Questions Management Should Ask Today

1. Can we produce a list of every PLC, HMI, SCADA component, gateway, remote-access system, and cellular modem with a path to the internet within 24 hours?
2. Are any PLCs directly exposed through port forwarding, public IP addresses, cloud gateways, vendor appliances, or cellular modems?
3. Who currently has remote access to the OT environment?
4. Are vendors and integrators using individually assigned accounts or shared credentials?
5. Is multifactor authentication required for remote OT access?
6. Can we identify when a PLC program was last changed, who changed it, and what was changed?
7. Do we possess an independently verified, known-good copy of every critical PLC program?
8. Can operators continue running the process safely if the HMI or SCADA display cannot be trusted?
9. Who has the authority to immediately suspend remote access when a credible threat is identified?
10. When was the last time the OT incident-response plan was tested?
11. When were manual or degraded operating procedures last tested?
12. Can management verify that remote-access controls actually match written policy?

The Bottom Line

A directly exposed PLC is not merely an IT weakness. It creates operational and potentially physical risk, and the federal government has now documented adversaries acting on exactly this exposure. The first control is not an expensive or complicated security platform. The first control is to stop making the controller directly reachable from the public internet. From there, the organization must determine whether the device was accessed, verify whether the PLC programming can still be trusted, confirm that recovery files are clean and usable, and review the surrounding OT environment rather than assuming the problem ends with the PLC. This work is measured in days, not quarters, and the organizations that do it now will be answering these questions on their own schedule rather than during an incident.