# CMVP and FIPS 140-3: How Cryptographic Modules Get Validated **Source**: https://quantumsequrity.com/blog/cmvp-fips-140-3 **Category**: Compliance & Regulation --- [← Back to Blog](../../blog.html) Compliance & Regulation # CMVP and FIPS 140-3: How Cryptographic Modules Get Validated 11 min read The Cryptographic Module Validation Program (CMVP) is the joint program of NIST and Communications Security Establishment Canada (CSE) that validates cryptographic modules against the Federal Information Processing Standard (FIPS) 140 series. A module that holds an active CMVP certificate has been independently tested and confirmed to implement specified cryptographic algorithms correctly and to provide specified protections against tampering, side channel attacks, and other threats. FIPS 140-3 is the current standard, having superseded FIPS 140-2 in 2019. This article walks through how CMVP works, what FIPS 140-3 requires, how it differs from FIPS 140-2, and how the post quantum cryptography algorithms (ML-KEM, ML-DSA, SLH-DSA) are entering the validation pipeline. ## What CMVP Is CMVP began in 1995. It tests cryptographic modules submitted by vendors against the requirements in the operative FIPS 140 standard. The testing is done by accredited Cryptographic and Security Testing (CST) laboratories. The CST lab produces a test report, NIST and CSE technical reviewers evaluate the report, and on successful review NIST issues a validation certificate. The certificate identifies the module by name, version, and vendor. It lists the validation level (1 through 4), the operational environment, and the algorithms validated within the module. The certificate is published on the NIST CMVP module list at csrc.nist.gov/projects/cryptographic-module-validation-program. ## Why CMVP Matters CMVP certificates are operationally required by: - FISMA federal information systems for protection of CUI (per NIST SP 800-53 SC-13) - FedRAMP authorized cloud services - NIAP Common Criteria evaluations (often) - Department of Defense systems handling CUI (per DFARS 252.204-7012) - HIPAA, PCI DSS, and other private sector frameworks that reference NIST cryptography A cryptographic module without a current CMVP certificate cannot be relied on as the basis for cryptographic claims in these frameworks. Vendors selling into these markets need CMVP certification. ## FIPS 140-3 Structure FIPS 140-3 was published as a NIST FIPS publication in March 2019, with effective date September 2019 for new submissions. FIPS 140-3 incorporates ISO/IEC 19790:2012 (Security requirements for cryptographic modules) and ISO/IEC 24759:2017 (Test requirements for cryptographic modules) as the technical content, with NIST specific implementation guidance overlaid. FIPS 140-3 has eleven security areas: 1. Cryptographic module specification 2. Cryptographic module interfaces 3. Roles, services, and authentication 4. Software / firmware security 5. Operational environment 6. Physical security 7. Non invasive security 8. Sensitive security parameter management 9. Self tests 10. Life cycle assurance 11. Mitigation of other attacks Each area has requirements at four security levels (1 through 4), with Level 1 being the lowest assurance and Level 4 being the highest. Many software cryptographic libraries are validated at Level 1 or 2. Hardware security modules are typically validated at Level 3 or 4. ## FIPS 140-3 vs FIPS 140-2 FIPS 140-2 was published in 2001 and remained the operative standard until FIPS 140-3 superseded it. The substantive differences include: - ISO/IEC 19790 alignment: FIPS 140-3 directly references the ISO standard, harmonizing with international cryptographic module evaluation - Non invasive security: FIPS 140-3 introduces an explicit area for side channel attack resistance, including Differential Power Analysis (DPA) and Timing Analysis countermeasures - Mitigation of other attacks: FIPS 140-3 adds a documentation requirement for attacks the module is designed to resist beyond the standard's other areas - Sensitive security parameters: Replaces the FIPS 140-2 concept of Critical Security Parameters with a broader definition that includes public security parameters and private cryptographic keys FIPS 140-2 historical certificates remain valid until expiry, with the CMVP working through a phased sunset. The transition has run through 2024 and 2025, with NIST publishing detailed sunset dates for each FIPS 140-2 certificate vintage. ## Validation Levels Explained Level 1: Basic security with at least one approved algorithm. Software modules typically claim Level 1. The validation evidence focuses on algorithm correctness and basic operational environment specification. Level 2: Adds tamper evident physical security and role based authentication. Software modules running on commercial general purpose operating systems can reach Level 2. Many enterprise cryptographic libraries (Microsoft, OpenSSL FIPS, BoringCrypto) are validated at Level 2. Level 3: Adds tamper resistant physical security and identity based authentication. Most production hardware security modules (HSMs) are validated at Level 3. Examples include Thales Luna Network HSM, AWS CloudHSM, and Google Cloud HSM. Level 4: Highest level, with envelope tamper detection and active tamper response. Level 4 modules typically include hardware that detects environmental attacks (temperature, voltage, EM) and zeroizes keys on detection. Few modules reach Level 4 because of cost and complexity. ## The Validation Process A typical FIPS 140-3 validation runs: 1. Vendor selects an accredited CST lab 2. Vendor and lab agree on a Statement of Work 3. Vendor provides design documentation, source code, test vectors, and physical samples 4. Lab tests the module against FIPS 140-3 requirements 5. Lab tests algorithm correctness against the Cryptographic Algorithm Validation Program (CAVP) test vectors 6. Lab produces a test report 7. Vendor and lab finalize the security policy document 8. Lab submits the report and security policy to CMVP 9. NIST and CSE reviewers evaluate the submission 10. CMVP issues the certificate, or returns the report with comments for remediation The end to end timeline is typically twelve to eighteen months, with longer durations for high level modules or modules with complex environments. The CMVP queue has historically been backlogged, with reviewer wait times contributing to overall duration. ## CAVP: Algorithm Validation The Cryptographic Algorithm Validation Program (CAVP) is the algorithm specific testing layer. CAVP issues test vectors for each NIST approved algorithm, and modules submit their implementations to CAVP testing as a prerequisite for CMVP module validation. CAVP certificates are public and listed on the NIST CAVP page. For the post quantum algorithms, CAVP test vectors and test runs for ML-KEM, ML-DSA, and SLH-DSA were published shortly after FIPS 203, 204, and 205 finalized in August 2024. Vendors implementing these algorithms can submit their implementations for CAVP testing now. ## Post Quantum Algorithms in CMVP PQC algorithms entering CMVP follow the same path as classical algorithms. The major milestones for PQC validation are: - August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) finalized - Late 2024: CAVP test vectors and validation services available for ML-KEM, ML-DSA, SLH-DSA - 2025: First CMVP certificates including PQC algorithms beginning to issue - 2025 to 2027: PQC validations becoming routine as vendor pipelines clear The CMVP active list now includes a small but growing number of modules with ML-KEM and ML-DSA support. Customers tracking PQC migration should query the CMVP list periodically and engage vendors directly about expected validation dates. ## Approved Mode Requirements A FIPS 140-3 validated module operates in either Approved Mode or Non Approved Mode. In Approved Mode, only NIST approved algorithms are available, and the module enforces algorithm and parameter constraints from the relevant SP 800-XX family. Customers using a FIPS validated module typically must enable Approved Mode in their configuration. The configuration is documented in the module's security policy. Failing to enable Approved Mode means the module is in Non Approved Mode, and FIPS validation does not apply to the cryptographic operations performed. For Microsoft Windows, Approved Mode is enabled through the FIPS algorithm policy setting. For OpenSSL FIPS, Approved Mode is enabled through provider configuration. Each module has its own activation procedure. ## Operational Environment The operational environment is the platform on which the module runs. For software modules, this is typically a specific operating system version on specific hardware. The validation certificate names the operational environment, and use of the module on a different environment voids the validation. CMVP allows for "vendor affirmation" of additional operational environments after initial validation, where the vendor states that the module operates equivalently on the additional environment. This is faster than re validation but is bounded by the original test scope. ## Side Channel Resistance FIPS 140-3 area 7 (Non invasive security) introduces explicit testing for side channel attacks at Levels 3 and 4. The implementation guidance is in NIST SP 800-140F (CMVP Approved Non Invasive Attack Mitigation Test Metrics). Tested attacks include: - Timing Analysis - Simple Power Analysis (SPA) - Differential Power Analysis (DPA) - Electromagnetic emanation analysis For lattice based PQC algorithms, side channel resistance is particularly important because of recent academic results showing leakage in non hardened implementations. Hardware security modules with PQC support typically include DPA countermeasures. ## Module Types CMVP recognizes three module types: - Software module: implemented entirely in software, runs on a general purpose operating system - Firmware module: implemented in firmware, runs on embedded or specialized hardware - Hybrid module: combination of software and hardware components Software modules are most common. Firmware modules are used in HSMs, smart cards, and embedded devices. Hybrid modules combine software with hardware accelerators. ## Module Maintenance A FIPS 140-3 certificate is valid for a defined period (typically five years from initial issue, with revalidation required to extend). Maintenance updates to the module require either a maintenance letter for minor changes or a full revalidation for significant changes. The CMVP guidance documents specify what counts as minor vs major. For PQC migration, adding a new algorithm to an existing validated module typically requires a major revalidation, because the algorithm boundary changes. ## What This Means for Vendors A cryptographic module vendor in 2026 should: 1. Track CMVP queue status and reviewer feedback rates. 2. Prioritize PQC algorithm support in product roadmaps. 3. Engage CST labs early to align on test scope and timeline. 4. Plan major revalidations for adding PQC algorithms. 5. Maintain ongoing FIPS 140-3 maintenance to avoid certificate lapses. ## What This Means for Customers A customer relying on FIPS validated cryptographic modules should: 1. Verify current certificate status before each procurement. 2. Confirm Approved Mode is enabled in production configurations. 3. Track upcoming sunset dates for FIPS 140-2 certificates still in use. 4. Engage vendors on PQC validation roadmaps. 5. Document module dependencies in SSP and inheritance artifacts. ## FAQ **Q: Is FIPS 140-2 still acceptable in 2026?** A: Active FIPS 140-2 certificates remain valid until expiry, with phased sunset through 2026 per CMVP transition guidance. New module submissions must use FIPS 140-3. **Q: Can I use a non FIPS validated cryptographic library?** A: For protection of CUI in federal civilian systems, FedRAMP authorized cloud services, or DoD systems, no. For non federal use cases, FIPS validation is often a contract requirement but may not always be strictly required. **Q: How long does FIPS 140-3 validation take?** A: Twelve to eighteen months end to end is typical, with the CMVP review queue contributing significantly. PQC capable validations are at the longer end of that range as reviewers work through new algorithm questions. **Q: What is the difference between CMVP and CAVP?** A: CAVP validates that an algorithm implementation produces correct outputs for known answer test vectors. CMVP validates an entire cryptographic module, including correct algorithm implementation, key management, physical security, and other module level requirements. CAVP is a prerequisite for CMVP. **Q: Where do I find a current CMVP certificate?** A: NIST publishes the CMVP active list at csrc.nist.gov/projects/cryptographic-module-validation-program. The list is searchable by vendor, module name, certificate number, and validation level. Each certificate listing links to the validated module's security policy document, which describes approved operating modes and configuration requirements. ## Sources 1. NIST FIPS 140-3, Security Requirements for Cryptographic Modules (March 2019). https://csrc.nist.gov/pubs/fips/140-3/final 2. ISO/IEC 19790:2012, Security requirements for cryptographic modules. https://www.iso.org/standard/52906.html 3. ISO/IEC 24759:2017, Test requirements for cryptographic modules. https://www.iso.org/standard/72515.html 4. NIST CMVP Active and Historical Validation Lists. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules 5. NIST SP 800-140 series, FIPS 140-3 Derived Test Requirements. https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-documentation 6. NIST FIPS 203, 204, 205 (August 2024). https://csrc.nist.gov/projects/post-quantum-cryptography ## Related Articles - [NIST FIPS Guide](nist-fips-guide.md) - [Common Criteria PQC](common-criteria-pqc.md) - [NIAP and PQC](niap-pqc-requirements.md) - [FedRAMP Rev 5 Cryptography](fedramp-rev-5-cryptography.md) - [CMMC Level 2 and 3 Cryptography](cmmc-level-2-3-crypto.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)