HSM and Key Management Buyer's Guide: What to Check

Buying a hardware security module (HSM) or key manager is a ten-year decision that is usually made on a feature sheet and a price per unit. The module you choose will hold root CA keys, code signing keys, database master keys and the wrapping keys behind your cloud encryption, and changing it later means migrating keys that were designed never to leave it. This buyer's guide is for security architects, PKI and cryptography teams and procurement leads choosing between network HSMs, PCIe cards, cloud HSM services and enterprise key managers. The wider choice between cloud KMS, external key managers and application encryption is in the Encryption Buyer's Guide; this page goes deeper on the HSM and key manager purchase itself: validation, administration model, performance, interfaces, backup and the commercial terms that decide whether you can ever leave.

Key takeaways

Buy the certificate, not the brochure. Ask for the CMVP certificate number, then check the exact module name, hardware and firmware version and FIPS 140-3 security level on the NIST list. FIPS 140-2 validations remained acceptable until 21 September 2026, when CMVP said they would move to the Historical list, after which they suit existing systems only.
The administration model is the security model. Who can create partitions, add users, export backups and update firmware, and whether those actions need an M of N quorum, matters more than algorithm lists.
Size for peak signing and unwrap load, plus failover. Measure operations per second for your real key types and sizes in a proof of concept, with one node of the cluster down.
Every HSM client is a non-human identity. Applications log in to partitions with PINs, certificates or tokens; how those credentials are issued, stored and rotated is part of the evaluation.
Plan the exit before you sign. Non-exportable keys are the point of an HSM and also the source of lock-in. Agree how keys will move to the next platform, and when the vendor will add post-quantum algorithms inside the validated boundary.

Define requirements

Start from use cases, not from the product class. The same organisation often needs two different answers: a dedicated HSM for a root CA, and a cloud KMS or key manager for thousands of storage and database keys.

Use case	Typical requirement	Likely fit
Offline root CA and issuing CAs	Non-exportable signing keys, quorum for key ceremonies, detailed audit, low volume	Network or USB-attached HSM, often kept offline for the root; see the Enterprise PKI Design and CA Hierarchy Guide
Code and artefact signing	Keys usable only by approved build identities, per-signature logging, timestamping	Network HSM or cloud HSM partition behind a signing service; see the Code Signing Buyer's Guide
Database and storage master keys	KMIP client support, high availability, many keys, low latency	Enterprise key manager, optionally backed by an HSM
Cloud data under your control (BYOK, HYOK)	Key generation outside the cloud provider, connector to cloud KMS, strict availability	Key manager or HSM with cloud connectors; see the BYOK, HYOK and External Key Management Guide
Payments (PIN, card verification, key exchange with schemes)	PCI PTS HSM approval, payment command set, TR-31 key blocks	Payment HSM, a separate product class; see the Payment HSMs guide
Application secrets and tokenisation	API access, high throughput, multi-tenant isolation	Key manager or secrets platform using an HSM as root of trust

Compliance drivers: record which rules apply (FIPS 140-3 for US federal systems and many regulated buyers, PCI DSS Requirement 3 for cardholder data keys, PCI PIN Security for payment keys, sector or eIDAS rules for trust services) and the security level each needs. The Encryption and Key Management Requirements Map lists the main ones.
Volumes: count keys today and in five years, peak operations per second by algorithm (RSA 2048 and 3072 signing, ECDSA P-256 and P-384 signing, AES unwrap), and the number of applications and partitions. A Cryptographic Inventory and CBOM Guide exercise gives realistic numbers.
Locations and availability: data centres and cloud regions, recovery time objective, and whether any keys must stay in a jurisdiction or physically outside a cloud provider.
Operating model: who will run it. Network HSMs need staff for key ceremonies, firmware updates and hardware replacement; a cloud HSM service removes the hardware work but not the user, partition and backup administration.

Capability areas

Form factor	Strengths	Limitations	Questions it raises
Network-attached HSM appliance	Shared by many applications, partitions for tenants, clustering, broad API support	Hardware lifecycle, data centre logistics, specialist skills, support contracts	How many partitions, how are they isolated, and how is a cluster kept in sync?
PCIe card HSM	Low latency inside one server, no network exposure	Tied to the host; the host operating system becomes part of the trust boundary	What happens to keys when the server fails or is retired?
USB or portable HSM	Low cost, suits offline root CAs and small key ceremonies	Low performance, limited redundancy, easy to lose	How are backups made and stored under dual control?
Cloud HSM service (dedicated partitions)	Provider runs hardware; you hold the HSM users and keys; regional clusters	Provider-specific clients and limits; you still own users, quorum and backups	Which validated module and level sits behind it, and who can administer it?
Enterprise key manager	Central policy, KMIP server for storage and databases, connectors to cloud KMS	Another critical dependency; often needs an HSM as its root of trust	Is the key manager itself validated, or only the HSM behind it?

Core capabilities to require in every option: generation of keys inside the validated boundary, non-exportable key attributes enforced by the module, role separation between security officer and crypto users, quorum (M of N) authorisation for sensitive administration, tamper evidence and response, signed firmware, per-operation audit logging, encrypted backup that only your HSMs can restore, and documented high availability.

Evaluation criteria

