Why Post-Quantum Trust Begins Inside the Hardware

Published: September 2025. Updated: August 2026. Reviewed by Encryption Consulting’s HSM Services and PQC Advisory teams.

Every post-quantum migration plan eventually reaches the same wall: the algorithm can be standardized, the application can be patched, and the certificate policy can be rewritten, but none of it means anything if the private key it all depends on was generated, stored, or signed on hardware that cannot be trusted to do it correctly. A software library can implement post-quantum cryptography (PQC) perfectly and still be undermined by a key that leaked through a side channel, a random number generator that was not truly random, or firmware that silently fell back to a classical algorithm under load. That is why post-quantum trust has to begin inside the hardware, specifically inside the Hardware Security Module (HSM) that anchors key generation and signing for everything downstream of it.

This matters now because the standards are no longer theoretical. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on August 13, 2024, and HSM vendors have spent the past year turning that standardization into shipping firmware. The remaining question for most enterprises is not which algorithm to pick, it is whether the hardware underneath their PKI, TLS terminators, code signing pipeline, and key management systems can actually run these algorithms inside a validated security boundary, at production scale, without breaking availability.

Why Does Post-Quantum Readiness Start at the Hardware and HSM Level?

PQC readiness starts at the hardware level because the HSM is the root of trust for every key the algorithm ever touches. If the module that generates, stores, and uses a ML-KEM or ML-DSA key is not itself trustworthy, the mathematical strength of the algorithm is irrelevant. Four hardware-level guarantees carry over directly into the PQC era, and each one changes in a specific, testable way once larger post-quantum keys enter the picture.

• Immutable device identity. A hardware-bound identity that cannot be cloned or forged authenticates the HSM itself to the systems that depend on it. In a post-quantum context, this identity increasingly needs to be signed with a quantum-resistant algorithm so an attacker with future quantum capability cannot forge it retroactively.
• Tamper-resistant key storage. Keys generated and used inside the HSM’s cryptographic boundary never leave in plaintext. This matters more, not less, with PQC, because ML-DSA and SLH-DSA private keys and the operational state some signature schemes require are larger and more expensive to regenerate if compromised.
• True random number generation. Lattice-based schemes like ML-KEM and ML-DSA depend on high-quality entropy for key generation and, in some implementations, for randomized signing. A hardware True Random Number Generator (TRNG) sourced from physical noise is a stronger foundation for PQC key material than a software pseudo-random generator.
• Secure boot and firmware signing. The HSM validates its own firmware before it runs. As PQC firmware updates become routine, secure boot needs to verify those updates with quantum-resistant signatures, which is exactly what CNSA 2.0 mandates LMS, XMSS, or ML-DSA for in firmware and software signing contexts.

None of these four guarantees is new. What changes in the PQC era is the size and shape of the material they protect, and that is where most PQC-readiness gaps actually show up in production HSM estates.

CBOM Secure

Gain complete visibility with continuous cryptographic discovery, automated inventory, and data-driven PQC remediation.

Book a Demo

What Is the Current State of HSM Vendor PQC Support?

All three major HSM vendors, Thales, Entrust, and Utimaco, now ship NIST CAVP-validated ML-KEM and ML-DSA support in current firmware, delivered as an upgrade rather than a hardware replacement. Coverage of SLH-DSA and the stateful hash-based signature schemes is where the vendors still diverge, and FIPS 140-3 module validation combining PQC algorithms inside the certified boundary, not just the algorithms in isolation, is the newest and most consequential differentiator.

