Register for part 2 of our Device Identity Webinar Series!

Add verified device identity to Zscaler Zero Trust Exchange

Smallstep controls which approved devices can obtain certificates and verifies hardware-backed identity where supported. Zscaler Client Connector evaluates those certificates through its certificate posture checks, while ZPA and ZIA keep enforcing their own access policies.

Get a demo
background gradientbackground texture
Works with ZPA posture profiles
Issued only to approved inventory
Hardware assurance where supported
Certificate-based device posture
Agent for Windows, macOS, Linux
Automated certificate lifecycle

Zscaler checks for a certificate. Smallstep decides which devices get one.

Zscaler's Client Certificate and Server Validated Client Certificate checks confirm a device holds a certificate from the CA you upload, not how the device obtained it. (Certificate Trust only confirms the device trusts a CA, so it is not evidence of an enrolled device.) Smallstep answers the issuance question: enrollment is authorized against your Jamf, Intune, or Google Workspace inventory for the fleets each supports, keys are hardware-backed where the platform allows, and renewal stops when a device leaves.

  • Client Connector, ZPA access policies, and ZIA trust levels stay; you add the posture profile to the policies that need it, trusting a CA hierarchy dedicated to Smallstep-governed devices.

How Smallstep device identity works

Zscaler integrates with Smallstep at two points

First, the posture profile. For ZPA, prefer Server Validated Client Certificate on supported Windows and macOS clients, with the Smallstep root uploaded. For ZIA trust levels, use the client-reported Client Certificate type, which is weaker. Second, the device: the Smallstep agent places the certificate where Client Connector reads it. One prerequisite: exclude Smallstep enrollment domains from ZIA TLS inspection, because enrollment uses mutual TLS.

Use the server-validated check where you can

Zscaler offers three certificate posture types. Certificate Trust checks whether the endpoint trusts a configured certificate or CA; it does not prove possession of a device certificate. Client Certificate is a client-reported check for a matching certificate and key. Server Validated Client Certificate has ZPA send a challenge the device signs with its private key, which proves possession; Zscaler recommends it for supported Windows and macOS clients on ZPA.

  • Non-Exportable Private Key makes the endpoint report a non-exportable key; it does not prove hardware binding.

Credentials Client Connector can read

Client Connector reads the Windows personal store, the macOS System keychain, or certificate files on Linux, depending on the posture type. On Windows the Smallstep agent can place a TPM-backed, non-exportable certificate there. On macOS and Linux the credential is software-protected, issued where supported and authorized by the device's attested identity; the macOS keychain path still needs validation. Security depends on both issuance assurance and credential protection afterward.

Smallstep manages issuance. Zscaler controls access.

Smallstep authorizes enrollment from your inventory and issues the certificate. Client Connector evaluates posture on its schedule, every 15 minutes by default, and ZPA applies policy to new connections; Smallstep is not in the request path.

Zscaler owns policy and enforcement. Smallstep owns which devices get a credential and how its key is protected.

Example: Intune-managed laptops enroll through the agent; a ZPA access rule requires the server-validated posture before a private app opens.

How device identity and key protection work

Key benefits for Zscaler customers

Certificates for authorized devices

Smallstep checks inventory and enrollment policy before issuing. Devices outside your policy cannot obtain those credentials; Zscaler then enforces access with its posture profiles and access rules.

Device identity assurance matched to each platform

TPM-based attestation on compatible Windows and Linux devices; Secure Enclave and managed-device workflows on Apple devices, with their own assurance levels. What reaches Zscaler also depends on where the credential is stored and which posture check evaluates it.

Keep Zscaler as the enforcement platform

Add Smallstep-issued certificates to supported posture profiles without replacing Client Connector, your identity provider, or your ZPA and ZIA policies.

Nothing for users to carry

Enrollment, issuance, and renewal happen through the agent or MDM. Users pass the posture check with a managed certificate instead of a prompt.

One identity, more than one enforcement point

The same device identity can serve Wi-Fi, VPN, SSO, and SSH integrations, each with its own credential configuration and enforcement on the resource side.

Lifecycle that follows inventory

Issuance and renewal are tied to device authorization. When a device is removed, renewal stops and existing credentials run to their configured expiry. Immediate removal needs enforcement in Zscaler.

Put issuance assurance behind the Zscaler policies you already run.

Zscaler keeps deciding who gets through. Smallstep governs which devices receive a certificate and how its key is protected.

Book a demo

FAQs Smallstep for Zscaler

Zscaler's Client Certificate and Server Validated Client Certificate checks evaluate certificates associated with a configured CA; the server-validated type also verifies possession of the private key. Certificate Trust only evaluates whether the endpoint trusts a configured certificate or CA. None of these checks establishes how a device was approved for certificate issuance. Existing AD CS or MDM deployments can issue hardware-backed, non-exportable keys when configured that way; Smallstep adds an explicit device approval and attestation workflow that ties issuance and renewal to inventory and policy. How much that changes depends on the controls already configured in your PKI. Zscaler's policy engine stays in charge of access.

Server Validated Client Certificate where it is available: ZPA sends a challenge, the client signs it with the private key, and the server verifies it, so a certificate without its key cannot pass. It requires Client Connector 4.4 or later on Windows and 5.0 or later on macOS, applies to ZPA only, and needs the root CA uploaded. Client Certificate is client-reported, works on Windows, macOS, and Linux, requires the certificate in the user store, can add a CRL check, and takes the template information field to match the Smallstep certificate. Certificate Trust only confirms the device trusts a certificate; it is not evidence of a device certificate and is the only type available on iOS.

