← Back to Blog Tutorials

Hardware Security Modules and PQC: A Buyer's Map

11 min read

A hardware security module is a tamper-resistant device that performs cryptographic operations and stores keys in a way that the keys never leave the device in plaintext. HSMs are how serious enterprises hold root certificate authority keys, code-signing keys, payment card master keys, and high-assurance encryption keys.

When buyers ask, "Does this HSM support post-quantum cryptography," they are really asking several questions at once. This post unpacks those questions and gives a practical map of the HSM market in the context of the NIST PQC standards.

What Counts as an HSM

The HSM category covers a wide spectrum of form factors, from devices that fit on a keychain to refrigerator-sized appliances in data centers. The four main categories matter for PQC because each has different memory, compute, and certification constraints:

Network HSMs. These are 1U or 2U appliances installed in racks. Examples include Thales Luna, Entrust nShield Connect, and Utimaco SecurityServer. They have substantial RAM and CPU, support hundreds of clients over network protocols, and target use cases like PKI roots, payment processing, and database encryption.
Cloud HSMs. These are HSMs offered as a service by cloud providers. AWS CloudHSM, Azure Dedicated HSM, and Google Cloud HSM all fall here. The underlying hardware is typically a network HSM from one of the established vendors, fronted by a cloud API.
USB tokens and smart card sized HSMs. YubiHSM 2, Nitrokey HSM, and various PIV-compatible tokens fit this category. They are cheap, portable, and have tight memory and compute constraints.
Smart cards and SIM-style secure elements. These are the smallest devices, embedded in payment cards, mobile phones, and ID cards. They have severe memory constraints that make ML-DSA and Falcon adoption nontrivial.

Each category has a different PQC adoption path. A network HSM with several gigabytes of RAM has no trouble running ML-KEM-1024 thousands of times per second. A smart card with 8 KB of EEPROM and a 200 MHz controller has to think carefully about which signature scheme it can store keys for.

Why HSMs Lag Software in PQC Adoption

HSM vendors face constraints that pure software vendors do not:

FIPS 140-3 validation. Most enterprise HSM purchases require FIPS 140-3 validated modules. Algorithm changes invalidate the existing validation and require a new evaluation, which costs hundreds of thousands of dollars and takes 12 to 24 months.
Hardware constraints. Some HSM platforms have firmware constraints that make adding new algorithms nontrivial. ML-KEM and ML-DSA require larger working memory than RSA or ECC.
Certification chains. Common Criteria and PCI HSM certifications layer on top of FIPS 140 validation. Each certification has its own algorithm catalog that must include the new PQC algorithms before customers can buy in.
Customer demand. HSM vendors prioritize features their largest customers ask for. Until banks, governments, and certificate authorities commit budget to PQC migration, vendor roadmaps move at the pace of demand.

The good news is that the major vendors have all announced PQC roadmaps and many are shipping firmware updates that expose ML-KEM and ML-DSA in production builds.

The Algorithms That Matter for HSMs

Three NIST PQC standards drive HSM purchasing decisions:

ML-KEM (FIPS 203). Key encapsulation mechanism. Replaces RSA-OAEP and elliptic curve key agreement for hybrid key establishment. ML-KEM-512, 768, and 1024 are the parameter sets.
ML-DSA (FIPS 204). Digital signature standard based on module lattices. Replaces RSA and ECDSA for most signing use cases. ML-DSA-44, 65, and 87 are the parameter sets.
SLH-DSA (FIPS 205). Stateless hash-based digital signature standard. A conservative backup for cases where lattice assumptions might be questioned. Larger and slower than ML-DSA.

For background on the differences between ML-DSA and SLH-DSA, see our ML-DSA vs SLH-DSA post.

Some HSM vendors also support Falcon, which is an older candidate that NIST is standardizing as FN-DSA. Falcon has smaller signatures than ML-DSA but more complex implementation requirements due to floating-point arithmetic.

What to Ask When Evaluating an HSM for PQC

When sizing up an HSM purchase with PQC in mind, the buyer's checklist should include:

