The recent joint advisory from CISA, FBI, NSA, EPA, DOE, and U.S. Cyber Command describes ongoing exploitation of internet-accessible PLCs across multiple U.S. critical infrastructure sectors, including water and wastewater, energy, and government facilities. According to the advisory, Iranian-affiliated threat actors accessed exposed OT devices, interacted with project files, and manipulated data shown on HMI and SCADA displays, in some cases causing operational disruption and financial loss.
The immediate lesson is straightforward: this activity was not driven by sophisticated malware or a novel exploitation chain. It was enabled by remote access paths that allowed threat actors to reach and interact with control assets in ways that should not be possible in a well-defended OT environment.
The advisory rightly calls for organizations to remove PLCs from direct internet exposure, review logs for indicators of compromise, monitor traffic on common OT ports, and harden affected controllers. It also recommends using a secure gateway or jump host to broker connectivity, enabling multifactor authentication for remote access, and monitoring for unusual access activity. These are important recommendations, and organizations that have not taken these steps should do so immediately.
At the same time, the advisory highlights a larger issue that deserves closer attention. In many OT environments, remote access is still treated as a network connectivity problem. The control system is placed behind a VPN, firewall, proxy, or jump host, and this is often taken as evidence that the exposure has been addressed. In practice, that architecture often still leaves one critical condition in place: a remote user, once connected, can directly communicate with the asset or the protocol stack that controls it.
That distinction matters. If a remote connection still creates network-level reachability to a PLC, then the attack surface has not been removed. It has been narrowed, wrapped, or relocated, but it still exists.
That is what makes this advisory important beyond the specific indicators and affected devices. The threat actors did not need to exploit an advanced vulnerability in order to cause disruption. The advisory notes that they used overseas-hosted infrastructure and legitimate configuration software to connect to internet-facing Rockwell Automation and Allen-Bradley PLCs. It also notes activity on common OT-related ports and the use of remote access tooling to maintain access. In other words, the path to impact was created by the access model itself.
This is where many discussions of secure remote access in OT still fall short. Controls such as MFA, patching, firewall policy, and log review are all necessary, but they do not change the underlying risk if the architecture still permits direct interaction with critical systems. MFA can verify identity. Logging can improve detection. Firewalls can reduce unnecessary exposure. None of those measures, on their own, prevent an authenticated session from being used to alter logic, change state, or manipulate operational data once direct access is established.
For OT operators, the better question is not simply whether remote access is protected. The better question is whether remote access still grants the user a direct path to the control environment.
A more resilient model for OT remote access starts from a different assumption. Users should not be given broad network access and then constrained after the fact through layers of security tooling. Access should be limited to a controlled session, scoped to a specific asset, for a defined purpose and time window, with full visibility into the interaction. Just as important, the architecture should prevent remote users from directly communicating with native OT protocols wherever possible. That approach does more than harden access. It changes the nature of access altogether.
The advisory points in this direction when it recommends removing inbound port exposure and ensuring that access is mediated, monitored, and controlled through a brokered connection. The practical implication is that remote access should no longer extend the network to the user. It should deliver a controlled interaction with the system, without exposing the system itself.
Organizations do not need to wait for a full architecture overhaul to move in this direction. In most environments, this model can be introduced incrementally by placing a brokered access layer in front of critical assets and routing remote interactions through it. This can often be done without readdressing networks, replacing PLCs, or disrupting existing operations. The shift is in how access is delivered, not in how the control system is engineered.
The benefits of this approach are immediate and measurable. Direct network paths to PLCs are removed, reducing exposure to both external and authenticated threats. Access becomes tied to identity and session context rather than network location. Every interaction with a control system can be observed, recorded, and audited without relying on endpoint logging or fragmented monitoring tools. Just as important, the risk of unintended or unauthorized changes is reduced because users are no longer interacting with the system through unrestricted protocol access.
Over time, this model also simplifies operations. Instead of managing layers of VPNs, firewall rules, jump hosts, and access exceptions, organizations can centralize control over who can access what, when, and how. That clarity becomes increasingly important as third-party access, vendor support, and distributed operations continue to expand.
This advisory should therefore be read as more than a warning about a specific threat campaign. It reflects a broader shift in how remote access to OT systems must be approached. Reducing exposure is no longer sufficient if the access model still allows direct interaction with critical assets.
Organizations that act on this now can move quickly from reactive mitigation to structural risk reduction. Those that do not will continue to rely on controls that assume the access model is sound, even as real-world incidents demonstrate otherwise.
For operators assessing their current posture, this is the right time to review a simple but important question: does remote access in your environment still create a direct path to critical systems, or has it been redesigned to deliver controlled, brokered interaction instead? The answer will say a great deal about how well your architecture is prepared for the threat environment now taking shape.