Criterion	What good looks like	How to verify
FIPS 140-3 validation	Active certificate for the exact hardware and firmware you will run, at Level 3 for most HSM uses; FIPS 140-3 defines four increasing qualitative levels	Search the CMVP validated modules list; read the security policy for the approved mode and its conditions
Approved mode in practice	Clear documentation of how to configure and prove FIPS-approved mode, and what stops working in it	Configure approved mode in the PoC and check the module reports it
Role and quorum model	Security officer, partition or crypto officer and crypto user roles separated; M of N authorisation for user management, backup and firmware updates; authentication with smart cards or tokens for administrators	Attempt a key export and a user creation with a single administrator
Partition isolation	Each application or tenant in its own partition with its own credentials, keys and policies; partition owners cannot see each other's keys	Create two partitions and test cross-partition access
Interfaces	PKCS #11 (version 3.1 or later; check which OASIS version the vendor supports), KMIP 2.1 for key manager functions, Java JCE, Microsoft CNG, OpenSSL providers, REST where needed	Run one real client per interface you need, including your CA and signing software
Performance	Published operations per second for your algorithms and key sizes, with headroom for growth and node failure	Benchmark with your own load profile; repeat with one node down
Backup and recovery	Backups encrypted by keys held only in your HSMs, restorable only into your HSMs, with dual control over backup tokens	Back up, wipe a test partition, restore into a second unit
High availability	Clustering or load balancing with automatic key replication between members, documented behaviour when a member is unreachable	Fail a node during a signing load test
Audit	Signed or tamper-evident audit records of administration and key use, exported to your SIEM with the calling identity	Trace a key creation and a signing operation into the SIEM
Firmware and vulnerability handling	Signed firmware, published security advisories, a firmware upgrade path that keeps validation, and a stated support period	Ask for the last three advisories and how long certified firmware took to ship
Post-quantum roadmap	Dated plan for FIPS 203 ML-KEM, FIPS 204 ML-DSA and FIPS 205 SLH-DSA inside the validated boundary, by firmware where possible	Ask whether existing hardware can be upgraded and when validation is expected
Commercial terms	Clear licensing for partitions, clients and performance tiers; hardware refresh, return and zeroisation terms; end of life notice period	Price a five-year model with growth and a hardware refresh

Questions to ask vendors

What is the CMVP certificate number for the exact module, hardware revision and firmware we will receive, at which FIPS 140-3 level, and when does it expire or move to Historical?
Which administrative actions can be put under M of N quorum, what is the maximum M and N, and can quorum be enforced for firmware updates and backup export?
How are partitions isolated, and can a security officer read keys or audit records in a tenant partition?
Which PKCS #11 version and KMIP version and profiles do you support, and which CA, signing, database and storage products have you tested with?
How do applications authenticate to a partition (PIN, certificate, token), and how do we rotate those credentials without downtime?
What operations per second do you guarantee for RSA 3072 signing, ECDSA P-256 signing and AES key unwrap on the model quoted, and under what test conditions?
How is a backup protected, who can restore it, and can it be restored into a different hardware model or a newer generation?
How do we migrate non-exportable keys to a future model of yours, and to another vendor's module? What is impossible by design?
When will ML-KEM, ML-DSA and SLH-DSA be available inside the validated boundary, and will current hardware support them?
For a cloud HSM service: can your staff administer our partitions or access our backups, and what happens to keys when we leave the service?
How long will you ship security fixes for this model, and how much notice do you give before end of sale and end of support?

Red flags

"FIPS compliant", "FIPS ready" or a certificate for a different hardware or firmware version than the one being sold.
A FIPS 140-2 certificate with no dated FIPS 140-3 plan for the product you are buying.
One administrator account that can create users, export backups and change firmware without a second person.
Backups that the vendor, the cloud provider or support staff can decrypt or restore without your quorum.
Applications expected to log in with a shared partition PIN kept in a configuration file.
Performance figures with no algorithm, key size or test conditions.
No published security advisories or no stated support period for the hardware.
A post-quantum answer that names no FIPS standards and no dates.

Where identity fits

An HSM is only as strong as the identities allowed to use it. Human administrators hold security officer and crypto officer roles; applications, CAs, build pipelines and key managers hold crypto user credentials. Both groups need the same discipline as any privileged access.

Administrators: named individuals with smart card or token authentication, quorum for sensitive actions and no shared accounts. See the HSM Deployment and Operations Guide for the role model in operation.
Applications: one credential per application per partition, held in a secrets manager or bound to the host rather than in a configuration file, rotated on a schedule and on staff change. Our Cryptographic Key Management Guide covers how this fits the key lifecycle.
Signing services: where an HSM signs code or tokens, the identity that may request a signature is as sensitive as the key itself. Evaluate how the product limits which callers may use which key.

Proof of concept

Pick three real workloads: one CA or signing service using PKCS #11, one KMIP client such as a database or storage array, and one application using your main programming language provider (JCE, CNG or OpenSSL).
Configure FIPS-approved mode and confirm the module reports it; record which algorithms and functions are unavailable in that mode.
Set up the role model with separate security officer, partition owner and crypto user roles, and quorum for user management and backup. Attempt each sensitive action with one person and confirm it is refused.
Generate keys as non-exportable and confirm that no interface, including backup, returns key material in clear.
Run a load test with your peak profile, then remove one cluster member and measure throughput, latency and client failover.
Take a backup, destroy a test partition and restore into a second unit under dual control; time it.
Rotate an application's partition credential without downtime.
Send administrative and key use events to your SIEM and confirm each record carries the identity, key label and outcome.
Apply a firmware update in a test cluster and confirm the module stays in its validated configuration and keys survive.

For the first months after purchase, the Cloud key management service (KMS) rollout playbook shows a phased onboarding pattern that applies equally to HSM-backed keys, and the Hardware security module (HSM) maturity model helps set targets.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for HSM and key management purchases, including the machine identities that use the keys. Browse vendors in our NHI and AI products directory or contact us.

HSM and Key Management Buyer’s Guide: evaluation criteria, questions and proof of concept tests