Zscaler Deployment: The Complete Guide to Architecture, Rollout, and Migration

At a glance

A Zscaler deployment is not a single installation step. It is a sequence of decisions that build on each other. Identity comes first, because every later rule references users and groups. Next comes the choice of forwarding method for each site and user type, then the distribution of Zscaler Client Connector to endpoints through Intune or Jamf, the connection of internal applications through App Connector in AWS or Azure, a phased rollout across growing user groups, and finally measurement with Zscaler Digital Experience (ZDX). Organizations moving from an existing proxy follow the same architecture and additionally bring along the migration of their existing rule set. This guide walks through each of these stages individually, with citations to Zscaler's own documentation and a checklist at the end.

Who this guide is for

You are planning a Zscaler rollout in your organization, or preparing the next step of one: another site, another user group, a cloud environment that needs connecting, or a move away from an existing proxy. This guide is written for IT leadership, network and security teams, and project owners who want a solid foundation for their own planning, whether the implementation itself happens in-house or with a partner.

1. The building blocks and how they depend on each other

A Zscaler deployment is made of a small number of building blocks that build on each other in a specific order. Knowing that order avoids the most common mistake: a rule that references a group that does not yet exist in the identity service, or a client that sends traffic before any policy exists to handle it.

Identity. Zscaler Authentication Service (previously known as ZIdentity) connects to your external identity provider (IdP) through SAML or OIDC and automates user provisioning through SCIM. Every later rule in ZIA or ZPA references users or groups that come from this service. Without identity in place, the first rule has nothing to point to.

Endpoints. Zscaler Client Connector runs on laptops, smartphones, and tablets and forwards the device's traffic to the nearest Zscaler service, regardless of which network the device happens to be on. Distribution runs through your existing device management, typically Microsoft Intune or Jamf Pro.

Sites. For offices and data centers with a fixed connection, GRE or IPSec tunnels or a PAC file come into play, depending on what equipment is available and whether a static IP address exists.

Private applications. App Connector forms the bridge between internal applications and the Zscaler cloud, without those applications ever needing to be reachable from the internet. It runs in your own data center, in AWS, in Azure, or on several other supported platforms.

Enforcement. ZIA (Zscaler Internet Access) inspects and controls internet and SaaS traffic; ZPA (Zscaler Private Access) controls access to internal applications without a traditional VPN. Both evaluate the same identities and policies.

Measurement. ZDX (Zscaler Digital Experience) measures whether what you configured actually reaches the user the way it was intended, through device metrics, path measurement, and application measurement.

2. The fork in the road: deployment models compared

Zscaler supports several ways to forward traffic to the service. Most organizations use a combination rather than a single method, because different site and user types have different requirements. The table below matches each situation to the method that fits.

What this means for your decision: The choice is rarely binary. A typical deployment combines GRE or IPSec tunnels for fixed sites, Zscaler Client Connector for mobile devices, and a PAC file as a safety net for devices that do not (yet) carry a client. Zscaler explicitly recommends a combination of tunneling, PAC files, and Client Connector rather than relying on a single method for the entire organization.

PAC files in detail. A PAC file (proxy auto-configuration file) is a text file containing JavaScript logic that tells the browser when and where to forward traffic to a proxy. Zscaler hosts a default PAC file that uses geolocation to insert the nearest Zscaler location automatically; custom PAC files can also be uploaded. Because the file lives in the browser itself, it works independently of whichever network the user is on, which is what makes it a useful complement outside the corporate network, even where a tunnel or Client Connector is already in place.

Source: help.zscaler.com/zia/choosing-traffic-forwarding-methods, help.zscaler.com/zia/understanding-pac-file (both retrieved September 30, 2026).

3. Before you start: planning and inventory

The part of a deployment that saves the most time later is not a configuration step at all. It is a clean inventory done up front. Zscaler recommends capturing, before the first rollout phase, which operating system versions are in use, which browsers, which VPN clients, antivirus solutions, and firewalls are already running, how devices are managed, and which business-critical applications might be affected. This information determines which edge cases show up during the pilot and which exceptions are worth planning for from the start.

