Register for part 2 of our Device Identity Webinar Series!

Keep your existing CA. Add verified device identity.

Your PKI stays in place, in AD CS, HashiCorp Vault, AWS Private CA, Google CAS, or EJBCA. Smallstep adds device-aware issuance: enrollment authorization against inventory, hardware-backed credentials where supported, and automated lifecycle. A Smallstep intermediate beneath your existing CA preserves your trust hierarchy while you gain control over which devices receive access credentials.

Get a demo
background gradientbackground texture
Chains to AD CS, Vault, AWS Private CA, Google CAS, EJBCA
Your CA key is never uploaded to Smallstep
Issued only to approved inventory
Hardware assurance where supported
Your CA keeps issuing as before
Automated certificate lifecycle

Your CA enforces issuance policy. Smallstep adds device enrollment and lifecycle controls.

AD CS, Vault, AWS Private CA, Google CAS, and EJBCA already control what they issue, through templates, roles, IAM, and issuance policies. Smallstep complements that by tying issuance to approved device inventory, enrollment workflows, and cryptographic device evidence where supported. Your PKI keeps the trust hierarchy; Smallstep manages which devices are eligible to receive and renew access credentials.

  • Your PKI team keeps the root, its ceremony, and its policies. Smallstep runs the device-facing issuer.

Bring your own root guide

Your PKI integrates with Smallstep at one point: a signed intermediate

Upload your root certificate, never the key. Smallstep generates the intermediate key in its HSM and hands you a CSR. Sign it with the CA authorized to issue subordinate CAs in your PKI; the guide covers signing from an existing root, with commands for AD CS, Vault, AWS Private CA, OpenSSL, and CFSSL, and multi-tier chains should be confirmed with us. Upload the signed certificate. The authority is live, and every certificate it issues chains to your root.

Trust the root, but key policy on the issuer

Smallstep certificates chain to your trusted root, so you generally need no new trust anchor. Relying parties still enforce their own profile, issuer, and identity-mapping rules, and a root-only rule also accepts every other intermediate beneath it. Configure each relying party to require the intended issuing CA and the certificate's purpose and identity.

  • Issuer tells you who signed, not what assurance applied. Where assurance levels differ, use separate issuing authorities or an attribute that identifies the policy.

Three ways to fit your PKI

Subordinate CA, hosted: Smallstep holds the issuing intermediate key in its managed cloud HSM; your CA key stays with you. Fits teams that want a managed device issuer under their hierarchy. Subordinate CA, self-hosted: Step CA Pro on your infrastructure with a supported PKCS#11 HSM, for key custody requirements. Registration authority: Step CA Pro authenticates and authorizes requests while Vault or Google CAS keeps the key and signs the leaf, for teams that must keep all signing in the existing CA.

Smallstep manages device issuance. Your PKI stays the root of trust.

Your CA keeps issuing what it issues today: server certificates, workload certificates, code signing. With a subordinate CA, Smallstep issues and renews device certificates beneath your trust hierarchy, can publish CRL and OCSP for them on authorities with active revocation, and stays out of your CA's other workflows. In RA mode, Smallstep authorizes device requests and your CA signs them.

Your PKI owns the trust anchor, the signing CA, and revocation of the intermediate. Smallstep owns which devices get a credential and how its key is protected.

Key benefits for teams with an existing PKI

Root key stays where it is

You upload a certificate and sign one CSR. Your CA private key stays under your control and is never uploaded to Smallstep; the intermediate can be revoked or rotated from your CA.

Certificates for authorized devices

Smallstep enforces the configured inventory, approval, and enrollment requirements before issuing. Hardware attestation applies where the platform supports it and the selected workflow requires it.

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, each with its own assurance level. The relying party sees it as a certificate under your root.

No new trust anchor

Certificates chain to the root your relying parties already trust. Each still applies its own profile, issuer, and identity rules; set those to the Smallstep issuer where assurance matters.

One identity, more than one enforcement point

The same device identity can serve Wi-Fi, VPN, ZTNA, and SSO integrations, each with its own credential configuration and enforcement; SSH uses a separate authority outside the X.509 hierarchy.

Lifecycle that follows inventory

Short lifetimes, automatic renewal, and issuance that stops when a device leaves inventory; an existing certificate is not invalidated by removal alone. Revocation of the intermediate itself stays with the CA that signed it.

Put verified device issuance under the root you already run.

Your PKI keeps the trust hierarchy. Smallstep governs which devices receive a certificate beneath it and how its key is protected.

Book a demo

FAQs Smallstep for your existing CA

Those CAs enforce issuance policy through roles, templates, IAM, and pool or end-entity rules, and that model works for workloads. What CA policy does not establish by itself is that the requester is an approved company device with a hardware-protected key. Smallstep adds an explicit device approval workflow: issuance follows the configured inventory, approval, and enrollment requirements, hardware attestation applies where the platform supports it and the workflow requires it, and renewal is tied to inventory status. Your existing PKI remains the trust foundation; Smallstep is a subordinate issuer under it, or an RA in front of it.

