Why Zscaler Client Connector Is More Than an Agent.

Zero Trust Connectivity • ZCC • Endpoint Steering • Field Notes

The endpoint used to be where the access model could be renegotiated. That is the thing this agent actually takes back.

1. Yes, it is another agent

Zscaler Client Connector usually gets introduced with a sentence that makes every endpoint team slightly nervous.

“We need to deploy an agent.”

That reaction is fair. Every new agent means packaging, deployment, testing, compatibility checks, support procedures, upgrade planning, user communication, troubleshooting, and at least one person asking whether the laptop is slow because of that new thing IT installed.

So yes, it is another component. But “is there an agent?” is the wrong thing to measure, and this article is an argument for measuring something else: where the access logic lives, and who is allowed to change it.

Because before this kind of client existed, the answer to both questions was uncomfortable. The logic lived in a dozen places on the endpoint, and the endpoint could change most of them.

Scope: this article is about the operating model. How traffic is actually forwarded — forwarding profiles, app profiles, tunnel versions, bypasses and DNS handling — is covered in detail in Z-Tunnel 2.0: Sending Everything to Zscaler Is the Easy Part. Where the two overlap, that one goes deeper.

Part one

The world before

2. When a user in Milan was still spiritually browsing from Rome

About twelve years ago, when I started working with web protection and UTM platforms, most of the customers I followed were multi-site organizations.

And by multi-site, I do not mean a clean architecture diagram with elegant arrows and a smiling cloud in the middle. I mean branches, appliances, local internet breakouts, proxy settings, DNS names, load balancers, GPOs, logon scripts, and a silent prayer every time somebody changed office.

In many environments, each site had a pair of appliances doing almost everything: firewalling, mail inspection, antivirus scanning, web protection, and what we would now call cloud application control, although at the time that was a very creative interpretation of the concept.

Each site had its own appliance pair. Each pair had its own FQDN. Each FQDN pointed to a load balancer in front of those appliances.

15 sites. 30 appliances. 30 FQDNs. 30 reasons to update documentation nobody trusted anymore.

Beautiful, if you enjoy spreadsheets more than sunlight.

Proxy configuration was usually pushed to Windows system settings through Group Policy. In less fortunate environments it went through logon scripts and VBS files, because somebody had decided that user logon was the right moment to perform network architecture.

A user whose device is configured for one office continuing to send traffic back to that office after travelling to another site, because the configuration was bound to the location rather than to the person — Figure 1. The visited site has a perfectly good local breakout sitting there, unused, because the device does not know it exists. Original diagram — Zero Trust Navigator.

The result was predictable. A user from Rome, in the Rome organizational unit, who travelled to Milan, would still browse the internet through the Rome proxy path.

Technically, the configuration was working. Emotionally, the user was not.

Static configuration assumes people stay where they were when it was written. People, inconveniently, move.

3. Proxy archaeology

If you have ever migrated away from an on-premises proxy, you already know where the configuration was.

Everywhere.

The many places proxy configuration used to live on a Windows endpoint, none of which was the single source of truth — Figure 2. Nine places a proxy setting could live, each capable of carrying a different answer, and no way to establish which one was winning. Original diagram — Zero Trust Navigator.

Microsoft documents that Windows can be configured to use proxy servers through automatic discovery, manual configuration, Group Policy and PAC files. It also notes that some applications may not obtain proxy settings from system settings at all, and may need their own configuration. Source: Microsoft Learn.

Browsers add another layer. Chrome and Edge both document their own proxy policies, with modes including direct, system, auto-detect, fixed server and PAC script, which means proxy behaviour can be decided at more than one level on the same machine. Source: Chrome Enterprise, Source: Microsoft Edge.

If the security model depends on every application politely reading the same setting, the model is already negotiating with the endpoint.

4. The endpoint had opinions

Reading a setting is one thing. Changing it is another, and the old endpoint could change a lot.

The levers available on an unmanaged endpoint that allow the access model to be rewritten locally, from proxy settings and PAC files to DNS servers, the hosts file and a second tunnel — Figure 3. Eight levers, none of which require an attacker. A determined user with local rights and an afternoon is enough. Original diagram — Zero Trust Navigator.

Change the proxy setting. Use a browser with its own policy. Point at a different PAC file. And then it gets more interesting, because name resolution is its own surface.

Windows lets administrators configure DNS server addresses on network interfaces through supported system tools and PowerShell. Source: Microsoft Learn, netsh dnsclient. The hosts file is the classic example: Windows consults it during name resolution, and editing it requires administrative rights precisely because it can redirect resolution for the whole system.

And then there are tunnels. Windows supports VPN profiles with routing, split tunnel, forced tunnel, proxy settings, name resolution, the name resolution policy table and always-on options. Source: Microsoft Learn, Windows VPN technical guide.

A second tunnel on the endpoint is not always a backup path. Sometimes it is a parallel universe.

None of this is theoretical, and none of it requires malice. It is what happens when the access model is expressed as a collection of local settings on a machine somebody else controls. The security architecture ends up being whatever the endpoint decided it was that morning.

Part two

What changes

5. One client, several outcomes

Client Connector is installed on the endpoint and connects the device to the Zero Trust Exchange. Zscaler describes it as a lightweight endpoint agent that enables secure access from any device or location and forwards traffic to the platform. Source: Zscaler Client Connector product page.

That description is accurate and slightly undersells the point. The reason it matters is not that it forwards traffic. It is that one endpoint component becomes the anchor for several capabilities that would otherwise each need their own.

One endpoint component supporting several platform services at once, from internet and private application access to experience monitoring, data protection and device posture — Figure 4. Every additional endpoint component adds friction. This one consolidates the friction rather than multiplying it. Original diagram — Zero Trust Navigator.

The question is not: Do we really need another agent? The question is: What becomes possible once this one is deployed correctly?

Which of those capabilities are actually available depends on licensing and configuration, and that conversation belongs with the account team rather than in an article. The architectural point stands regardless: the endpoint stops being a place where software is installed and becomes a managed part of the access architecture.

6. Forwarding stops being a setting and becomes a policy

In the legacy model, traffic forwarding was a browser or system setting. It said where traffic should go. It said nothing about whose traffic it was.

A static proxy setting says: Send traffic there. An enrolled client says: This traffic belongs to this user, from this device, under this policy.

That shift is the whole difference. Once the endpoint is enrolled, forwarding is expressed centrally rather than locally, and it can carry identity with it. Network context can be evaluated too, so behaviour changes according to where the device actually is rather than which organizational unit it was in when somebody wrote the policy.

That is what solves the user who moved to Milan. The user does not need to know which proxy to use. The user should not need to know that the building has an appliance pair at all. The endpoint receives policy and applies the right steering logic.

The user moves. The policy follows.

The how is a separate conversation. Which forwarding modes exist, which tunnel driver is required for Tunnel 2.0, how forwarding profiles differ from app profiles, how trusted network detection should be configured, and where bypasses belong — all of that is covered properly in Z-Tunnel 2.0: Sending Everything to Zscaler Is the Easy Part. It is the runbook to this article’s model.

What happens to the old proxy settings

System proxy settings do not vanish on migration day. They matter during the transition, when legacy applications still expect them, when old Group Policy objects or automatic discovery are still present and could conflict, and in enforcement scenarios where the organization wants to control what happens if the client is disabled or disconnected.

They are not the target architecture. They are part of the transition and the control story, and they are one of the first things worth auditing before anything is switched on.

Less proxy archaeology. More predictable policy. Fewer moments where the real security architecture is hiding inside a logon script from 2013.

7. Enrollment: where the device becomes known

When the client starts for the first time, it does not simply connect. It enrols, and the difference matters.

