Vault PKI Root of Trust: Where Your CA Key Actually Lives

By default, HashiCorp Vault PKI generates and stores CA private keys — root and intermediate — inside Vault's storage barrier: encrypted at rest, but a software key on a general-purpose server. HSM- or cloud-KMS-backed CA keys ("managed keys") require Vault Enterprise. This page covers the three custody models for Vault PKI trust anchors, what each survives, and how to anchor an existing Vault PKI to a KMS-protected root without replacing Vault.

AxelSpire's position: Teams evaluate Vault PKI on throughput and protocol support and accept the default root custody without noticing they've made a decision. The CA key is the one component whose compromise is unrecoverable by rotation-as-usual — every other Vault PKI limitation is an operational cost; this one is a trust decision. It deserves ten minutes of architecture before the first vault write pki/root/generate/internal.

For throughput ceilings, HCP pricing, and platform comparison, see the private CA platform comparison; for the enterprise fit decision, when Vault PKI works and when it doesn't; for the compliance and licensing assessment (BSL, OpenBao), Vault PKI as a private CA.

What "internal" key storage actually means

vault write pki/root/generate/internal creates the key inside Vault. The custody facts that follow from that:

The private key lives in Vault's storage backend, encrypted by the barrier key. Its protection is transitively the protection of your unseal mechanism plus storage backend plus Vault's privilege model.
The key is used in server memory on the active node for every signing operation. A privileged compromise of that node is a key-extraction opportunity in a way that hardware-held keys structurally are not.
On Vault Community/OSS, this is the only option. Managed keys — PKCS#11 HSMs, AWS KMS, Azure Key Vault, GCP Cloud KMS holding the CA key, with Vault delegating sign operations — are an Enterprise feature (1.10+).
Snapshot and DR handling inherit the risk: a Raft snapshot contains the barrier-encrypted key material; snapshot custody becomes CA key custody.

The auto-unseal misconception, stated plainly: KMS auto-unseal does not put your CA key in KMS. Auto-unseal protects the unseal path — KMS wraps the barrier key. The CA private key still lives in Vault's storage and still performs signing in Vault's memory. In AxelSpire's assessment work this is the single most common root-custody misunderstanding: teams report "our CA key is KMS-protected" when what they have is KMS-assisted unsealing of a software key. An auditor applying PCI DSS key-management requirements, or an internal policy requiring HSM custody for CA keys, will not accept the substitution — and discovering that during fieldwork is the expensive way to learn it.

The three custody models

	Model A: everything in Vault	Model B: offline root, Vault intermediate	Model C: KMS-anchored root, Vault intermediate
Root key location	Vault storage barrier (software)	Air-gapped machine / HSM, offline	Cloud KMS HSM, non-exportable by construction
Intermediate key	Vault barrier	Vault barrier	Vault barrier (unchanged)
Root compromise path	Vault privilege escalation, snapshot exfiltration, node memory	Physical/ceremony compromise	KMS policy compromise — key itself cannot be exported
Survives total Vault cluster loss	No — trust anchor dies with the cluster	Yes — re-sign new intermediates from offline root	Yes — re-sign new intermediates via KMS API
Operational cost	None (the default for a reason)	Key ceremonies, secure storage, manual signing process for every new/rotated intermediate	KMS key policy + a signing workflow; no ceremony logistics
Compliance posture (HSM-custody requirements)	Fails on OSS; Enterprise managed keys required	Depends on offline HSM choice	FIPS-validated HSM custody inherited from the KMS
Who actually runs this	Most Vault PKI deployments	The minority that staffed it	The emerging middle path

Model B is HashiCorp's own recommended pattern — their guidance explicitly describes keeping the root external to Vault and running Vault as an intermediate-only CA for higher security. It is also the pattern teams most often plan and then skip, because ceremony logistics for an offline root are real work with no feature payoff. The honest field observation: the gap between "we should have an offline root" and "we generated the root in Vault two years ago and it's load-bearing now" is most of the installed base.

