FIPS 140-3 and PQC: Why No Validated Module Exists Yet and What Compliance Teams Must Do Now

Your auditor is going to ask a simple question: does your organization use FIPS 140-3 validated cryptographic modules that support post-quantum algorithms? As of Q1 2026, the honest answer for every organization on earth is no — because no such validated module exists. Zero. Not a single entry on the NIST Cryptographic Module Validation Program (CMVP) active list carries an approved post-quantum algorithm in validated status.^{[NIST CMVP MIP List]} If your vendor's press release led you to believe otherwise, this article will explain exactly where the confusion lives — and what you need to do before 2027.

The FIPS 140-3 Validation Pipeline, Explained in Plain Terms

FIPS 140-3 validation is not a single event. It is a two-stage process that compliance officers must understand precisely, because conflating the two stages is the single most common source of misinformation in PQC procurement conversations today.

Stage one is CAVP — the Cryptographic Algorithm Validation Program. CAVP tests whether a specific algorithm implementation produces mathematically correct outputs. Passing CAVP means an algorithm implementation has been verified for correctness against published test vectors. It does not mean the module containing that algorithm is approved for use in FIPS-regulated environments.^{[NIST FIPS 140-3 Implementation Guidance]}

Stage two is CMVP — the Cryptographic Module Validation Program. CMVP evaluates the entire module: its physical security, key management, self-tests, documentation, and the integrated algorithms. Only a module that completes CMVP review and appears on the NIST validated modules list is legally usable as a FIPS 140-3 compliant component in regulated federal systems. A CAVP certificate alone does not meet this bar.^{[NIST FIPS 140-3 Implementation Guidance]}

FIPS 140-3 defines four security levels — Level 1 through Level 4 — ranging from basic software implementations to tamper-responsive hardware security modules. Most federal agencies and regulated financial institutions require Level 2 or Level 3 for key protection. This distinction matters enormously for HSM procurement decisions, where vendors are currently racing to complete Level 3 validations for PQC-capable hardware.

Where PQC Algorithms Actually Stand Today

In January 2026, CIQ's NSS module became the first to achieve CAVP certification for both ML-KEM and ML-DSA — the algorithms standardized as FIPS 203 and FIPS 204 respectively.^{[CIQ Press Release, January 2026]} This is a genuine milestone and represents the leading edge of the validation pipeline. However, CIQ's target for full FIPS 140-3 module validation is Q2 2027 — more than a year away from the time of this writing. Compliance officers who read the January announcement as evidence of current FIPS compliance would be misrepresenting their posture to auditors.

Several other vendors appear in the CMVP Modules in Process (MIP) list at Implementation Under Test (IUT) or Review Pending status, including Entrust nShield 5, Thales Luna, Marvell, and Utimaco.^{[NIST CMVP MIP List]} None of these have crossed the finish line. The MIP list updates continuously, and compliance teams should treat any specific vendor status cited here as a point-in-time snapshot that requires independent verification. For context on which underlying algorithms are involved, FIPS 203, FIPS 204, and the HQC backup standard represent the full scope of NIST's finalized PQC algorithm suite that vendors are working to incorporate.

For organizations running Linux-based infrastructure, OpenSSL 3.5 has added PQC support, with FIPS module validation targeted for Q3 2026 onward. However, as of Q1 2026, no enterprise Linux distribution holds FIPS 140-3 PQC validation. This closes a common assumption gap: teams that believe their OS-level OpenSSL FIPS module covers PQC requirements are operating on an incorrect premise.

The February 2026 CMVP Rule Change and What It Unlocks

On February 27, 2026, NIST published an administrative update to the CMVP Implementation Guidance that permits multiple sub-chip subsystems to appear on a single FIPS 140-3 certificate.^{[NIST CMVP IG Announcements, February 27, 2026]} This is a procedural change with real consequences for the vendor pipeline.

Previously, hardware security modules that incorporated multiple cryptographic subsystems — for instance, a classical RSA engine alongside a PQC coprocessor — faced structural challenges in how those components could be represented within a single validation boundary. The February update addresses this directly. In practical terms, it means HSM vendors who have been building PQC-capable hardware can now consolidate their module submissions more efficiently, potentially compressing the 12-to-24-month validation backlog that has accumulated as PQC-capable products entered the pipeline faster than the review process could accommodate.

