A hardware security module (HSM) is a specialized, tamper-resistant device, or a cloud service built on such devices, that generates, stores and uses cryptographic keys. Applications send the HSM a request, such as “sign this” or “decrypt this”, and the HSM does the work internally. The usual policy is that sensitive private and symmetric keys stay inside the HSM; public keys, and securely wrapped key material for backup or transfer, may be exported where the product’s policy allows. HSMs protect the most sensitive keys an organization holds, such as certificate authority root keys, database encryption keys, code-signing keys and payment keys.
At a glance
- An HSM keeps sensitive private and symmetric keys inside hardened hardware and performs encryption, decryption and signing there; public keys and securely wrapped backups may leave it where policy allows.
- HSMs come as network appliances, plug-in cards, USB devices and cloud services offered by many cloud providers.
- Many are validated to FIPS 140 at a security level that varies by product and model.
- Common uses include public key infrastructure (PKI), database and storage encryption, code signing and payment processing.
- Key backup, high availability and access control need careful design, because a lost HSM key can mean lost data.
What problem it solves
Encryption is only as strong as the protection of its keys. If a private key sits in a file on a server, anyone who compromises that server, or a backup of it, can copy the key and use it elsewhere: to decrypt data, impersonate a website or sign malicious software that looks legitimate. Software-only key storage also makes it hard to prove to auditors who used a key and when.
An HSM moves keys into hardware designed to resist extraction and tampering. Sensitive keys are typically generated and used inside the device, and are exported, where policy allows, only as securely wrapped key material for backup or transfer. Public keys can be shared freely. Access requires authenticated administrators, often with several people needed to approve sensitive actions, and the device logs what happens. This gives a much higher level of assurance for the keys that matter most, and it is often what auditors, payment networks and certificate standards expect.
How it works
Hardened hardware. HSMs use tamper-resistant and tamper-evident designs. Depending on the product and its security level, opening or tampering with the device may trigger deletion of its keys.
Key operations inside the device. Applications connect through standard interfaces such as PKCS#11, Microsoft CNG or KMIP, or through a vendor API. They ask the HSM to generate a key, encrypt, decrypt or sign, and usually receive the result, not the sensitive key itself.
Roles and quorum. Administrative tasks are separated among roles, and critical actions may require approval from several security officers, each holding a smart card or credential.
Backup and high availability. Keys are backed up in encrypted form to another HSM or a protected backup, and HSMs are usually deployed in clusters so services keep running if one fails.
Cloud options. Many cloud providers offer dedicated cloud HSMs and also key management services that are backed by HSMs. Some organizations keep keys in their own HSM while encrypting data in the cloud, often called “bring your own key” or “hold your own key”, depending on how much control they need.
When it matters for buyers
- When running your own certificate authority. Root and issuing keys are usually expected to be in an HSM, and certificate lifecycle management tools often integrate with one.
- When moving sensitive data to the cloud. Deciding who controls the encryption keys is a key cloud security choice. See our public cloud overview for the wider picture.
- When handling payments. Payment processing often requires HSMs certified for payment use; requirements depend on your role in the payment chain.
- When signing software or documents. Some code-signing certificate rules require keys to be stored in an HSM or similar hardware.
- When planning for post-quantum cryptography. HSMs are long-lived, so ask how they will support post-quantum cryptography (PQC) algorithms.
Questions to ask vendors
- Which FIPS 140 version and level is this exact model and firmware validated to, and in which mode?
- Which interfaces and applications do you integrate with, such as our PKI, database or cloud provider?
- How are keys backed up, and how do we recover if an HSM or a whole site fails?
- What does high availability cost, and how many devices do we need?
- Is the cloud option a dedicated HSM or a shared key management service, and who can administer it?
- What is your roadmap for post-quantum algorithms, and will it need new hardware?
- What happens to keys and devices at end of contract or end of life?
How it differs from PKI
Public key infrastructure (PKI) is the whole system of certificate authorities, policies and processes that issue and manage digital certificates. An HSM is a component that PKI often relies on: it protects the certificate authority’s private keys and performs the signing when certificates are issued. You can run PKI without an HSM, storing keys in software, but for root and issuing keys an HSM is usually considered best practice. HSMs are also used well beyond PKI, wherever keys need hardware-level protection.