Cisco Secure Access gives users three paths to private resources:
This post focuses on the ZTA client, and specifically on enrolling users with certificates. But first: why ZTA at all?
The two extend access in fundamentally different ways.
By default, VPN trusts the network. Once a user is on the tunnel, they're inside — with access to far more than they need. You then write access policy to narrow that down. The danger is the administrator who never gets around to it, for any of a dozen reasons. ZTA inverts this. It trusts nothing by default: access is explicitly granted per resource, only after the user is verified, and everything else stays blocked. An administrator can still make mistakes — but here the failure mode is accidentally blocking a resource, which is a far safer mistake than accidentally exposing one.
The day-to-day experience differs too.
With ZTA, the user signs in once, when they first enroll their device. After that, connecting is invisible — no manual "log in and connect" before each session. That's the default: users don't reauthenticate to applications unless you make them with a reauthentication policy. VPN is the opposite. The user connects and reconnects as a recurring action. How often depends entirely on how the tunnel is configured.
Let's say more about how users "log on" to ZTA as this can sometimes trip people up — largely because there's no single "log on" the way a VPN has one. ZTA splits into two parts: enroll, then connect. Keep those separate and the rest follows.
Enrollment is the one-time event behind that "sign in once" experience — and depending on the method, the user may not even see it happen! Once the user and device are verified, Secure Access issues the client a trusted certificate and stores it in the device's TPM (Windows/Linux) or system keychain (macOS).
Connect is everything after. The client makes connections on its own — per resource, not as a blanket tunnel. When the user requests a private resource, each connection streams up to Secure Access carrying user data, and each one is evaluated against policy. At rest, everything is blocked and dropped by default; you explicitly open specific ports, protocols, and applications for specific users. It's a closed, targeted model rather than an open door.
When the ZTA Client first shipped, SSO was the only way to enroll. The user signed in through SSO, followed the prompts, and the device enrolled.
That was a gap compared to the VPNaaS side of Secure Access, which already supported a broader set — SAML, certificates, and RADIUS. So early on, ZTA enrollment was the more constrained of the two.
That gap is now closing. Cisco has added certificate-based enrollment for ZTA, which lets administrators onboard users on Windows and macOS with identity certificates and no action required from the user. If your organization already runs a corporate CA, you can lean on that existing infrastructure instead of routing every enrollment through an interactive SSO prompt — silent, hands-off onboarding that scales across large device fleets. For organizations that want enrollment to be as frictionless as possible, this is the preferred method.
One caveat: CSA supports identity certificates, not machine certificates. For organizations whose PKI only issues machine certs, certificate enrollment is currently not an option.
Let's walk through the procedure, which is simple and straightforward.
Step 1 - Upload a CA Certificate
At least one root certificate or certificate chain must be uploaded to validate identity certificates on endpoint devices. If you have already uploaded a certificate for another purpose, like VPNaaS, you can reuse the certificate. If not, here is the procedure.
Navigate to Secure > Settings > Certificates. Select the Client Authentication tab, and click upload.
Use the certificate for ZTA enrollment and any other use-case.
Step 2 - Enable Certificate Enrollment
The default enrollment procedure for ZTA is SSO. This is to say, you must enable certificates for enrollment. Note that you can enable both SSO and certificates, and a device can use either method.
Navigate to Connect > Essentials > End User Connectivity. In the Zero Trust Access menu, click the Manage gear for Enrollment Methods.
Click Use Certificates.
Step 3 - Install the Configuration File on the Endpoint
On the same page, download the configuration file. The configuration file contains information about the CA certificates that have been uploaded to CSA for ZTA enrollment.
Then, install it in the follow location.
C:\ProgramData\Cisco\Cisco Secure Client\ZTA\enrollment_choices/opt/cisco/secureclient/zta/enrollment_choicesStep 4 - Verify
The ZTA module on Secure Client should now be enabled, although you may need to restart your device for it to fully take effect. Notice that with certificate enrollment, a user cannot unenroll their device.
Zero Trust Access grants access one resource at a time, only after the user is verified, and keeps everything else closed by default — a departure from VPN's trust-the-network model. The user signs in once at enrollment and then mostly forgets the client is there. If your organization runs a corporate CA, pairing ZTA with certificate enrollment is the most frictionless path available — just confirm it can issue identity certificates.
Please don't hesitate to reach out with your Secure Access questions.