A second, often underestimated planning point: exceptions for your own authentication traffic. All traffic destined for your identity provider should go there directly rather than being inspected by Zscaler itself. That applies to SSL inspection exemptions as much as to authentication exemptions, regardless of whether the traffic runs through a PAC file, a GRE tunnel, an IPSec tunnel, or Client Connector. Miss this, and you get login problems that only trace back to a single cause after a frustrating delay.

A third point concerns interoperability with software you already run. If Zscaler Client Connector runs alongside a VPN client or a VPN-like application, a targeted interoperability test before the broad rollout begins is worth the time.

On policy strategy: according to a Zscaler-published customer account, a CTO who has led four Zscaler deployments recommends starting with simple, pragmatic global policies rather than full lockdown. Internet access started out as read-only by default, which eliminated the risk of data loss without breaking the user experience and sped up the rollout; individual allowances, for example for specific cloud services, were then added deliberately afterward. The same approach transfers regardless of organization size: a broad, understandable baseline first, tightened later based on real usage.

Source: help.zscaler.com/zscaler-client-connector/best-practices-zscaler-client-connector-deployment, help.zscaler.com/zscaler-deployments-operations/zscaler-client-connector-deployment-and-operations-guide (both retrieved September 30, 2026); customer account: zscaler.com/blogs/customer-stories/lessons-learned-four-zscaler-deployments-later, published September 3, 2024, retrieved September 30, 2026.

4. Identity first: SAML, SCIM, and moving your identity provider

Every rule in ZIA and ZPA ultimately points to a user or a group. That information does not originate inside Zscaler. It comes from your identity provider, connected through Zscaler Authentication Service. That is why identity is the first thing to settle in any deployment, not a side topic somewhere in the middle.

Two protocols, one recommendation. Authentication Service supports both OpenID Connect (OIDC) and SAML for authentication, along with SCIM for automated user provisioning. Zscaler recommends OIDC, particularly if you plan to use step-up authentication (an additional check triggered by higher-risk actions), because most identity providers only support that capability over OIDC. SAML remains the right choice where an OIDC integration is not available for your chosen identity provider.

SCIM over just-in-time provisioning. For provisioning itself, Zscaler recommends SCIM over just-in-time (JIT) provisioning. SCIM proactively synchronizes identities through an API, on a schedule or on demand. JIT, by contrast, only updates identities reactively, at the moment a user logs in, which means changes to group membership take effect with a delay, for example when someone leaves the organization.

One point that matters specifically if you plan to change identity providers: users and groups from the primary identity provider remain stored in Authentication Service even after the primary identity provider is removed. This is a deliberate design choice meant to make it easier to move the primary identity provider from one partner to another later, without having to rebuild the entire user and group structure from scratch.

Supported external identity providers, according to Zscaler's own documentation, with the protocol each supports: Microsoft Entra ID (OIDC through a gallery app, plus SAML), Okta (OIDC through an OIN app or a custom app, plus SAML), Microsoft AD FS (both protocols), PingOne (both protocols), Auth0 (both protocols), OneLogin (both protocols), PingFederate (both protocols). Authentication Service can also connect to any identity provider that follows a standard SAML, OIDC, or SCIM implementation, and supports up to 64 identity providers per organization, useful for managing separate user domains independently.

One operational point worth keeping in mind for later. The admin console shows a warning banner once a SAML certificate is within 90 days of expiring. Noting that date on a calendar avoids an unannounced login outage for the entire organization.

What this means for your decision: if you have multiple user groups with different requirements, for example a group under stricter compliance rules, a secondary identity provider connection for that specific domain is often a cleaner approach than piling exceptions onto your main rule set. If you already plan to change identity providers, perhaps as part of a broader IT consolidation, the timing of a Zscaler deployment is a natural point to do it, because the migration capability is already built in.

Source: help.zscaler.com/zidentity/about-external-identity-providers, retrieved September 30, 2026.

5. Endpoints: Windows through Intune, macOS through Jamf

Zscaler Client Connector itself does not require a separate license. Its use is already included in ZIA and ZPA licensing; the real work lies in distributing it to endpoints.

Windows through Intune, SCCM, or GPO. For Windows, an MSI installer package is available, suitable either for manual installation or for distribution through common device management tools that support MSI files, including Microsoft Intune, SCCM, and GPO. If you need install options beyond the default, for example strict enforcement of the client requirement, you create an MST transform file or run the MSI installation with command-line options instead. For Intune environments using Windows Autopilot, Zscaler provides a dedicated guide of its own.

