FIPS 140-3: Cryptographic Module Validation (CMVP), explained

Unlike its predecessor, FIPS 140-3 does not spell out its own detailed technical requirements. NIST's own CMVP standards page states it plainly: "FIPS 140-3 references International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 19790" for the actual module security requirements, and "the testing for these requirements will be in accordance with ISO/IEC 24759." NIST supplements both ISO standards with its own SP 800-140 series of derived test requirements, which CMVP-accredited labs use during validation.

That structural point matters for accuracy here: this guide can confirm, directly from NIST's publication page, that there are four levels and that they are "qualitative" and "increasing." The clause-by-clause detail of what separates Level 1 from Level 4 — physical tamper-evidence versus tamper-resistance, authentication requirements, environmental failure protection — lives inside ISO/IEC 19790, a paywalled ISO standard. Device makers scoping a validation should treat that document (or NIST's own SP 800-140 series) as the source of record for level-by-level requirements, not any secondary summary, including this one.

The FIPS 140-3 text itself does name the 11 areas the requirements cover: module specification; interfaces; roles, services, and authentication; software/firmware security; operating environment; physical security; non-invasive security; sensitive security parameter management; self-tests; life-cycle assurance; and mitigation of other attacks. It also says the level "must be chosen to provide a level of security appropriate for the security requirements of the application and environment." The SP 800-140 documents that a lab and vendor work with:

Modules are not self-certified against FIPS 140-3 — they go through the Cryptographic Module Validation Program (CMVP). NIST's own project page states the program's goal is "to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules," and confirms CMVP is run jointly by NIST and Canada's Canadian Centre for Cyber Security. NIST's page states the program currently maintains over 1,000 active validated modules, and confirms "As of September 22, 2020, CMVP began validating cryptographic modules to" FIPS 140-3 — a full validation year after the standard itself was published, reflecting the time needed to stand up ISO/IEC 24759-aligned test requirements.

The same page sets out why federal buyers care: "Non-validated cryptography is viewed as providing no protection to the information or data," and "if cryptography is required, then it must be validated."

NIST's cost recovery fee page lists the 2026 fees for CMVP report review, effective 1 January 2026. "Modules and entropy sources are not validated unless all applicable fees have been collected." The CST laboratory's own testing is contracted and priced separately.

A transition NIST had scheduled since shortly after FIPS 140-3's publication has now taken effect. NIST's own FIPS 140-3 Transition Effort page states: "FIPS 140-2 modules can remain active for 5 years after validation or until September 21, 2026, when the FIPS 140-2 validations will be moved to the historical list." That date has now passed as of this guide's publication (26 October 2026).

For a device maker, the practical read is: an in-field product validated under FIPS 140-2 did not suddenly become insecure on 21 September 2026, and NIST's own guidance confirms continued use for existing systems. But any new product, new contract, or new compliance attestation that specifies a FIPS-validated cryptographic module should now be scoped against FIPS 140-3, not 140-2 — and given CMVP's published validation queues, that scoping should start well before a shipping deadline rather than at the point a customer asks for proof. FIPS 140-3 itself adds that "the CMVP Historical list should not be used for procurement decisions."

NIST answers this on its Updates, Patches, and CVEs page: "The original version would maintain its validation but the new version that includes the patch/update would not be validated." NIST still "strongly recommend[s] patching," and says the patch decision is "not a decision the CMVP has either the information necessary or the authority to make."

To bring the patched version back under a certificate, the Management Manual (§7.1.11) offers a CVE revalidation scenario:

• the lab confirms the security-relevant changes only correct the vulnerability, with no new features or cryptography;
• the lab tests the affected assertions plus CMVP's predefined regression tests;
• if the fix touches an algorithm implementation, that algorithm is CAVP-tested again;
• once complete, "the previous version of the module is no longer considered validated (in essence, Revoked)" and is removed from the certificate, unless the Security Policy shows how the issue is mitigated.

A fix that needs no security-relevant change can go through the non-security-relevant (NSRL) revalidation route instead. For porting, §7.9.1 lets a vendor recompile a firmware module without source changes on the same tested operating system, but "Level 2 and above Firmware modules cannot be ported and maintain their validation, since Physical Security must be retested."

A validated cryptographic module is frequently the concrete artifact regulators and customers ask for when a broader cybersecurity regulation requires "state of the art" encryption or secure communication — see our guides to EN 18031 and the Cyber Resilience Act for two examples of regulations that reference cryptographic requirements without mandating FIPS specifically. Because CMVP validation lead times run long, and because the FIPS 140-2 sunset above means some existing designs now need re-validation under FIPS 140-3, it is worth treating cryptographic module choice as an early architecture decision rather than something resolved at the point of a compliance deadline. Defense and payment buyers ask for it too: see our guides to SP 800-172A assessments and PCI DSS v4.0.1.

• "FIPS compliant" claims. Using approved algorithms is not validation; a module is validated only for the version and operating environment on its certificate.
• Algorithm certificates mistaken for module certificates. CAVP certificates are a prerequisite, not the result.
• Silent rebuilds. Changing module source code for a feature makes it a new module that needs a full submission.
• Missed interim sunsets. An interim validation moves to the historical list after two years unless converted in time.
• Historical certificates in new bids. FIPS 140-3 says that list "should not be used for procurement decisions."
• Weak defaults outside the module. A validated module does not fix insecure cryptography elsewhere in the firmware (how to fix weak cryptography).

FIPS validation itself is a CMVP-accredited lab's job, not something SoftWSP's pipeline performs or claims to. What the pipeline does is extract a CycloneDX 1.6 SBOM from a firmware image, identifying which cryptographic library and version a product actually ships, and match that version against NVD, CISA KEV, FIRST EPSS and CISA CSAF ICS advisories. It does not query the CMVP list: an engineer compares the identified library and version with the module name and version on the certificate. AI-assisted analysis drafts the plain-language finding naming the component, version and any matched CVE, with citations, for an engineer to weigh against the product's FIPS 140-3 plan. SoftWSP's AI does not decide a module's security level or perform any part of CMVP's own validation testing. The extracted SBOM opens in the SBOM viewer; our firmware security testing methodology guide covers the wider review.

SoftWSP's firmware security assessments can help device makers scope cryptographic module requirements alongside broader regulatory obligations like CRA and RED/EN 18031: see device firmware security.

This guide summarises public NIST publications; it does not constitute legal or compliance advice.