SD-WAN security: why local breakout keeps getting sent back to a data center

Short answer: SD-WAN was bought to break internet traffic out locally at each site instead of hauling it to a headquarters firewall. Almost every SD-WAN security design then sends that same traffic to a cloud proxy point of presence and back, which reintroduces the detour SD-WAN was purchased to remove. dope.security fixes it the other way around: inspection runs on the device with our Fly Direct architecture, so branches, home offices and travelers all get full SSL inspection, URL filtering, CASB and DLP without a network hop in the middle.

SD-WAN sold one very good idea. Stop paying for MPLS circuits that drag every branch packet back to a central data center, put a cheap broadband link at each site, and let internet-bound traffic go straight out. That is local breakout, and it worked. Latency dropped, bandwidth got cheaper, and Office 365 stopped feeling like a punishment.

Then the security question arrived. If traffic no longer passes the headquarters firewall, what inspects it? The industry answer was SASE: keep the local breakout, but tunnel that broken-out traffic to the vendor's nearest cloud point of presence for inspection. Read that sentence again. You paid to stop backhauling to your data center, and the fix was to backhaul to somebody else's. If you are already comparing your options, our guide to the best Zscaler alternatives walks through what happens to branch latency when inspection lives in a PoP rather than on the endpoint.

This post is about the gap between those two facts, and what SD-WAN security looks like if you refuse to pay the detour twice.

What SD-WAN security actually has to cover

SD-WAN is a routing and transport technology. It picks paths, steers application traffic across links, fails over when a circuit degrades, and applies quality of service. None of that is security. An SD-WAN edge device typically brings a stateful firewall, some IPsec, and basic URL category blocking. That is a 2010 control set applied to a 2026 traffic mix.

The list of things it does not cover on its own is longer than the list it does:

• Encrypted traffic: roughly 95% of web traffic is encrypted, so any control that cannot decrypt is reading envelopes, not letters. Category blocking on a hostname tells you a user reached a domain. It cannot tell you what they uploaded there.
• SaaS tenant control: a branch firewall sees traffic to a domain. It cannot separate your corporate Microsoft 365 or ChatGPT workspace from an employee's personal account on that same domain, because the difference lives in an HTTP header inside the TLS session.
• Data in motion: a file upload and a pasted AI prompt look identical to a router. Both are POST bodies over 443.
• Anyone not at a branch: this is the big one. The SD-WAN edge protects the site. Most of your people are not at the site.

That last point deserves its own section, because it quietly invalidates the whole design.

Your SD-WAN protects the place your users left

A branch appliance can only inspect traffic that crosses the branch. Hybrid work broke that assumption permanently. A laptop at a kitchen table, in a hotel, on airport wifi or in a customer's office never touches the SD-WAN edge. It is doing exactly what the branch does, breaking out locally to the internet, with none of the inspection.

Teams patch this with a client VPN that pulls remote users back to a site, or with an agent that tunnels them to a cloud PoP. Both are the same move: recreate a network chokepoint because the control lives in the network. Our breakdown of what backhauling actually costs covers the arithmetic, and it does not get better when the user is far from the chokepoint.

The honest framing is this. SD-WAN security is not a branch problem that spilled over to remote workers. It is a device problem that used to be small enough to solve at the branch.

The detour you paid twice for

Here is the sequence most organizations actually run. MPLS backhaul was expensive and slow, so SD-WAN replaced it with local breakout. Local breakout removed inspection, so a cloud SSE tunnel restored inspection by sending traffic to a PoP. The PoP is a network detour. You are now paying, in milliseconds, for the thing you replaced.

The numbers are not exotic. Measured cloud-proxy latency runs roughly 40 to 80 ms when a user sits near a point of presence, and 150 to 400 ms when they do not (ThousandEyes and vendor documentation). Netskope's own SLA is a useful, documented example of how decryption changes the math: under 10 ms for non-decrypted traffic, 50 ms for decrypted, a five times penalty for the inspection you actually want. Zscaler forwards all traffic to a ZEN or Service Edge node, and Gartner has cited a 10 to 20% throughput drop as modules stack.

Multiply by round trips. A single enterprise SaaS page load chains twenty or more requests. A 60 ms detour per request is not 60 ms of pain, it is well over a second, on every page, for every user at every site you just gave a fast local circuit to.

Want the number for your own network rather than ours? The Fly-Direct Speed Test measures your real round-trip latency in the browser and shows what a PoP detour would add per application. See how Fly Direct inspection works on the device, or book a 20-minute demo and we will run it against your environment.

