Amar Jeer

SSE Architecture in 2026: The Two Ways to Run Security Service Edge (and Why On-Device Wins)

August 12, 2026

MIN READ

SSE Architecture in 2026: The Two Ways to Run Security Service Edge (and Why On-Device Wins)

The short answer

Every Security Service Edge (SSE) platform runs on one of two architectures. The first is cloud-backhaul: your traffic leaves the device, rides to a vendor data center for inspection, then continues to its destination. The second is on-device: inspection happens on the endpoint itself, and traffic goes straight to the internet. dope.security calls the second approach Fly Direct.

In 2026, on-device is the modern default. The cloud-backhaul model was a real upgrade over hauling branch traffic back to a headquarters firewall, but it was designed for a world of offices and network perimeters. Most people no longer work that way. They work on laptops, on home networks, in coffee shops, and on the road. Routing every one of those requests through a distant data center adds latency, cost, and privacy exposure that the on-device model simply removes.

This page explains both architectures in plain language, shows the trade-offs side by side, and links to a deeper explainer on each piece so you can decide which model fits how your people actually work.

Why architecture is the decision that matters

Most SSE buying guides compare features: whose CASB is deeper, whose DLP has more connectors, whose console has more dashboards. Those things matter. But they sit downstream of one choice that shapes everything else: where does inspection happen?

Where you inspect traffic decides your latency, your data-residency story, your operational weight, and whether the product keeps working when a user is far from a point of presence or sitting behind a national firewall. Two products with identical feature checklists behave completely differently if one inspects in a cloud node and the other inspects on the device.

So before you compare features, compare architectures. There are only two.

Architecture 1: cloud-backhaul (the proxy model)

This is the model Zscaler defined and most of the SSE market followed. Netskope, Palo Alto Prisma Access, Cloudflare One, Forcepoint ONE, Cato Networks, and Fortinet FortiSASE all use a version of it.

Here is how it works. An agent or tunnel on the device forwards the user's traffic to the vendor's nearest point of presence (PoP), sometimes called an enforcement node. That node decrypts TLS, applies your policy (URL filtering, malware scanning, DLP, CASB controls), re-encrypts, and sends the traffic on to its real destination. The response comes back the same way.

For a branch office that used to send traffic back to a corporate firewall, this was a genuine improvement. Inspection moved to a cloud that was closer and more scalable than an appliance in a closet.

The catch is the detour. Every request makes a stopover at the PoP before it reaches where it was going. When the user sits near a PoP, that stopover is small. When the user is far from one, or when the nearest PoP is congested, or when a network chokepoint like the Great Firewall sits in the path, the detour becomes the slowest part of the connection. You also decrypt corporate traffic inside a third party's cloud, which is a data-residency conversation every regulated team eventually has to have.

We break down the cost of that detour in the latency math of a cloud-proxy SWG, and why it breaks in restricted regions in why cloud-proxy SSE struggles in China.

Architecture 2: on-device (Fly Direct)

The on-device model asks a simple question: if the goal is to inspect the traffic, why move the traffic to the inspection instead of moving the inspection to the traffic?

dope.security runs a lightweight agent on the endpoint. The agent decrypts TLS locally, applies your policy on the device, and sends traffic straight to its destination. There is no enforcement node in the path. The Fly-Direct Secure Web Gateway does SSL inspection, URL filtering, anti-malware, Cloud Application Control, and AI-powered Dopamine DLP, all on the endpoint, managed from one cloud console.

Because inspection happens where the user is, the detour disappears. The agent runs in under 100 MB of RAM and delivers up to 4x the performance of legacy proxy SWGs. Because TLS is decrypted on the device, corporate data never transits a third-party cloud to be read, which is a cleaner data-residency story and one reason the model keeps working in places where backhaul-dependent vendors struggle.

For the technical detail of how endpoint inspection works, see on-device SWG: how endpoint-based web inspection actually works.

The two architectures, side by side

