The FBI’s recent advisory regarding anticipated Iranian retaliation against U.S. organizations was direct and grounded in real investigations. The recommended actions were clear:
- Disconnect OT/ICS assets from the public internet
- Change default passwords
- Implement phish-resistant MFA for OT access
- Patch internet-facing systems
- Rehearse incident response plans
These aren’t theoretical mitigations. Iranian-affiliated actors have already compromised programmable logic controllers (PLCs) and human-machine interfaces (HMIs) in U.S. critical infrastructure by exploiting known vulnerabilities and factory-default credentials on internet-connected systems. But here’s the uncomfortable reality most security leaders already sense: most organizations believe they’ve already implemented these controls. And yet, pathways still exist.
The Real Problem Is Architectural Drift, Not Negligence
Very few OT environments are intentionally exposed to the public internet. The problem is rarely a deliberate configuration, it’s what happens over time. Operational changes introduce complexity: vendor remote access exceptions, firewall rule updates, cloud integrations, temporary workarounds that quietly become permanent. A misconfigured route here. A legacy trust relationship there. A VPN that terminates deeper into the network than anyone realized.
The result isn’t “OT on the internet.” The result is a reachable path from the internet to OT. Attackers don’t require direct exposure. They require connectivity.
Disconnecting OT Is Harder Than It Sounds
The FBI’s guidance assumes something foundational: that you actually understand how access flows through your environment. If a credential is phished and used to authenticate via VPN, where does that session terminate? What segmentation controls prevent lateral movement from there? Is there a route from a compromised IT system to an OT subnet? Does “deny by default” function as intended, or are legacy rules quietly permitting access nobody remembers approving?
Without real visibility into reachability, segmentation becomes an assumption, not a verified control. And in OT environments, assumptions are expensive.
OT Simply Doesn’t Protect Itself the Way IT Does
In traditional IT environments, organizations lean on endpoint detection and response, rapid patching cycles, and automated isolation. In OT environments, most of those controls are impractical or impossible. Devices are often legacy or vendor-controlled. Patching windows are constrained by production schedules. Downtime carries real physical and financial consequences.
Because OT systems often can’t be hardened the way IT systems can, the most reliable defensive strategy is architectural: make them unreachable. If an attacker can’t reach OT systems, they can’t disrupt them. That’s not a workaround, it’s the right design principle for these environments.
Prioritization Is the Missing Piece
“Patch internet-facing systems” is good advice. It’s also incomplete. Security teams are staring down thousands of vulnerabilities, and not all of them carry equal risk. The critical question isn’t: What is vulnerable? It’s: Which vulnerabilities create a pathway to high-value OT assets?
A medium-severity vulnerability with network connectivity into an operational environment may represent far greater business risk than a critical CVE sitting isolated inside a segmented IT enclave. Without understanding reachability, remediation becomes reactive and teams end up patching loudly while the actual exposure goes unaddressed.
Destructive OT Attacks Are a Different Category of Risk
When manufacturing lines go down, when water treatment is disrupted, when power generation is interrupted the consequences extend well beyond financial or reputational damage. They become physical. They become societal. That’s why eliminating unintended connectivity between internet-accessible systems and OT assets is a resilience imperative.
Moving From Checklist to Actual Assurance
The FBI’s recommendations reflect the gaps adversaries consistently exploit: simple weaknesses in consequential environments. But closing those gaps sustainably requires more than changing passwords and applying patches. It requires being able to answer one question with confidence:
If an internet-facing system is compromised today, what can the attacker actually reach?
If the answer includes OT assets, the risk remains regardless of how many checklist items are marked complete. If the answer is confidently “nothing in OT,” the architecture is working as intended. That’s the difference between compliance and assurance. But how do you know?
See Every Asset. Understand Every Risk. Close Every Gap.
RedSeal gives security teams a unified, business-contextual view of the entire hybrid environment across IT (on-prem, cloud, remote workers), OT, and IoT so you can identify unintended pathways and validate that segmentation is actually doing what you think it’s doing.
By understanding reachability, not just vulnerability scores, teams can prioritize remediation where it matters most and confirm that critical operational systems remain inaccessible to attackers.
In today’s threat environment, exposure isn’t defined by what’s vulnerable but is defined by what’s reachable. And for OT environments, reachability is everything.
We’d love to walk through what this looks like in your environment, contact the RedSeal team today to learn more.
