What is a hardware security module (HSM)?
On this page
A hardware security module (HSM) is a dedicated, tamper-resistant device that generates and stores cryptographic keys and performs operations with them internally, so that applications can sign or decrypt with a key without the key ever leaving the device in usable form.
What it is
NIST defines an HSM as "a physical computing device that safeguards and manages cryptographic keys and provides cryptographic processing" (NIST glossary). Another NIST definition stresses "tamper-evident and intrusion-resistant safeguarding" of keys. Many teams use HSMs only indirectly, inside a cloud service: AWS says the keys in its KMS are protected by FIPS 140-3 Security Level 3 validated HSMs (AWS KMS).
The property that matters is non-exportability. You can ask the HSM to use a key; you can't ask it for the key.
Where HSMs are used
- Root keys of key management services, which in turn protect data keys for databases and secret stores.
- Certificate authorities, whose signing keys must never be copied.
- Code signing for release builds; see signed release.
- Auto-unseal of server-side vaults, where an HSM holds the key that opens the vault's storage; see vault unsealing.
What an HSM doesn't do
An HSM protects the key, not the decision to use it. Anyone or anything that can send requests to the HSM, with the right credentials, can have it decrypt or sign. If the application that talks to the HSM is compromised, the attacker can use the key through it for as long as they keep access, even though they can never take the key away.
That is why "protected by an HSM" doesn't answer "who can decrypt my data?" It answers "can the key be stolen?" For a cloud secret manager, an HSM-backed KMS key still decrypts values whenever an authorized principal asks, which includes the service itself.
Common mistakes
- Equating HSM-backed with end-to-end. The service holding the HSM still reads the data.
- Weak access to the HSM. A single API credential that can use the key from anywhere is the real secret.
- No plan for loss. If the only copy of a key is in one device, losing the device loses the data.
Crunu and HSMs
Crunu has no HSM. It doesn't store keys in hardware modules, and it doesn't integrate with a cloud KMS for value encryption. Keys are generated and used in the browser through WebCrypto and in the crunu agent. Your account key is derived from your password and a Secret Key on your device; environment keys are sealed to each recipient's public key.
The protection comes from where the keys are, not from hardware: the server never holds a key that decrypts values, so there is nothing on it for an HSM to protect. The trade-off is that keys on devices are only as safe as those devices; Crunu can't protect against malware on a machine where keys are in use. The comparison of models is in who can decrypt your secrets?.
Sources
- NIST CSRC glossary: hardware security module (HSM), checked October 30, 2026.
- AWS Key Management Service: overview, checked October 30, 2026.
From the blog
Security
Customer-managed keys don't stop the cloud from decrypting
With a customer-managed key, AWS, Google Cloud and Azure still decrypt your secrets to serve them. What CMEK really controls, and when that is enough.
Who can decrypt guide
Teams
Removing someone from git-crypt, SOPS or Ansible Vault
None of the three can take back access someone already had. What each tool does when a person leaves, in what order, and why old commits stay readable.
Offboarding guide
Secrets
Should you commit .env files? What belongs in Git
Commit the template, never the values. Which .env files go in Git, what frameworks say, encrypted .env files, and where the real values should live.
Sharing .env files guide