Diagram comparing three Vault PKI root custody models: default in-Vault software storage, offline air-gapped root, and cloud-KMS-anchored root with non-exportable key. — Three root custody models for Vault PKI. The default (A) ties trust-anchor survival to Vault cluster survival; models B and C decouple them, at very different operational cost. Source: AxelSpire.

Rotation: multi-issuer helps, distribution doesn't change

Since Vault 1.11, a PKI mount holds multiple issuers, which makes the mechanics of rotation — generating a successor, cross-signing, serving both CRLs during transition — dramatically better than the old one-issuer-per-mount surgery. Two things multi-issuer does not fix:

Trust distribution. A rotated root still has to reach every trust store that pinned the old one — OS bundles, containers, appliances, partner systems, device fleets. That is an estate problem, and Vault has no view of where its chain is trusted. (This is the general cross-estate blindness covered in the cross-CA inventory analysis.)
Custody. Rotating a software-custody root produces a new software-custody root. Rotation is the natural moment to change model — the successor can be KMS-held even though the incumbent wasn't, with a cross-signing bridge covering the transition. Rotating into the same custody model wastes the one event that justifies the disruption.

DR: the question that exposes the model

Ask it concretely: if the Vault cluster is unrecoverable tomorrow — Raft quorum lost, snapshots suspect — what happens to your PKI?

Model A: the trust anchor is gone. Every trust store that pins your root must be re-seeded with a new one. This is not a Vault restore problem; it is a re-bootstrap of organizational trust, measured in weeks.
Models B/C: stand up a new Vault (or a different CA engine entirely), generate a new intermediate, sign it from the surviving root, resume issuance. Leaf-certificate churn only; trust stores untouched.

The dependency chain — sealed Vault means offline CA, quorum loss means no issuance — is documented in the private CA assessment. Root custody determines whether that chain ends at "issuance outage" or at "trust anchor loss." Those are different severity classes, and most risk registers record only the first.

The KMS-anchored pattern, concretely

Model C in practice, using AWS KMS as the example:

Root CA key is generated in KMS as an asymmetric signing key. Non-exportable is a property of the key, not a policy: KMS will perform sign operations but cannot release the private key. Custody is the KMS HSM fleet's FIPS-validated boundary, access is IAM policy, every signature is a CloudTrail event.
Vault keeps doing what it does well: pki/intermediate/generate produces the CSR; the KMS-held root signs it; the signed intermediate is imported back. Issuance, roles, ACME, cert-manager integration — all unchanged. Application teams notice nothing.
Root signatures are rare events (new intermediates, CRL for the root tier), so KMS API latency and cost are irrelevant at this tier — the objections that rule KMS out for leaf issuance don't apply to root operations.
The same root can anchor more than Vault: intermediates for AD CS, step-ca, or a cloud CA can hang off the same KMS-held trust anchor, giving one root of trust across heterogeneous issuance engines instead of one root per tool.

The cost math: HSM vs KMS at root-signing volumes

At root-signing volumes the economics are not close: an AWS KMS asymmetric key costs $1/month with signing at $0.15 per 10,000 operations, so a root CA that signs a few times a year runs around $12/year for FIPS 140-3 Level 3 custody — against roughly $28,000/year for a CloudHSM cluster (two instances at $1.60/hour for HA) or $50,000+/year all-in for on-premises HSMs once hardware, support contracts, and specialist staffing are counted.
The assurance level is identical; what you lose relative to a dedicated HSM is single-tenancy and customer-controlled hardware, which a handful of regimes (eIDAS QSCD, PCI PIN/P2PE, no-cloud sovereignty mandates) explicitly require and most do not — "we need an HSM" is worth pressing to "which requirement, verbatim?" before it drives the architecture. This spread only holds at root/subordinate-CA signing rates; at leaf-issuance volumes KMS per-operation cost and API quotas become real constraints, which is why the pattern anchors the root in KMS and leaves high-volume issuance to the engine below it.
The full HSM-versus-KMS decision, including which CA engines support KMS-held keys natively versus PKCS#11-only, is covered in HSM deployment strategy.