Under Device Posture, add a profile, select the platforms, and choose the posture type. Upload the Smallstep root CA for the server-validated type, or the root or issuing intermediate for the Client Certificate type; use a root and issuing CA dedicated to Smallstep-governed devices: the server-validated type trusts the uploaded root and any intermediate beneath it, so a dedicated intermediate under a shared corporate root does not isolate the check on its own. Verify what restrictions your chosen posture type can enforce. Enable Non-Exportable Private Key where the deployed credential and operating system support the check, and verify the Smallstep-issued credential passes before enforcing. For the Client Certificate type on Windows and macOS, the template information field must match metadata in the issued certificate; confirm what your Smallstep certificate profile contains, or add the extension it needs, before relying on that field. Reference the profile in ZPA access rules with the expected result set to verified, or in ZIA posture trust levels. Then confirm results on a test device before enforcing.

Windows and macOS support all three certificate posture types. Linux supports Client Certificate with PEM files in Zscaler-defined directories. iOS supports Certificate Trust only. Zscaler ended Client Certificate posture support for Android at Client Connector 5.0. Smallstep's agent covers Windows, macOS, and Linux; for iOS, a certificate pushed through MDM can satisfy Certificate Trust, which is a trust check rather than a possession check.

It depends on the platform and credential configuration. On Windows the agent can place a TPM-backed certificate in the local computer personal store, which the server-validated type reads and which passes a non-exportable key check. On macOS, the server-validated type requires the certificate in the System keychain with the key accessible without a prompt, which the agent's CryptoTokenKit identity does not satisfy; Smallstep can issue, where supported and configured, a short-lived provisioned credential authorized by the device's attested identity, but the path into the System keychain with the required permissions has not been validated and should be treated as configuration-dependent. On Linux the credential is certificate and key files protected by filesystem permissions, which is access control, not hardware binding. Zscaler's non-exportability check reports what the endpoint says about the key; it does not prove the key was generated in hardware. Confirm the key protection model for each OS with us before setting policy expectations.

The Client Certificate type can perform a CRL check; on Windows it uses the CRL cached by a Microsoft API, or, from Client Connector 4.8, a locally downloaded CRL on a 0 to 30 minute cache interval that Zscaler Support enables. Zscaler does not document revocation checking for the server-validated type. Plan on short certificate lifetimes and stopped renewal as the removal mechanism, and treat CRL checking as an addition where it is available.

Client Connector evaluates posture every 15 minutes by default, configurable from 2 to 15 minutes per posture type on current Windows and macOS clients, and on events such as reboot, network change, or service restart. New connections use the updated result; existing connections are not affected by a posture change, so bound sessions with the reauthentication timeout. These are Zscaler behaviors and are independent of Smallstep.

On Windows, the ZPA machine tunnel can evaluate Client Certificate, Certificate Trust, and Server Validated Client Certificate before login when the profile is applied to the machine tunnel. The macOS machine tunnel does not evaluate any certificate posture type. Whether the Smallstep credential is available in the pre-login context on Windows has not been validated; test it in a pilot.

Yes, for enrollment. The Smallstep agent and CLI authenticate to Smallstep with mutual TLS, which TLS inspection breaks. Add the Smallstep service domains to a ZIA do-not-inspect policy before rolling out the agent; the Intune reference guide lists them.

Yes. The same posture profile feeds Internet and SaaS posture trust levels, which shape inspection and policy for a device rather than allowing or denying a private application. The server-validated type is ZPA-only; use Client Certificate for a profile that must also drive ZIA trust levels. On Windows the two types read different stores (the server-validated type accepts the local computer store, Client Certificate reads the user store), so running both may need separate certificate profiles or store configurations.

Remove the device from inventory, by removing it from the MDM or in Smallstep, and issuance and renewal stop; the certificate runs to its short expiry. Removal that originates in the MDM reaches Smallstep on the inventory connector's synchronization schedule, so for urgent removal disable authorization directly in Smallstep and enforce termination through Zscaler and the identity provider. Zscaler does not query Smallstep inventory, so the certificate may continue to satisfy the posture check until it expires, a CRL check catches a revocation, or another Zscaler control denies access. For urgent removal, disable further issuance in Smallstep, revoke the user's access through the identity provider and Zscaler, and verify that active sessions have ended or will end within an acceptable policy-defined interval; the default reauthentication timeout is days, not minutes. Do not rely on certificate expiry or reauthentication timing for immediate termination.

No. This page is about using Smallstep certificates inside Zscaler's own posture checks. Smallstep also offers Enterprise Relay, a MASQUE-based identity-aware relay, for specific internal destinations that must be reachable only from attested devices. It is an option alongside ZPA, not a prerequisite for the integration above.

The posture certificate is what Client Connector evaluates; ZPA does not use it to authenticate the application session, which continues through your identity provider and ZPA policy. If you also use Smallstep certificates for browser mTLS to an application, that is a separate credential profile with its own store and issuer. Decide which path each resource uses and configure the profile for it.

Smallstep can extend device identity beyond Zscaler to supported Wi-Fi, VPN, SSO, SSH, and internal application integrations. Each needs its own credential configuration and enforcement on the resource side; for example, Smallstep can act as an additional device identity factor in supported Okta or Entra sign-in flows.

Smallstep can extend device identity beyond Cloudflare to supported Wi-Fi, VPN, SSO, SSH, and internal application integrations. Each needs its own credential configuration and enforcement on the resource side; for example, Smallstep can act as an additional device identity factor in supported Okta or Entra sign-in flows.