Are Your HSMs PQC-Ready?

Ask an HSM vendor in 2026 whether their product is post-quantum ready, and the honest answer is a qualified yes. The leading platforms now implement NIST’s post-quantum algorithms in firmware; those implementations have passed NIST’s algorithm testing, and you can generate and use ML-DSA and ML-KEM keys today. For most organizations, that is genuinely enough to begin. But for buyers operating under a strict FIPS 140-3 Level 3 mandate, there is a gap hiding behind the word ready, and it is the difference between an algorithm being certified and a module being certified with that algorithm inside its validated boundary.

This article unpacks that distinction, which is easy to miss and consequential to ignore. We will explain the difference between CAVP algorithm validation and CMVP module validation, document where the major HSM platforms actually stand as of early 2026, set out what the gap means for regulated procurement and deployment, and offer a practical way to evaluate whether your HSMs are PQC-ready for your specific compliance posture rather than for marketing purposes. Throughout, we point to how Encryption Consulting helps regulated organizations close this gap, from assessing HSM PQC-readiness to executing a compliant migration.

Why This Matters Now?

Three forces are converging to turn HSM PQC-readiness into an immediate procurement question rather than a future one: vendors have shipped post-quantum firmware, NIST’s deprecation clock is running, and the FIPS 140-2 sunset is forcing a parallel move to FIPS 140-3.

PQC firmware has shipped, and the marketing followed

The post-quantum algorithms are no longer drafts. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and HSM vendors moved quickly. Entrust delivered post-quantum support in nShield 5 firmware and earned CAVP certification for ML-DSA, ML-KEM, and SLH-DSA in firmware v13.8.0. Thales shipped Luna HSM firmware v7.9 with native ML-KEM and ML-DSA integrated into the firmware. The capability is real and the messaging is enthusiastic, which is exactly why buyers need to read the certification fine print rather than the headline.

Deprecation deadlines are pushing procurement

The timeline gives the question urgency. NIST has signalled a 2030 deprecation date for the classical asymmetric algorithms, a point Entrust underscores in its own PQC messaging, noting that NIST already has a set deprecation date of 2030 for the classical asymmetric algorithms. For national security systems, CNSA 2.0 sets a 2030 mandatory migration target. Procurement teams are therefore specifying PQC capability in HSM purchases now, which makes understanding what PQC certification means a live commercial issue rather than an academic one.

A separate FIPS deadline compounds the pressure

There is a second clock for regulated buyers. FIPS 140-2 certificates move to NIST’s historical list on a defined schedule, after which they no longer satisfy validation requirements for new federal procurement, making FIPS 140-3 validation a start-now-or-miss-it situation given the length of the CMVP queue. Organizations are thus being pushed toward FIPS 140-3 modules and toward PQC at the same time, which is precisely the intersection where the certification gap lives.

How Certification Works: CAVP vs. CMVP

Understanding the gap starts with two NIST programs that sound similar but certify very different things. The sections below explain how algorithm validation relates to module validation, what it means for an algorithm to sit inside a module’s validated boundary, and why the combined certification takes time.

CAVP and CMVP are not the same thing

Two distinct NIST programs govern cryptographic assurance, and conflating them is the root of the confusion. The Cryptographic Algorithm Validation Program, or CAVP, tests a specific implementation of an algorithm against its standard and issues an algorithm certificate. The Cryptographic Module Validation Program, or CMVP, validates an entire cryptographic module, the HSM, against the FIPS 140-3 standard at a given security level. The relationship is sequential: as one analysis of implementing PQC in FIPS 140-3 modules explains, algorithms must pass CAVP testing first, and those algorithm certificates are a prerequisite to submitting a module to the CMVP for validation.

NIST took the necessary preparatory steps quickly. On the day the PQC standards were published, the CMVP updated its approved-function references so that FIPS 204 and 205 are approved digital signature methods and FIPS 203 is an approved key-encapsulation method, with DigiCert noting the updates to SP 800-140C and SP 800-140D and the self-test guidance for PQC implementations. The algorithms can therefore be claimed in a FIPS-validated module, but only once a module completes CMVP validation with them inside its boundary.

What it means for PQC to be inside the module boundary

