What breaks when private CA keys are not isolated in dedicated HSMs?

Why This Matters for Security Teams

When private CA keys are not isolated in dedicated HSMs, the failure is not just technical hardness, it is trust collapse. A CA key is the root of issuance authority, so any exposure in a shared platform, hypervisor, or adjacent tenant can turn certificate signing into an enterprise-wide impersonation event. That is why guidance from the NIST Cybersecurity Framework 2.0 and NHI Management Group both emphasize strong protection of high-value identity material. NHI Mgmt Group notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is directly relevant because CA keys are among the most privileged NHIs in the environment.

The practical risk is that a shared or exportable CA key weakens every certificate issued from that trust anchor, including internal service identities, mTLS endpoints, and automation workflows. Once the key is reachable outside a dedicated boundary, the attacker no longer needs to break individual workloads one by one. They can mint trust instead. In practice, many security teams encounter certificate abuse only after a signing path has already been misused, rather than through intentional key isolation design.

How It Works in Practice

Dedicated HSM isolation changes the threat model by making the CA private key non-exportable and cryptographically bound to a controlled signing boundary. The key should never exist in general-purpose memory, file systems, backup jobs, or shared control planes. Instead, the HSM performs the private-key operation internally, returning only the signed output. That reduces exposure from platform compromise, insider misuse, and cross-tenant leakage.

For private PKI, the operational question is not only where the key lives, but who can request signatures, under what policy, and with what audit trail. A mature design usually combines HSM-backed CA protection with:

• separate root and intermediate CAs, with offline or tightly restricted root access
• role separation for issuance, approval, and recovery operations
• policy-based certificate issuance rules tied to workload identity
• short-lived intermediates or constrained issuance paths where possible
• tamper-evident logging and dual control for sensitive CA actions

This approach aligns with the broader identity guidance in NHI Management Group’s NHI research, especially where secrets, certificates, and service identities are treated as first-class attack surfaces. It also fits the control intent in the NIST Cybersecurity Framework 2.0, which pushes organisations to govern critical assets according to business impact and trust requirements. These controls tend to break down when CA operations are centralized in a shared platform that cannot enforce non-exportability or tenant-level separation.

Common Variations and Edge Cases

Tighter CA isolation often increases operational overhead, requiring organisations to balance signing resilience against key management complexity. That tradeoff becomes visible during disaster recovery, certificate migration, and high-availability planning, where teams may be tempted to replicate keys into secondary environments. Best practice is evolving here: there is no universal standard for every private PKI topology, but the current guidance consistently rejects broad key portability for high-trust CAs.

Two edge cases matter most. First, some environments use cloud HSMs or managed key services and assume that provider tenancy alone is enough. That can be acceptable only when the signing boundary, administrative access, and auditability remain tightly controlled. Second, some teams protect leaf keys but leave intermediate or subordinate CA keys in weaker storage. That is a common failure mode because subordinate keys still have issuance power and can generate a large blast radius if compromised.

Where this breaks down fastest is in multi-tenant platforms, CI/CD automation, and legacy PKI stacks that require exportable keys for backup or failover. Those conditions undermine the very property that makes a CA trustworthy: the ability to prove that issuance authority stayed inside a dedicated boundary.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• What problem does ownership attribution solve for service accounts and API keys?
• What challenges do unmanaged API keys pose within MCP?
• What breaks if browser private keys are stored badly for DPoP?