Skip to main content
In this lesson, we explore how integrating a Hardware Security Module (HSM) for auto unsealing Vault boosts security, simplifies operations, and helps meet compliance requirements.
The image is an informational slide explaining what an HSM (Hardware Security Module) is, highlighting its functions, tamper resistance, and deployment options in data centers and cloud services. It also mentions examples like AWS CloudHSM and AWS KMS.
An HSM is a network-attached, tamper-resistant device that generates, manages, and protects cryptographic keys. Common use cases include:
  • Encrypting/decrypting data
  • Digital signatures
  • Strong authentication
  • Secure key storage
If tampering is detected, the HSM can zeroize its keys to prevent unauthorized access. Enterprises with strict security needs—such as banks, telcos, or PCI-DSS environments—often deploy on-premises HSMs. Cloud providers also offer dedicated and shared HSM services, for example:
  • AWS CloudHSM
  • Azure Dedicated HSM
  • AWS KMS (shared HSM-backed)
  • Azure Key Vault (shared HSM-backed)

​
Vault Enterprise HSM Support

Vault Enterprise integrates with any HSM that supports the PKCS#11 standard. Key features include:
FeatureDescription
Root Key ProtectionEncrypts Vault’s root key within the HSM instead of deriving it from Shamir shares.
Auto UnsealVault auto-decrypts its root key by calling the HSM on startup.
Seal WrappingWraps secret data for FIPS 140-2 compliance using an additional HSM layer.
Entropy AugmentationFeeds Vault’s internal RNG with HSM-generated entropy for stronger cryptographic operations.
To use these features, download the Vault Enterprise HSM–enabled binary (suffix +ent+hsm) from releases.hashicorp.com.
The image outlines the general HSM support features of Vault Enterprise, including root key protection, auto unsealing, seal wrapping for FIPS compliance, and entropy augmentation, requiring an HSM that supports the PKCS11 standard.

​
HSM in Vault Initialization

When initializing Vault with HSM auto unseal:
  1. Vault generates the root key.
  2. Vault submits the root key to the HSM.
  3. The HSM encrypts it with its internal key and returns ciphertext.
  4. Vault stores the encrypted root key on its backend.
The image illustrates the process of initializing a Vault using a Hardware Security Module (HSM), showing the steps of passing a root key through the HSM, returning an encrypted root key, and storing it on a storage backend.

​
Auto Unseal Flow

On each Vault restart, auto unseal follows these steps:
  1. Retrieve the encrypted root key from the storage backend.
  2. Send the ciphertext to the HSM for decryption.
  3. Receive the plaintext root key from the HSM.
  4. Use the root key to decrypt Vault’s data-encryption key.
  5. Keep the data-encryption key in memory to handle storage encryption/decryption.
The image illustrates the process of auto unsealing with a Hardware Security Module (HSM), showing the steps of retrieving, passing, and decrypting an encryption key. It includes labeled components like Vault Memory, Storage Backend, and HSM.
This workflow mirrors cloud HSM services (AWS KMS, Azure Key Vault) but keeps traffic on-premises when using a local HSM.

​
Configuring the PKCS#11 Seal Stanza

Add a seal "pkcs11" block to your Vault HCL configuration to enable HSM auto unseal: 
seal "pkcs11" {
  lib            = "/usr/vault/lib/libCryptoki2_64.so"
  slot           = "2305843009213693953"
  pin            = "AAAA-BBBB-CCCC-DDDD"
  key_label      = "vault-hsm-key"
  hmac_key_label = "vault-hsm-hmac-key"
}
Avoid embedding sensitive values (like the HSM PIN) directly in a world-readable file.
Vault supports environment variables for all PKCS#11 parameters so you can inject secrets at runtime without exposing them on disk.
The image lists PKCS11 environment variables related to Vault HSM, with a note stating that memorization is not required for the exam. There's also a Vault certification badge and a cartoon character.

​
References

Watch Video