Cloud-Backhaul vs Fly-Direct: The Two SSE Architectures, Explained

The short answer

Security Service Edge (SSE) runs on one of two architectures. Cloud-backhaul sends every user's traffic to a vendor data center for inspection, then forwards it on. Fly-direct inspects traffic on the device itself and sends it straight to its destination, with no detour. Both apply the same controls, secure web gateway, CASB, DLP, and AI governance. The difference is where inspection happens, and that single choice decides latency, privacy, operational weight, and how the product behaves for a distributed workforce.

In 2026, fly-direct is the modern default. Cloud-backhaul made sense when people worked in offices near a vendor point of presence. Most people no longer do, and routing their traffic to a distant data center just to inspect it has become the slowest, most expensive part of the stack.

The two architectures at a glance

Dimension	Cloud-backhaul	Fly-direct (on-device)
Where inspection happens	Vendor point of presence	On the endpoint
Traffic path	Device to PoP to destination	Device to destination
Latency added	The round trip to the PoP	None from a network hop
TLS decryption	In the vendor cloud	On the local device
Restricted regions	Backhaul hop can fail	No remote hop to fail
Deployment	Tunnels, PAC files, connectors	One agent via MDM

How cloud-backhaul works

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

The mechanics are consistent. 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 the TLS session, applies your policy, URL filtering, malware scanning, DLP, CASB controls, re-encrypts, and forwards the request to its real destination. The response returns the same way.

For a branch office that used to haul traffic back to a headquarters firewall, this was a genuine upgrade. Inspection moved to a cloud that was closer and more scalable than an appliance in a closet. The assumption underneath it, though, was that users sit near a PoP. That assumption held in 2015. It does not hold now.

The cost is the detour. Every request makes a stopover at the PoP before reaching where it was going. Near a PoP that stopover is small, roughly 40 to 80 ms. Far from one, through a congested node, or across a filtered path like the Great Firewall, it climbs to 150 to 400 ms and can fail outright. That tax lands on every request, all day, and it lands hardest on the remote and international staff you most need to keep productive.

How fly-direct works

Fly-direct asks a simpler 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 performs 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 already 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 fly-direct keeps working in restricted regions where backhaul-dependent vendors struggle.

Fly-direct does not mean no cloud. Management, policy, analytics, and cloud data-at-rest scanning still live in the cloud console. The cloud runs the brains. The device runs the enforcement on live traffic. That division is exactly what lets fly-direct be centrally managed and still avoid backhauling user traffic.

Why the architecture decides everything downstream

Most SSE buying guides compare features: whose CASB is deeper, whose DLP has more connectors, whose dashboard is prettier. Those things matter, but they sit downstream of the architecture choice. Two products with identical feature checklists behave completely differently if one inspects in a cloud node and the other inspects on the device.

Latency is set by architecture, not by bandwidth. Backhaul adds a detour to every request that no amount of bandwidth removes. Fly-direct adds none.

Privacy and data residency are set by where decryption happens. A cloud proxy holds your corporate plaintext in its infrastructure at the moment of inspection. Fly-direct keeps it on the endpoint.

Reliability in hard geographies is set by whether inspection depends on a remote hop. If it does, a national firewall can break it. If inspection runs on the device, there is nothing remote to break.

Operational weight is set by whether traffic has to be routed somewhere. Backhaul needs forwarding: tunnels, PAC files, connector meshes. Fly-direct needs an agent pushed through your MDM.

Why fly-direct is the modern default

Two forces flipped the default this year.

First, work is permanently distributed. The backhaul detour was tolerable when most users sat near a corporate PoP. It is not when your team is remote, traveling, and international. Routing a laptop in Singapore through a data center in New Jersey is the branch-office model applied to people who left the branch.

Second, AI changed what "sensitive data leaving" looks like. It is no longer only a file uploaded to a website. It is a prompt pasted into ChatGPT desktop, a code snippet sent from an IDE, an autonomous agent acting on company data. Catching that means inspecting at the point data leaves the machine, which is exactly what fly-direct does and what a browser-only or proxy-only model misses.

The proof is in deployments, not slideware. A Fortune 100 customer runs the fly-direct agent on more than 18,000 devices, scaling from 900 to 18,000-plus in weeks. Outreach Health secured 99% of its fleet in a week and cut web-access tickets 70%. Greylock Partners moved off a legacy SSE and signed in 27 days. None of them built a forwarding architecture, because fly-direct has nothing to route.

Where each still fits

To be fair to the incumbents: cloud-backhaul still suits teams that want every control to live in a network cloud and whose users cluster near points of presence, or that are locked deep into a single vendor ecosystem. If that is you, a cloud proxy is a reasonable choice, with the latency, privacy, and operational trade-offs noted above.

For everyone with a hybrid, remote, or international workforce, and for anyone whose real 2026 risk is data leaking into AI tools, fly-direct is the architecture that matches how people actually work. That is why it has become the default rather than the exception. For the full breakdown, see the SSE architecture guide, and for the swap paths, the best Zscaler alternatives and top Netskope alternatives.

Frequently asked questions

What are the two SSE architectures? Cloud-backhaul and fly-direct. Cloud-backhaul routes traffic to a vendor point of presence for inspection, then forwards it. Fly-direct inspects on the endpoint and sends traffic straight to its destination.

What does fly-direct mean? Fly-direct is dope.security's term for on-device SSE: inspection runs on the endpoint, so traffic flies straight to the internet instead of detouring through a vendor data center.

Is fly-direct better than cloud-backhaul? For hybrid, remote, and international workforces, yes, because it removes the backhaul latency, keeps TLS decryption local, and keeps working in restricted regions. Cloud-backhaul still fits teams that want all enforcement in a network cloud.

Does fly-direct still use the cloud? Yes, for management, policy push, analytics, and data-at-rest scanning. Only the inspection of live user traffic moves to the device.

Which architecture is better for AI governance? Fly-direct, because it sees AI traffic from browsers, desktop apps, IDEs, and scripts at the point it leaves the machine, rather than only 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.