Bring your own root requires an Advanced Authority and may need to be enabled for your account. Create the Advanced Authority and choose "Upload external root." Upload the PEM of your root certificate; do not upload the private key. Smallstep generates the intermediate key and gives you a CSR to download. Sign it with your CA, ideally from an offline or air-gapped machine, and upload the signed certificate. The guide includes commands for the step CLI, AD CS (certreq with a SubCA template), HashiCorp Vault (pki/root/sign-intermediate), AWS Private CA (issue-certificate with the subordinate CA template), OpenSSL, and CFSSL. Google CAS and EJBCA can sign subordinate CA requests as well, though the guide does not document their procedures. Your signing CA may itself be an intermediate; it needs permission to issue subordinate CAs and a path length that allows one more level.

In the hosted platform, Smallstep protects CA signing material in its managed cloud HSM infrastructure; ask us for the current validation details of the module. With bring your own root, Smallstep holds only the issuing intermediate key; your root and any higher intermediate signing keys remain in your existing PKI infrastructure, under your control. Holding the issuing key in a customer-owned HSM is not supported in the hosted platform; for that, see the self-hosted option.

Yes, with Step CA Pro on your own infrastructure, as a VM appliance or Kubernetes install, with signing keys in a PKCS#11 HSM that meets the documented build and library requirements. Step CA Pro can also run in registration authority mode in front of HashiCorp Vault or Google CAS: those services keep the signing keys and sign requests that the RA has authenticated and policy-checked. This is a different architecture from a subordinate CA: the leaf is signed by your CA, not by Smallstep, so your CA's issuance limits apply. Each RA mode has its own documented limitations; review them against your requirements.

Usually no new trust anchor, because the certificates chain to your root. Each relying party still applies its own rules: EKU and certificate purpose, subject or SAN identity mapping, issuer restrictions, revocation checking, and application policy; NPS, for example, checks purpose, identity, and network policy, not only the chain. A rule that keys on the root alone also accepts your other intermediates. Where device assurance is the point, require the Smallstep issuing CA and the certificate's purpose and identity. Requiring the issuer proves who signed, not what assurance applied: if different assurance levels share an issuer, split them across issuing authorities or enforce an attribute that identifies the policy.

Yes. Nothing about your root or its other issuers changes. Your CA continues to issue server, workload, and code-signing certificates as before; Smallstep issues device certificates beneath the same root. You can migrate device issuance over time, one credential type at a time.

Two layers. Smallstep can publish CRL and OCSP for certificates it issues when the authority has active revocation enabled; relying parties that check status query those endpoints, subject to their own caching, which can delay enforcement. Revoking the Smallstep intermediate is handled by the CA that signed it, which may itself be an intermediate: publish the revocation through that CA's CRL or OCSP, and relying parties that validate the path and enforce revocation checking then reject certificates beneath it. Plan the intermediate lifetime and rotation with that CA's CRL cadence in mind.

You set the lifetime when you sign the CSR; the guide's examples use ten years. To rotate, create a new authority, sign a new CSR from your root, and move credential configurations to it; device certificates are short-lived and renew onto the new issuer. Keep the old intermediate valid until its last certificate expires or is revoked, and update any relying party configured to require the old issuer; that does not happen automatically.

Yes, and it is the most common case: upload the enterprise root certificate, sign the CSR with certreq against a SubCA template, and Smallstep becomes an issuer in your existing hierarchy. Domain-joined machines already trust the root, so no new trust anchor is distributed; NPS and other relying parties still apply their purpose, identity, and policy checks to the new certificates. See the AD CS page for the full migration path.

Remove the device from inventory, by removing it from the MDM or in Smallstep, and issuance and renewal stop; the existing certificate is not invalidated by removal and runs to its expiry unless revoked. Revoke it in Smallstep on an authority with active revocation, and expect enforcement to follow the relying party's validation and caching behavior. Removal that originates in the MDM reaches Smallstep on the connector's synchronization schedule, so remove the device in Smallstep directly when timing matters. Your root is not involved.

Both are common. Bring your root when a PKI team already owns a root ceremony, when relying parties are configured to trust it, or when policy requires the root key to stay on your HSM. Let Smallstep host the chain when there is no existing PKI or when the device identity authority should be independent of it. You can migrate between the two models later, but changing roots can mean distributing a new trust anchor, updating relying-party policies, and reissuing certificates, so plan the transition to avoid disrupting authentication.

Smallstep can extend device identity to supported Wi-Fi, VPN, ZTNA, SSO, SSH, and internal application integrations. Each needs its own credential configuration and enforcement on the resource side; SSH uses a separate SSH authority with no chain to your X.509 root.

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.