Hardware Security Module (HSM)

A Hardware Security Module (HSM) is a tamper-resistant physical device that generates, stores, and uses cryptographic keys within isolated secure hardware, ensuring the private key never exists in software, system memory, or configuration files where an attacker could access it.

That single principle is what makes an HSM different from other key storage approaches. The private key never leaves the device in plaintext form. This is not just one security feature among many. It is the foundation of the entire HSM security model, and every other protection an HSM provides is built around it.

What is a hardware security module?

A Hardware Security Module (HSM) is a dedicated cryptographic processor designed to perform encryption, decryption, digital signing, and key management operations inside a physically protected and logically isolated environment. HSMs are available in several forms, including network-attached appliances, PCIe cards, USB tokens, and cloud-based services.

Keys created inside an HSM remain inside the device throughout their lifecycle. When an application needs to use a key, it sends the required operation to the HSM. The device performs the cryptographic function internally and returns only the result. At no point is the private key exposed to the operating system, application, or network.

Many HSMs also include physical protections that detect tampering attempts. If someone tries to access the device improperly, it can automatically erase its stored cryptographic material before any key data can be recovered.

Because of these protections, HSMs are widely used as the root of trust for critical security infrastructure. They protect the keys that underpin certificate authorities, identity providers, payment systems, code-signing platforms, and other systems where cryptographic trust must be preserved.

Quick summary

Three security properties that define HSMs

1. Key isolation

Cryptographic keys generated inside an HSM never leave it in plaintext form. When an application needs to perform a signing or decryption operation, it sends the request to the HSM through an API. The HSM performs the operation internally and returns only the result. The key material itself is never exposed to the host operating system, application, or network interface.

This eliminates an entire class of attacks. Memory scraping, process injection, configuration file theft, and environment variable exposure cannot compromise a key that exists only inside dedicated hardware.

2. Tamper resistance and zeroization

HSMs are physically designed to resist intrusion. Their enclosures can detect unauthorized opening attempts, voltage irregularities, temperature anomalies, and electromagnetic probing. If tampering is detected, the HSM immediately zeroizes, erasing stored key material before it can be extracted.

This capability is particularly important in environments where physical access cannot be completely controlled, such as co-location facilities, cross-border deployments, or supply chain operations. Even if an HSM is stolen, seized, or tampered with, it is designed to prevent attackers from recovering usable key material.

3. Hardware-backed entropy

The strength of a cryptographic key depends heavily on the quality of the randomness used to generate it. HSMs use hardware random number generators (HRNGs) that derive entropy from physical sources such as electronic noise, thermal fluctuations, or quantum effects, rather than relying solely on software pseudo-random number generators (PRNGs).

The result is stronger, less predictable, and non-reproducible cryptographic keys that provide a higher level of assurance than software-generated alternatives.

HSM deployment types

A critical distinction: Cloud HSMs such as AWS CloudHSM, Azure Dedicated HSM, and Google Cloud HSM provide dedicated physical hardware located within the cloud provider's data centers. Customers retain exclusive control over their HSM partitions and the cryptographic keys stored within them.

Cloud KMS services, such as AWS KMS or Azure Key Vault standard tiers, take a different approach. While keys may be protected by HSM-backed infrastructure, customers do not control the underlying hardware, and key management is handled through a shared service model.

For organizations that must maintain customer-exclusive key custody to satisfy regulatory, contractual, or compliance requirements, a cloud HSM is typically the appropriate choice. A standard cloud KMS may not meet those requirements.

Where HSMs appear in identity and access management

HSMs are often associated with payment systems and PKI, but their role within identity and access management has grown significantly. Today, they frequently serve as the hardware root of trust for authentication systems, signing services, and workload identity platforms.

• Certificate Authority root keys
  The root CA certificate acts as the trust anchor for every certificate issued within an organization's PKI. If the root CA private key is compromised, attackers can create fraudulent certificates that appear legitimate. For this reason, best practices and many compliance frameworks require root CA keys to be generated, stored, and used only within an HSM, often under strict dual-control procedures.
• FIDO2 and passkey infrastructure
  Large-scale FIDO2 deployments rely on secure attestation processes to validate authenticator registrations. Enterprise implementations commonly store attestation-related keys within HSMs. Together, hardware-backed keys on authenticators and HSM-protected keys on the server side provide strong assurance for passwordless authentication.
