FIPS 140-3 CMVP Lifecycle and Status

FIPS 140-3 was issued on March 22, 2019 and superseded FIPS 140-2. CMVP began accepting FIPS 140-3 submissions on September 22, 2020. The standard's implementation schedule records program transition milestones; it does not set a recurring deadline for every commercial product.

CMVP changes its technical interpretations and management procedures over time. The official pages checked on 15 October 2026 identify an August 19, 2026 Implementation Guidance edition and an April 9, 2026 Management Manual edition. A submission must use the applicable requirements and guidance at the relevant submission stage, so record the edition used for each decision and recheck the official pages before a new or updated submission.

A module project runs on its own evidence and review sequence. Timing depends on when the vendor freezes scope, finishes evidence, engages a laboratory, closes findings, and enters CMVP review. FIPS 140-3 says the review schedule varies with coordination among the vendor, laboratory, and CMVP. Neither an IUT listing nor a Modules in Process state promises a validation date.

A separate procurement transition ended in September 2026: the cited CMVP FAQ set September 21, 2026 as the last day FIPS 140-2 validations remained on the Active list, with only FIPS 140-3 validations remaining Active from September 22, 2026. This status transition does not convert a FIPS 140-2 certificate into FIPS 140-3 or validate a changed product.

The vendor defines the implementation under test: its boundary, version, interfaces, roles, services, operational environments, security ratings, approved security functions, Security Policy, and supporting evidence. The vendor contracts with an accredited Cryptographic and Security Testing laboratory. The CST laboratory independently evaluates the module, performs required testing, prepares the report, and submits the package. CMVP, jointly managed by NIST and the Canadian Centre for Cyber Security, reviews the submission and makes the validation decision.

CAVP algorithm testing supports the package but does not replace module validation. A CAVP certificate identifies a tested algorithm implementation and operational environment. The CMVP certificate detail connects the defined module to its Security Policy, caveats, status, and algorithm references.

The buyer or system owner does not repeat laboratory testing. The buyer verifies the public CMVP entry and reads the Security Policy to decide whether the deployed module, version, environment, services, and caveats meet the system's requirements. If a validated module is embedded in a larger product, CMVP does not assure that the product invokes it correctly.

Use one versioned record through the lifecycle rather than recreating scope for each team. The record should let an engineer, laboratory, CMVP reviewer, release owner, and buyer identify the same module and distinguish planned scope, tested claims, submitted claims, and completed validation.

Public process labels are not certificates. The Implementation Under Test list is voluntary and covers modules undergoing laboratory testing whose reports have not been submitted; CMVP says it does not know whether or when those reports will arrive. The Modules in Process list tracks specified submission types after CMVP receives the report and shows states such as Pending Review, Cost Recovery, Review, Comment Resolution, Finalization, or Hold. Only the published validation entry establishes completed validation.

Step 1, Scope and design freeze. Owner: Vendor. Evidence: boundary diagram, module/version manifest, interfaces, roles, services, target levels, operational environments. Exit question: Is the implementation under test unambiguous?

Step 2, Evidence preparation. Owner: Vendor with laboratory input. Evidence: Security Policy, requirement mapping, algorithm and entropy evidence, self-test results, physical and lifecycle evidence. Exit question: Is the package ready for independent testing?

Step 3, Conformance testing. Owner: Accredited CST laboratory. Evidence: test results, reviewed vendor evidence, findings, final test report. Exit question: Does the tested module satisfy the claimed requirements?

Step 4, Submission and CMVP review. Owner: CST laboratory, vendor, and CMVP. Evidence: submitted package, cost-recovery record where applicable, comments, responses, corrected evidence, and review state. Exit question: Has CMVP completed review and accepted this exact module and claim?

Step 5, Publication and release. Owner: CMVP and vendor. Evidence: public module record, certificate details, non-proprietary Security Policy, caveats, release claim. Exit question: Does the shipped configuration match the public record?

Step 6, Maintenance and reassessment. Owner: Vendor, laboratory when needed, and product owner. Evidence: change-impact record, status check, Common Vulnerabilities and Exposures (CVE) analysis, updated evidence or revalidation submission. Exit question: Can the existing validation still be relied on?

Validation is not a permanent whole-product approval. Assess changes to hardware, software, firmware, excluded components, the boundary, services, algorithm implementations, operating systems, processors, hypervisors, entropy sources, and bound or embedded modules against the validated configuration and current CMVP rules before shipping the old claim.

Section 7.1 of the current CMVP Management Manual defines twelve submission scenarios. An updated version may use revalidation rather than full validation depending on the extent and type of change; if it does not meet a revalidation scenario, it must undergo full validation. The vendor reviews every FIPS 140-3 requirement affected by the change, while the CST laboratory independently evaluates the impact and performs the required testing.

CMVP guidance requires CVE assessment during and after validation. A module need not be free of every CVE, but the vendor must determine applicability and security relevance and document mitigation where needed. For a post-validation security-relevant CVE or maintenance fix, work with a CST laboratory on the applicable CVE, Update, or Full Submission path; do not patch the module and keep using the old claim without that assessment.

Before procurement or customer assurance relies on a certificate, check the live CMVP record rather than a supplier slide, an old Security Policy copy, or a CAVP algorithm result. Record the module name, version, certificate number, status, sunset date, tested environments, Security Policy, caveats, approved services, and the product configuration that invokes the module.

Active is the default status for a newly validated module. Current CMVP policy generally places FIPS 140-3 validations on the Active list for five years; an Interim Validation is valid for two years unless converted through the applicable follow-up process. The certificate's actual sunset date controls the record, and programmatic transitions can move a validation to Historical sooner.

Historical means the record is no longer Active because of age, current guidance, or a programmatic transition; it does not mean the module never passed validation. FIPS 140-3 warns that the Historical list is for reference and should not be used for procurement decisions, although the Management Manual allows an agency to make a documented risk decision about continued use. Revoked means the validation is no longer valid and may not be cited to demonstrate FIPS 140 conformity.