Vendor and Product Line	PQC Algorithms Shipping	Delivery Method	FIPS 140-3 Status (as of update)
Thales Luna HSM (firmware 7.9, July 2025)	ML-KEM (FIPS 203), ML-DSA (FIPS 204), hybrid PQC for backup and key sync	Firmware upgrade to existing Luna hardware, no external functionality module needed	FIPS 140-3 Level 3 validation reported in progress at release
Thales Trusted Cyber Technologies Luna T-Series (firmware 7.15.1, certificate 5450)	ML-DSA, ML-KEM, LMS, the full CNSA 2.0 PQC set	U.S.-manufactured Luna PCIe HSM, Luna Network HSM, Luna as a Service, CipherTrust Manager	FIPS 140-3 Level 3 validated as of August 2026, the first HSM line to combine all CNSA 2.0 PQC algorithms inside one FIPS 140-3 validation
Thales Luna 8 (announced August 2026)	Classical and post-quantum algorithms on a custom cryptographic processor	New hardware generation, purpose-built for PQC and AI-era workloads	FIPS 140-3 Level 3 and Common Criteria assessment in progress, not yet finalized at announcement
Entrust nShield (firmware 13.8.0, released August 22, 2025)	ML-DSA, ML-KEM, SLH-DSA, all three NIST CAVP validated	Native firmware support, announced with NIST CAVP validation on September 10, 2025	Algorithm-level CAVP validation confirmed; check current module-level FIPS 140-3 status before procurement
Utimaco u.trust GP HSM (Se-Series and CSe-Series)	ML-DSA (FIPS 204), ML-KEM (FIPS 203), LMS, with SLH-DSA on the roadmap	Quantum Protect application package, activated on existing hardware, no hardware swap	Algorithm-level CAVP validation confirmed for shipping algorithms; includes a proprietary state-management design for LMS and XMSS in HA and backup scenarios

Two things are worth being precise about here. First, algorithm validation and module validation are not the same event, and treating a vendor’s CAVP announcement as proof that a specific HSM appliance is fully FIPS 140-3 validated with PQC inside the boundary is a common procurement mistake; Encryption Consulting covers that distinction in detail in Are Your HSMs PQC-Ready?. Second, SLH-DSA (FIPS 205) support is genuinely uneven: Entrust has it validated, Utimaco lists it as roadmap, and the Thales sources reviewed for this update do not confirm it in shipping firmware. If your PQC roadmap depends on SLH-DSA specifically, for example as a conservative hash-based fallback for long-lived signing keys, confirm current vendor status directly before committing to a platform.

What Is Crypto-Agility at the Hardware Level, and Why Does It Matter?

Crypto-agility at the hardware level means an HSM can adopt new algorithms through a firmware update and a modular SDK, without a physical hardware replacement or a redesign of the applications that call it. The Thales, Entrust, and Utimaco firmware updates above are the practical proof: all three added ML-KEM and ML-DSA to hardware that customers already owned, through an upgrade path rather than a forklift replacement.

Hardware crypto-agility depends on a few specific design choices that are worth checking for in any HSM procurement or renewal decision:

• Firmware update mechanism. Can new algorithm support be delivered as a signed firmware update, and is that update process itself protected by a quantum-resistant signature so it cannot be forged during the transition?
• Modular cryptographic providers. Is PQC support built into core firmware, as with the Thales Luna approach, or delivered as a separate application package, as with Utimaco’s Quantum Protect? Either model works, but the procurement and licensing implications differ.
• API and standard alignment. Does the HSM expose PQC operations through current PKCS#11 mechanism identifiers and vendor SDK versions your applications already call, or does it require a parallel integration path?
• Headroom for the next standard. NIST is still evaluating additional signature schemes beyond the initial three FIPS standards. An agile HSM platform should be able to absorb a fourth algorithm family without another hardware cycle.

Crypto-agility is a hedge, not a finish line. An HSM that can theoretically be upgraded is only agile in practice if your organization has the firmware update process, the testing environment, and the change control discipline to actually apply that upgrade before the algorithms it protects become the weak link.

What Does a Hybrid Classical Plus PQC HSM Deployment Topology Look Like?

Almost no organization moves directly from classical-only to PQC-native HSM operations. The realistic deployment topology runs classical and post-quantum algorithms side by side inside the same HSM cluster during a multi-year transition window, using hybrid key exchange and, where the application supports it, dual or composite signatures.

A typical hybrid topology has three layers:

1. The HSM cluster layer. A high-availability HSM cluster, whether on-premises appliances, cloud HSM instances, or an HSM-as-a-Service deployment, runs firmware that supports both classical (RSA, ECC) and PQC (ML-KEM, ML-DSA) algorithms concurrently, with partitioning so different application groups can be migrated on independent schedules.
2. The protocol layer. TLS terminators and PKI issuance systems negotiate hybrid key exchange, for example X25519 combined with ML-KEM-768, so a session remains secure if either the classical or the post-quantum component is broken. Certificate authorities issue composite or dual certificates where the client ecosystem supports them, and fall back to classical-only for clients that do not yet negotiate PQC.
3. The application layer. Code signing, database encryption, and long-lived document signing workflows call the HSM for the appropriate algorithm per use case, informed by how long that signature or ciphertext needs to remain trustworthy, rather than switching every workload to PQC on the same day.

The decision of which layer to migrate first should be driven by exposure, not convenience. Key establishment used for confidentiality (TLS session keys, VPN tunnels, encrypted backups) is exposed to harvest-now-decrypt-later attacks today, because captured ciphertext can be decrypted retroactively once a cryptographically relevant quantum computer exists. Digital signatures used for authentication carry a different risk profile: a signature validated today does not become invalid retroactively, so signing workloads can generally be sequenced slightly behind encryption workloads, with the notable exception of long-lived code and firmware signing keys, where a forged signature years from now would still be damaging today. This exposure-based prioritization is the same logic Encryption Consulting applies in RSA: Secure Today, Scheduled for Retirement, which walks through the classical-algorithm side of this same migration.

How Does the FIPS 140-3 Boundary Apply to PQC-Validated HSMs?

FIPS 140-3 validation applies to a defined cryptographic module boundary, not to an algorithm in the abstract. That distinction is the single most misunderstood part of HSM PQC procurement. NIST’s Cryptographic Algorithm Validation Program (CAVP) tests whether an implementation of ML-KEM or ML-DSA is mathematically correct. NIST’s Cryptographic Module Validation Program (CMVP) tests whether the entire hardware and firmware module, including that algorithm implementation, key management, physical tamper protection, and self-tests, meets FIPS 140-3 requirements as a unit. A vendor can hold a valid CAVP certificate for ML-KEM well before the HSM appliance running it holds an updated FIPS 140-3 module certificate that covers PQC operations inside the boundary.

This gap is not hypothetical. Thales Luna’s July 2025 firmware update shipped ML-KEM and ML-DSA support with FIPS 140-3 Level 3 validation described as in progress, meaning the algorithms were available before the module certificate covering them was finalized. It was not until August 2026 that Thales Trusted Cyber Technologies’ Luna T-Series, running firmware 7.15.1 under certificate 5450, became the first HSM line documented to combine the full CNSA 2.0 PQC algorithm set, ML-DSA, ML-KEM, and LMS, inside a completed FIPS 140-3 Level 3 validation. That is roughly a year between algorithm availability and a validated module boundary that regulated buyers can actually cite in an audit.

For organizations in regulated environments, DFARS, FedRAMP, PCI DSS, or agencies subject to CNSA 2.0, the practical rule is: do not treat a vendor’s PQC algorithm announcement as equivalent to a validated module you can deploy into a regulated workload. Ask specifically which FIPS 140-3 certificate number covers the firmware version you intend to run, and confirm that certificate’s validated algorithm list includes the PQC algorithms you plan to use, not just the module’s original classical algorithm set.

What Changes in the Key Ceremony for PQC Key Generation?

A PQC key ceremony follows the same governance structure as a classical one, dual control, witnessed generation, documented custodian roles, but the technical details inside that ceremony change in ways that a script written for RSA or ECC will not account for.