This is the pattern AxelSpire 3AM Mint productizes: a serverless, KMS-backed root that issues subordinate CA certificates for the CA engines you already run — Vault PKI, AD CS, step-ca — so the fix is additive. Keep Vault; fix the root. It is deliberately not a Vault replacement and not a CLM: issuance stays where it is, custody moves to where it should have been.

Architecture diagram of a KMS-backed root certificate authority anchoring Vault PKI, Microsoft AD CS, and step-ca as subordinates, with existing issuance paths unchanged. — The KMS-anchored pattern: one FIPS-validated, non-exportable root issuing subordinate CA certificates to Vault PKI, AD CS, and step-ca via 3AM Mint. Issuance engines and application integrations are unchanged. Source: AxelSpire.

Decision guidance

Running Vault PKI with an in-Vault root today: don't panic-rotate; schedule custody change into the next planned root or intermediate rotation, and bridge with cross-signing. Panic rotation of a trust anchor causes the outage it's meant to prevent.
Vault Enterprise customer: managed keys give you HSM/KMS custody natively — evaluate that first; the gap Mint closes for you is multi-engine anchoring and the estate layer, not custody per se.
OSS/Community (or OpenBao) with HSM-custody requirements: you cannot meet them inside the product. Options are Enterprise licensing, the offline-root ceremony you've been deferring, or the KMS-anchored pattern.
Greenfield: generate the root outside Vault on day one — offline or KMS-held — and make Vault intermediate-only. This costs an hour at the start and removes the whole page of problems above.

Where root custody sits in your broader posture is the Key Management category of the PKI assessment — in AxelSpire's assessment work it is the highest-severity, lowest-visibility gap: it causes no incidents at all until it causes an unrecoverable one.

FAQ

Where does Vault PKI store the CA private key?
In Vault's storage backend, encrypted by the storage barrier — a software key on the Vault servers, used in memory on the active node for signing. Hardware-backed CA keys (managed keys via PKCS#11 HSM or cloud KMS) require Vault Enterprise 1.10+; Community edition has no HSM custody option for PKI keys.

Does KMS auto-unseal protect my Vault CA key?
No. Auto-unseal uses KMS to wrap Vault's barrier key, protecting the unseal process. The CA private key remains in Vault's storage and memory. HSM custody of the CA key itself requires Enterprise managed keys or a root held outside Vault entirely.

Should the root CA be inside Vault?
HashiCorp's own guidance recommends keeping the root external — offline — and running Vault as an intermediate-only CA. Most deployments generate the root in Vault anyway because offline-root ceremonies are operationally expensive. A KMS-held root is the middle path: external, non-exportable custody without ceremony logistics.

How do I rotate a Vault PKI root CA?
Vault 1.11+ multi-issuer support handles the mechanics: generate the successor issuer, cross-sign to bridge trust, serve both during transition, retire the old issuer. The unsolved part is distribution — updating every trust store that pins the old root — which Vault cannot see or manage. Rotation is also the right moment to move the successor root to stronger custody.

Can I add an HSM-backed root to Vault Community edition?
Not inside Vault — managed keys are Enterprise-only. You can, however, hold the root outside Vault (offline HSM, or a cloud-KMS key such as via 3AM Mint) and have it sign Vault's intermediate. Vault Community then operates normally as an intermediate CA; custody of the trust anchor no longer depends on the Vault license tier.

What happens to Vault PKI if the cluster is lost?
With the root inside Vault, the trust anchor is lost with it — recovery means distributing a new root to every trust store. With the root outside Vault (offline or KMS-held), recovery is generating a new intermediate and signing it from the surviving root; clients and trust stores are unaffected.

Dan Cvrcek, AxelSpire. Field observations from enterprise Vault PKI assessments and platform work, 2024–2026. Vault feature availability (managed keys, multi-issuer) per HashiCorp documentation — re-verify version gates against current docs before publication. Updated July 2026.