macOS through Jamf Pro. For macOS, IT administrators first download the PKG installer package from the Zscaler Admin Console (Infrastructure, Common Resources, Deployment, Platform Releases) and then upload it to Jamf Pro, where a policy handles distribution to the intended devices. Beyond that, up to eight further optional configuration profiles are available: a custom settings profile, a certificate profile, traffic interception configuration, tunnel parameter configuration, a custom VPN profile for Private Access VPN with legacy applications, full disk access for endpoint DLP, managed login items, and a process-based application bypass.

macOS through Intune. If you manage macOS devices through Microsoft Intune instead of Jamf Pro, the pattern is the same: download the PKG file from the Admin Console, deploy it through the Intune admin center, then optionally layer on the same eight configuration profiles as needed. Windows and macOS end up distributed through different management tools, but follow the same basic flow: obtain the package, assign it, refine it if needed, and confirm it arrived.

What this means for your decision: the choice between Jamf Pro and Intune for macOS almost always comes down to whatever device management you already have, not to any Zscaler-specific advantage of one over the other. Running Jamf for macOS and Intune for Windows in parallel is normal and needs no new management layer. The eight optional macOS profiles are worth reviewing deliberately once: full disk access for endpoint DLP and the process-based application bypass are the two most often overlooked, and both turn into support tickets later if skipped.

Before you roll anything out: allowlist Zscaler Client Connector as a trusted process on the endpoint firewall and antivirus solution, and make sure your own corporate firewall permits communication to the Zscaler cloud. Both belong in preparation, not in troubleshooting afterward.

Source: help.zscaler.com/zscaler-client-connector/customizing-zscaler-client-connector-install-options-msi, help.zscaler.com/zscaler-client-connector/deploying-zscaler-client-connector-jamf-pro-macos, help.zscaler.com/zscaler-client-connector/deploying-zscaler-client-connector-microsoft-intune-macos, help.zscaler.com/zscaler-deployments-operations/zscaler-client-connector-deployment-and-operations-guide (all retrieved September 30, 2026).

6. Connecting private applications: App Connector in AWS and Azure

Internal applications that should never be reachable from the internet get connected to ZPA through App Connector. App Connector runs as a virtual instance as close as possible to the application itself, whether in your own data center, in AWS, in Azure, or on several other supported platforms, and establishes an outbound, authenticated connection to the Zscaler cloud. No network needs to be opened up from the outside for this to work.

The process is identical for AWS and Azure, according to Zscaler's own deployment guides for both platforms: first confirm the prerequisites are met, then deploy the App Connector on the chosen platform, then configure the networking for the deployed App Connector, and finally verify that it is running, healthy, and meeting your sizing requirements. Zscaler and AWS are independent technology partners; for AWS, additional platform-specific guides exist as well, for example on traffic forwarding and on integration with Amazon CloudWatch.

Sizing: how many App Connectors do you need? An App Connector with the recommended default specification reaches roughly 500 Mbps of throughput. With more resources, for example 8 virtual CPU cores (or 4 physical cores) and 8 GB of memory, throughput per App Connector can scale up to 1 Gbps. As a rule of thumb for a site connection with 1 Gbps of aggregate bandwidth, Zscaler recommends 2 to 3 App Connectors if double encryption is not in use, or 4 to 6 if double encryption is active. As a general principle, several smaller App Connectors are preferable to a few larger ones, because the failure of a single App Connector then affects fewer user sessions. On top of that, the N+1 principle applies for redundancy, meaning at least one additional App Connector beyond the raw capacity requirement.

Two practical points that are easy to miss. First, App Connector deployment requires a valid ZPA license (Professional, Business, or Transformation Edition). Second, the underlying operating system stays your own responsibility: Zscaler maintains the App Connector application itself, not the OS of the virtual instance beneath it. Plan patching of that instance as a recurring task of your own, separate from Zscaler's software updates to the App Connector.

After deployment. Once App Connector is running, two further steps follow: setting up application segments and access policies so that application traffic can actually pass (a simple test segment, for example allowing SSH access to the App Connector itself, works well as a first proof of function), and optionally configuring a log receiver to gather information about App Connectors or users through the Log Streaming Service.

