Axelspire

Smallstep step-ca: Operations, Cost & Compliance Assessment

step-ca is the fastest path to a working private ACME CA. A single Go binary, step ca init, and you have a functioning certificate authority issuing certificates via ACME, OIDC, JWK, or cloud instance identity tokens. For DevOps and platform engineering teams building mTLS, Kubernetes workload identity, or SSH certificate infrastructure, step-ca removes friction that other platforms impose.

The trade-off is scope. step-ca is opinionated by design: one configured intermediate per instance, no built-in web UI, limited enterprise protocol support in the open-source version, and no native Windows GPO integration. It does one thing well — automated certificate issuance for cloud-native workloads — and does not pretend to be a full enterprise PKI platform.

For the cross-platform evaluation, see the Private CA Platform Comparison.

step-ca deployment architecture: single Go binary with embedded or PostgreSQL storage, cloud provisioners (AWS IID, GCP IIT, Azure MI), and cert-manager integration — annotated with HA requirements and key management options.
step-ca deployment architecture: single Go binary with embedded or PostgreSQL storage, cloud provisioners (AWS IID, GCP IIT, Azure MI), and cert-manager integration — annotated with HA requirements and key management options.

What step-ca does well

ACME-first private CA. step-ca's ACME implementation is mature and battle-tested. HTTP-01 and DNS-01 challenges work out of the box. For teams standardising on ACME for certificate automation — the "private Let's Encrypt" model — step-ca is the most natural fit.

Minimal operational footprint. Single Go binary, no JVM, no application server. Default deployment is the binary plus a configuration file and key material. Production HA adds an external database — standard MySQL or PostgreSQL, not a specialised clustering setup.

SSH + X.509 together. step-ca issues both SSH certificates and X.509 certificates from the same platform. Organisations moving from SSH key-based access to SSH certificates can use the same CA infrastructure they use for TLS.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

Operational complexity

Total deployment time from zero to issuing ACME certificates: under an hour for a competent operator. No other CA platform matches this. Day-two maintenance is lightweight — Go binary upgrades, standard database operations for HA, and KMS/PKCS#11 for intermediate key protection.

Dimension step-ca (OSS) Certificate Manager
ACME (HTTP-01, DNS-01)✓ Full✓ Full + EAB
SCEP (Intune/Jamf)✗ None✓ Full
SSH certificates✓ Full✓ Full
Windows GPO autoenrollment✗ None✗ None
EST / CMP / CMPv2✗ None✗ None
Cloud provisioners (AWS/GCP/Azure)✓ Full✓ Full
Compliance certificationsNoneCloud provider inherited

Cost model

Component OSS (5-yr) Notes
LicensingFreeApache 2.0
Infrastructure$5K–$15K/yrSmallest instance type + database
Staffing (0.25–0.5 FTE)$37K–$75K/yrAbsorbed by platform engineering
5-year TCO (OSS)$50K–$150KLowest self-managed CA by significant margin

Enterprise gaps

No Windows GPO autoenrollment. No CEP/CES interface, no GPO integration. Windows environments requiring autoenrollment must look to AD CS or EJBCA Enterprise.

No cross-CA inventory. step-ca tracks certificates it issues. No visibility into certificates from other CAs, no discovery, no unified inventory across multi-CA environments.

No built-in compliance certifications. No Common Criteria, no FIPS 140-2 at the CA application level. Compliance evidence assembly is manual unless integrated with external tooling.

step-ca capability radar: ACME maturity, enterprise protocols, Windows GPO support, SSH certificates, compliance evidence, and cross-CA inventory — OSS versus Certificate Manager versus EJBCA and Vault PKI.
step-ca capability radar: ACME maturity, enterprise protocols, Windows GPO support, SSH certificates, compliance evidence, and cross-CA inventory — OSS versus Certificate Manager versus EJBCA and Vault PKI.

When step-ca fits — and doesn't

Choose step-ca for greenfield DevOps/platform engineering PKI, Kubernetes workload identity, SSH certificate rollout, mTLS between microservices, or "private ACME CA" requirements where speed to production matters most.

Don't choose step-ca for regulated enterprise PKI requiring compliance certifications (see EJBCA Enterprise), Windows-centric environments needing GPO autoenrollment (see AD CS), or teams already running Vault where Vault PKI is the more natural fit. For fully managed CA without operating a binary, see AWS Private CA or 3AM Mint.

Pair step-ca with 3AM Mint when step-ca handles cloud-native issuance but the organisation needs enterprise visibility, compliance audit trails, and unified management across step-ca and other CA platforms. 3AM Mint provides the enterprise integration layer that step-ca intentionally omits.


Private CA Platform ComparisonVault PKI (Vault-native alternative) — EJBCA (enterprise protocol breadth) — AD CS (Windows GPO autoenrollment) — AWS Private CA (managed alternative) — 3AM Mint (enterprise integration layer). Contact Axelspire or Ask Axel.