Remote Access Security in 2026: Why Backhauling to a Data Center Is the Wrong Default

Remote access security has a location problem

Most remote access security setups protect the connection into your internal apps and then stop. The other ninety percent of a remote worker's day, the open web and the SaaS apps they live in, either runs unprotected or gets backhauled to a far-off data center for inspection. Here is the thesis, and it is testable: remote access security only works if the policy travels with the user, and the moment enforcement lives in a data center or on the office network, a laptop in a coffee shop is one routing decision away from no protection at all. The fix is web security that runs on the device. If your incumbent is Zscaler, the broader case is laid out in the complete guide to replacing Zscaler in 2026.

dope.security is the agent-based alternative built for distributed teams. The proxy runs on the endpoint, so the same policy applies in the office, at home, on hotel wifi, or on a plane. Nothing is steered anywhere. The security flies direct with the user.

That sounds obvious until you look at how legacy remote access security is actually wired. Most of it assumes the user will be funneled back to a chokepoint. Remote workers do not live at chokepoints.

The two halves of remote access nobody connects

Remote access security usually gets split into two products. One handles private app access, the Zscaler Private Access style tunnel into internal systems. The other handles internet and SaaS, the Zscaler Internet Access style proxy. We broke down that division in Zscaler ZIA versus ZPA. The private side usually gets the attention because it replaced the VPN. The internet side is where the real exposure lives, because that is where data leaves: uploads, AI prompts, personal accounts, file sharing.

When the internet side runs through a data center, two things happen. Latency goes up on every request, and protection depends entirely on the user's traffic being steered correctly. Drop the steering agent, hit a captive portal, or sit on a network that mishandles the tunnel, and the worker is browsing the open internet with nothing in front of them. The control existed. It just was not in the path at that moment.

Think about how often that happens in a normal week for a remote employee. They join airport wifi behind a captive portal, tether to a phone, connect from a relative's home network, or work from a hotel that throttles unfamiliar tunnels. Each of those is a moment where a backhaul-dependent model can quietly fall back to no inspection, and the worker has no idea. Security that only works under ideal network conditions is not security for a distributed team, it is security for the office the team no longer sits in. The whole reason remote access security exists is to cover the messy, unpredictable networks people actually use, and that is exactly where the steered model is weakest.

Why on-device enforcement changes the math

When the proxy lives on the endpoint, there is no steering step to fail. SSL inspection, URL filtering, Cloud Application Control, and Dopamine DLP all run locally on the device, so the policy is enforced before traffic leaves, every time, on any network. The City of Visalia made this exact move: a 700-plus user government workforce that had outgrown perimeter-based policies once employees went mobile. They chose on-device SSL decryption with no data-center backhaul so enforcement followed the user off-network. Read the City of Visalia customer story for how that played out.

This is the difference between a policy that is configured and a policy that is present. Backhauled models configure the rule centrally and hope the traffic shows up. On-device models carry the rule with the device. For remote access security, presence beats configuration every time, because remote workers spend their day outside the conditions the central model assumes.

Remote workforce requirements versus how each model handles them

Here is what a distributed team actually needs from remote access security, and how a backhaul model compares to an on-device one.

The takeaway: a distributed workforce needs protection that is present by default, not protection that depends on being routed correctly.

AI is the remote access exposure nobody scoped

The thing that makes remote access security urgent in 2026 is not the open web in general. It is AI. Remote workers reach for ChatGPT, Claude, and a dozen other tools all day, and the sensitive data that used to sit safely inside an internal app now gets pasted into a prompt or uploaded to a personal account. A tunnel into your private apps does nothing about this, because the AI tool is not a private app. It is the open internet, and that is exactly the traffic backhaul models treat as an afterthought.

dope.security handles this with three layers of AI governance that all run on the device. Shadow IT discovery shows which AI tools people are actually using and whether they are signing in with corporate or personal accounts. SWG policy decides what to block, warn, or allow. Cloud Application Control restricts access to your approved enterprise tenants only, so a user can reach the company ChatGPT workspace but not a personal one. Dopamine DLP then inspects what is being typed or uploaded and catches sensitive data before it leaves. You can see the model on the manage AI page. For a remote worker, all of that enforcement happens locally, which means it works on the home network and the hotel network exactly as it does in the office.

This is the part of remote access security that the VPN-plus-tunnel mental model never accounted for. The risk moved from the connection into your systems to the data leaving through the browser, and only an on-device control sits in the right place to catch it.

The cost and overhead case

Backhaul-based remote access security is expensive in two ways that do not show up on the headline per-seat price. The first is infrastructure dependency. You are paying for points of presence, egress, and the engineering time to keep steering configured correctly across a distributed fleet. The second is the operational tax: every tunnel, connector, and steering policy is something a lean IT team has to babysit, and remote workers generate support tickets every time the routing misbehaves on an unfamiliar network.

On-device enforcement collapses both. There is no point-of-presence footprint to pay for and no steering layer to maintain, because the proxy is already on the laptop. Policy changes push from the single console in seconds rather than waiting on a polling cycle. The ticket reduction is real and measurable: Outreach Health cut web access IT tickets 70 percent in 90 days after moving to the on-device model, and policy changes that used to take days dropped to minutes. For a distributed team without a large security operations group, that overhead difference is often the deciding factor, not the feature list.

The deployment story is the quiet advantage

Remote access security that takes months to roll out fails its own remote workers in the meantime. The lightweight agent uses under 100 MB of RAM and pushes through your existing MDM, whether that is Intune or Jamf. Outreach Health, a healthcare org with 34 offices across three states, secured 99 percent of devices within a week and cut web access IT tickets 70 percent in 90 days. Read how Outreach Health flies direct. That is the difference between a remote access security project and a remote access security deployment that is actually done.

For the broader stack design, our hybrid workforce security stack breakdown covers how on-device web security sits alongside identity and endpoint tooling without another tunnel to manage. If your current remote setup leans on Zscaler and the latency or steering overhead is the pain point, our piece on replacing Zscaler without backhaul walks through what changes when the proxy moves to the device, and endpoint SWG for distributed teams covers the rollout pattern in more detail.

Frequently asked questions

What is the best remote access security setup for a distributed team?

One where web security runs on the device rather than in a data center. On-device enforcement means the same SSL inspection, URL filtering, and DLP policy applies on any network, with no steering step to fail. dope.security delivers this as an agent-based Secure Web Gateway, which is why distributed teams use it to replace backhaul-based models.

Is a VPN enough for remote access security?

No. A VPN or private access tunnel protects the connection into internal apps, but it does not inspect the open web and SaaS traffic where most data movement now happens. You need web security that covers that traffic on the device, not just a tunnel into the data center.

Does remote access security have to add latency?

Only if you backhaul traffic to a data center for inspection. When the proxy runs on the endpoint, traffic goes direct to the internet and inspection happens locally, so there is no detour and no added hop. dope.security reports up to 4x performance over legacy proxy-based gateways.

Put the policy where the user is

To say it again in different words: remote access security breaks when protection depends on routing a remote worker's traffic back to a place it does not want to go. The control that survives is the one that lives on the device and travels with the user, on every network, with no tunnel to drop. Presence beats configuration, and for a workforce that spends its day outside the office, presence is the whole game. That is what dope.security does, and it is why distributed teams move off backhaul-based models. If you are weighing a switch from a backhaul incumbent, the complete guide to replacing Zscaler in 2026 lays out the migration. Then start a free instant trial and watch the policy follow your users instead of waiting for them to come back to a data center.