Security teams should keep private keys in a hardware security module rather than on a general-purpose server. An HSM provides dedicated hardware for key protection and cryptographic operations, which reduces exposure to malware, OS misconfiguration, and flaws in the underlying CPU or kernel memory. For PKI, the main goal is to keep sensitive key material out of environments with a broad attack surface.
Why Hardware Separation Matters When Keys Must Survive OS and CPU Exposure
Private keys should be treated as high-value secrets whose safety depends on more than file permissions. When the host OS, kernel, or CPU may be vulnerable, the key is safest when the signing operation happens inside dedicated hardware and the raw key never becomes available to the general-purpose environment. That changes the trust boundary, not just the storage location.
For PKI and similar trust models, this is a practical design choice: the server can still request a signature, but it should not be able to read, copy, or export the private key. That is why hardware-backed protection is preferred for long-lived CA keys, code-signing keys, and other keys whose compromise would be broadly damaging.
In practice, the question is less “where is the key stored?” and more “what can the host actually do with it?” A hardware security module can limit key export, keep operations isolated from host memory, and reduce exposure to malware or memory-scraping attacks that would otherwise benefit from OS flaws or kernel-level compromise. See the Machine Identity, PKI and Certificate Lifecycle Guide for the broader lifecycle context around key protection and certificate operations.
What Changes In The Threat Model Compared With Software-Only Key Storage
When keys live on a workstation or server, the attacker does not need to “steal the file” in the old sense. A memory disclosure bug, privileged malware, a compromised admin account, or a kernel flaw may be enough to reach the material that unlocks trust. That makes software-only storage especially fragile on systems with a broad attack surface.
Hardware-backed protection narrows the damage path. The host can be compromised without automatically yielding the private key, because the sensitive material stays inside the module and the host receives only the result of the cryptographic operation. The operational benefit is strongest when the key must remain online but should still resist extraction, such as signing, TLS termination, or API authentication use cases.
That said, hardware is not a substitute for governance. If the wrong service is allowed to use the key, or if access to the HSM is too broad, the key can still be abused even if it cannot be copied. The control protects confidentiality of the key material, but it does not automatically solve authorization, lifecycle, or blast-radius problems. If the key can authenticate to production systems, treat access review and rotation as part of the same control set, not as an afterthought. The broader exposure patterns are illustrated in The 52 NHI Breaches Report.
How To Decide When An HSM Is The Right Control
The strongest candidates for HSM protection are keys whose compromise would create high blast radius, long-lived trust, or direct impersonation risk. That usually includes CA private keys, signing keys, and any private key that underpins automated trust at scale. When the key is operationally important and the host environment is not fully trusted, the default should be hardware-backed protection rather than software files or local keystores.
General-purpose host storage is more defensible only when the key is low impact, short-lived, or already bounded by another strong control and the exposure window is tightly constrained. Even then, the team should be explicit about what residual risk is being accepted, because OS patches, hardening, and EDR do not eliminate memory disclosure or privileged compromise risk. For teams managing application and automation credentials, the same principle appears in the API Key Management Guide, which treats storage and revocation as part of one lifecycle.
When the key is tied to machine authentication or certificate use, the key management decision should also reflect how often the key is renewed, who can invoke it, and whether the environment can support rotation without service disruption. In other words, choose the hardware boundary because the key is too valuable to trust to the host, not because hardware is a generic best practice in the abstract. For service-to-service authentication patterns, the NHI Authentication Guide provides the adjacent identity context.
Risk and Threat Considerations
When private keys remain on a general-purpose system, the main risk is that a platform flaw can turn a local compromise into key compromise. A single OS exploit, memory read primitive, or privileged malware implant can convert broad system access into long-term cryptographic trust abuse.
Failure mechanism: The key material is reachable from host memory, local storage, or a software keystore that inherits the exposure of the underlying server or workstation. Once the host is compromised, the attacker may be able to extract, copy, or misuse the key without needing to defeat the cryptography itself.
Impact: A stolen private key can enable impersonation, fraudulent signing, unauthorized decryption, or persistent trust abuse until the key is revoked and replaced. The operational damage is usually larger than a single host compromise because the key may be trusted by multiple systems, clients, or certificate chains.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Covers machine and service authentication using protected key material. |
| IA-5 — Authenticator Management | Private keys are authenticators whose storage, protection, and rotation must be managed. | |
| SC-12 — Cryptographic Key Establishment and Management | Directly addresses protection of cryptographic keys across their lifecycle. | |
| Recommendation — Use IA-9 to keep service keys in hardware-backed or otherwise protected authenticators. Use IA-5 to control key generation, storage, rotation, and destruction. Use SC-12 to require protected key establishment and lifecycle handling. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Applies because the answer is about protecting cryptographic private keys. |
| Recommendation — Require hardware-backed protection for high-value private keys. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Protecting private keys is a core data protection concern. |
| Recommendation — Store critical private keys in tamper-resistant hardware and limit exposure. | ||
Practitioner Guidance
What to verify: Confirm that the key cannot be exported from the hardware boundary and that the host only receives signing or decrypting results, not raw key material. Also verify the exact failure mode for HSM unavailability, because availability design matters when the key is no longer stored locally.
What to prioritise: Put the highest-value, longest-lived, and most widely trusted keys into hardware first. If you cannot move every key immediately, start with CA, code-signing, and production authentication keys that would create the largest blast radius if exposed.
Practitioner takeaway: The decisive question is whether the host can ever see the private key in usable form, because once the answer is yes, OS and CPU flaws become key-compromise paths rather than just server-security issues.
Related resources from NHI Mgmt Group
- What should security teams do first when SSH private keys may be exposed or duplicated across servers?
- How should security teams protect cryptocurrency private keys without creating unnecessary trust in a wallet provider?
- What should security teams do when a wallet library may have exposed seed material or private keys?
- How should security teams protect application secrets when the operating system itself may be compromised?