FIPS 140-3 validation roadmap: what hardware security module vendors need to know about CMVP submission timelines

For financial institutions evaluating post-quantum hardware security modules, FIPS 140-3 validation status is the first question in the procurement checklist. The question "is it certified?" is asked before throughput numbers, interface compatibility, or pricing. Understanding exactly what FIPS 140-3 validation requires, what the CMVP process looks like for hardware vendors, and what the current timeline landscape is in 2025 is essential for institutions that need to begin procurement planning now.

This article is written from the perspective of someone who has sat through multiple FIPS 140 CMVP cycles with hardware vendors — both as a financial institution representative managing vendor qualification programs and now as part of Cryptrig's team managing our own validation path. The process is slower and more complex than most institutions realize, and the gap between "we designed for FIPS 140-3 Level 3" and "we hold a CMVP certificate" is measured in years, not weeks.

What FIPS 140-3 is and is not

FIPS 140-3 (Federal Information Processing Standard Publication 140-3) specifies security requirements for cryptographic modules. It is based on and incorporates ISO/IEC 19790:2012 and ISO/IEC 24759:2017. It superseded FIPS 140-2, which was issued in 2001 and remained in force for 20 years.

The standard defines four security levels:

• Level 1: Basic security requirements for cryptographic module design. Software implementations running on general-purpose hardware can achieve Level 1. No physical security requirements.
• Level 2: Physical tamper-evidence requirements added. Coatings, seals, or enclosures must provide evidence of tampering. Role-based authentication required.
• Level 3: Physical tamper-detection and response required — not just evidence, but active mechanisms that detect penetration and zeroize key material. Identity-based authentication. Private keys encrypted or split during entry and exit.
• Level 4: Complete envelope of physical security. Environmental failure protection required (voltage, temperature extremes). Highest assurance; primarily for air-gapped national security applications.

Payment HSMs, card scheme authorization modules, and regulated financial cryptographic infrastructure are required under PCI HSM and OCC/FFIEC examination expectations to use modules validated at FIPS 140-2 Level 3 or equivalent — and increasingly, FIPS 140-3 Level 3. Level 2 modules are generally not accepted for transaction key operations in regulated environments.

What FIPS 140-3 is not: it is not a cybersecurity certification, not a product security audit, and not an assessment of the correctness of the cryptographic algorithms implemented. A module can hold a FIPS 140-3 certificate and still implement those algorithms incorrectly outside of the test vectors. The standard validates that the module meets specific security engineering requirements — physical boundary, key management, self-tests, random number generation, operator authentication — not that the implemented cryptography is mathematically correct for every possible input.

The CMVP process: phases and timelines

The Cryptographic Module Validation Program (CMVP) is administered jointly by NIST and the Communications Security Establishment of Canada (CSE). Testing is performed by NIST-accredited third-party laboratories (NVLAP laboratories). The process has five main phases:

Phase 1: Pre-submission preparation (6–18 months)

Before engaging an NVLAP lab, hardware vendors prepare the Security Policy document, the module boundary documentation, and the evidence package demonstrating compliance with each security requirement. For a Level 3 hardware module, this includes:

• Cryptographic module boundary diagram (defining exactly what is inside the validated boundary)
• Physical security documentation (tamper mesh design, sensor specifications, zeroization circuit design)
• Key management design (all key types, their lifecycle, entry/exit procedures)
• Operator and user role definitions and authentication mechanism documentation
• Self-test documentation (power-on self-test procedures and expected results)
• Algorithm test evidence (ACVTS-generated test results for all implemented algorithms)

This phase is frequently the longest because it requires finalizing the hardware design before testing — any design change during testing requires re-documentation and potentially re-testing. Vendors who submit before their hardware is fully stable face significant delays.

Phase 2: NVLAP lab engagement and testing (6–18 months)

NVLAP (National Voluntary Laboratory Accreditation Program) laboratories accredited for CMVP testing include a small number of organizations globally. The testing queue at major NVLAP labs for hardware modules at Level 3 is currently 9–18 months. The lab performs:

• Document review against all FIPS 140-3 and ISO/IEC 19790 requirements
• Physical security evaluation — in some cases including destructive testing of physical samples
• Algorithm correctness testing via NIST Automated Cryptographic Validation Testing System (ACVTS)
• Self-test verification
• Entropy assessment for RNG components

Phase 3: NIST review and coordination (3–6 months)

After the lab completes testing, the package is submitted to NIST's CMVP team for independent review. NIST may request clarifications, additional evidence, or corrections. For novel module types — PQC-native hardware falls into this category — NIST review tends to be more thorough as reviewers are establishing interpretation precedents.

