SASE for manufacturing plants with awful internet - experiences?

Great question - I've been down this road with a few agri-processing plants. The performance hit is real, especially with full TLS inspection turned on. We had to dial that back for OT traffic to keep SCADA systems responsive.

Phasing in an SSE-first approach with Zscaler really helped. Their "branch connector" appliance does local breakout for trusted destinations, which saved our limited bandwidth for actual cloud apps. We still got the security stack for things like Salesforce and our ITSM tool, but the latency-sensitive OT traffic got a simpler firewall rule.

One hard lesson: test the fail-open behavior of any SASE proxy in a lab that mimics your awful link before you go live. We had a brownout that caused more disruption than it should have. Some vendors handle flaky connections better than others.

The phased SSE approach user1021 mentioned is the right call. We ran a similar deployment for a mining operation, but found the "branch connector" logic itself can become a point of failure if not tuned right. Our Zscaler Connector kept trying to re-establish tunnels on a flaky link, starving other traffic.

You'll absolutely have to make trade-offs on TLS inspection. We ended up creating a separate, non-inspected policy rule for any OT system traffic destined for vendor cloud services. It's a risk, but the alternative was timeout-induced reboots on the PLCs.

The biggest lesson? Your monitoring becomes critical. You need Prometheus metrics on tunnel health, latency, and packet loss from the on-prem appliance itself, not just the cloud service. I built a Grafana dashboard specifically for this - watching tunnel flapping was the only way we caught a misconfigured SD-WAN link fighting with the SASE policy.

Did you look into any vendors offering more aggressive local caching? I've heard some can cache OS updates and even static SaaS content, which can be a bandwidth lifesaver.

You're right to focus on the performance hit, that's the primary constraint here. Based on what we've seen in the community, the key is to treat your OT network traffic as a separate class from the start.

Your idea about architectures with local breakout is spot on. We've had members use that for their legacy MES systems to avoid backhauling traffic over a satellite hop just for a security check. The trade-off is less visibility, but it keeps the lines running. The real test is how gracefully the edge appliance fails when the link drops entirely; some just freeze.

What's your plan for the initial traffic classification? Getting that wrong can tank performance from day one.

I agree that classifying OT traffic as a separate class from the start is non-negotiable. Your point about the appliance freezing on a link drop is a scary one we've seen too.

Beyond just initial classification, I'd add that you need a plan for re-classification. In one plant, a "trusted" vendor system update started phoning home to a new CDN, which suddenly got inspected and brought the process to a crawl. The policy tuning never really ends, so you need a lightweight process for the ops team to report new latency issues and get rules adjusted quickly, without a full security review bottleneck.

How are you thinking about ownership for that ongoing policy management? Keeping OT running often means security teams have to trust the plant network admins to flag new traffic patterns.

I've seen two plants try this. Both gave up and ran the OT traffic on a completely isolated VLAN with a simple, old-school firewall.

The "local breakout" everyone's praising just becomes a management nightmare when you're dealing with PLCs that can't handle a 5ms blip. You'll spend more time tuning policies and watching Grafana than you ever did on the old setup.

Direct to cloud sounds nice until the satellite goes out in a storm and your central team has zero visibility. Sometimes a bit of latency is the least of your problems.

Isolation works, but then you have zero visibility into OT traffic until something fails. The trade-off isn't just visibility vs latency, it's detection time.

I've seen that isolated VLAN get breached via a forgotten engineering laptop. Without central logs or traffic inspection, they didn't know for weeks. The "management nightmare" of a SASE appliance is replaced by the silent incident.

The real failure in those two plants was likely expecting SASE to handle everything. You don't run PLC traffic through a cloud proxy. You use it to secure and monitor the management and data historian traffic going off-site. That's the balance.

You're right about detection time being the critical trade-off, but I think the isolated VLAN breach example points to a different problem: asset management and network access control. A forgotten laptop shouldn't be on that VLAN in the first place.

The balanced approach you described, using SASE for management and historian traffic while keeping PLCs local, is essentially a segmentation strategy. But its success hinges on the initial policy definition being exhaustive. In my tests, we found that teams consistently underestimate the number of systems that need to phone home for routine updates or telemetry, which later becomes a scramble for policy exceptions. The process for defining what constitutes "management traffic" must be incredibly granular from day one.

Yes, we've done this successfully. The trick was starting with a proof of concept at one plant that had the worst connection. We used Cato's edge SD-WAN appliance for local, policy-based breakout. It let us keep critical OT traffic completely local while still getting basic traffic visibility for the paths we *did* send through their cloud.

The biggest compromise was on TLS inspection. We never even attempted it for OT traffic - it was a non-starter. The trade-off was accepting that we were securing the path and applying access controls, but not inspecting the content of those sessions. For us, that was an acceptable risk profile compared to the operational disruption.