Takeaway: local breakout only pays off if inspection does not send the traffic somewhere else first.

How the SD-WAN plus cloud proxy model compares to on-device inspection

There are three realistic architectures for securing an SD-WAN estate. Here is what each one actually does, without the diagram.

Branch appliance only

You inspect at the SD-WAN edge with whatever the edge device supports. It is simple and there is no extra hop for on-site users. It also cannot do meaningful SSL inspection at scale, cannot enforce SaaS tenant restrictions, and covers zero percent of your remote workforce. Policy lives in as many places as you have sites.

SD-WAN plus a cloud proxy or SSE tunnel

Every site tunnels internet-bound traffic to the vendor's nearest PoP, and remote users run an agent that does the same. You get consistent policy and real inspection. You also get the detour back, a cloud control plane you do not operate, and a licensing structure where the AI and data-protection pieces usually sit in a higher tier. Zscaler gates prompt DLP behind its Data Protection add-on and licenses AI Guard and AI Scanning separately. Netskope's AI Guardrails, which are genuinely strong, ship in the higher Max Advantage tier with CASB API as a separate SKU. Palo Alto's AI Access Security needs AI Access-X or CASB-X stacked with Enterprise DLP. Cisco's own documentation (doc 225162) is explicit that allowing a private ChatGPT workspace while blocking others requires the intelligent proxy, SSL decryption and a root certificate, so the DNS-layer base tier structurally cannot do it.

SD-WAN plus on-device inspection (dope.security)

The SD-WAN keeps doing what it is good at: routing and link selection. Security moves to the endpoint. The dope.endpoint agent performs SSL inspection, URL filtering, Cloud Application Control and Dopamine DLP locally, then the request flies direct to its destination. There is no PoP, so there is no detour, and the policy is identical whether the laptop is behind the SD-WAN edge, on hotel wifi, or in a country where your proxy vendor sells connectivity as a paid uplift.

Put side by side, the differences are concrete rather than philosophical:

• Path: a cloud proxy sends every request to a PoP and back before it reaches the internet; dope.security inspects on the device and the request goes straight out.
• Coverage: a branch appliance protects traffic that crosses the branch; dope.security protects the device, so the branch, the home and the airport are the same policy.
• Encrypted inspection: legacy proxies terminate TLS in shared multi-tenant infrastructure and maintain bypass lists for cert-pinned apps; dope.security terminates on the endpoint and surfaces SSL errors so admins create bypasses in a few clicks instead of guessing.
• AI control: tenant-aware AI governance is typically an add-on SKU or a higher tier on cloud platforms; dope.security ships Shadow IT discovery, SWG policy and CAC tenant restriction natively in one console.
• Failure mode: when a cloud control plane degrades, customers report losing dashboards and logs mid-incident; dope.security runs a fallback mode with cached policies on the device.
• Footprint: heavy agents are a recurring complaint on legacy platforms, including vendor-confirmed macOS battery drain on GlobalProtect; the dope agent runs under 100 MB of RAM.

The cloud vendors named here all score well overall, and none of the above is a claim that they cannot inspect traffic. The claim is narrower and testable: their architecture requires a network hop that SD-WAN was bought to eliminate.

What to actually do with an SD-WAN you already own

Nobody is ripping out SD-WAN. The useful question is which layer owns which job.

Let the SD-WAN own transport. Path selection, link failover, application steering, QoS for voice and video, and site-to-site connectivity are real value and the edge device does them well. Stop asking it to be a security stack.

Move inspection to the device. Every control that needs to read inside TLS, attribute traffic to a process, or tell a corporate SaaS tenant from a personal one belongs where the session starts. That is the endpoint. Our comparison of on-device versus cloud-proxy SSL inspection covers why the position of the decrypt point changes what is possible, not just what is fast.

Then delete the tunnel you no longer need. This is where the SD-WAN investment finally pays out. If inspection happens locally, internet-bound branch traffic can break out at the branch and stay broken out. The SD-WAN circuit does the job you bought it for.

For teams weighing where SSE fits alongside SD-WAN more broadly, our SASE versus SSE architecture explainer is the map, and the cloud proxy latency math is the receipt.

Does this hold up at real scale?

Deployment lift is the fair objection. Putting a control on thousands of endpoints sounds harder than turning on a tunnel at forty sites.