Dimension	Cloud-backhaul (proxy)	On-device (Fly Direct)
Where inspection happens	Vendor PoP / data center	On the endpoint
Traffic path	Device → PoP → destination	Device → destination
Latency off-network	Grows with distance from a PoP	No network detour added
TLS decryption location	Third-party cloud	Local device
Data residency	Corporate traffic transits vendor cloud	Data stays on device
Restricted regions (e.g. China)	Backhaul hop can fail	Keeps working, no remote hop
Operational model	Tunnels, PAC files, connector mesh	One agent via MDM
AI visibility	Depends on what routes through the proxy	Sees browser and thick-client AI traffic on device

The single choice in row one drives every row below it.

What each architecture means for AI governance

AI governance is where the architecture gap gets sharp, because AI traffic no longer lives only in the browser. People paste source code and customer data into ChatGPT and Claude desktop apps, run AI from IDEs and command-line tools, and hand tasks to autonomous agents. A model that only sees what routes through a browser or a cloud proxy misses a growing share of that activity.

On-device inspection sees AI traffic at the point where it leaves the machine, regardless of whether it came from a browser, a desktop client, or a script. dope.security layers three controls on top of that visibility: Shadow IT discovery to find what is in use, SWG policy to allow or block, and Cloud Application Control to restrict AI tools to your enterprise tenant and block personal logins. Dopamine DLP then inspects prompts and uploads on the device and classifies them with a large language model, not regex, so it blocks PII, PCI, PHI, and IP before they reach the AI provider. Dopamine DLP is covered by US Patent no. 12,464,023.

Why the endpoint is structurally better suited to this is worth its own read: browser extensions and cloud proxies can't see all shadow AI, on-device can.

Does on-device replace the cloud entirely?

No, and it is worth being precise. On-device means inspection runs on the endpoint. Management, policy, analytics, and cloud data-at-rest scanning still live in the cloud. dope.console is the single cloud management layer, and CASB Neural scans Microsoft 365 and Google tenants for exposed data at rest. The difference is that your users' live web traffic no longer takes a detour through someone else's data center to be inspected. The cloud runs the brains. The device runs the enforcement.

How to tell which architecture you actually need

Two questions settle it fast.

First, is your pain architectural or feature-level? If users say the internet feels slow, if remote and international staff suffer most, or if you would rather not send corporate traffic to a vendor cloud to be decrypted, that is an architecture problem. Only an on-device model removes the backhaul. Swapping one cloud proxy for another just relabels the detour.

Second, how central is AI to your risk? If your real 2026 exposure is data leaking into ChatGPT and Claude and agents acting on your data, you want AI DLP and tenant governance built into the inspection point, not bolted on through an add-on tier.

Proof it holds up at scale

On-device is not a lab idea. A Fortune 100 company runs the dope agent on more than 18,000 devices, scaling from 900 to 18,000-plus in a matter of weeks. Outreach Health secured 99% of its fleet within one week and cut web-access IT tickets 70% in 90 days. Greylock Partners moved off a legacy SSE and signed in 27 days. One Cisco Umbrella customer migrated 2,000 machines in two days. None of those rollouts required a forwarding architecture or a connector mesh, because there is nothing to route.

Go deeper on each piece

Frequently asked questions

What are the two SSE architectures? Cloud-backhaul and on-device. Cloud-backhaul routes traffic to a vendor point of presence for inspection, then on to its destination. On-device inspects traffic on the endpoint and sends it straight to the internet. The choice drives latency, privacy, and operational complexity.

Is on-device SSE better than a cloud proxy? For a laptop-first, hybrid, or international workforce, yes, because it removes the backhaul detour and keeps TLS decryption local. Cloud proxies still make sense for teams that want all enforcement to live in a network cloud, with the latency and data-residency trade-offs that come with it.

Does dope.security backhaul traffic? No. dope.security inspects on the device and routes traffic direct to its destination. There is no enforcement node in the path.

Which SSE architecture is best for AI governance? On-device, because it sees AI traffic from browsers, desktop apps, IDEs, and scripts at the point it leaves the machine, and can apply DLP and tenant controls there rather than only on what routes through a proxy.

See it on your own fleet

The fastest way to judge the two architectures is to run them side by side for a week and watch the latency and the AI activity. Start a free trial or book a 20-minute demo at dope.security.

SSE

Secure Web Gateway

Endpoint Security

← back to blog Home