My concrete advice? Forget a big-bang rollout. Start with one site and a very short list of 'green light' traffic you'll send through the cloud proxy, like your ITSM or data historian replication. Everything else gets a local breakout rule by default. You can always tighten it later, but you can't undo a PLC reboot.

Agreed on separate traffic class. We saved 40% on bandwidth costs right away by doing that.

> Getting that wrong can tank performance from day one.
It also hits your wallet. We classified too broadly at first and got hit with massive data egress fees from the SASE provider for traffic that should have broken out locally. Took two billing cycles to fix.

Test the fail-open with the actual ISP link, not a simulated one. We had one vendor's appliance that passed lab tests but locked up during real-world packet loss. The contract penalty for that downtime covered our next year's monitoring tools.

You've hit on the key tension here: visibility vs. operational reality. I've seen this play out a few times, and the successful projects all shared one thing. They started by mapping every single OT application and its specific network dependencies *before* picking a vendor or writing a policy.

Looking at architectures with local breakout is absolutely the right direction, as others have said. But performance isn't just about bandwidth, it's about session persistence. Some vendors' edge appliances handle flaky links better by maintaining local state, while others are more brittle. Ask for a real-world failover demo on a throttled, lossy link, not a clean lab test.

To your point about trade-offs with TLS inspection, you'll almost certainly have to forgo it for the sensitive OT traffic. The more critical question is what you do with the decrypted traffic you *do* inspect. Does your chosen architecture backhaul that decrypted data for analysis, eating your precious bandwidth, or can it process and forward intelligently at the edge? That architectural choice will impact your monthly data costs more than almost anything else.

Your focus on local breakout and caching is correct, but I'd add that the caching capability is often oversold for these environments. The cache hit rate for unique OT telemetry and MES data is typically below 5% in my tests, making it a negligible factor for bandwidth savings. The real architectural differentiator is how the edge appliance handles state synchronization during link flapping without resetting sessions.

On your question about trade-offs, forgoing TLS inspection was a given. The more critical trade-off we documented was accepting lower-fidelity logs for the locally broken-out traffic. We got connection events, but deep packet inspection metadata was lost. This meant our SOC had to adjust their detection rules to rely more on netflow analysis and endpoint telemetry from those segments.

The transition lesson was to simulate failure modes for longer than you think. We ran a pilot for 90 days and only saw the crippling failure, where the appliance's local state table corrupted after 72 hours of sustained 30% packet loss, in the final week. That specific scenario wasn't in any vendor's test plan.

That last point about state table corruption under sustained packet loss is a nightmare scenario I've seen too, and it's rarely in the spec sheets. It's precisely why we now build our own "bad link" simulators for PoCs, replicating the exact jitter and loss patterns from the plant's historical ISP data.

You're absolutely right about the cache being oversold. The bandwidth saving narrative is a red herring for most OT data. Where I've seen caching add unexpected value wasn't for telemetry, but for the ancillary stuff like Windows Updates or vendor knowledge base portals that the engineers hit. It stopped a 2 GB patch download from killing the link for everyone else, which is a different kind of performance win.

The shift in SOC detection rules is the real, long-term cost. We had to get our security team to stop relying on those DPI logs for alerts and invest in better endpoint monitoring for the OT segments, which was a separate budget fight. It made the overall project more expensive, but it was the only sustainable path.

That "silent incident" you describe isn't a SASE vs isolation problem. It's a NAC and logging failure. If an unauthorized laptop was on the VLAN for weeks, your netflow data or even switch MAC tables would have shown the anomaly.

The issue is those logs were local-only and nobody was looking. SASE's central visibility only helps if your SOC is actually monitoring the feed. I've seen teams deploy this, route the logs, and then have zero alerts configured for new MAC or IP addresses on the OT segment because "it's all local traffic now." You get the management overhead without the detection benefit.

You've nailed the policy definition problem. The scramble for exceptions is a direct result of relying on network teams to document application dependencies without input from OT engineers and system vendors. We implemented a formal "dependency attestation" process before any policy was written, where each equipment vendor had to sign off on a matrix of their system's external connections for updates, telemetry, and remote support. It cut our initial exception requests by about 70%.

The granularity you mention is critical, but it's not just about listing IPs and ports. It's about defining the *behavioral* policy: "This SCADA server may connect to vendor-cloud-update.example.com for two hours every second Tuesday of the month." Without that temporal component, you either leave a permanent hole or break the update cycle.

Your point about "management traffic" being poorly defined is why we stopped using that term entirely. We now categorize traffic as "operational necessity," "business intelligence," or "administrative," each with its own policy rigor. A data historian pushing reports to corporate is different from a vendor performing remote PLC diagnostics, though both might be called "management."