Cloud-First Security Was Built for IT
Cloud-routed security — the model used by Zscaler, Palo Alto Prisma Access, and Netskope — works by routing user traffic through a global network of cloud PoPs (Points of Presence). Traffic is inspected, policies are applied, and the connection is forwarded to its destination.
This architecture made sense for a specific problem: securing remote workers accessing SaaS applications from laptops. The user is already on the internet. The application is already in the cloud. Inserting a security layer between them is logical.
OT networks have none of those characteristics. The devices are on-premise. The applications are on-premise. The traffic is local. And the consequences of added latency or connectivity loss are physical — not a slow page load, but a failed control loop or a safety system timeout.
Why Cloud-Routed Fails for OT: 5 Specific Reasons
1. Latency on Real-Time Control Loops
SCADA polling cycles, PLC-to-HMI communication, and safety instrumented systems operate on tight timing budgets. A Modbus TCP poll-response cycle that normally completes in 5ms cannot tolerate a 40-80ms cloud round-trip through a PoP in another city.
The numbers:
- Typical SCADA poll cycle: 100ms-1s, with 5-50ms expected response time
- Cloud PoP round-trip (same region): 20-40ms added latency
- Cloud PoP round-trip (different region): 60-150ms added latency
- Safety system tolerance: Many safety PLCs timeout at >50ms response delay
Routing OT traffic through a cloud proxy introduces latency that ranges from operationally annoying to safety-critical, depending on the process.
2. Air-Gap Violations
Many OT environments are air-gapped by design — physically or logically isolated from the internet. This isn't a preference; it's a regulatory or safety requirement.
Cloud-routed security requires internet connectivity by definition. Every packet must reach the cloud PoP. Deploying a cloud-routed security tool in an air-gapped environment means breaking the air gap. The security tool becomes the vulnerability.
Industries with air-gap requirements:
- Defense manufacturing (CMMC, ITAR)
- Nuclear energy (NRC 10 CFR 73.54)
- Water treatment (AWIA Section 2013)
- Pharmaceutical manufacturing (FDA 21 CFR Part 11)
3. Data Sovereignty
Cloud-routed solutions process traffic in data centers owned and operated by the security vendor. For OT environments handling Controlled Unclassified Information (CUI), proprietary process data, or critical infrastructure telemetry, this creates a data sovereignty problem.
Questions that matter:
- Where is the cloud PoP physically located?
- Who has access to decrypted traffic at the PoP?
- Does the vendor's data residency guarantee survive a subpoena or government data request?
- Can you prove to an auditor that OT traffic never left the facility?
With on-premise enforcement, the answer to the last question is always yes.
4. OT Protocol Support
Cloud-routed platforms were built to inspect HTTP/S, DNS, and common IT protocols. They have limited or no support for industrial protocols:
- Modbus TCP/RTU — no inspection or policy enforcement
- EtherNet/IP (CIP) — not parsed at the application layer
- OPC UA — limited or no support for method-level policies
- PROFINET — real-time variants incompatible with proxy architectures
- DNP3 — no deep packet inspection at the cloud layer
- BACnet — typically invisible to cloud security stacks
A security platform that can't read OT traffic can't make OT-aware security decisions.
5. Uptime Dependency on Internet Connectivity
Cloud-routed security fails when the internet connection fails. In IT, this is an inconvenience — users can't access SaaS apps until connectivity returns. In OT, a security platform that goes offline during an internet outage leaves the network unprotected at exactly the moment it might be under attack.
On-premise enforcement operates independently of internet connectivity. The appliance enforces policy whether the WAN link is up, degraded, or down entirely.
On-Premise vs Cloud-Routed: Direct Comparison
| Factor | On-Premise Enforcement | Cloud-Routed Security |
|---|---|---|
| Latency impact | Zero added latency — enforcement is local | 20-150ms added per connection |
| Air-gap support | Full compatibility | Requires internet — breaks air gaps |
| Data sovereignty | Traffic never leaves the facility | Traffic processed in vendor's cloud PoPs |
| OT protocol awareness | Can inspect and enforce on industrial protocols | Limited to IT protocols (HTTP/S, DNS, etc.) |
| Deployment model | Single appliance or VM per site | Cloud subscription + endpoint agents |
| Uptime dependency | Operates independently of WAN/internet | Fails when internet connectivity drops |
| Agent requirement | Agentless — works with any device | Requires endpoint agent on managed devices |
| Legacy device support | Full — any IP-connected device | None for devices that can't run agents |
| Scalability model | Per-site appliance | Per-user or per-seat subscription |
| Best fit | OT, industrial, air-gapped, sovereign | Remote workers, SaaS access, branch IT |
When Cloud-Routed Does Make Sense
This is not a blanket rejection of cloud security. Cloud-routed platforms are the right choice for:
- Remote IT workers accessing SaaS and cloud applications
- Branch office internet breakout where local security appliances aren't justified
- BYOD environments where endpoint agents provide the only enforcement point
- Cloud-native workloads — securing traffic between cloud services
The problem isn't that cloud-routed security is bad. It's that it was designed for a different environment. Applying IT security architecture to OT networks creates gaps that the architecture cannot close.
The OT Security Stack Needs Local Enforcement
OT networks need security that:
- Enforces policy locally — no cloud round-trip, no added latency
- Works without agents — PLCs, HMIs, and RTUs can't run endpoint software
- Respects air gaps — operates without internet connectivity
- Understands OT protocols — makes decisions based on industrial traffic, not just IP headers
- Stays up when the WAN goes down — enforcement doesn't depend on external connectivity
On-premise enforcement isn't a legacy approach. For OT, it's the only architecture that meets operational requirements. Build your OT security stack accordingly — deploy enforcement where the traffic is, not where the vendor's data center is. For a practical look at how to implement on-premise segmentation without network redesign, see our comparison of overlay networking vs VLANs for OT segmentation.
