What is the difference between an HSM and a vault for key storage?

How an HSM differs from a vault at the storage boundary

An HSM is built to keep cryptographic key material inside a hardened, tamper-resistant boundary and perform sensitive operations there. A vault is broader: it centralises secrets, controls access, and may hand keys to software at request time. The practical difference is not just where keys are kept, but whether the cryptographic operation itself can stay inside protected hardware.

That difference matters when you are deciding what the system must protect against. If the main concern is secret distribution, rotation, and application access, a vault is usually the right abstraction. If the concern is high-assurance key protection, signing, or private-key operations where export risk must be minimised, the HSM model is stronger.

Most modern architectures use both. A vault can manage credentials, lifecycle, and developer ergonomics, while an HSM can protect root keys, CA keys, code-signing keys, or any material whose compromise would have outsized impact. In that pattern, the vault is the operational control plane and the HSM is the cryptographic trust anchor.

What changes in practice when keys never leave hardware

The biggest security difference is whether key material is exportable. In an HSM-centric design, the application asks the hardware to sign, decrypt, or unwrap, but the private key stays inside the module. That reduces exposure from host compromise, memory scraping, backups, and accidental copying, because the key is not meant to exist in general-purpose application space.

A vault, by contrast, often prioritises retrieval, policy, and automation. It can still be secure, but it commonly serves applications by delivering secrets over an authenticated channel, and those secrets may exist temporarily in process memory or on an attached runtime. That is acceptable for many operational secrets, but it is a different assurance model from non-exportable hardware protection.

That distinction becomes material for certificate authorities, signing services, token-signing keys, and any workflow where misuse of the key would be difficult to detect or impossible to revoke cleanly. For those use cases, the question is not whether a vault can hold the secret, but whether the key should ever be exposed outside a protected cryptographic boundary.

How to choose between vault, HSM, or both

Choose by the function the key serves, not by the label on the product. If you need secrets distribution, application bootstrapping, dynamic credential delivery, or a central place to manage multiple secret types, a vault is usually the better operational fit. If you need assured key generation, non-exportable private keys, and hardware-backed cryptographic operations, an HSM is the better control.

For many teams, the strongest design is layered: keep low- and medium-sensitivity secrets in a vault, and place the highest-value signing or root material in an HSM. That approach preserves developer usability without treating every secret as if it needs the same level of hardware assurance. It also avoids overusing HSMs for workloads that mainly need lifecycle management rather than hardware-backed signing.

If your architecture spans cloud and on-premises systems, compare how each service handles access policy, auditability, rotation, backup, and recovery. A vault may be easier to integrate broadly, while an HSM may be stricter, slower to operate, and harder to automate. That trade-off is often worthwhile when the protected key is a trust root rather than a convenience secret.

Risk and Threat Considerations

The main risk is assuming a vault provides the same protection model as an HSM. If a secret is exportable, then host compromise, overly broad access policy, or a misused API can turn centralised storage into centralised exposure. The reverse risk is using an HSM where the operational workflow still copies sensitive material out of hardware, which defeats much of the assurance you paid for.

Failure mechanism: The key or secret crosses the trust boundary in a form that can be copied, logged, cached, or reused outside the intended control plane, so compromise of the surrounding system becomes compromise of the key material itself.

Impact: Attackers or insiders may gain the ability to sign, decrypt, impersonate, or persist with the key, and the organisation may lose the non-repudiation and containment benefits it expected from hardware-backed protection.

Practitioner Guidance

What to verify: Confirm whether the use case requires non-exportable keys or simply centrally managed secrets. If the answer involves root certificates, code signing, or token signing, verify that the private key cannot be exported from the trust boundary.

Trade-off: Treat HSMs as assurance devices and vaults as orchestration devices. If you need broad automation and fast rotation for many applications, a vault is usually the better day-to-day control; if you need maximal protection for a small set of critical keys, the HSM should own that boundary.

Practitioner takeaway: The right design is often not vault versus HSM, but which keys can tolerate being operationalised in software and which keys must remain non-exportable for the life of the trust relationship.

Related resources from NHI Mgmt Group

• Key Storage
• How should security teams implement HSM-backed PKI in environments that rely on software-only key storage today?
• What is the difference between an HSM and software based key storage?
• What is the difference between traditional offline HSM-based key storage and cloud-native distributed key management?