HSM Procurement: Five PQC Readiness Criteria for 2026

Enterprise hardware security module fleets have five to ten year hardware lifecycles. An HSM purchased in 2024 with a seven-year operational life will be processing key management operations through 2031. The Q-Day timeline for a cryptographically relevant quantum computer falls approximately in the 2033 to 2035 range. A 2026 procurement decision either buys hardware that can handle the transition or buys hardware that will need replacement before the transition completes.

This is not a theoretical constraint. CNSA 2.0 transition timelines for National Security Systems have already started. BSI TR-02102-1 (2024 edition) and ANSSI guidance for European financial and government organisations already include ML-KEM and ML-DSA in recommended algorithm sets. The procurement question in 2026 is concrete: does this HSM support ML-KEM-1024 and ML-DSA-87 with a valid FIPS 140-3 CMVP certificate, and will it continue to do so for the operational life of the hardware?

Five criteria answer that question. Each is addressed below with a concrete evaluation approach and one vendor-specific example.

Criterion 1: FIPS 140-3 Validation Scope for PQC Algorithms Specifically

FIPS 140-3 Level 3 certifies the physical security mechanisms and role-based authentication of the HSM module. It does not guarantee any specific cryptographic algorithm is present or validated. Cryptographic algorithm validation is handled separately through the CMVP's Automated Cryptographic Validation Testing System (ACVTS). NIST added ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) to the ACVTS catalogue after their August 2024 publication. Any HSM with a FIPS 140-3 certificate predating August 2024 has not been tested for PQC algorithms, regardless of what the vendor's firmware may now support.

The procurement requirement is specific: ask for the CMVP certificate number, the security policy document, and the explicit list of algorithms within the validation boundary. A certificate covering RSA, ECDSA, and AES does not cover ML-KEM or ML-DSA. A firmware update that adds PQC support is not automatically within the validated boundary until a delta validation or new submission has been approved by NIST.

Practical evaluation: search the NIST CMVP database directly at csrc.nist.gov/projects/cryptographic-module-validation-program/certificate-search using the vendor name and product model. Do not rely on the vendor's marketing materials for validation status. The CMVP database is the authoritative source.

Vendor example, Thales Luna Network HSM 7: the Luna 7 series supports FIPS 140-3 Level 3 and Thales participated in the NIST NCCoE Migration to Post-Quantum Cryptography project. Thales has communicated PQC firmware roadmaps incorporating ML-KEM and ML-DSA. [ASSUMED: verify current Luna 7 firmware version with validated ML-KEM and ML-DSA support against the CMVP database before procurement; roadmap communications from vendors are not equivalent to issued validation certificates.]

Criterion 2: Hybrid Operation Support

During the PQC migration window, an environment will simultaneously include classical clients and post-quantum-capable clients. An HSM that forces a hard cutover from classical to PQC, with no hybrid operational mode, is not suitable for large-scale enterprise key management migration. The requirement is that the HSM can operate classical and PQC algorithms simultaneously and can perform hybrid key derivation as a single HSM operation.

Specifically: can the HSM take an X25519 ECDH output and an ML-KEM-768 shared secret and combine them through HKDF within the HSM boundary, without exposing the intermediate key material to the host system? This matters because a hybrid construction where the combining step occurs in software, outside the HSM, reduces the security guarantee to whatever the host system's security level is. The combining step should remain within the HSM tamper boundary.

ANSSI and BSI both mandate hybrid operation as a minimum for PQC deployments in their respective guidance. For European deployments or organisations subject to ANSSI or BSI oversight, a single-mode (PQC-only) HSM that cannot accommodate hybrid migration does not meet the regulatory baseline, regardless of its FIPS validation status.

Vendor example, Entrust nShield Connect: the nShield CodeSafe developer toolkit allows custom applications, including hybrid key derivation workflows, to run within the HSM security boundary. This architecture accommodates hybrid ML-KEM + X25519 key derivation without exposing intermediate material to the host. [ASSUMED: verify current nShield firmware version and FIPS 140-3 validation status for specific hybrid operation capabilities before procurement.]

Criterion 3: Key Hierarchy Re-Wrapping at Scale

An HSM holding a classical root key, typically RSA-4096 or ECDH P-384, that protects a key hierarchy of thousands of wrapped data encryption keys cannot simply add PQC support and continue operating. The root key must be migrated to ML-KEM, and every key wrapped under the classical root must be re-wrapped under the new PQC root. The HSM must support this re-wrapping at the throughput and volume required by the environment.

Performance benchmarks for PQC key operations on production HSMs are not yet widely published. Thales Luna HSM 7 datasheet figures for classical asymmetric operations show approximately 10,000 RSA-2048 signing operations per second. ML-DSA throughput at equivalent security levels should be faster per operation than RSA-2048 due to lattice-based arithmetic advantages, but hardware-accelerated RSA implementations may narrow that gap on specific HSM architectures. [INFERRED: relative ML-DSA vs. RSA performance depends on implementation quality and hardware optimisation; request explicit benchmark data from the vendor for your specific transaction volumes and parameter sets.]

The management interface matters as much as raw throughput. PKCS#11 v3.0 (OASIS, June 2020) added an extensibility framework for new cryptographic mechanisms; standardised ML-KEM and ML-DSA mechanism identifiers are under development in a subsequent version. [INFERRED: verify current v3.1 publication status; as of Q1 2026 it was in development.] Legacy PKCS#11 v2.x interfaces cannot accommodate PQC algorithms without vendor-specific extensions, which introduce interoperability risk. Similarly, the key management server connected to the HSM must support KMIP v2.1 with PQC algorithm identifiers; the OASIS KMIP v2.1 standard (2021) includes attribute definitions for NIST PQC selection candidates.