What this means for your decision: the real question is rarely "AWS or Azure" but "where does the application actually run." App Connector follows the application, not the other way around. For a hybrid landscape with applications in both clouds and your own data center, a mixed deployment is the normal case, because each platform gets its own App Connector group placed close to the applications it serves.

Source: help.zscaler.com/zpa/connector-deployment-guide-amazon-web-services, help.zscaler.com/zpa/connector-deployment-guide-microsoft-azure, help.zscaler.com/zpa/connector-deployment-prerequisites, help.zscaler.com/zscaler-deployments-operations/app-connector-deployment-and-operations-guide, help.zscaler.com/zsdk/understanding-app-connector-throughput (all retrieved September 30, 2026).

7. Staged, not all at once: the phased rollout

The biggest mistake in a Zscaler deployment is rarely a wrong configuration setting. It is trying to move every user at once, before platform- and infrastructure-specific problems have had any chance to surface.

Zscaler's own recommendation follows four phases:

At every phase, Zscaler explicitly recommends testing on as many different computer configurations as possible, to discover and resolve issues across different device images and infrastructures before the full rollout begins. Choosing a homogeneous test group instead, for example only new laptops on a single standard image, simply pushes the real problems to a later, more expensive point in the project.

These four phases are the fine-grained mechanics inside a larger project frame. At the project level, the logic stays the same whether one site or forty are involved: take stock of what exists, define the target picture, run a single measurable pilot, move through the actual waves, then hand over into operations, with a deliberate decision point between the pilot and the waves. The four Zscaler phases above play out within that "waves" stage, once the decision to continue has already been made.

What this means for your decision: the exact group size can and should reflect the maturity of your own team, not just the Zscaler template. An organization with an experienced deployment team can run larger waves; a team running its first zero trust deployment is better served by smaller groups and more time between phases. What matters is less the precise number than the principle behind it: start with a small, manageable group, then a larger one, then the rest, with a genuine check after every stage rather than a formality.

Source: help.zscaler.com/zscaler-client-connector/best-practices-zscaler-client-connector-deployment, retrieved September 30, 2026.

8. Proof, not a gut feeling: measuring with ZDX

A configuration that looks correct on paper is not proof that it actually reaches the user the way it was intended. That is precisely the gap Zscaler Digital Experience (ZDX) closes.

How ZDX is built. Zscaler Client Connector, already installed on endpoints for other reasons, delivers additional device metrics once ZDX is enabled, at negligible extra resource cost. These metrics travel through what Zscaler calls a Telemetry and Policy Gateway to the ZDX cloud, which also connects to ZIA and ZPA to resolve users, departments, and locations. Analysis itself happens through a dedicated ZDX admin portal with role-based access control and single sign-on.

What ZDX measures. Beyond applications you define yourself, ZDX already covers a range of predefined applications out of the box, including Zoom, Box, Salesforce, ServiceNow, and several Microsoft 365 services such as Teams, SharePoint Online, OneDrive for Business, and Outlook. Evaluating call quality, for example in Microsoft Teams or Zoom, requires additional customer-specific onboarding, because ZDX needs access to the respective provider's own interface for that.

Why this belongs in a rollout guide, not just in later operations. During the rollout phases from Section 7, ZDX answers a question that otherwise only surfaces through support tickets: is a reported slowdown actually caused by the new configuration, by the Wi-Fi at that particular site, by the user's own internet connection, or by the target application itself? Turning ZDX on only after the rollout is already complete means giving up exactly the data that would have been most valuable during the most critical phase.

What this means for your decision: ZDX pays off most when it is activated alongside the actual rollout, not as a follow-up step. For organizations with heavy Microsoft 365 or video conferencing use, the predefined coverage of those services alone delivers concrete, measurable value with very little extra configuration.

Source: help.zscaler.com/zdx/understanding-zdx-cloud-architecture, retrieved September 30, 2026.

9. From an existing proxy to Zscaler

Many organizations do not arrive at this deployment on a blank slate. They bring an established proxy infrastructure, often a traditional secure web gateway appliance. Technically, that changes little about the architecture described in Sections 1 through 8: identity, forwarding methods, Client Connector, and App Connector work the same way regardless of what was in place before. What is genuinely new is migrating the existing rule set itself.