Which algorithms are in the firmware today? Ask for explicit version numbers. Check whether ML-KEM-768 and ML-DSA-65 are in the production build or only in beta firmware.
What is the FIPS 140-3 validation status? A firmware version that adds ML-KEM but loses FIPS validation does not satisfy compliance requirements. The validation must cover the PQC algorithms.
Does the management console expose PQC operations? Some firmware updates expose new algorithms only at the PKCS#11 layer, not in the GUI. This affects operational ease.
What are the hybrid mode options? Hybrid signatures and hybrid KEMs combine classical and PQC algorithms. Vendors approach this differently. Some implement dedicated hybrid algorithms. Others expect the operator to compose two operations.
What is the migration path? Can you rotate from RSA-4096 to ML-DSA-65 within an existing key hierarchy, or do you need to roll out a new HSM partition?
What does the throughput look like? ML-DSA verification is fast. ML-DSA signing is slower than ECDSA on the same hardware. For a code-signing HSM that processes millions of signatures per day, this matters.

Network HSM Snapshot

The major network HSM vendors and their positioning relative to PQC:

Thales Luna 7. Firmware updates have added ML-KEM and ML-DSA support in recent revisions. FIPS 140-3 validation tracking is published by NIST CMVP.
Entrust nShield 5. The latest generation supports CodeSafe sandboxed code execution, which lets customers deploy PQC implementations as guest applications inside the HSM boundary.
Utimaco SecurityServer. Firmware lines have added ML-KEM and ML-DSA in beta and general availability builds. Compliance trajectory follows NIST CMVP timelines.

For deeper coverage of each vendor see our individual posts.

Cloud HSM Snapshot

Cloud HSM offerings inherit the underlying hardware vendor's roadmap:

AWS CloudHSM. Backed by Marvell LiquidSecurity HSMs. PQC algorithm availability in the AWS API tracks the Marvell firmware roadmap. AWS KMS, which is separate from CloudHSM, has its own roadmap that we cover in aws-kms-quantum-migration.
Azure Dedicated HSM. Customer-dedicated Thales Luna 7 hardware. PQC support follows Thales firmware availability.
Google Cloud HSM. Backed by Marvell and Thales hardware depending on region.

Cloud HSMs typically lag standalone deployments in algorithm availability because the cloud provider must validate, integrate, and roll out across regions before exposing the new algorithms to customers.

USB Token Snapshot

USB-form HSMs and tokens face tighter constraints:

YubiHSM 2. Yubico's small-form HSM. PQC roadmap depends on firmware bandwidth. Memory constraints make Falcon-512 attractive.
Nitrokey HSM. Open-source-friendly HSM token. PQC support depends on the underlying SmartCard-HSM firmware roadmap.
PIV cards. PIV is a US federal credential standard. PQC migration of PIV is a multi-year effort coordinated by NIST.

For a closer look at YubiKey integration see our YubiKey integration post.

Smart Card Constraints

Smart cards have the toughest memory and compute budgets in the HSM ecosystem. Typical numbers:

ROM: 256 KB
RAM: 8 to 16 KB
EEPROM: 32 to 256 KB
CPU: 8 to 32 bit microcontroller, 50 to 200 MHz

ML-DSA-44 keys are around 1312 bytes for the public key and 2560 bytes for the private key. Signatures are around 2420 bytes. These sizes are on the edge of what a smart card can handle, especially when the device must also store legacy RSA or ECC keys.

Falcon-512 has smaller signatures (around 666 bytes), making it attractive for smart card use. The downside is that Falcon signing requires floating-point arithmetic that is hard to implement constant-time on small microcontrollers.

For a deeper dive on smart card constraints see our smart cards and PQC post.

Procurement Timeline Considerations

If you are buying HSMs in 2026 or 2027, the realistic posture is:

Buy hardware that supports firmware upgrades to PQC. Avoid devices where the silicon cannot handle ML-KEM-1024 or ML-DSA-65 without performance collapse.
Plan for two-stage rollout. First stage: deploy with hybrid mode where supported. Second stage: when validation completes, switch to pure PQC for new keys.
Budget for replacement of older HSMs. Devices from before 2020 may not have the firmware headroom for PQC.
Track CMVP listings. The NIST Cryptographic Module Validation Program publishes the official list of validated modules. Filter for FIPS 140-3 modules with ML-KEM or ML-DSA in the algorithm certificate.

Side-Channel Considerations

Hardware security modules earn their price by resisting side-channel attacks: timing analysis, power analysis, electromagnetic emissions, and various fault injection techniques. PQC algorithms must be implemented with the same side-channel resistance as classical algorithms.

For HSM vendors, this is a substantial engineering effort. The reference implementations of ML-KEM and ML-DSA published by NIST are not necessarily side-channel resistant. Vendors must:

Adapt the algorithm implementations for constant-time execution
Add masking or shuffling to hide power consumption patterns
Test against electromagnetic side-channel attacks in lab conditions
Submit the resulting implementations to FIPS 140-3 validation testing