It has not played out that way. A Fortune 100 customer scaled from 900 devices to over 18,000 in a matter of weeks, averaging roughly 3,000 devices per week, deployed silently through Intune with no pre-install customization. A healthcare organization with 34 offices across Texas, Arizona and Massachusetts secured 99% of devices inside one week and saw a 70% reduction in web access tickets over the following 90 days. Greylock Partners moved off Cisco Umbrella and went from first proposal to signed contract in 27 days, specifically because DNS-only filtering missed HTTPS traffic and the SWG component still backhauled through Cisco data centers.

The pattern is consistent. Agent rollout is an MDM push. Tunnel rollout is a network project.

The one test that settles it

If you want a single, unambiguous evaluation for any SD-WAN security design, use this one: allow your corporate ChatGPT workspace and block personal ChatGPT logins, on the same domain, for a user sitting in a hotel room.

DNS cannot do it, because it resolves a hostname and stops. A branch firewall cannot do it, because the user is not at the branch. A browser extension cannot do it, because the desktop app and the CLI never open the browser. A cloud proxy can do it, if you decrypt in the PoP, buy the right tier, and accept the detour. dope.security does it on the device by injecting the workspace header inside the decrypted session, with no PoP and no add-on SKU. That is also the cleanest way to see the difference between data at rest coverage with CASB Neural and data in motion coverage on the endpoint.

SD-WAN's whole premise was that the shortest path is the right path. On-device security is the same premise applied one layer up: if you are willing to send traffic straight to the internet, be willing to inspect it straight on the device. Local breakout only counts as local if nothing pulls the traffic back.

Ready to see it? Book a 20-minute demo and we will show full SSL inspection, tenant control and DLP running on a laptop with no data center in the path.

Frequently Asked Questions

Does SD-WAN replace a secure web gateway?

No. SD-WAN is transport technology: it selects paths, steers applications and fails over between links. A secure web gateway decrypts and inspects web traffic, enforces URL and application policy, controls SaaS tenants and applies DLP. Most SD-WAN edge devices offer a stateful firewall and basic category blocking, which is not the same thing. dope.security provides the SWG layer on the device so the SD-WAN can stay focused on routing.

What is local breakout and why does cloud SSE undermine it?

Local breakout means internet-bound traffic exits at the branch instead of being hauled to a central data center. Cloud SSE keeps the local circuit but tunnels that traffic to the vendor's nearest point of presence for inspection, which adds a detour to every request. dope.security inspects on the endpoint, so traffic breaks out locally and stays that way.

How much latency does a cloud proxy add to branch traffic?

Measured cloud-proxy latency is roughly 40 to 80 ms when users sit near a point of presence and 150 to 400 ms when they do not. Netskope's published SLA is a documented example of the decryption penalty: under 10 ms non-decrypted versus 50 ms decrypted. Because a typical enterprise SaaS page chains twenty or more requests, a per-request detour compounds into seconds of page load.

Can I secure remote workers with SD-WAN alone?

No. A branch appliance only inspects traffic that crosses the branch, and remote laptops never do. The common workarounds are a VPN back to a site or an agent that tunnels to a cloud PoP, both of which rebuild a network chokepoint. Because dope.security enforces policy on the device, the same policy applies at the branch, at home and on the road.

Do I need a separate add-on to govern AI tools in an SD-WAN estate?

On most cloud platforms, yes. Zscaler gates prompt DLP behind its Data Protection add-on and licenses AI Guard and AI Scanning separately, Netskope ships AI Guardrails in a higher tier with CASB API as a separate SKU, and Palo Alto requires AI Access-X or CASB-X stacked with Enterprise DLP. dope.security includes Shadow IT discovery, SWG policy and Cloud Application Control tenant restriction natively, with Dopamine DLP inspecting prompts and uploads on the device.

Does on-device inspection work in China and other restricted regions?

Yes, and without a paid uplift. Several cloud proxy vendors sell China connectivity as a premium add-on, and Cisco has no mainland China data center. Because dope.security inspects locally and the request goes direct to its destination, there is no dependency on reaching a foreign point of presence, which is exactly where proxy-based SSE tends to struggle.

Is deploying an agent to thousands of endpoints harder than turning on a tunnel?

In practice it has been faster. A Fortune 100 customer went from 900 to over 18,000 devices in weeks at roughly 3,000 per week via a silent Intune push, and a healthcare organization with 34 offices secured 99% of devices in one week. Agent rollout is an MDM task, while tunnel rollout is a network change at every site.