Zscaler publishes migration material specifically for organizations moving off a legacy appliance and positions itself as a cloud-based alternative to appliance-based secure web gateway products, for example for customers moving from Symantec or Blue Coat products. This guide deliberately does not carry over any judgment about the previous vendor from that material. The prior vendor did its job at the time, and a switch is, first and foremost, a technical project like any other.

Three practical recommendations for migrating the rule set, applicable regardless of which vendor you are moving from:

1. Review the existing rule set before carrying it over. A rule set that has grown over years typically contains entries for projects that no longer exist and exceptions whose original reason nobody remembers anymore. Copying that unreviewed into the new environment simply rebuilds the old clutter in a new syntax.
2. Start with a simple baseline rather than a full replica. As described in Section 3, the approach that tends to work well in practice is to start with a small number of clear, global policies and tighten them deliberately from there, rather than trying to reproduce every rule of the old system one-to-one from day one.
3. Settle authentication first, then categories, then exceptions. This follows the same logic as the identity-first principle from Section 4: a working login is the precondition for testing everything else cleanly in the first place.

A special case: identity moves along with everything else. If the proxy switch coincides with a change or consolidation of your identity provider, the migration capability from Section 4 applies as well: users and groups remain stored in Authentication Service even after the original identity provider is eventually retired.

What this means for your decision: plan the rule set migration as its own milestone with its own time estimate, separate from the pure infrastructure switch. Experience from comparable projects consistently shows the same pattern: the tunnel tends to be up and running well before the rule set has been properly carried over.

