Is Your SSE Backhaul or Fly-Direct? How to Tell, and Why It Decides Everything

Is Your SSE Backhaul or Fly-Direct? How to Tell, and Why It Decides Everything

The short answer

Your SSE platform uses one of two architectures. Cloud-backhaul sends your traffic to a vendor point of presence to be inspected, then forwards it, so every request takes a detour. Fly-direct inspects on the device and sends traffic straight to its destination, with no detour. To tell which you have, ask one question: where does inspection happen? If your vendor talks about points of presence, PoPs, tunnels, PAC files, or forwarding, you are backhauling. If inspection runs in an agent on the endpoint, you are fly-direct.

It matters because that single architectural fact sets your latency, your privacy posture, your reliability in hard geographies, and how much your team spends keeping the thing running.

Five ways to tell which architecture you have

You do not need vendor cooperation to figure this out. Five signals give it away.

1. Ask where TLS is decrypted. If the answer is "at our nearest point of presence" or "in our cloud," that is backhaul. If it is "on the device," that is fly-direct. This is the cleanest single question.

2. Look at how traffic is steered. PAC files, GRE or IPsec tunnels, forwarding profiles, and connector meshes are all the plumbing of backhaul. Fly-direct has none of them, because there is nothing to steer traffic toward.

3. Watch remote and international users. If your office users are fine but remote, traveling, and overseas staff complain the internet feels slow, that pattern is the signature of a backhaul detour that scales with distance from a PoP.

4. Check behavior in restricted regions. If users in China or other filtered networks have connectivity that comes and goes, the tool is likely depending on a cross-border hop to a PoP. Fly-direct has no such dependency.

5. Count the consoles and the maintenance. Backhaul platforms often mean multiple modules and ongoing forwarding upkeep. Fly-direct is typically one agent and one console.

Why the architecture decides everything downstream

Feature checklists get most of the attention in an SSE evaluation, but they sit downstream of the architecture. Two products with identical features behave differently if one inspects in a cloud node and the other on the device.

Signal You are backhauling if... You are fly-direct if...
Inspection point A vendor PoP or data center An agent on the endpoint
Traffic steering PAC files, tunnels, connectors None
Remote-user speed Degrades with distance from a PoP Consistent everywhere
Data residency Decrypted in vendor cloud Decrypted on the device
AI visibility Proxy-routed traffic only Any app on the endpoint

Most of the market is backhaul: Zscaler, Netskope, Palo Alto Prisma Access, Cloudflare One, Forcepoint, Cato Networks, and Fortinet FortiSASE all inspect in a vendor cloud. dope.security is the fly-direct exception that inspects on the device. See the full field in secure web gateway vendors in 2026.

Which one is right for you

Be honest about your workforce and your risk, and the answer usually falls out.

Cloud-backhaul still fits teams whose users cluster near points of presence, who want every control to live in a network cloud, and who are committed deep into a single vendor ecosystem. If that describes you, a cloud proxy is defensible, with the latency, privacy, and maintenance trade-offs above.

Fly-direct fits hybrid, remote, and international workforces, teams that want corporate traffic inspected without sending it to a vendor cloud, organizations with users in restricted regions, and anyone whose real 2026 risk is data leaking into AI tools. For those situations, on-device inspection removes the backhaul detour and matches how people actually work. This is why fly-direct has become the modern default rather than a niche pick. See cloud-backhaul vs fly-direct for the full comparison.

How to evaluate the switch

If the signals point to backhaul and the pain is real, here is how to test fly-direct without a leap of faith.

  1. Run them side by side. Keep your incumbent live and deploy the fly-direct agent through your MDM in parallel. Watch latency and AI activity on real traffic for a week.
  2. Translate one policy set. Recreate your URL categories, allow and block lists, and DLP rules in one console. Because SWG, CASB, and DLP live together, you are not stitching policy across products.
  3. Test the hard users. Point the trial at your remote, international, and restricted-region staff, the people a backhaul detour hurts most, not just someone next to a PoP.
  4. Check the AI coverage. Confirm the tool sees AI traffic from desktop apps and scripts, not only the browser.
  5. Measure deployment effort. Note how much forwarding you had to build. With fly-direct the answer should be none.

Migrating off a cloud proxy is usually simpler than migrating between two, because you remove the forwarding layer rather than rebuild it. A Fortune 100 customer scaled to more than 18,000 devices in weeks, Outreach Health hit 99% in a week, and a Cisco Umbrella customer moved 2,000 machines in two days. See migrating off a cloud-proxy SSE.

Frequently asked questions

How do I know if my SSE is backhauling? Ask where TLS is decrypted. If it happens at a vendor point of presence or in the vendor cloud, and your setup uses PAC files, tunnels, or connectors, you are backhauling. If inspection runs in an agent on the device, you are fly-direct.

What is the difference between cloud-backhaul and fly-direct? Cloud-backhaul inspects traffic in a vendor data center, adding a detour to every request. Fly-direct inspects on the endpoint and sends traffic straight to its destination.

Which SSE vendors backhaul? Most, including Zscaler, Netskope, Palo Alto Prisma Access, Cloudflare, Forcepoint, and Fortinet. dope.security inspects on the device instead.

Is backhaul always bad? No. It suits teams whose users sit near points of presence and who want all enforcement in a network cloud. It becomes a liability for hybrid, remote, and international workforces.

How hard is it to switch to fly-direct? Usually easier than a cloud-to-cloud migration, because you remove the forwarding layer. You translate policy, push an agent through your MDM, run in parallel, and cut over, often in days to weeks.

See it in action

Not sure which architecture you are running? Run fly-direct next to your current SSE for a week and see the difference. Start a free trial or book a 20-minute demo at dope.security.

SSE
SSE
Comparisons & Alternatives
Comparisons & Alternatives
Secure Web Gateway
Secure Web Gateway
back to blog Home