• Workload identity certificates (SPIFFE/SPIRE)
  SPIFFE-based workload identity systems issue short-lived SVIDs to workloads through a certificate authority. The CA signing key becomes the trust anchor for the entire workload identity system. Protecting that key inside an HSM reduces the risk of compromise through software-based attacks.
• Signing keys for identity tokens
  Identity providers use private keys to sign JWT access tokens, SAML assertions, and OpenID Connect ID tokens. If those signing keys are exposed, attackers can generate valid identity tokens and impersonate legitimate users. Storing signing keys in an HSM provides one of the strongest available protections against this risk.
• Code signing for software supply chains
  Organizations use code-signing keys to verify the authenticity and integrity of software packages, container images, and firmware. A compromised signing key can allow malicious software to appear trustworthy. HSM-backed code signing helps prevent this by ensuring the signing key never leaves protected hardware.

HSM vs. TPM vs. software key storage

These three mechanisms serve related but distinct purposes. Confusing them leads to compliance gaps and mismatched security controls.

Summary: HSMs serve enterprise-wide, multi-application key management. TPMs serve device-level attestation and integrity. Software key storage serves development environments and low-assurance use cases. Treating software keystores as equivalent to HSMs for compliance purposes is a common audit failure.

Compliance standards that reference HSMs

HSMs are either required or strongly recommended by many major security and compliance frameworks because they provide a high-assurance method for protecting cryptographic keys.

• FIPS 140-2 / FIPS 140-3
  The U.S. federal standards for cryptographic modules. Level 2 introduces physical tamper evidence, while Level 3 adds tamper resistance and automatic response mechanisms such as zeroization. Most enterprise-grade HSMs are validated at Level 3.
• PCI DSS
  Requires strong controls around payment encryption keys and cardholder data environments. Payment HSMs are commonly used to protect PIN encryption keys, manage cryptographic operations, and support payment transaction signing.
• Common Criteria
  An internationally recognized security evaluation framework. Many enterprise HSMs undergo Common Criteria evaluations and achieve certifications such as EAL4+.
• eIDAS / EU Digital Identity Wallet
  Supports legally binding electronic signatures through Qualified Signature Creation Devices (QSCDs). HSMs are commonly used as the hardware foundation for these implementations.
• NIST SP 800-57
  Provides guidance on cryptographic key management and recommends hardware-backed protection for high-value and long-lived cryptographic keys.

Industry use cases

Financial services: payment HSM

Payment processors rely on dedicated payment HSMs to protect PIN encryption keys and transaction-signing operations. PIN blocks are encrypted within the HSM before being transmitted across the network, ensuring the underlying keys are never exposed outside secure hardware.

To maintain compliance, organizations undergo regular PCI HSM audits that validate physical security controls, operational procedures, and key management practices. New HSM deployments often involve formal key ceremonies conducted under dual-control procedures with documented oversight.

Enterprise PKI: root CA protection

Large enterprises frequently operate their own PKI to manage employee device certificates, TLS certificates, and code-signing infrastructure. In these environments, root and intermediate CA private keys are commonly stored in network-attached HSMs located within dedicated key management facilities.

Production certificate issuance typically occurs through HSM-protected intermediate CAs, while root CA operations are reserved for specific administrative events. Access to root CA keys is tightly controlled and often requires documented dual-control procedures.

Cloud-native identity infrastructure

Modern cloud-native organizations increasingly rely on HSMs to protect identity-related signing keys. For example, a SaaS provider may store FIDO2 attestation keys and SPIFFE CA signing keys within AWS CloudHSM, maintaining exclusive control over the hardware partition and cryptographic material.

This approach helps satisfy regulatory and audit requirements while ensuring that critical identity infrastructure remains protected by hardware-backed controls. Developer code-signing workflows can also leverage HSM-backed keys, with every signing event recorded for accountability and auditing.

Operational considerations: planning an HSM deployment

High availability architecture

Without redundancy, an HSM can become a single point of cryptographic failure. To avoid this risk, organizations commonly deploy network-attached HSMs in active-active or active-passive clusters. Cloud HSM offerings also support deployment across multiple availability zones.