Phase 4: Certificate issuance

Upon NIST approval, the module receives a CMVP certificate number, the Security Policy is published on the NIST CMVP website, and the module appears in the NIST Cryptographic Module Validation Program database. The certificate lists the exact hardware version, firmware version, and operating mode(s) validated. Any subsequent change — firmware update, hardware revision — requires a delta submission or new submission depending on the scope of change.

The PQC-native HSM certification gap

As of the publication of NIST FIPS 203 and FIPS 204 in August 2024, no hardware security module has received a CMVP certificate covering CRYSTALS-Kyber-1024 or CRYSTALS-Dilithium-3 as validated algorithms. This is not a vendor failure — it is a timeline fact. The standards were finalized in August 2024. CMVP testing of PQC-native hardware began entering the queue in late 2024. The first certificates for hardware implementing FIPS 203/204 are expected in the 2026–2027 timeframe, based on current queue depths at NVLAP labs.

Several established HSM vendors have announced FIPS 140-3 submissions covering existing algorithms with PQC algorithms listed as "not validated" or as a separate module component. This is an accurate representation of the certification state — the hardware boundary and classical algorithms may be validated while the PQC-specific mechanisms are pending. Financial institutions should read vendor claims carefully: "FIPS 140-3 validated" on an established Thales Luna or Entrust nShield product refers to the classical algorithm set, not PQC algorithms.

How to manage procurement during the certification gap

The certification gap creates a real procurement challenge for institutions that want to begin PQC integration now but whose compliance frameworks require certified modules. Several approaches are being used in the market:

Approach 1: Conditional deployment with regulatory engagement

Some institutions, particularly those with mature risk management frameworks and constructive relationships with their regulatory examiners, are deploying PQC-capable hardware in non-production evaluation configurations with the explicit plan to achieve FIPS 140-3 certification before moving to production key operations. This requires documented evidence of the vendor's validation path, a copy of the vendor's Security Policy draft, and examiner pre-engagement about the conditional deployment posture.

Approach 2: Hybrid deployment with certified classical HSM

Deploy a FIPS 140-3 Level 3 certified classical HSM alongside a PQC-capable HSM (designed for Level 3 but not yet certified). Use the classical HSM for regulated key operations that require a certificate today; use the PQC HSM for session key exchange where the classical HSM provides the certified key material. This layered approach maintains certified coverage while building operational experience with PQC hardware before full certification.

Approach 3: Wait for first-to-market PQC certificates

Begin integration testing with pre-production evaluation hardware now, with deployment deferred until CMVP certificate is issued. This approach costs migration runway — integration testing itself takes 6–12 months at most regulated institutions. Beginning integration testing in 2025 on a module that receives its certificate in 2027 means production deployment by 2027, which is within the recommended migration window.

What to require from hardware vendors before proceeding

For financial institution security and procurement teams evaluating PQC-capable HSMs during the certification gap, the minimum documentation set to request:

1. Security Policy draft: The FIPS 140-3 Security Policy document is the definitive specification of what the module does, its boundary, its key management approach, and its operator authentication. A vendor who cannot produce a draft Security Policy has not completed the design work required for CMVP submission.
2. ACVTS algorithm test results: NIST's Automated Cryptographic Validation Testing System generates test vectors for each algorithm. Kyber-1024 and Dilithium-3 implementation correctness can be verified independently against these vectors.
3. Physical security documentation: Engineering documentation for the tamper-detection mesh design, sensor types, and zeroization circuit. This is not always shareable under NDA, but vendors should be able to confirm the physical design elements targeted.
4. NVLAP lab engagement confirmation: Written confirmation of the vendor's engagement with a specific NVLAP lab and the expected submission timeline. "We plan to submit" is insufficient; confirmation of the contract with a specific lab is the signal that the vendor is committed to the timeline.
5. Reference to the module version in the submission: CMVP certificates are version-specific. If a vendor is telling you their current hardware will be certified, confirm that the hardware version you are evaluating is the version they are submitting — not a future hardware version.

Timeline realism: what the next three years look like

Based on current NVLAP queue data and NIST CMVP processing timelines:

• 2025: Pre-production evaluation hardware available from PQC-native HSM vendors. CMVP submissions entering queue. Integration testing window open for early adopters.
• 2026: First CMVP certificates for PQC-capable HSMs expected (likely Thales, Entrust, Utimaco for their established platforms with PQC additions; purpose-built PQC vendors like Cryptrig targeting late 2026 submission).
• 2027: First certified purpose-built PQC HSMs expected. Regulated institutions that began integration testing in 2025 can complete production deployment by this point.
• 2028–2029: NSA's CNSA 2.0 guidance target for full PQC deployment in National Security Systems. Financial institutions following FFIEC exam expectations should be in production by this window.