The enrollment sequence in which a newly installed client authenticates the user, registers the device, receives profiles and becomes entitled to services, rather than simply connecting — Figure 5. Six steps, and by the end of them the platform knows who is using this device, which device it is, and what both are entitled to. Original diagram — Zero Trust Navigator.

The client needs to understand the user domain, the identity provider, the services the user is entitled to, the profiles to download, the forwarding behaviour to apply, and the device registration context. For private access the sequence continues, so the client also learns which applications the user is allowed to reach.

This is where the agent stops being software on a laptop and becomes an identity-aware, device-aware, policy-aware access component.

And policy that does not refresh is not policy

It is nostalgia.

The client periodically refreshes what it knows about applications, profiles, PAC files, software status and policy, because endpoints are not static. Users close laptops. Users open laptops. Users move from office wireless to home wireless to hotel wireless to a mobile hotspot, and invent new ways to make “it worked yesterday” technically true and operationally useless.

Nobody should be chasing endpoint state manually. The endpoint has to participate in its own policy refresh.

8. Device posture: finishing the sentence

Zero trust is not only about identity. The user may be correct. The password may be correct. The second factor may be correct. The device may still be a disaster with a keyboard.

An access decision built on identity alone compared with one that also evaluates the device, presented as an incomplete sentence and a complete one — Figure 6. On the left, a sentence somebody forgot to finish. On the right, the same decision with the device included in it. Original diagram — Zero Trust Navigator.

Posture is how the endpoint joins the access decision: whether the device is managed, whether encryption is enabled, whether endpoint protection is running, whether the operating system is acceptable, whether this device should be allowed to reach this application at all.

Credentials travel. Managed devices do not.

A correct identity on an unhealthy device is not a complete zero trust decision. It is half an answer, and business applications should not be exposed on the strength of half an answer.

9. Tamper protection: because “please do not disable the agent” is not a control

This is the part that closes the loop with section four, and it is easy to underestimate.

Every lever in that figure was a way for the endpoint to rewrite the access model locally. Deploying a client that steers traffic centrally achieves nothing if the same user can log out of it, disable a service, or uninstall it on a difficult afternoon.

Tamper protection can require authorisation for sensitive actions: logging out, disabling internet or private access, stopping services, uninstalling the client, or changing protected behaviour.

Secure access is not only about where traffic goes. It is also about who is allowed to change how traffic is handled.

Field note: a global uninstall password has roughly the security charm of a shared spreadsheet called final_passwords_v3_reallyfinal.xlsx. Use controlled support processes, and per-device or one-time mechanisms where they are available. Your future incident response team will appreciate it.

10. What actually changes, operationally

The value here is not only security. Most of it is operational, and it is the part that gets the migration funded.

Where the access logic lives before and after a managed client: scattered across endpoint settings and site infrastructure, or held in centrally managed profiles that travel with the user — Figure 7. Six rows, and the one that changes the day job most is the last: troubleshooting stops being archaeology. Original diagram — Zero Trust Navigator.

The user moves and the policy follows. The security stack stops being a collection of local islands, each with its own personality and its own DNS record.

Infrastructure with personality is rarely a compliment.

Final thought: no more proxy archaeology

Client Connector is more than an agent because it changes where the access logic lives.

In the old world, endpoint forwarding was a fragile mix of proxy settings, local appliances, branch assumptions and scripts written in times of great optimism. The endpoint could read them inconsistently, and could rewrite most of them.

In the new model, the endpoint stops being the place where the access architecture is negotiated, and becomes the place where it is applied.

That does not remove the need for good design, or for testing, or for understanding DNS, PAC behaviour, browser authentication and exclusions. Those problems are still there and the next article in this series is about exactly that.

But the security path should no longer depend on a registry value, a forgotten policy object, or a VBS file nobody admits owning.

For how traffic is actually steered once the client is deployed, continue with Z-Tunnel 2.0: Sending Everything to Zscaler Is the Easy Part.