An HSM’s cryptographic boundary is the validated perimeter, defined physically and logically, within which approved cryptography is performed and keys are protected. For an algorithm to be covered by the module’s FIPS 140-3 validation, it must be inside that boundary in a validated configuration. An HSM can have a current FIPS 140-3 Level 3 validation for its classical algorithms while its newly added PQC algorithms are not yet part of any validated configuration. That is not a contradiction; it is the normal state during a transition because the module must be revalidated to bring the new algorithms within the certified boundary.

The current state of the market

The precise position as of late 2025 is documented and worth stating exactly. According to industry analysis, several vendors have obtained CAVP certification for the PQC algorithms, and several hold FIPS 140-3 Level 3 CMVP validation for their HSMs, including Entrust nShield 5, Marvell LSM2, Thales Luna G7 and K7, and Utimaco’s Atalla. But the same analysis states that none have yet obtained FIPS 140-3 Level 3 with PQC support combined, with all currently at the Modules in Process or Implementation Under Test stage. In other words, the algorithms are validated and the modules are validated, but not yet together.

The vendors are explicit about being in the queue. Entrust has submitted nShield 5 firmware for updated FIPS 140-3 Level 3 validation through the CMVP. Thales describes its Luna firmware v7.9.2 as the next FIPS candidate with PQC, and its v7.9 materials note FIPS 140-3 Level 3 validation in progress as a critical step beyond experimental implementation. The combined certification is coming; it has not arrived.

Why the queue takes time

The lag is structural, not a sign of vendor delay. Research on quantum-era cryptography notes that NIST’s FIPS 140-3 validation pathway for post-quantum modules introduces 12 to 18 months delays between algorithm availability and certified module availability because of the validation queue and testing requirements. Planning around that lead time, rather than expecting the module certification to follow the algorithm certification immediately, is the realistic posture.

Risks for Regulated Buyers

The gap creates specific, avoidable risks for organizations with strict compliance mandates.

Risk	Cause	Consequence
Compliance assumption error	Treating CAVP for PQC as equivalent to CMVP with PQC.	Running PQC outside the validated boundary while believing it is covered.
Audit finding	Deploying PQC in production under a strict FIPS 140-3 L3 mandate now.	Non-compliance discovered during assessment.
Procurement misalignment	Specifying PQC-ready without defining the certification level.	Buying capability that does not meet the actual mandate.
Timeline mismatch	Expecting module validation to follow algorithm validation at once.	The migration plan was built on an unrealistic certification date.
Configuration error	Enabling PQC in a way that drops the FIPS-approved mode.	Loss of Level 3 compliance for the whole partition.

FIPS-approved mode is strict, and PQC handling can affect it

Compliance is not only about whether an algorithm is validated; it is about the configuration. In a FIPS 140-3 Level 3 Security World, the HSM only supports approved algorithms and key types, and using a non-approved algorithm forces a choice between migrating to a different mode or replacing the protocol. Thales documentation reflects how tightly this is enforced: the Luna v7.9 release added restrictions in FIPS-approved configuration to comply with FIPS 186-5 and wrapping-off of ML-DSA and ML-KEM keys is not supported in that release. The way PQC is enabled and how its keys are handled can directly affect whether a partition remains in its validated state.

For most organizations, the gap is manageable; for some, it is decisive

The right framing is proportional. For an enterprise that is testing, piloting, or running PQC for defense-in-depth against harvest-now-decrypt-later, deploying the CAVP-validated algorithms now is sensible and low-risk. For an organization whose contracts or regulations require that all cryptography run inside a FIPS 140-3 Level 3 validated boundary, deploying PQC before the combined CMVP validation lands is a compliance decision that must be made consciously and documented. The gap is not a reason to avoid PQC; it is a reason to be precise about what your mandate requires.

How to Evaluate Your HSMs?

Evaluating whether your HSMs are PQC-ready for your situation comes down to matching capability against your real compliance requirements.