Source: zscaler.com/resources/solution-briefs/replace-symantec-with-a-cloud-based-solution.pdf (Zscaler's own positioning as an alternative to appliance-based secure web gateways, 2021, retrieved September 30, 2026); Sections 3 and 4 of this guide for the transferred principles.

10. Common pitfalls

A few points from the previous sections cost real time when they surface after the fact rather than being planned for in advance:

• Identities that land too late. A rule referencing a group that does not yet exist in Authentication Service points at nothing, with no obvious error message.
• Authentication traffic accidentally inspected. Without the SSL and authentication exemption for the IdP, this shows up as an intermittent login problem, hard to trace to a single cause.
• A test group that is too uniform. Testing only on identical, new devices means older OS versions, unusual VPN combinations, or nonstandard antivirus setups only surface once the broad rollout is underway.
• Underestimated App Connector redundancy. One heavily sized App Connector looks efficient, but concentrates far more sessions on a single point of failure than several smaller ones.
• Forgotten OS maintenance for the App Connector instance. Zscaler maintains the application, not the instance beneath it; patching in AWS or Azure is easy to overlook.
• ZDX turned on only after the rollout. That leaves the phase with the most support requests without solid measurement data.
• The old rule set carried over unreviewed. A working migration is a deliberate decision made rule by rule, not a copy.

11. After go-live: operations

The last rollout step ends the project, but not the task. Identity, endpoints, sites, private applications, and ZDX measurement now run day to day, facing the same questions as before: is a reported issue actually Zscaler, or the Wi-Fi? Are ZIA and ZPA policies still current, or have exceptions piled up since the rollout? Is every App Connector still running at the capacity you expect?

This is exactly the day-to-day work SourcingBlox built CentaurNexus for: our own cockpit that brings ZIA, ZPA, and ZDX together in one interface. If you still have to switch between several Zscaler consoles after go-live just to answer a single question about a user, you lose exactly the speed a clean rollout was supposed to deliver. CentaurNexus is the optimal complement to your Zscaler security stack: a searchable history of policy changes with four-eyes approval, a tool that surfaces unused or conflicting rules, a way to roll back individual configuration changes with precision, and a running status overview of your own App Connectors. Hosted in the EU, GDPR-compliant.

This section stays deliberately short. If you would like to know more about operating Zscaler after the rollout, with or without CentaurNexus, reach out to us.

12. Checklist

Before you start

• Endpoint inventory complete: OS versions, browsers, VPN clients, antivirus, firewalls, device management
• Identity provider and protocol decided (OIDC preferred, SAML as the alternative)
• SCIM provisioning planned instead of just-in-time
• SSL and authentication exemptions defined for the identity provider
• Forwarding method decided per site and user type (GRE, IPSec, PAC file, Client Connector, Cloud Connector, Branch Connector)
• If moving from an existing proxy: rule set reviewed, not carried over unreviewed

For endpoints

• Distribution path for Windows decided (Intune, SCCM, or GPO through MSI)
• Distribution path for macOS decided (Jamf Pro or Intune through PKG)
• Relevant optional macOS configuration profiles reviewed, especially full disk access for endpoint DLP
• Client Connector allowlisted as a trusted process on firewall and antivirus

For private applications

• Target platform clarified per application (own data center, AWS, Azure, others)
• ZPA license in place (Professional, Business, or Transformation Edition)
• App Connector sizing calculated against expected bandwidth, including N+1 redundancy
• Responsibility for operating system maintenance of the App Connector instance assigned

For the rollout

• Four phases planned: IT test, expanded IT test, end user pilot group, remaining users in waves
• Test group deliberately made heterogeneous, not just identical devices
• Decision point after the pilot defined: continue or adjust
• ZDX activated alongside the rollout, not only afterward

For operations afterward

• Ownership assigned for rule maintenance, exceptions, and certificate renewal
• Reminder set up for the 90-day SAML certificate expiry warning
• Decision made on how the day-to-day view across ZIA, ZPA, and ZDX will be organized

FAQ

What is the difference between a GRE tunnel, an IPSec tunnel, and a PAC file? GRE and IPSec connect a fixed site to the Zscaler service at the network level. GRE needs a static IP address and GRE-capable equipment and, in exchange, carries the lowest processing overhead. IPSec works without a static IP address but needs more processing power. A PAC file, by contrast, operates inside the browser on the individual device, so it works regardless of which network the user is currently on.

Does identity have to be fully in place before the rollout starts? Yes, at least for the part of the organization being rolled out in that phase. Every rule in ZIA and ZPA references users or groups from the connected identity provider. Without identity in place, no rule can be meaningfully tested.

How many App Connectors do we need in AWS or Azure? That depends on the bandwidth you need and the redundancy you want. An App Connector with default specifications delivers around 500 Mbps, and up to 1 Gbps with more resources. For a connection with 1 Gbps of aggregate bandwidth, Zscaler recommends 2 to 3 App Connectors without double encryption, or 4 to 6 with double encryption active, plus at least one more for redundancy.

Can we move directly from an existing proxy, such as a legacy appliance, to Zscaler? Yes. The architecture does not change, regardless of the previous vendor. On top of the infrastructure switch comes migrating the existing rule set, for which a deliberate review and a gradual build-up from a simple baseline tend to work well.

What is different about Client Connector distribution between Windows and macOS? Windows uses an MSI installer that can be distributed through Intune, SCCM, or GPO, with an optional MST file for additional install options. macOS uses a PKG installer, distributed through Jamf Pro or Intune, with up to eight optional configuration profiles covering certificates, traffic interception, tunnel parameters, and other details.

Does Zscaler Client Connector require its own license? No. Use of Zscaler Client Connector is already included in ZIA and ZPA licensing.

How long does a full Zscaler deployment take? That depends on the size of the organization, the number of sites, and the scope of rules to migrate, so no honest general number exists. The phased rollout itself follows the four phases in this guide, at a pace matched to your own team's maturity.

What does Zscaler Digital Experience (ZDX) do during the rollout? ZDX measures whether the configuration actually reaches the user the way it was intended, through device metrics, path measurement, and application measurement. Activated alongside the rollout, it helps trace reported issues to a cause quickly instead of investigating them only after the fact.

SourcingBlox as your Zscaler partner

SourcingBlox is an official Zscaler partner and looks after more than 100,000 users across Zscaler environments. This guide summarizes what Zscaler's own documentation publicly describes about architecture, rollout, and migration. If you are planning your own deployment and want support along the way, from the first inventory through to handover into operations, get in touch.

Zscaler, ZIA, ZPA, ZDX, and Zscaler Client Connector are trademarks of Zscaler, Inc. Microsoft, Intune, and Azure are trademarks of Microsoft Corporation. Jamf is a trademark of Jamf Software, LLC. Apple and macOS are trademarks of Apple Inc. Amazon Web Services and AWS are trademarks of Amazon.com, Inc. Symantec and Blue Coat are trademarks of Broadcom Inc. SourcingBlox is not affiliated with, endorsed, or sponsored by these companies. All trademarks are the property of their respective owners.