Compliance teams should not interpret this as a signal that validated modules are imminent. Validation timelines are notoriously difficult to forecast, and the CMVP review queue remains substantive. But the rule change does indicate that NIST is actively managing pipeline bottlenecks — a signal worth noting for organizations setting internal planning horizons.

The Hybrid Mode Problem — What Federal Guidance Does and Does Not Say

Many organizations are deploying or piloting hybrid cryptographic configurations — pairing a classical algorithm such as ECDH with ML-KEM in a combined key encapsulation scheme — as a hedge against the validation gap. Products like OpenSSL 3.5 support these configurations at the implementation level. The security rationale is sound: a hybrid scheme is at least as strong as its strongest component, so a successful quantum attack on ML-KEM still leaves classical protection in place, and vice versa.

The compliance problem is that there is currently no formal NIST guidance on risk acceptance for pre-validation PQC deployments in FIPS-regulated environments.^{[NIST FIPS 140-3 Implementation Guidance]} This leaves compliance officers in an undocumented gray zone: hybrid configurations may be technically prudent and operationally valuable, but they cannot be represented as FIPS 140-3 compliant today. Any internal policy document, system security plan, or auditor communication that describes a hybrid PQC deployment as FIPS-compliant is inaccurate. The honest characterization is that it is a pre-validation pilot operating under documented risk acceptance, pending the availability of a validated module. The urgency here is amplified by the harvest-now-decrypt-later threat model, where adversaries collecting encrypted data today can retroactively decrypt it once quantum capability matures — making deployment delay itself a compliance and security risk.

What Auditors Will Ask Before a Validated Module Exists

Federal auditors under FedRAMP, DoD RMF, and FISMA frameworks are already beginning to ask PQC-related questions, even absent a validated module. Compliance officers should prepare for the following lines of inquiry:

Cryptographic Inventory Documentation

Can you produce a current inventory of every cryptographic module in your environment, with FIPS 140-3 validation status and certificate numbers? Auditors will want to see that this inventory exists and is maintained, not reconstructed at audit time. Cross-referencing your inventory against the NIST CMVP active list and MIP list should be a routine quarterly activity, not an emergency response.

Vendor Roadmap Evidence

For every HSM or cryptographic library in your environment, do you have documented vendor commitments — not marketing claims — to PQC validation timelines? This means written roadmaps, ideally with contractual milestone language, that establish when the vendor expects to submit for and receive FIPS 140-3 validation for PQC algorithms. Verbal assurances from sales teams are not audit artifacts.

Hybrid Configuration Risk Acceptance

If your organization is running hybrid PQC configurations, does a formal risk acceptance document exist? Who signed it, at what authority level, and what compensating controls are documented? Auditors are unlikely to penalize organizations for piloting hybrid configurations — but they will flag the absence of governance documentation around those pilots. Understanding the actual federal migration obligations under NSM-10 and NIST IR 8547 is essential context for framing that risk acceptance language accurately.

Cryptographic Agility Posture

Can you demonstrate that your architecture supports algorithm substitution without full system re-engineering? Cryptographic agility — the capacity to swap underlying algorithms as validated options become available — is increasingly treated as a design requirement rather than a nice-to-have. Document it explicitly in your security architecture artifacts.

A Compliance Roadmap for the Gap Period (Now Through 2027)

The following phased framework gives compliance teams a structured path through the validation gap without waiting for conditions that may not materialize on predictable timelines.

Phase 1: Inventory and Baseline (Immediate)

Pull your complete FIPS 140-3 module inventory today. For every entry, document the current CMVP certificate number, validation date, and whether the module appears in the MIP list with IUT or Review Pending status for ML-KEM, ML-DSA, or SLH-DSA. Flag every module that has no MIP entry as an open compliance risk item, and assign a named owner responsible for quarterly monitoring through 2027. This is not a one-time exercise — the MIP list changes frequently as vendors enter and advance through review.