Vendor example, AWS CloudHSM: CloudHSM provides FIPS 140-3 Level 3 validated HSM instances with PKCS#11, Java JCE, and OpenSSL Dynamic Engine interfaces. PQC support in CloudHSM depends on AWS issuing firmware updates to its managed fleet. Customers cannot independently control firmware update timing. [ASSUMED: verify current CloudHSM PQC support status and any announced timeline against AWS documentation before procurement; AWS has indicated PQC support is planned but managed-service update timelines differ from on-premises firmware control.]

Criterion 4: Firmware Update Governance

The CMVP validation timeline creates a predictable procurement gap. FIPS 203, 204, and 205 were published in August 2024. CMVP validations for new algorithm submissions typically take six to twenty-four months from submission. As of mid-2026, most HSM vendors will have submitted for PQC validation but not all will have received certificates. The practical approach for procurement in 2026 is to require a contractual commitment covering a specific milestone: for example, ML-KEM-1024 and ML-DSA-87 with FIPS 140-3 CMVP validation within a defined period of contract execution, if the validated certificate does not exist at procurement time.

For on-premises HSMs, the relevant questions are: is the PQC firmware update covered by the existing maintenance contract without additional licensing cost, does the firmware update trigger a new CMVP re-submission (and if so, who bears the validation cost and timeline), and what is the downtime requirement for a firmware update? A firmware upgrade with a four-hour maintenance window in a high-availability CA environment is a different operational cost from one requiring a 30-minute rolling update.

For managed cloud HSMs, the governance question reverses. AWS CloudHSM, Azure Dedicated HSM, and Google Cloud HSM all remove hardware management overhead, but transfer firmware update control to the cloud provider entirely. For organisations with CNSA 2.0 obligations where a specific PQC validation deadline applies, the inability to control when the provider applies PQC firmware may be a material constraint. On-premises HSMs give direct control over the validation timeline; cloud HSMs depend on the provider's roadmap.

Vendor example, Marvell LiquidSecurity 2 (underlying AWS CloudHSM): Marvell's LS2 platform supports programmable cryptographic acceleration and has announced PQC algorithm support in LS2 firmware. [ASSUMED: verify current LS2 PQC firmware status and FIPS 140-3 validation for PQC operations against current Marvell documentation before procurement.]

Criterion 5: Regulatory Parameter Set Alignment

Not all regulatory environments require the same parameter sets, and the distinction is a procurement pass/fail gate in regulated contexts, not a weighting factor in a balanced evaluation.

NSA CNSA 2.0 (September 2022) specifies ML-KEM-1024 for key encapsulation and ML-DSA-87 for signatures in National Security Systems. An HSM that supports only ML-KEM-768 and ML-DSA-65 does not meet CNSA 2.0 requirements for NSS deliveries, regardless of its FIPS 140-3 validation level. Defence contractors, cleared facility operators, and NSS-adjacent programme managers should treat ML-KEM-1024 and ML-DSA-87 support as a non-negotiable shortlist criterion. For the full CNSA 2.0 key management requirements, see CNSA 2.0 key management requirements.

European deployments face a different constraint. ANSSI recommends combining ML-KEM with a classical algorithm in all deployments and has expressed caution about deploying PQC algorithms in isolation before further cryptanalytic experience accumulates. BSI TR-02102-1 (2024 edition) includes both ML-KEM and ML-DSA with a hybrid mandate. An HSM procured for European financial or government deployments must support hybrid algorithm operation as a minimum; a PQC-only mode without classical algorithm fallback does not satisfy the ANSSI and BSI baseline.

The Mosca inequality provides the risk framing for organisations without explicit regulatory deadlines. Michele Mosca's formulation states that an organisation faces risk when the time to migrate cryptographic infrastructure exceeds the time remaining before a CRQC is available. Average HSM procurement and deployment cycles in enterprise environments span eighteen to thirty months from RFP to production. For organisations with no external deadline, a procurement decision in 2026 that results in a fully deployed PQC-capable key management infrastructure by 2029 provides a four to six year buffer before the approximate Q-Day window. That buffer is narrower than it sounds when key hierarchy re-wrapping and application integration are included in the migration programme timeline.

Vendor example, Utimaco Se-Series: Utimaco HSMs are widely deployed in European financial infrastructure and PKI. Utimaco's European base makes it directly relevant for ANSSI and BSI alignment requirements. Utimaco has communicated PQC readiness plans for its CryptoServer and Se-Series products. [ASSUMED: verify current Se-Series firmware and FIPS 140-3 validation status for ML-KEM and ML-DSA against Utimaco's current product documentation before procurement.]

A Note on Software-Layer PQC as a Substitute

Using a software PQC library, liboqs, BouncyCastle, or AWS-LC, alongside an HSM that does not yet support PQC natively is not equivalent to HSM-resident PQC operations. Software-side PQC does not benefit from the tamper resistance, secure key storage, or physical attack mitigation of the HSM. For operations where the private key must remain inside the HSM security boundary, the PQC implementation must be inside the HSM. Software wrappers defeat the purpose. This is the operating constraint that makes the CMVP validation gap a material procurement concern rather than a paperwork inconvenience. For guidance on selecting PQC cryptographic libraries for the software layer, that article covers the evaluation framework for the non-HSM components of a migration programme.