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

FIPS 140-3 ("Security Requirements for Cryptographic Modules") is the current US federal standard for validating the cryptographic modules inside hardware and software products. Published by NIST on 22 March 2019, it supersedes FIPS 140-2 (3 December 2002). NIST's own publication page describes the standard as providing "four increasing, qualitative levels of security intended to cover a wide range of potential applications and environments" — meaning a single framework is meant to cover everything from low-sensitivity administrative systems to physically unprotected, high-assurance deployments. The standard applies directly to US federal agencies, and is referenced well beyond government procurement: device and firmware makers selling into regulated sectors (healthcare, critical infrastructure, defense supply chains) frequently need a FIPS-validated crypto module regardless of whether they sell to the US government directly.

Four security levels, incorporated by reference

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 honesty 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 this guide did not access the full text of this session. 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.

CMVP: the joint NIST/Canada validation program

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 FIPS 140-2 sunset: 21 September 2026

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).

Status	What it means, per NIST's own CMVP guidance
Active	Meets the current standard; can be cited in new procurements
Historical (all FIPS 140-2 modules, as of 21 Sept 2026)	Completed its validation lifecycle; NIST's transition page states "Even on the historical list, CMVP supports the purchase and use of these modules for existing systems," but new acquisitions should not rely on it where an Active validation is required
Revoked	A specific security failure is on record for the module

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.

Why this matters for device and firmware makers

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.

A workable starting point

1. Check whether any component you already ship is on CMVP's list — a module may already carry a FIPS 140-2 validation now moving to historical status, which is a signal to re-scope it under FIPS 140-3 rather than assume continued coverage.
2. Scope the target security level against your actual deployment environment, not the highest level available — Level 1 software-only modules are a legitimate, common choice for products that do not need physical tamper protection.
3. Budget validation lead time into the product schedule, not the compliance schedule — CMVP throughput for new FIPS 140-3 submissions has been a published bottleneck industry-wide since the standard's 2019 publication.
4. Read ISO/IEC 19790 directly (or engage a CMVP-accredited lab) before committing to level-specific claims — FIPS 140-3 itself incorporates that standard by reference rather than restating it.

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.