How to Onboard Zscaler: Every Scenario — Managed, Unmanaged & the ZIdentity Deadline

Picture two people on their first day. Sneha joins Infosys and is handed a company laptop. Priya is an external auditor at HDFC Bank who shows up with her own personal laptop and zero patience for installing software. Both need to work securely through Zscaler today — but the way you onboard them could not be more different.

Onboarding Zscaler is really the art of answering one question for every person: can I put my agent on this device, or not? That single fork decides everything — the access method, the security you can enforce, and even how the licence is counted. Let's build the whole map.

First, the vocabulary — tap to flip

Four terms show up in every Zscaler onboarding conversation. Learn these and the rest of the lesson reads easily.

Here's the whole architecture on one page. One cloud, two front doors — keep this picture in your head for the rest of the lesson.

① Scenario 1 — Managed laptops with the ZCC agent

This is the gold path, and it's the one Sneha runs at Infosys for 5,000 employees. A Zscaler Client Connector (ZCC) agent goes on every company laptop, the device proves it's trustworthy, and from then on all traffic is tunnelled and inspected.

ZCC forwards traffic using Z-Tunnel 2.0, which sends all ports and protocols over DTLS on UDP 443 (falling back to TLS on TCP 443 if UDP is blocked). The old Z-Tunnel 1.0 was proxy-style and only handled ports 80/443 — fine for web, useless for everything else.

Identity comes first. You wire your SAML identity provider (Okta or Microsoft Entra ID) for login, and SCIM to auto-provision users and groups. Then you build the policy in the Client Connector Portal: an App Profile and a Forwarding Profile, plus Device Posture profiles.

Here's the screen Sneha actually fills in — the App Profile and its Forwarding Profile for a managed Windows laptop.

With the policy ready, you push the agent silently with your MDM. The two parameters that matter most: CLOUDNAME (which Zscaler cloud you're on, e.g. zscalertwo) and — if you enforce strict mode — POLICYTOKEN. Here's a real Intune/SCCM command line for a managed Infosys laptop:

msiexec /i ZSAInstaller.msi ^
  CLOUDNAME=zscalertwo ^
  USERDOMAIN=infosys.com ^
  POLICYTOKEN=8f3c-strict-d21a ^
  INSTALLLWFDRIVER=1 LWFBOOTSTART=1 /qn

MSI (s) ... Installation completed successfully.
ZSATray service: Running
ZCC: awaiting user login (SAML)  ·  Cloud: zscalertwo
Z-Tunnel 2.0: connecting (DTLS udp/443)

When the user logs in, ZCC issues a device token and computes a unique device fingerprint. That fingerprint is the clever bit: copy the install to another machine and enrolment fails, because the fingerprint won't match. Finally the profiles and posture apply, and Z-Tunnel 2.0 comes up.

🏛 Architect note: on Windows, Zscaler recommends Tunnel (Packet Filter-Based); on macOS, Tunnel with Local Proxy. Keep DTLS primary but allow TLS fallback (needs ZCC 3.4+ on Windows, 3.9+ on macOS) so users behind UDP-hostile ISPs don't degrade.

② Scenario 2 — Unmanaged & BYOD devices (no ZCC)

Now Priya, the external HDFC auditor on her own laptop. She cannot install ZCC — it's not your device, and she'd refuse anyway. So she fails device posture by definition. The answer isn't "force the agent" — it's clientless access, and the destination app type picks the door.

For Priya's internal web app, the answer is Browser Access: you publish the app with a server certificate and a DNS CNAME, and she reaches it in her normal browser. For a server console (RDP/SSH/VNC) you'd use PRA. When the rule is "no sensitive data may touch the device", you wrap the session in Cloud Browser Isolation (CBI).

🔧 Engineer note: for BYOD that also needs SaaS, redirect the SaaS app's SSO to Zscaler so the session opens inside CBI with download/upload/copy/paste/print blocked — and apply different controls to BYOD vs corporate devices. The hosted PAC file is a last resort: it only proxies web/SaaS egress, gives no Z-Tunnel 2.0 and no posture, and a user can edit it out.

③ How many users? Licensing every scenario

This is the question every onboarding plan trips on. Zscaler licenses a Seat = one authenticated user, counted as unique users over a rolling 90-day window. Per person, never per device. Admin accounts don't consume end-user seats. Contractors who authenticate do count.

Let's run the four worked examples students get asked in interviews:

• Infosys — all managed (base case). 5,000 employees, each with a laptop and a phone on ZCC = 5,000 ZIA seats, not 10,000. The extra phones are free; same identity, one seat.
• TCS — employees + contractors. 8,000 staff on managed laptops + 1,500 occasional contractors + 200 admin accounts. = 8,000 full seats + 1,500 Light-User seats (contractors authenticate, so they count — but the cheaper Light tier fits) + 0 for admins.
• HDFC Bank — managed + BYOD. 12,000 employees on ZCC + 800 external auditors on unmanaged laptops via Browser Access & CBI = 12,800 seats. "No agent installed" ≠ "no licence" — the agentless user still consumes a per-user seat.
• Wipro — the multi-device trap. 3,000 employees averaging ~3 devices each. Per-device thinking says 9,000; the correct answer is 3,000 seats. Zscaler counts the person.

🏛 Architect note: if the rolling-90-day unique-user count exceeds your contract by >10%, Zscaler triggers a true-up — buy prorated seats or upgrade Light Users. Scrub stale identities (Reports → Users → last-login) before renewal so you don't over-buy, and negotiate the contractor/Light-User band up front.

④ The new requirement — the ZIdentity migration

Here's the onboarding most teams haven't noticed. In 2025–2026 Zscaler is retiring how admins log in and manage everything. Each product used to have its own console and its own local logins. That's being replaced by two linked things: ZIdentity (one centralized login, formerly ZSLogin) and the Experience Center (one unified admin console).

This is not optional. Three dates decide your 2026.

The trap that bites teams: only IdP-federated admin accounts migrate automatically. Any local admin account (credentials stored in the old portal) does not carry over — you must recreate it in your IdP first. Here's the migration screen, with the local account flagged.

The compliance steps, in order:

1. Inventory admin accounts — separate IdP-federated from local (portal-stored). Local ones won't migrate.
2. Connect your IdP to ZIdentity — SAML/OIDC SSO + SCIM provisioning from Okta/Entra/Ping.
3. Recreate the local admins in your IdP, then re-run migration so they're federated.
4. Plan MFA — ZIdentity has built-in MFA; decide whether to enforce at Zscaler or rely on the IdP.
5. Migrate admins first, validate console + MFA access in the Experience Center.
6. Then phase end users — remember the rollback window is only 14 days.
7. Finish before March 2026 to keep new features and stay ahead of the September 2026 legacy shutdown.

⑤ Field notes — the mistakes that page you at 2 a.m.

Onboarding rarely fails at "install" — it fails at the edges. Here are the four most common production bites, each with the symptom you'll actually see.

C:\> nslookup gateway.zscalertwo.net
C:\> curl -s https://ip.zscaler.com
# In ZCC: ⚙ → More → Export Logs ; tray → "Z-Tunnel 2.0 Connected"

ip.zscaler.com  →  Your request is arriving via the Zscaler cloud: zscalertwo
Location: Mumbai III  ·  Z-Tunnel 2.0: Connected (DTLS)
Portal → Enrolled Devices: this device = Authenticated ✓