• Larger key and signature material. An ML-KEM-768 public key runs roughly 1.2KB and an ML-DSA-65 public key and signature run several kilobytes combined, compared to 32 to 64 bytes for an equivalent-strength ECC key. Ceremony scripts, backup media capacity planning, and any process that manually transcribes or verifies key fingerprints need to account for this before the ceremony, not during it.
• Entropy requirements. Lattice-based key generation consumes more entropy per operation than ECC key generation. Confirm the HSM’s hardware TRNG throughput is validated for the PQC key generation volumes your ceremony plan requires, particularly for bulk key generation events ahead of a migration wave.
• Stateful hash-based signatures need state discipline, not just key discipline. LMS and XMSS, the stateful hash-based schemes CNSA 2.0 approves for firmware and software signing, generate a fixed number of one-time signature leaves per key. Ceremony procedures must document how the private key’s signing state is tracked and never reused, including across any backup or clone of that key, because reusing a one-time signature leaf breaks the security guarantee entirely.
• Ceremony script and witness training. Witnesses and custodians trained on RSA and ECC ceremonies need a short, specific briefing on what a PQC ceremony verification step actually confirms, since visually comparing a multi-kilobyte public key fingerprint is not the same exercise as comparing a short ECC fingerprint.

How Do You Assess PQC Readiness Across Your HSM Estate?

A structured assessment answers whether each HSM in your estate can run PQC today, can be upgraded to run it, or needs to be replaced before your migration deadline arrives. Encryption Consulting runs this as a five-step process:

1. Inventory every HSM and its firmware version. Build a complete cryptographic asset inventory covering on-premises appliances, cloud HSM instances, and embedded modules, recording model, firmware version, and current FIPS 140-3 certificate status for each.
2. Map algorithm usage to business exposure. Identify which HSMs protect key establishment for long-lived confidential data (harvest-now-decrypt-later exposure) versus signatures for long-lived trust artifacts like root CAs and firmware signing keys, since these drive different migration urgency.
3. Confirm vendor PQC roadmap and validation status per model. For each HSM model in the estate, confirm current firmware availability of ML-KEM, ML-DSA, and, if required, SLH-DSA or LMS/XMSS, and the FIPS 140-3 certificate that covers that firmware, not just the vendor’s general PQC announcement.
4. Test hybrid operation in a non-production environment. Validate firmware upgrades, hybrid key exchange, and larger key and signature handling against real application traffic before touching production, including throughput and latency under expected load.
5. Build the phased migration and decommissioning plan. Sequence upgrades by exposure and business risk, flag any HSM that cannot reach PQC readiness through firmware and requires replacement, and set decommissioning dates that align with your CNSA 2.0 or internal compliance timeline.

What High Availability and Backup Considerations Apply to PQC-Enabled HSMs?

High availability and backup design for PQC-enabled HSMs has to solve two problems classical HSM clustering did not: larger key material moving between cluster members, and, for stateful hash-based signatures, preventing any backup or failover event from ever reusing a signing state.

Standard HSM clustering replicates keys across members so a node failure does not interrupt signing or decryption operations. With ML-KEM and ML-DSA, that replication simply moves more data per key, which is a capacity and bandwidth planning item, not a structural problem. LMS and XMSS are the harder case: if a cluster fails over to a backup that has an out-of-sync view of which one-time signature leaves have already been used, the same leaf can be signed twice, which breaks the algorithm’s security guarantee outright. Utimaco’s Quantum Protect package addresses this directly with what the vendor describes as a patented state-management approach built specifically for HA and backup scenarios with stateful algorithms; any vendor or HSM platform you evaluate for LMS or XMSS support should be able to explain, in specific technical terms, how it prevents state reuse across cluster failover and backup restore, not just that it supports the algorithm.

Backup and restore procedures also need updated capacity and timing assumptions. Larger PQC key and signature material means backup media, encrypted export files, and disaster-recovery restore windows should be re-baselined rather than assumed to match classical-era sizing and timing.

What Are the Integration Prerequisites Before Enabling PQC on Production HSMs?

Before enabling PQC operations on a production HSM, confirm these prerequisites are in place, since a missing one turns a planned upgrade into an outage:

• Client SDK and PKCS#11 provider versions. Applications integrate with the HSM through a client library and PKCS#11 or vendor-specific SDK; that library needs a version that recognizes the new PQC mechanism identifiers before the firmware upgrade, or calls will fail even though the HSM firmware supports the algorithm.
• PKI and CA software compatibility. Your certificate authority software, whether on-premises, a managed PKI-as-a-Service platform, or a public CA integration, needs to support issuing certificates against PQC or hybrid public keys before those keys are useful in production.
• Network and protocol negotiation support. TLS terminators, load balancers, and VPN gateways in the traffic path need TLS stacks that support hybrid key exchange groups; an HSM that can generate ML-KEM keys does not help if nothing in the connection path can negotiate them.
• MTU and fragmentation handling. Larger PQC keys and certificates increase TLS handshake message size, which can push handshakes past path MTU limits on some network paths and expose fragmentation handling bugs in older network equipment that classical-size handshakes never triggered.
• Monitoring and alerting updates. Operational dashboards and alert thresholds tuned for classical key generation and signing latency need updated baselines, since PQC operations have different, generally higher, computational cost per operation.

A cryptographic discovery and inventory platform is the fastest way to confirm these prerequisites across a large estate rather than checking application by application; this is the specific gap CBOM Secure is built to close.

What Failure Modes Should You Plan For?

Most PQC-at-the-hardware failures fall into a small number of predictable categories. Planning for these before migration reduces the odds of an unplanned outage or a compliance gap discovered during an audit.

Failure Mode	Why It Happens	Mitigation
Firmware cannot be updated for PQC	End-of-life or end-of-support HSM hardware never receives a PQC firmware release from the vendor	Inventory firmware end-of-life dates now; budget hardware refresh for any model without a confirmed PQC firmware roadmap
Throughput and latency degrade under PQC load	ML-DSA signing and larger key handling cost more compute per operation than RSA or ECC on the same hardware	Load-test PQC operations at expected production volume before cutover; confirm vendor-published performance figures against your own traffic patterns
Stateful signature state reuse during failover	HA cluster members or backup restores fall out of sync on LMS or XMSS one-time signature state	Use HSM platforms with documented, tested state-synchronization guarantees for stateful algorithms across HA and backup
Handshake or message size breaks legacy network paths	Larger PQC keys and certificates exceed MTU or buffer assumptions in older network equipment	Test hybrid TLS handshakes across the actual network path, including any legacy load balancers or middleboxes, before production rollout
Algorithm validated but module boundary is not	CAVP algorithm validation is treated as equivalent to a completed FIPS 140-3 module certificate	Confirm the specific FIPS 140-3 certificate number and its validated algorithm list for the exact firmware version deployed
Client or application library incompatibility	PKCS#11 provider or SDK version predates the PQC mechanism identifiers the new firmware exposes	Upgrade and test client libraries in a staging environment ahead of the firmware upgrade, not alongside it

Limitations

• NIST IR 8547 remains an Initial Public Draft as of this update; its comment period closed January 10, 2025, and the transition timeline it proposes is not yet finalized and may change.
• Vendor PQC support and FIPS 140-3 certificate status change frequently. The vendor details in this article reflect publicly available information current as of this update; confirm the exact firmware version and certificate number with the vendor before procurement or deployment.
• CNSA 2.0’s mandatory milestones apply directly to U.S. National Security Systems; commercial enterprises are not bound by CNSA 2.0 but many use it as a planning reference for algorithm selection and timing.
• Performance figures for PQC operations vary meaningfully by HSM model, firmware version, and workload; treat the general guidance here as a starting point for your own load testing, not a substitute for it.

What Would Encryption Consulting Recommend?

Treat the HSM layer as the first gate in any PQC migration, not the last one to check. Concretely, that means starting with a cryptographic inventory rather than an algorithm pilot, confirming FIPS 140-3 module status rather than trusting a CAVP headline, and building the key ceremony and HA runbook changes before a single production key is generated.

Encryption Consulting’s PQC Advisory Services run this as a structured, nine-phase roadmap covering cryptographic discovery, risk-based prioritization, vendor and hardware evaluation, hybrid architecture design, and phased implementation, so the hardware layer and the application layer migrate on a coordinated schedule instead of independently.

Where the gap is specifically hardware, our HSM Services team evaluates current HSM firmware and FIPS validation status against your PQC requirements, runs proof-of-concept testing for hybrid and PQC-native configurations, and designs the HA and key ceremony changes stateful algorithms require. For estates where the first problem is simply not knowing what is deployed where, CBOM Secure builds and maintains the continuous cryptographic inventory that makes every step after it possible.