Maintaining availability requires careful planning for key replication, synchronization, and master key management across cluster members.

Throughput and latency

Although HSMs perform cryptographic operations efficiently, they are still finite resources that require capacity planning. High-volume workloads such as TLS termination, certificate issuance, and token signing can place significant demand on HSM infrastructure.

PCIe-based HSMs are often preferred for latency-sensitive workloads, while network-attached HSMs provide greater flexibility at the cost of additional network round trips.

Key ceremonies

Initializing an HSM, especially for root CA environments, is typically a formal security process rather than a simple administrative task. Key ceremonies often involve multiple administrators, documented procedures, physical presence requirements, and witnessed logging.

Organizations frequently underestimate the importance of these processes until compliance reviews reveal gaps in documentation or evidence collection.

Backup and recovery

Cryptographic keys must be recoverable without weakening the HSM security model. To accomplish this, HSMs use encrypted backups protected by master keys. Those backups can generally be restored only to authorized HSMs that possess the appropriate cryptographic trust relationship.

A complete deployment plan should include backup procedures, master key protection, recovery testing, and periodic validation to ensure keys can be restored when needed without compromising security.

Frequently Asked Questions

What is a hardware security module (HSM) used for?

HSMs are used wherever private cryptographic keys must be protected from software-based compromise. Common use cases include securing PKI root and intermediate CA keys, protecting identity provider signing keys for JWT and SAML tokens, safeguarding payment encryption keys, supporting code-signing operations, and protecting workload identity certificate authorities in SPIFFE/SPIRE environments. While these use cases serve different functions, they all rely on the same principle: protecting high-value cryptographic keys that act as trust anchors for critical systems.

What is the difference between an HSM and a TPM?

A TPM (Trusted Platform Module) is a hardware chip embedded in a single device and is primarily used for functions such as secure boot, device attestation, and disk encryption. An HSM serves a broader purpose. It is a dedicated cryptographic appliance, available as a network-attached device, PCIe card, or cloud service, that provides centralized key management for multiple users, applications, and systems. In simple terms, TPMs protect individual devices, while HSMs protect an organization's cryptographic infrastructure. The two technologies complement each other but are not interchangeable.

What is the difference between a cloud HSM and a cloud KMS?

A cloud HSM provides dedicated physical hardware within a cloud provider's environment, giving customers exclusive control over their HSM partition and the cryptographic keys stored within it. A cloud KMS, by contrast, is a managed key management service that simplifies key lifecycle operations and integrations. Although KMS platforms may use HSM-backed infrastructure behind the scenes, customers do not directly control the underlying hardware. For organizations that require exclusive key custody because of regulatory, contractual, or compliance requirements, a cloud HSM is often the preferred choice. For many general encryption and key management needs, a cloud KMS may be sufficient.

What does FIPS 140-2 / FIPS 140-3 mean for HSMs?

FIPS 140-2 and FIPS 140-3 are U.S. government standards that define security requirements for cryptographic modules. HSM vendors submit their products for independent testing to validate compliance with these standards. The validation levels represent increasing security requirements, ranging from basic cryptographic functionality to advanced protections such as tamper evidence, tamper resistance, and automatic zeroization when tampering is detected. Most enterprise HSMs are validated at Level 3 because it offers a strong balance between security assurance and operational practicality. Many government agencies and regulated industries require FIPS-validated cryptographic modules as part of their compliance programs.

Can HSMs protect non-human identity credentials?

Yes. Protecting non-human identities has become one of the fastest-growing HSM use cases. Workload identity certificate authorities, service account signing keys, API gateway signing keys, machine identities, and IoT device provisioning keys all depend on cryptographic trust. If the signing key behind any of these systems is compromised, attackers can create fraudulent identities that appear legitimate. By storing and using these signing keys within an HSM, organizations extend hardware-rooted trust beyond human authentication and into the broader machine identity ecosystem, strengthening security across modern cloud, application, and infrastructure environments.

Related Terms

• Cryptographic Identity Binding

• Public Key Infrastructure (PKI)

• Certificate Lifecycle Management

• FIDO2 / WebAuthn

• Workload Identity

• Ephemeral Credentials

• Non-Human Identity (NHI)

• Zero Trust Architecture