Post-quantum HSM migration: ML-KEM, ML-DSA and sovereign key stores

A Hardware Security Module (HSM) is the physical root of trust for certificate authorities, payment processors, government signing systems and regulated data stores. Migrating that root of trust to post-quantum algorithms, specifically ML-KEM (FIPS 203) for key encapsulation and ML-DSA (FIPS 204) for digital signatures, is not a routine firmware update. It is a multi-year programme that touches key ceremonies, escrow policy, PKCS#11 interfaces, validation certificates and procurement strategy simultaneously.

Why the HSM transition cannot wait for quantum computers to arrive

The harvest-now-decrypt-later threat is the central reason sovereign operators must act before a cryptographically relevant quantum computer exists. Adversaries are already collecting ciphertext today, holding it until a sufficiently powerful quantum machine can break the RSA or ECDH keys that protected it. For data with a confidentiality horizon of ten years or more, including classified government material, long-term financial records and healthcare data subject to extended retention requirements, the relevant protection window has already started.

FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) were finalised by NIST in August 2024, establishing the first approved post-quantum signature standards for use in US federal and allied regulated environments. The National Security Agency has stated directly: “Agencies should not wait for quantum computers to be built before taking action. The transition to post-quantum cryptography must begin now.” That position is mirrored by ENISA and by the Dutch NCSC in their respective migration guidance documents.

Vendor landscape: what has actually shipped versus what is on a roadmap

The gap between vendor announcements and production-ready, formally validated firmware is significant and must be the first filter in any procurement decision.

Thales Luna Network HSM 7 firmware 7.8 and later introduced experimental support for ML-KEM and ML-DSA, exposed through the PKCS#11 interface via new CKM_ mechanism identifiers. However, as of early 2025 the corresponding FIPS 140-3 CMVP validation certificate for the PQC-enabled firmware build had not yet been issued, meaning deployments in environments that require validated cryptography operate in a compliance gap. Thales has also confirmed that Luna HSM 5 and earlier generations use fixed-function accelerators that cannot be retro-fitted.

Entrust nShield Connect XC and the nShield 5s have a published PQC firmware roadmap that includes ML-KEM-768 and ML-DSA-65, with the nShield Post-Quantum SDK providing application-layer access. The functional gap for sovereign deployments is the same: CMVP validation of the PQC build is pending, and the remote administration client (Remote Administration Client) must be updated separately to handle lattice-based key ceremonies, since the classic client has no concept of ML-DSA key material.

Stranded-asset risk in long-lifecycle deployments

The average lifecycle of an HSM in a production payment or CA environment is seven to ten years, according to PCI Security Standards Council guidance on cryptographic key management. This creates a concrete stranded-asset problem: hardware purchased in 2018 or 2019, still within its support contract and carrying an existing FIPS 140-2 or 140-3 validation, may be technically incapable of running ML-DSA or ML-KEM, forcing early retirement at significant cost.

For financial transaction processing environments, this intersects directly with PCI DSS 4.0 requirements to maintain validated cryptographic modules for cardholder data. For certificate authority operations, retiring an HSM that holds an active root key requires a key ceremony of equivalent or greater assurance level to generate its replacement, which in turn requires an HSM that already supports the target algorithm. The sequencing problem is real: you cannot generate a new quantum-safe root on a device that does not yet have a valid CMVP certificate for that algorithm.

Government classified systems face the most acute exposure. Hardware replacement in accredited environments requires re-accreditation of the enclave, which in European national security contexts can take twelve to thirty-six months. An HSM that reaches end-of-life before its replacement is accredited creates a continuity-of-operations gap with no good answer.

IETF guidance and the PKCS#11 interface problem

IETF draft-ietf-pquip-pqc-hsm-constrained, published by the PQUIP working group, addresses exactly this operational reality for constrained hardware. The draft distinguishes between HSMs that can execute lattice-based operations internally and constrained secure elements that cannot, recommending that the latter offload PQC operations to a co-located full HSM acting as a PQC gateway while retaining classical signing capability for continuity.

For PKCS#11 interfaces specifically, the draft recommends that operators audit the CKM_ namespace exposed by each device. ML-KEM-768 should appear as CKM_KYBER_KEY_PAIR_GEN or the equivalent OASIS PKCS#11 v3.1 identifier, and ML-DSA-65 should appear as CKM_DILITHIUM or its successor identifier. An absent mechanism identifier means the algorithm is inaccessible to calling applications regardless of what the firmware release notes claim. Operators should also verify that the C_GenerateKey and C_Sign calls for lattice-based mechanisms return correct outputs against the NIST Known Answer Tests for FIPS 204 and FIPS 205 before trusting the implementation in production.

FIPS 205 (SLH-DSA), a hash-based signature scheme with a simpler security proof than ML-DSA, is relevant for constrained environments because it does not rely on lattice hardness assumptions. Its larger signature sizes (up to 50 KB for the highest security parameter set) make it unsuitable for TLS or high-throughput signing, but it is a credible fallback for long-lived document signing use cases where the device cannot support full lattice operations.

Key ceremonies, escrow and firmware update chain continuity

The most operationally dangerous moment in a PQC HSM migration is the key ceremony for generating new ML-DSA root keys. If the ceremony is conducted on unvalidated firmware, the resulting key material may not be accepted by relying parties, auditors or regulatory bodies. Sovereign operators should therefore:

First, conduct a parallel ceremony: generate the new ML-DSA root on the PQC-capable HSM while keeping the existing RSA or ECDSA root active. This hybrid trust anchor approach, described in IETF RFC 8446 extension work and the hybrid certificate drafts, ensures that relying parties without PQC support are not cut off during the transition period.