The migration window is tighter than the timelines suggest because the 2028–2029 target requires production deployment, not commencement of procurement. Working backward: production deployment requires certified hardware, certified hardware requires passing CMVP testing, CMVP testing requires final hardware, final hardware requires completed integration testing, integration testing takes 6–18 months. An institution that starts procurement evaluation in 2026 is unlikely to achieve production deployment by 2028.

The correct moment to begin evaluation was 2024. The second-best moment is now.

What FIPS 140-3 does not cover: reading the certificate correctly

A FIPS 140-3 certificate establishes that a specific hardware module, at a specific firmware version, operating in a specific set of documented modes, meets the security engineering requirements of FIPS 140-3 at the stated level. What financial institutions sometimes misread in vendor representations is how narrow this scope is.

The certificate covers the cryptographic module boundary. Operations performed outside that boundary — key material handled in host application memory, TLS session establishment in software on the host, configuration files that affect cryptographic policy — are not covered by the certificate. A common procurement error is assuming that "FIPS 140-3 Level 3 certified" on the HSM means the entire cryptographic infrastructure is FIPS-validated. It means the HSM module itself is. The application layer that calls the HSM via PKCS#11, the host server OS, and the network infrastructure carrying the PKCS#11 connections are outside the validation scope.

This is relevant for PCI DSS and FFIEC compliance assessments. The controls that payment regulations require around HSMs — dual-control key ceremonies, tamper-evidence logs, role-based authentication — are validated within the module boundary. Controls around the application layer that drives the HSM (proper key lifecycle management in application code, secure storage of PKCS#11 configuration, administrator authentication management) are the institution's responsibility, regardless of the HSM's certification level.

We are not saying FIPS 140-3 certification is insufficient — it is the correct and necessary floor for regulated payment HSMs. We are saying that institutions should read the Security Policy document for any certified module and confirm that the modes and configurations validated cover their intended use case. An HSM may be certified for Level 3 operations in a specific key management mode that excludes the bulk key generation path a particular application relies on. The Security Policy defines the operating environment; the certificate alone does not.

Physical security specifics at Level 3: what the tamper system actually does

FIPS 140-3 Level 3's physical security requirements are more specific than they appear in the standard's high-level summary. "Tamper-detection and response" requires active circuitry — not just epoxy coatings that show evidence of tampering, but sensors that detect penetration attempts in real time and trigger an autonomous zeroization response.

In a Level 3 module, this typically involves:

• Conductive tamper mesh: A fine-pitch conductive grid covering the FPGA or ASIC die and surrounding circuitry. The mesh resistance is continuously monitored; a penetration attempt that breaches a mesh trace changes resistance and triggers zeroization. The mesh must be designed with sufficient trace density to prevent tunneling between traces.
• Environmental sensors: Voltage and temperature sensors that detect glitching attacks — attempts to cause transient faults in key operations by perturbing the power supply or exposing the module to extreme temperatures. Detection of out-of-bounds voltage or temperature immediately triggers zeroization.
• Zeroization circuit: A hardware circuit independent of the main processor that, when triggered by tamper detection, writes all key material in volatile storage to zero within a defined time window (typically 100 milliseconds or less). The zeroization must be complete — partial zeroization that leaves some key material in battery-backed RAM or flash is a failure mode that the security policy must document as prevented.
• Battery-independent zeroization: The tamper response must operate even if main power is removed. This requires either a battery (with its own security design requirements — battery bypass is itself an attack vector) or a capacitor bank that provides enough energy to complete zeroization after power is cut.

For financial institutions evaluating pre-certification hardware, reviewing the vendor's tamper system design documentation — even under NDA — is the appropriate step. The question is not "will it pass Level 3" but "has the vendor designed the tamper mesh, sensor suite, and zeroization circuit to the Level 3 specification in sufficient detail that an NVLAP lab will be testing hardware that can pass." A vendor who can walk through each of the above elements with engineering specificity is further along the validation path than one who describes the tamper system at a marketing level.

CQ1's physical security architecture was designed to Level 3 specification from the first hardware revision. The tamper mesh, environmental sensors, and zeroization circuit are integrated design elements rather than add-ons to a hardware design that was originally built for Level 1 compliance. This design-from-day-one approach to physical security is one reason we are confident in our CMVP submission timeline — the Level 3 physical requirements are not a retrofit, they are the baseline the hardware was built around.