Home  ›  Glossary  ›  Hardware Security Module

Hardware Security Module (HSM)

A hardware security module (HSM) is a dedicated, tamper-resistant hardware device that generates, stores and uses cryptographic keys, so the key material never exists in plaintext outside the device. Every sensitive operation — creating a key, signing, encrypting, or unwrapping another key — happens inside the hardened boundary of the HSM itself.

An HSM is not about who controls a key; that is the job of customer-managed keys. An HSM is about where the key physically lives and how it is protected. It is the hardware root of trust that often sits underneath a key management service (KMS) — the place a "your own" key actually resides.

What an HSM actually does

An HSM concentrates four capabilities in one hardened device:

  • Key generation. Keys are created on-device using a hardware true random number generator (TRNG), producing higher-entropy keys than software alone.
  • Secure storage. Private and secret keys stay inside the cryptographic boundary and are never exported in plaintext; at most they leave wrapped (encrypted) by another key that also never leaves.
  • On-device operations. Signing, encryption, decryption and key wrapping/unwrapping run inside the HSM, so an application sends data in and gets a result back without ever handling the raw key.
  • Access control and audit. Strong authentication, role separation and tamper-resistant logging govern who can use each key and record how it was used.

Because the key never leaves in usable form, stealing the surrounding server does not yield the key.

HSM vs. KMS vs. CMK/BYOK

These terms are often used interchangeably, but they answer different questions:

  • KMS (key management service) is software that manages the lifecycle of keys — creation, rotation, policy, access and auditing — usually exposed as an API.
  • HSM is the hardware root of trust. A KMS is frequently "HSM-backed," meaning the master keys it manages are actually generated and held inside an HSM.
  • CMK / BYOK is about control — whether you, rather than the provider, own and administer the key.

Put simply: CMK decides who controls the key, a KMS decides how the key is managed, and an HSM decides where the key lives and how tamper-resistant its custody is. A customer-managed key very often resides in an HSM-backed KMS.

Assurance: FIPS 140-3, tamper resistance and interfaces

An HSM's value rests on independent assurance that its protections actually hold.

  • FIPS 140-3. This is the current U.S. and Canadian standard for cryptographic modules, superseding FIPS 140-2 (whose validations are being retired). It defines four security levels (1–4) of increasing physical and logical protection; HSMs are commonly validated at Level 3, which adds tamper detection and response and identity-based authentication.
  • Tamper resistance. HSMs combine tamper-evidence (you can tell it was opened) with tamper-response (keys are zeroized if the boundary is breached). Many are also evaluated under Common Criteria.
  • Standard interfaces. Applications talk to HSMs through PKCS#11 (a local API, also called Cryptoki, for talking to a crypto token) and KMIP (a network protocol for key management between a client and a KMS or HSM).

On-prem appliance, cloud HSM, and when you need one

HSMs come in several deployment shapes:

  • On-premises appliance. A physical device in your own data center, giving you direct custody of the hardware.
  • Cloud HSM. A dedicated, single-tenant HSM instance rented from a cloud provider — still a real HSM, just hosted and operated remotely.
  • HSM-backed KMS. A managed KMS whose master keys live in HSMs behind the scenes, giving much of the assurance without operating the hardware yourself.

You typically need an HSM when regulation or contract demands a hardware root of trust: financial services and payments (for example, PCI DSS), public-sector and defense workloads, and public-key infrastructure such as a root or issuing certificate authority.

HSM and ARTESCA

ARTESCA is not an HSM and does not contain one. Instead, ARTESCA is designed to keep encryption keys off the storage array entirely and delegate their custody to a key manager you control — which can be HSM-backed.

ARTESCA encrypts objects at rest using server-side encryption with envelope encryption: each object gets a unique data key, and that data key is wrapped by a master key. When ARTESCA is configured with an external KMS, the master key material never leaves the KMS — only a reference (the key ID) is stored in the object metadata, and object data is never sent to the KMS. Supported external backends include KMIP-compatible key managers (such as Thales CipherTrust Manager, HashiCorp Vault and HyTrust KeyControl) and AWS KMS-compatible services. Any of these can, in turn, be backed by an HSM as their root of trust.

The result is a clean zero-trust separation: your data lives in ARTESCA, your keys live in your KMS or HSM, and no single system holds both. This complements customer-managed keys for control over the key and S3 Object Lock for immutability of the data.

HSM FAQs

What is the difference between an HSM and a KMS?

A KMS is software that manages the key lifecycle (creation, rotation, policy and access). An HSM is the tamper-resistant hardware where keys can be generated and held. They are complementary: a KMS is often "HSM-backed," using an HSM as its root of trust.

Is a cloud HSM still a "real" HSM?

Yes. A cloud HSM is a dedicated, single-tenant hardware module operated by a cloud provider on your behalf. The hardware and its FIPS validation are real; only the hosting and physical custody differ from an on-premises appliance.

What does a FIPS 140-3 level mean?

FIPS 140-3 defines four levels of protection for cryptographic modules. Higher levels add stronger authentication and physical tamper protection. HSMs are commonly validated at Level 3, which requires tamper detection and response plus identity-based authentication.

Do I need an HSM to use customer-managed keys?

Not necessarily. Customer-managed keys are about who controls the key, and can be held in a software KMS. An HSM raises the assurance by ensuring the key material lives in tamper-resistant hardware — which is why many customer-managed keys sit in an HSM-backed KMS.

PKCS#11 or KMIP — what's the difference?

PKCS#11 is a local API for an application to use a cryptographic token or HSM on the same system. KMIP is a network protocol for managing keys between a client and a KMS or HSM. They are complementary standards; ARTESCA integrates with external key managers over KMIP.