The Question at Hand
Your industrial control systems might be online right now. Not just "connected to the corporate network" but actually internet-accessible, discoverable by anyone with a port scanner and a few minutes.
The UK National Cyber Security Centre warns that attacks on operational technology systems are rising globally, with internet-exposed devices being the primary vector. Their recent advisory follows three warnings about internet-exposed edge devices in five months. When a national cybersecurity agency repeats itself that often, it's not just guidance. It's a preview of mandatory controls.
This raises a critical question: should OT systems ever be directly accessible from the internet? This debate isn't theoretical. It's happening in boardrooms where production uptime conflicts with security budgets, and in network diagrams where a single misconfigured firewall rule can expose a programmable logic controller running a 20-year-old operating system.
The Case for Strict Isolation
The traditional security stance is clear: operational technology should never be directly internet-accessible.
The reasoning is straightforward. OT devices weren't designed for hostile network environments. A programmable logic controller managing a water treatment plant or manufacturing line was built for reliability, not defense against remote exploitation. These systems often run outdated protocols, use hardcoded credentials, and can't be patched without costly production downtime.
Chris Grove, director of cybersecurity strategy at Nozomi Networks, highlights the core vulnerability: "The most dangerous phrase in industrial cybersecurity is 'that system isn't connected to the internet because I have an air-gap.'" That supposedly isolated system might actually be connected through a forgotten vendor connection or a misconfigured firewall.
Data supports strict isolation. Claroty's Team82 found that 82% of over 200 cyber-physical system attacks involved VNC clients used to access exposed assets, while 66% involved compromised human machine interfaces or SCADA systems. These aren't sophisticated attacks. They're exploiting exposed devices that free scanning tools can easily find.
Legacy equipment strengthens the isolation argument. Team82 found 88% of cyber-physical systems fail to transmit an exact product code, and 76% use product names different from the vendor's official record. If your security team can't accurately identify what's running, how can they assess risk or apply appropriate controls?
The Case for Controlled Connectivity
The operational reality is more complex. Modern industrial environments require remote access. Vendors need to troubleshoot equipment, engineers monitor systems from home, and cloud-based analytics platforms require data export. Supply chain integration depends on real-time connectivity.
Completely isolating OT isn't just impractical. It's harmful to the business outcomes that security is supposed to protect. A maintenance team that can't remotely diagnose a failing component will have to send a technician on a long drive, extending downtime and increasing physical safety risks.
New technologies complicate strict isolation further. 5G equipment, industrial IoT gateways, and edge computing devices are designed to sit between cloud services and legacy OT infrastructure. They export data, enable predictive maintenance, and support digital transformation initiatives that leadership has committed to. Telling operations they can't use these capabilities because security prefers outdated network architecture isn't effective.
The U.S. Cybersecurity and Infrastructure Security Agency's guidance acknowledges this tension. Their focus isn't on eliminating internet connectivity but on eliminating direct exposure. Route necessary remote access through a secure gateway, firewall, or VPN instead of connecting directly to critical control devices.
This approach recognizes that the problem isn't connectivity itself. It's unmanaged, unmonitored, poorly configured connectivity that leaves PLCs and HMIs vulnerable.
Where Practitioners Actually Land
Most organizations aren't choosing between absolute isolation and unrestricted internet access. They're implementing layered controls that allow necessary connectivity while reducing attack surface.
The NCSC's advisory outlines a practical middle ground: use stronger authentication methods, restrict access from external networks, adopt secure protocols, log all connectivity to and within OT networks, prevent remote programming during normal operations, segment different networks, and maintain a recovery plan.
Sean Tufts, Claroty's field CTO, emphasizes that visibility must go beyond an inventory list. Your security team can see an asset without having enough information to accurately identify or assess the risk associated with it. This is especially true for decades-old equipment that uses protocols IT scanners can't safely touch.
The wave of attacks on more than 100 water and wastewater systems in July often involved PLCs connected to a mobile network via a SIM card for wireless internet access. These weren't sophisticated supply chain compromises. They were direct connections that nobody inventoried, monitored, or secured.
Organizations that successfully manage OT internet exposure typically start by assuming that everything they think is air-gapped probably isn't. They verify isolation rather than assume it. They implement network segmentation that treats the OT environment as a separate trust zone. They route remote access through jump hosts or VPN concentrators with multi-factor authentication and session logging.
Our Take
The debate over OT internet connectivity is a false choice. The real question isn't whether systems should ever touch the internet. It's whether you know which ones do, how they're protected, and what happens when those protections fail.
Direct internet exposure of OT devices is indefensible. A PLC shouldn't have a public IP address. A human machine interface shouldn't be reachable via VNC from anywhere on the internet. These aren't debatable positions. They're baseline security hygiene.
But controlled, monitored, authenticated connectivity through proper security controls? That's not just acceptable. It's often necessary for modern industrial operations.
The NCSC's repeated warnings suggest where this is heading. As Grove notes, the next communication won't be an advisory. It'll be a mandate. CISA's binding directive on end-of-support edge devices signals the same shift in the U.S.
Start with verification. Don't assume systems are isolated. Scan your external attack surface. Query your internet-facing IP ranges. Check for forgotten vendor connections and misconfigured firewalls. Then implement the controls that let you say yes to necessary connectivity while maintaining the security posture that keeps you out of incident response.
The cheapest attack vector is the one you didn't know existed.
