Give every workload a short-lived identity
Smallstep issues and renews short-lived X.509 certificates for workloads across Kubernetes, cloud, and on-prem environments. Requests are authorized through Kubernetes service accounts, cloud instance identity, policy-based enrollment, or hardware-backed device attestation, helping teams replace the long-lived credentials behind mTLS.
Cross-platform coverage
Seamless integration
Reduce credential theft & replay risk
Searchable issuance records
IDP integration
Replace static keys with certificates
From device identity to workload identity
Device identity is the first layer: Smallstep co-created the IETF standard for device attestation with Google, now adopted by Apple and other major platforms, giving the devices and hosts in your infrastructure cryptographic identities of their own. Workload identity is the layer above it. The services running on those hosts earn their own short-lived certificates, authorized by their own evidence, such as Kubernetes service-account identity, cloud instance identity, and policy-controlled enrollment.
The last rotation runbook you'll delete
If you already run step-ca for service certificates, Step CA Pro slots in where it sits, no rebuild and no new root. You keep the CA and root signing keys under your control and gain what open source leaves out: active revocation over CRL and OCSP, a searchable issuance history for audit, per-provisioner issuance policy, and HSM-backed signing.
Policy decides who gets a certificate
Before issuing a certificate, Smallstep validates evidence such as Kubernetes service-account identity, cloud instance identity, or hardware-backed device attestation. Issuance policies determine which requests and identity attributes are accepted, and every issuance is recorded, so you can answer who got a credential, under which policy, and when.
Short-lived certificates for Kubernetes
Each enrolled pod can receive and automatically renew a short-lived X.509 identity for mTLS, issued through autocert, cert-manager, or ACME. Certificates rotate on their own schedule, so service-to-service encryption inside the cluster stops depending on secrets someone has to distribute and remember to rotate.
Standards-based, not vendor-locked
Smallstep helped write the IETF standard for high-assurance device identity, and we're bringing the same posture to workloads: identifiers can follow SPIFFE conventions, and the emerging IETF WIMSE drafts on workload credentials and proof of possession are shaping where this product goes. Cloud providers already accept federated workload identities in place of stored access keys, mapping them to short-lived cloud credentials through their native flows. Standards keep the exit door open.
From step-ca to Step CA Pro, no rebuild
If you already run step-ca for service certificates, Step CA Pro slots in where it sits. You keep the CA and the root signing keys under your control and gain attestation verification, issuance policy, a management interface, and the compliance options the open source server doesn't ship.
Get the Data Sheet
Smallstep Workload Security issues and automatically renews short-lived X.509 certificates for workloads, with issuance controlled by policy and authorized using platform evidence. Searchable issuance records show each certificate's identity, issuer, provisioner, and validity period, so audits and incident reviews start from data instead of guesswork.
The CA is the easy part
Signing certificates is a solved problem. What turns a certificate into workload identity is everything around it: validating enrollment evidence, enforcing issuance policy, automating renewal and revocation, and keeping searchable records of what was issued to whom. That surrounding machinery is what teams underestimate when they build in-house, and it's what the platform provides.
Zero Trust doesn't stop at the laptop
Extend the same identity guarantees you enforce for devices to every service that runs your business.