Phase 2: Vendor Engagement and Contractual Documentation (30–90 Days)

Contact every cryptographic module vendor in your environment and request written PQC validation roadmaps. Specifically ask for: the algorithms they are targeting for CAVP certification, their expected CMVP submission date, and their projected validation completion date. Treat Q2 2027 — CIQ's public target for the first anticipated full PQC-validated module — as your current best-case planning anchor, while building contingency assumptions that extend to 2028 given historical validation delays.

Phase 3: Internal Policy on Hybrid Mode (60–120 Days)

Establish a written internal policy that defines under what conditions your organization will deploy hybrid PQC configurations pre-validation, what approval authority is required, and what compensating controls must be documented. This policy should be reviewed by legal and compliance counsel and approved at the CISO or equivalent level. It is the foundation for defensible audit conversations during the gap period.

Phase 4: Auditor Pre-Engagement (Ongoing)

Do not wait for your next scheduled audit to surface PQC compliance gaps. Engage your lead auditor or assessment organization proactively with a written status memo that explains the current state of FIPS 140-3 PQC validation, your vendor roadmap documentation, and your hybrid mode risk acceptance posture. Auditors who are briefed in advance are significantly more likely to treat gap-period activities as evidence of due diligence rather than compliance failures.

Phase 5: Go/No-Go Gates Tied to Validated Module Availability

Set explicit internal decision gates: when the first FIPS 140-3 validated PQC module is published on the CMVP active list, your organization will trigger a defined procurement and migration process within a specified number of days. This prevents the validation gap from becoming a planning gap — ensuring that the moment a compliant option becomes available, your organization is positioned to act rather than beginning its internal process from scratch.

Key Takeaways

• As of Q1 2026, zero FIPS 140-3 validated cryptographic modules support post-quantum algorithms in approved status. CAVP certifications exist; full CMVP validation does not.
• CAVP certification (algorithm correctness testing) and CMVP validation (full module approval) are distinct stages. Only CMVP validation confers FIPS 140-3 compliance. Conflating the two in auditor communications is a material misrepresentation.
• CIQ's Q2 2027 target represents the most specific public timeline for the first anticipated full PQC module validation. Treat this as a planning anchor, not a guarantee — validation timelines have historically slipped.
• The February 27, 2026 CMVP administrative update permitting multiple sub-chip subsystems on a single certificate may accelerate HSM vendor pipelines in the 12–24 month window ahead.
• Hybrid classical-plus-PQC configurations are technically sound but cannot be represented as FIPS 140-3 compliant. Organizations deploying them must document formal risk acceptance with appropriate approval authority.
• NIST has signaled deprecation of RSA and ECC by 2030. With migrations historically requiring seven to ten years, the gap-period planning work begins now, not when validated modules appear.
• This week's concrete action: pull your FIPS 140-3 module inventory, cross-reference every entry against the NIST CMVP Modules in Process list, and flag any module without MIP/IUT status for ML-KEM or ML-DSA as an open compliance risk item requiring a named owner.

This article draws on primary documentation from the NIST Cryptographic Module Validation Program (CMVP), including the FIPS 140-3 Implementation Guidance document, the CMVP IG Announcements page (including the February 27, 2026 administrative update), and the CMVP Modules in Process list. Vendor milestone information is sourced from publicly available press releases. All claims verified against official sources as of March 2026.

Related Reading

• Federal PQC Migration Deadlines: What Agencies Actually Face in 2026 and Beyond — A detailed breakdown of NSM-10, NIST IR 8547, and DoD memo obligations that define the real compliance timeline for federal agencies navigating the pre-validation period.
• Harvest Now, Decrypt Later: Why Every Month of PQC Delay Is an Irreversible Security Decision — An examination of the adversarial threat model that makes pre-validation pilot deployments a risk management imperative, not merely a technical experiment.
• FIPS 203, 204, and HQC Explained: What Security Architects Need to Know About NIST's Finalized PQC Standards — Technical grounding on ML-KEM, ML-DSA, and HQC for compliance officers who need to evaluate vendor algorithm claims against the actual finalized standards.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.