PQC Advisory Services

Gain post-quantum readiness with expert-led cryptographic assessment, migration strategy, and hands-on implementation aligned to NIST standards.

Learn More

Frequently Asked Questions

Do we need new HSM hardware to support PQC, or is a firmware upgrade enough? For most current-generation HSMs, a firmware upgrade is enough. Thales, Entrust, and Utimaco have all added ML-KEM and ML-DSA support to existing hardware through firmware updates. Older or end-of-life HSM models that will never receive a PQC firmware release are the exception, and those need to be identified and budgeted for replacement now.

Is a vendor’s PQC algorithm announcement the same as a FIPS 140-3 validated PQC-capable module? No. Algorithm validation through NIST’s CAVP program and module validation through CMVP are separate processes, and a gap of roughly a year between the two has been typical in the current generation of PQC firmware releases. Confirm the specific FIPS 140-3 certificate number covering the firmware version you plan to deploy.

Which PQC algorithm should our HSM support first, ML-KEM or ML-DSA? Prioritize based on exposure, not preference. ML-KEM protects key establishment, which is exposed today to harvest-now-decrypt-later attacks on any traffic captured now and decrypted once a cryptographically relevant quantum computer exists. ML-DSA protects signatures, where the exposure window opens later for most use cases, except for long-lived code and firmware signing keys, which should be treated with similar urgency to key establishment.

Do LMS and XMSS require different operational handling than ML-DSA? Yes. LMS and XMSS are stateful hash-based signature schemes with a fixed number of one-time signature leaves per key; reusing a leaf, which can happen during a mismanaged HA failover or backup restore, breaks the security guarantee. ML-DSA and ML-KEM do not carry this state-management requirement.

How much bigger are PQC keys and signatures than RSA or ECC, in practice? An ML-KEM-768 public key is roughly 1.2KB versus about 32 to 64 bytes for an equivalent-strength ECC key, and ML-DSA public keys and signatures run into the low kilobytes combined. Plan for this in backup media capacity, certificate and handshake size limits, and any ceremony process that manually verifies key material.

Conclusion

Algorithms get the attention in most PQC conversations, but the HSM layer decides whether those algorithms are trustworthy in practice. The hardware has to generate PQC keys with real entropy, store them inside a validated boundary, survive a firmware upgrade path that keeps up with an evolving standard, and support HA and backup procedures that respect the specific requirements stateful signature schemes introduce. Thales, Entrust, and Utimaco have each closed most of the algorithm-support gap over the past year, and the first FIPS 140-3 validated modules combining the full CNSA 2.0 PQC suite arrived in 2026. What remains is operational: inventorying your HSM estate, confirming module-level validation rather than algorithm-level announcements, and rebuilding key ceremony and HA runbooks around larger keys and, where relevant, one-time signature state. Organizations that treat the hardware layer as the starting gate for PQC migration, rather than an afterthought to the application layer, are the ones who will be ready when the deadlines that matter to them actually arrive.

References

• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/204/final
• NIST FIPS 205, Stateless Hash-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/205/final
• NIST IR 8547 (Initial Public Draft, November 2024), Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
• NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) guidance: https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
• Thales, Luna HSM v7.9 Delivers PQC Readiness at Scale: https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
• Thales Trusted Cyber Technologies, U.S.-Manufactured Post-Quantum HSM Achieves FIPS 140-3 Level 3: https://www.thalestct.com/hsm-fips140-3-validation/
• Thales Group, Thales Builds Cryptographic Security for the Age of AI and Post-Quantum Computing (Luna 8): https://www.thalesgroup.com/en/news-centre/press-releases/thales-builds-cryptographic-security-age-ai-and-post-quantum-computing
• Entrust, nShield HSMs Post-Quantum Cryptography Algorithms Achieve Validation From the NIST Cryptographic Algorithm Validation Program: https://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
• Utimaco, The 2029 Post-Quantum Deadline: Can Your HSMs Make the Migration?: https://utimaco.com/news/blog-posts/post-quantum-hsm-migration-2029