1. Define your actual mandate first: Determine whether your obligations require cryptography to run inside a FIPS 140-3 Level 3 validated boundary, or whether CAVP-validated algorithms in a current-generation HSM suffice. The answer changes everything downstream.
2. Read the certificate, not the brochure: Check the vendor’s specific CMVP validation and its security policy to see which algorithms are inside the validated boundary, in which configuration, and treat CAVP certification and CMVP validation as separate things.
3. Separate testing from production posture: Use PQC freely in development and pilots to validate performance and integration, while making a deliberate, documented decision about whether production PQC may run outside the combined validation during the transition.
4. Track the CMVP queue against your timeline: Plan for the 12-to-18-month lead time between algorithm and module validation, monitor the vendor’s modules-in-process status, and align your production cutover with the certification you require.
5. Preserve FIPS-approved mode deliberately: Confirm how enabling PQC and handling its keys interacts with FIPS-approved configuration, so you do not inadvertently drop a partition out of its validated state.
6. Exploit crypto-agile hardware: Where the HSM uses a reprogrammable security processor, you can adopt new algorithms and acceleration through firmware rather than hardware refresh; Entrust, for instance, notes nShield 5 PQC acceleration arriving via a subsequent firmware upgrade.
7. Document the decision for auditors: Whatever posture you choose, record the rationale, the certification status relied upon, and the transition plan, so the choice reads as a managed risk decision rather than an oversight.

What This Means for Your Teams?

The gap is not only a compliance abstraction; it changes what different roles need to verify and decide. Here is what it means in practice across the organization.

• CISOs need to know whether the organization’s PQC deployment satisfies its actual compliance mandate, not just whether the HSM supports PQC.
• Compliance and audit teams must distinguish CAVP from CMVP and verify what is inside the validated boundary before signing off.
• Procurement teams should specify the required certification level precisely, rather than the ambiguous term PQC-ready.
• Cryptography and PKI teams decide how to enable PQC without compromising FIPS-approved mode and plan the cutover against the CMVP queue.
• Security architects weigh whether to deploy PQC now for defense-in-depth or stage it until the combined validation lands, based on the threat and the mandate.

How Encryption Consulting Can Help?

At Encryption Consulting, we work with organizations across industries to turn quantum readiness from an abstract goal into a concrete, executable program.

CBOM Secure is our cryptographic discovery and inventory solution. It automatically scans your environment to identify all cryptographic assets, including certificates, keys, algorithms, and protocols, giving you the visibility you need to assess quantum exposure and prioritize your migration roadmap.

CertSecure Manager provides full certificate lifecycle management across cloud, on-prem, and hybrid environments. As quantum-resistant certificate standards emerge and CA/Browser Forum timelines tighten, it gives your team the automation and control to manage large-scale certificate transitions without disruption.

PKI-as-a-Service offers a fully managed PKI platform for organizations that need a modern, scalable certificate authority without the overhead of running one in-house, purpose-built for the flexibility that PQC migration demands.

HSM-as-a-Service ensures your cryptographic keys are protected in hardware security modules with high-assurance key isolation, even as you transition to post-quantum algorithms.

On the advisory side, our Post-Quantum Cryptographic Advisory Services guide organizations through every stage of PQC readiness, from threat assessment and algorithm selection to migration planning and hybrid implementation. Our PKI Services team helps design and modernize the PKI infrastructure that quantum migration depends on, and our Compliance Advisory Services ensure your transition aligns with NIST, CISA, CMMC, and other evolving regulatory frameworks.

Whether you are just beginning to assess your quantum exposure or actively executing a migration plan, we have the tools and expertise to get you there. Get in touch to start your quantum readiness journey.

Conclusion

HSM vendors are right to say their products support post-quantum cryptography; the algorithms are implemented in firmware and CAVP-validated, and they can be used today. But CAVP algorithm validation and CMVP module validation are different programs, and as of early 2026, no HSM holds a FIPS 140-3 Level 3 validation with PQC inside the module boundary, with all the major platforms still in the CMVP queue. For most organizations, that gap is a manageable transition detail; for regulated buyers under a strict validated-boundary mandate, it is a decision that must be made consciously.

To assess whether your HSMs are genuinely PQC-ready, define your actual compliance requirement first, read the CMVP certificate and security policy rather than the brochure, separate testing from production posture, and plan around the 12-to-18-month gap between algorithm and module validation. The post-quantum capability is real and worth adopting; the discipline is in matching it precisely to what your mandate requires, so PQC-ready means ready for your obligations rather than ready in the abstract. This is where Encryption Consulting comes in.

Our Post-Quantum Cryptographic Advisory Services help you assess your quantum exposure, read the certificate rather than the brochure, and build a migration plan matched to your mandate, while CBOM Secure, CertSecure Manager, PKI-as-a-Service, and HSM-as-a-Service give you the tooling to execute it. Get in touch to start your quantum readiness journey.