Second, update escrow policy before the ceremony, not after. Key escrow for ML-DSA material requires escrow tokens that are themselves wrapped with ML-KEM, not with RSA-OAEP, because escrow material that can be decrypted by a quantum computer provides no long-term protection. This requires that the escrow HSM also supports ML-KEM-768 before the ceremony can proceed.

Third, the firmware update chain must be quantum-safe. Delivering a firmware update signed with ECDSA P-256 to a device intended to protect against quantum adversaries is a logical contradiction. Operators should verify that the vendor’s firmware signing infrastructure uses ML-DSA or SLH-DSA for update authenticity, and that the on-device bootloader validates that signature before loading new code.

ISO/IEC 19790 constraints on lattice-based hardware validation

ISO/IEC 19790 defines the security requirements for cryptographic modules that underpin FIPS 140-3 validation. Its boundary requirements, self-test mandates and conditional test requirements were written around classical algorithms and present specific challenges for lattice-based implementations. The power analysis and timing side-channel mitigations required under the physical security level requirements (Levels 3 and 4) have not yet been fully characterised for the NTT (Number Theoretic Transform) operations central to ML-KEM and ML-DSA. Testing laboratories under the CMVP must develop new leakage models before they can issue certificates, which is why the validation queue for PQC HSM submissions is expected to extend well into 2026.

For sovereign deployments that cannot accept unvalidated cryptographic modules, this creates a practical ceiling: the earliest defensible date for deploying PQC HSMs in environments requiring formal FIPS 140-3 certification is likely late 2025 at the earliest, and only for the specific product variants that have already entered the CMVP queue.

Procurement criteria for genuine PQC capability

Regulated buyers evaluating HSM products should apply four concrete tests beyond reading vendor literature. First, request the CMVP certificate number or submission tracking number for the specific PQC firmware build, not a future-dated roadmap commitment. Second, request a demonstration of ML-KEM-768 and ML-DSA-65 key generation and signing via PKCS#11 against the NIST FIPS 204 Known Answer Tests, with the vendor’s test output provided in writing. Third, confirm that the vendor’s key management software, remote administration client and HSM manager console have been updated to handle lattice-based key material natively, since firmware support without tooling support has no operational value. Fourth, ask specifically whether the firmware signing chain that delivers PQC updates to the device is itself protected by a post-quantum signature algorithm.

Products that pass all four checks occupy a materially different risk position from those that can only pass the first. Procurement decisions in financial, government and healthcare environments that involve HSM lifecycles of seven or more years should weight long-term algorithm agility, the vendor’s demonstrated commitment to the CMVP queue, and the availability of a defined migration path for existing key material over unit price.

FAQ

What is the difference between ML-KEM and ML-DSA, and why do HSMs need to support both?

ML-KEM (FIPS 203) is a key-encapsulation mechanism used for key exchange and transport encryption, while ML-DSA (FIPS 204) is a digital signature algorithm. HSMs typically serve dual roles: protecting private signing keys for PKI and code signing, and managing session key material for encrypted communications. A deployment that migrates only one algorithm leaves the other attack surface open to quantum-capable adversaries.

Can existing HSMs be upgraded to support ML-DSA through firmware, or does hardware replacement become necessary?

It depends on the specific model and generation. Thales Luna Network HSM 7 and Entrust nShield Connect XC have published firmware roadmaps that add ML-KEM and ML-DSA through software updates, provided the onboard processor has sufficient performance headroom. Older generations with fixed-function cryptographic accelerators hardwired to RSA and ECC cannot be retro-fitted and will require hardware replacement. Buyers should request the vendor’s FIPS 140-3 validation certificate number for the PQC firmware build, not just a roadmap slide.

How does ISO/IEC 19790 affect the timeline for getting PQC-capable HSMs formally validated?

Every change to the approved algorithm list inside a cryptographic module boundary requires a fresh CMVP validation submission. Because lattice-based algorithms such as ML-DSA introduce new side-channel attack surfaces, testing laboratories must develop new test vectors and leakage models before issuing certificates. This process typically adds twelve to twenty-four months between a vendor shipping firmware and that firmware carrying a formal validation certificate, creating a window during which operators must decide whether to accept unvalidated PQC or delay migration.

What does IETF draft-ietf-pquip-pqc-hsm-constrained recommend for organisations running constrained secure elements alongside full HSMs?

The draft advises a hybrid approach: constrained secure elements that cannot run full ML-DSA or ML-KEM internally should offload PQC operations to a co-located HSM acting as a PQC gateway, while retaining their classical signing capability for continuity. Operators should also audit the PKCS#11 interface to confirm that new CKM_ mechanism identifiers for ML-KEM and ML-DSA are present, since an absent identifier means the algorithm is inaccessible to calling applications even if the firmware nominally supports it.

What procurement red flags should a CISO look for when a vendor claims PQC readiness?

Four concrete checks: first, ask for a CMVP validation certificate number, not a press release. Second, request the specific PKCS#11 CKM_ identifiers for ML-KEM-768 and ML-DSA-65 exposed through the current production firmware build. Third, verify whether the key ceremony tooling and remote administration software have been updated to generate, wrap and escrow lattice-based key material. Fourth, confirm that the firmware signing chain used to deliver PQC updates is itself protected by a quantum-safe signature, because a classical ECDSA-signed firmware update intended to protect against quantum threats is a logical contradiction.