Do I need an HSM or is a cloud KMS enough?

A cloud KMS is backed by HSMs and is enough for most application encryption keys. You need a dedicated or single-tenant HSM when a regulation, a certificate policy or a contract requires control of the module itself, when you need a specific API such as PKCS#11 with custom mechanisms, or when you must hold keys outside a cloud provider's control.

Is FIPS 140-3 Level 3 always better than Level 2?

Level 3 adds identity-based operator authentication and physical tamper response, which matters for devices in shared or less trusted spaces. For a module in a locked cage, Level 2 may satisfy the requirement. Buy the level your policy or auditor requires, and check that the validated configuration matches how you will run it.

Can I test PKCS#11 code without buying an HSM?

Yes. SoftHSM2 implements the PKCS#11 interface in software and is ideal for development and CI. It offers none of the physical protection of an HSM, so never use it for production keys.

Choosing an HSM: FIPS 140-3, PKCS#11 and form factors

A hardware security module (HSM) is a hardened, tamper-responsive computer whose only job is to generate, store and use cryptographic keys without ever exposing them. HSMs sit behind certificate authorities, code-signing pipelines, payment networks, DNSSEC signers and cloud key management services. When a single private key would be catastrophic to lose or leak, it belongs in one.

This guide covers what to look for when you select an HSM, and how certifications, APIs and form factors map to real use cases.

What an HSM gives you that a server does not

Non-exportable keys. Keys are generated inside the boundary and can be marked non-extractable. Applications send data in and get signatures or ciphertext out.
Tamper response. Higher-assurance modules detect physical intrusion (drilling, opening, voltage or temperature abuse) and erase key material.
Role separation and quorum. Security officers, crypto officers and users are distinct roles; sensitive actions can require M of N smart cards or credentials.
Audit logs of key use and administration, signed or protected by the module.
Certified implementations of algorithms and random number generation.

FIPS 140-3 levels in plain language

FIPS 140-3 (which superseded FIPS 140-2 for new validations, aligned with ISO/IEC 19790) is run by the NIST Cryptographic Module Validation Program (CMVP). It defines four security levels:

Level	In short	Typical products
1	Approved algorithms, correct implementation; no physical security requirement	Software crypto libraries
2	Adds tamper evidence (seals, coatings) and role-based authentication	Many USB tokens and smart cards
3	Adds tamper response, identity-based authentication, stronger separation of key entry	Most network and PCIe HSMs for PKI and payments
4	Adds protection against environmental attacks (voltage and temperature out of range) and a complete protective envelope	Few products; very high assurance use

Three details matter more than the headline number:

Certificates are per module and firmware version. Look up the certificate number in the CMVP database and check the exact hardware and firmware versions listed.
The security policy document defines the approved mode. Running the module outside that configuration can take you out of the validated state.
Historical certificates move to the historical list after their sunset date. Existing deployments can often continue, but new procurements usually require an active certificate.

Other schemes you will see: Common Criteria evaluations (often EAL4+ against a protection profile such as EN 419221-5 for trust services in the EU), and PCI PTS HSM for payment HSMs.

Form factors

Form factor	Shape	Good for	Trade-offs
Network HSM	1U/2U appliance on the LAN	Shared service for many applications, PKI, clustering	Requires rack space, network design, client software
PCIe card	Card inside one server	Low latency for a single host, offline root CAs	Tied to one machine; availability depends on that host
USB HSM / token	Small USB device	Offline root CA, small teams, lab work, code signing on one workstation	Lower throughput, fewer management features
Cloud HSM (single-tenant)	Dedicated HSM in a cloud region	Cloud workloads that need their own module and PKCS#11	You manage clusters and backups; the provider manages hardware
Cloud KMS	Multi-tenant API backed by HSMs	Envelope encryption, most application keys	You do not control the module; limited algorithms and APIs

APIs and integration

The API decides how much work integration will be:

PKCS#11 (Cryptoki) is the lingua franca: OpenSSL (via a provider or engine), Java via SunPKCS11, EJBCA, HashiCorp Vault, BIND and OpenDNSSEC, signing tools and many databases speak it.
Microsoft CNG / KSP for Windows services such as AD CS and SignTool.
Java JCE/JCA providers for Java applications.
KMIP for key lifecycle management between a key manager and storage or database encryption.
Vendor REST or SDK APIs, increasingly common for cloud and newer appliances.

Before buying, list every application that will use the HSM and confirm the exact mechanism support (for example ECDSA on P-384, RSA-PSS, EdDSA, AES-GCM, or post-quantum algorithms such as ML-DSA if you plan to pilot them).

Developing against PKCS#11 without hardware

SoftHSM2 implements PKCS#11 in software, which makes it ideal for development and CI pipelines:

# Create a token
softhsm2-util --init-token --free --label dev-token --so-pin 0000 --pin 1234

# List slots and tokens with OpenSC's generic tool
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --list-slots

# Generate an EC P-256 key pair on the token
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --pin 1234 \
  --keypairgen --key-type EC:prime256v1 --label signing-key

# List objects
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --pin 1234 --list-objects

The module path varies by distribution (for example /usr/lib/x86_64-linux-gnu/softhsm/libsofthsm2.so on Debian and Ubuntu). When you move to a real HSM, you change the module path and the credentials, not the application logic. The PINs above are throwaway development values.

Use cases and what they need

Use case	Key requirement	Typical choice
Offline root CA	Highest assurance, rarely used, strict ceremony	USB or PCIe HSM in a safe, FIPS 140 Level 3
Issuing CA	Online, audited, highly available	Network HSM cluster
Public code signing	Industry rules require keys in hardware	FIPS 140 Level 2+ or Common Criteria EAL4+ token or HSM, or a cloud signing service backed by one
DNSSEC	Automated signing, key rollover	Network HSM or cloud HSM with PKCS#11
Payments (PIN, card keys)	PCI PTS HSM, payment-specific commands	Dedicated payment HSM
Application secrets, database TDE	Envelope encryption at scale	Cloud KMS or KMIP key manager backed by HSM

For publicly trusted code-signing certificates, the CA/Browser Forum baseline requirements have required private keys to be generated and stored in hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL4+ since June 2023. That rule is why developers now receive signing certificates on tokens or use cloud signing services.

Key ceremonies and quorum

For root keys, the way you use the HSM matters as much as the HSM:

Script the ceremony in advance: every command, every role, expected outputs.
Use split knowledge and dual control. Quorum authentication (for example 3 of 5 cards) for key generation, backup and restore.
Record everything. Video, signed logs, witness signatures, hashes of exported public keys and certificates.
Back up keys to other HSMs using the vendor's wrapped backup mechanism, and store backup tokens in separate locations.
Store credentials separately from the device: smart cards and PINs in different safes held by different people.

Selection checklist

Which regulation, certificate policy or contract sets the minimum assurance level?
Is there an active FIPS 140-3 (or required Common Criteria / PCI) certificate for the exact model and firmware?
Does it support every algorithm and API your applications need, today and on your cryptographic roadmap?
How are high availability, clustering, backup and disaster recovery handled?
What does role separation and quorum look like, and can it be enforced by policy?
How are firmware updates delivered and validated, and what happens to certification after an update?
What are the support lifetime and end-of-life policy, and how do you migrate keys to a successor model?
How does the device log, and can those logs reach your SIEM?

An HSM does not fix weak processes. It gives you a boundary that keys cannot leave; your ceremonies, access control and monitoring decide who gets to ask it to sign.