This is why PQC support in HSM firmware lags pure software implementations by months. The validation and side-channel hardening work is non-trivial.

For buyers, the practical question is whether the vendor publishes side-channel test results for their PQC implementations. Some vendors are transparent about this; others are not. Request side-channel testing documentation as part of the procurement process.

Operational Considerations Beyond Algorithms

PQC migration in HSMs touches operational concerns beyond the cryptographic core:

Key ceremonies. Generating a CA root key on an HSM is a high-stakes ceremony with multiple operators, video recording, and detailed documentation. PQC keys add new variables: parameter set selection, hybrid composition, and verification of correct generation.
Backup and recovery. Most enterprise HSM deployments include offline backup of key material. PQC keys are larger; backup file sizes grow proportionally. Recovery procedures must be tested with PQC keys.
Multi-HSM replication. Many deployments replicate keys across multiple HSMs for high availability. The replication protocol must handle PQC key types.
Auditing. PQC operations may generate different audit log entries. SIEM rules must be updated.
Operator training. HSM operators need training on the new key types, parameter set choices, and migration procedures.

Cost and Timeline Realism

A realistic PQC migration timeline for an enterprise HSM deployment runs over several years:

Year 1. Inventory keys, audit applications, plan algorithm choices, evaluate vendor PQC roadmaps. Stand up a non-production HSM with PQC firmware for testing.
Year 2. Roll out PQC firmware to production HSMs. Generate PQC keys for new use cases. Begin parallel operation alongside classical keys.
Year 3. Migrate existing key holders to PQC keys. Run hybrid where appropriate. Test cross-organization interoperability.
Year 4. Begin deprecating classical keys for new operations. Maintain decryption capability for older ciphertext.
Year 5+. Continue parallel operation for ciphertext that has not yet rotated. Eventually retire classical keys.

For organizations under CNSA 2.0 mandate or similar regulatory timelines, the schedule may compress.

Procurement Decision Framework

When evaluating an HSM purchase with PQC in mind, decisions span several axes:

Algorithm coverage today. What is in the firmware now? What is in the validated firmware now (which may be different)?
Algorithm coverage roadmap. What is the publicly committed timeline for the algorithms not yet shipped?
Hybrid mode support. Native hybrid versus application-level composition.
Performance. Throughput numbers for the algorithms you care about.
Validation status. FIPS 140-3 listing for the firmware version of interest.
Vendor stability. HSM purchases are 5- to 10-year commitments. Vendor financial health matters.
Ecosystem support. PKCS#11, KMIP, and JCE provider compatibility.
Operator tooling. Management console, automation APIs, monitoring integration.

A well-run procurement weighs all of these rather than fixating on one dimension.

Frequently Asked Questions

Do I need a new HSM to do post-quantum crypto? Not necessarily. Many enterprise HSM lines from 2020 onward can run ML-KEM and ML-DSA via firmware updates. Older devices may not have the memory headroom. Check vendor documentation for the specific model.

What is the best HSM for PQC right now? There is no single answer. The right choice depends on form factor, throughput needs, certification requirements, and existing vendor relationships. Network HSMs from Thales, Entrust, and Utimaco all have credible PQC roadmaps.

Are cloud HSMs lagging behind standalone HSMs? Generally yes, by six to twelve months on average, because the cloud provider must integrate and validate before exposing new algorithms. AWS, Azure, and Google all have PQC on the roadmap.

Should I wait for FIPS 140-3 validation before migrating? It depends on your compliance posture. For regulated industries that mandate validated modules, yes. For defense-in-depth applications, deploying PQC in software while waiting for HSM validation is a sensible interim posture.

What if my use case is signing rather than encryption? ML-DSA-65 is the typical recommendation for general-purpose signing. SLH-DSA is the conservative backup. For long-lived signatures (code signing for software that must verify in 30 years), SLH-DSA is the safer choice despite the larger signature size.

Sources

NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard." 2024.
NIST. "FIPS 204: Module-Lattice-Based Digital Signature Standard." 2024.
NIST. "FIPS 205: Stateless Hash-Based Digital Signature Standard." 2024.
NIST CMVP. "Cryptographic Module Validation Program." https://csrc.nist.gov/projects/cryptographic-module-validation-program
OASIS. "PKCS #11 Cryptographic Token Interface Standard." https://docs.oasis-open.org/pkcs11/
NIST. "Post-Quantum Cryptography Standardization." https://csrc.nist.gov/projects/post-quantum-cryptography

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY