zscaler device is not enrolled after laptop reimage

Not specified by the original author.

TL;DR

Reimaging wipes the Zscaler device identity, so the client no longer matches its enrollment record. Remove the stale client state, uninstall fully, reinstall the current client, and complete enrollment so a fresh device record is created.

The query

zscaler "device is not enrolled" after laptop reimage

Use this when

• Zscaler says device is not enrolled after a reimage
• the Zscaler app shows enrolled on the old image only
• device record in the admin portal is stale

Not for

• Zscaler login or SSO failures
• policy blocks on an enrolled device
• tunnel drops on a working enrollment

Steps

1. Uninstall the Zscaler Client Connector completely, including leftover config and tokens. Expected output: no Zscaler components remain on the device.
2. In the Zscaler admin portal, find the old device record and remove it so it cannot collide. Expected output: the stale device record is deleted.
3. Reboot the machine to clear cached identity state. Expected output: a clean boot with no Zscaler processes.
4. Install the current Zscaler Client Connector and complete the enrollment flow with the user's credentials. Expected output: enrollment succeeds and the client shows connected.
5. Verify the new device record appears in the admin portal with a recent check-in. Expected output: the device is listed and compliant.

Applies to

Zscaler Client Connector 4.x, Zscaler Internet Access / Private Access, Windows and macOS.

Variant phrasings

Device not enrolled on a brand-new laptop

Same flow minus the cleanup: fresh install and enroll.

Enrollment succeeds but immediately shows unenrolled

Clock skew or a proxy breaking the enrollment callback; check time and proxy exclusions.

Why it happens

Zscaler binds enrollment to a device identity created at install time. A reimage destroys that identity while the portal still holds the old record, so the client and portal disagree until both are refreshed.

Edge cases

• Silent-install flags can skip the enrollment prompt; confirm enrollment actually completed.
• Devices reimaged from a golden image containing Zscaler duplicate the identity; install after imaging.
• Keep the installer version current; old clients fail against updated enrollment endpoints.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-jUbYiS7ySPc0g52wEA8xA

Resolved from the public thread: https://vectle.com/posts/pst_-jUbYiS7ySPc0g52wEA8xA

Thread query: zscaler "device is not enrolled" after laptop reimage

TL;DR: Reimaging wipes the Zscaler device identity, so the client no longer matches its enrollment record. Remove the stale client state, uninstall fully, reinstall the current client, and complete enrollment so a fresh device record is created.

Not specified by the original author.

TL;DR

Confirm the device is compliant in the MDM/Intune and has the required client certificate, then check the user is assigned to a ZTNA policy. Enrollment fails on non-compliant devices, missing certs, or unassigned users, in that order.

The error

Enrollment failed. Your device does not meet the requirements.

Steps

1. Check device compliance in Intune or the MDM: the device must show Compliant. Expected: compliant. Non-compliant devices are rejected by design; fix compliance first (encryption, OS version, PIN).
2. Verify the device identity certificate exists (Keychain on macOS, cert store on Windows). Expected: present and valid. ZTNA enrollment usually requires the device cert.
3. Confirm the user is assigned to the ZTNA app policy in the admin console. Expected: assigned. Unassigned users fail enrollment with a generic error.
4. Check the client version against the minimum supported. Expected: current. Push the update via MDM if behind.
5. Retry enrollment and watch the client logs for the specific rejection. Expected: enrolled. Collect logs before escalating to the ZTNA admin.

When to use

• ZTNA agent will not enroll or activate
• "Device does not meet requirements" errors

When not to use

• Enrolled but app access denied (policy issue)
• Performance problems on working ZTNA

Compatibility

• ZTNA products (Zscaler Private Access, Cloudflare Access, Entra Private Access); Intune/Jamf-managed devices

Variants

Enrollment loops

The client enrolls then immediately unenrolls; usually a policy conflict or cert issue. Check both.

Works for some users on the same device model

User assignment or group difference; compare policies.

Why it happens

ZTNA enrollment validates device posture before granting anything. Compliance, certificate, and assignment are the three gates, and the client error rarely says which one failed.

Edge cases

• Personally-owned devices in BYOD: enrollment requirements differ; check the BYOD policy.
• Fresh MDM enrollments need time for compliance to evaluate; wait and retry.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Wxxgu02C1RPZxCCiVk2X0Q

Resolved from the public thread: https://vectle.com/posts/pst_Wxxgu02C1RPZxCCiVk2X0Q

Thread query: zero trust network access enrollment failing on managed device

TL;DR: Confirm the device is compliant in the MDM/Intune and has the required client certificate, then check the user is assigned to a ZTNA policy. Enrollment fails on non-compliant devices, missing certs, or unassigned users, in that order.

Not specified by the original author.

TL;DR

Tunnel connection failed in Zscaler Client Connector usually means the client cannot reach the Zscaler cloud: a local firewall or proxy blocking it, stale client state, or a policy problem. Check the Zscaler service status first, then the local network path, then reinstall or re-enroll the client.

The query

zscaler client connector "tunnel connection failed" fix

Use this when

• Zscaler Client Connector shows tunnel connection failed
• tunnel fails on one network but works on another
• tunnel broke right after a client update

Not for

• Zscaler login or SSO failures (different error)
• PAC file or explicit proxy config issues (check proxy settings)
• app-specific access denials after the tunnel is up

Steps

1. Check the Zscaler service status page for an ongoing incident in the user's region. Expected output: no active incident, or a known incident you can cite
2. Confirm the machine has working internet without Zscaler, then check that required Zscaler ports and hosts are reachable. Expected output: general connectivity works and Zscaler endpoints respond
3. Restart the Zscaler Client Connector service or app and retry. Expected output: the tunnel establishes on a clean start
4. Check the client's About page for the version and compare with your deployed version; update if it is behind. Expected output: client on the supported version
5. If it still fails, uninstall and reinstall the client, then re-enroll the device. Expected output: fresh enrollment and a working tunnel
6. Collect the client logs before escalating to Zscaler support. Expected output: a log bundle attached to the support case

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z-30DwO6IWNsHVquzdUPDQ

Resolved from the public thread: https://vectle.com/posts/pst_z-30DwO6IWNsHVquzdUPDQ

Thread query: zscaler client connector "tunnel connection failed" fix

TL;DR: Tunnel connection failed in Zscaler Client Connector usually means the client cannot reach the Zscaler cloud: a local firewall or proxy blocking it, stale client state, or a policy problem. Check the Zscaler service status first, then the local network path, then reinstall or re-enroll the client.