A plain-language sequence from module scoping and accredited-laboratory testing to CMVP review, public validation evidence, maintenance, and status checks.
The standard, the CMVP process, CAVP algorithm testing, and a supplier's product claim are related but not interchangeable. This guide shows where each fits.
Structured answer sets in this page tree.
Cited legal and guidance references.
A FIPS 140-3 validation belongs to one defined cryptographic module: its name, version, boundary, tested operational environments, services, security ratings, and caveats. The vendor prepares the module and evidence, an accredited Cryptographic and Security Testing laboratory tests it, and reviews the submitted report and decides whether to validate it. Publication is not the end of the lifecycle. Product owners and buyers must keep checking the live record, Security Policy, sunset date, guidance and algorithm transitions, vulnerabilities, dependencies, and implementation changes before reusing the claim.
FIPS 140-3 was issued on March 22, 2019 and superseded FIPS 140-2. 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.
changes its technical interpretations and management procedures over time. The official CMVP pages identify April 9, 2026 as the latest Implementation Guidance and Management Manual editions. 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 review. FIPS 140-3 says the review schedule varies with coordination among the vendor, laboratory, and CMVP. Neither an listing nor a state promises a validation date.
A separate procurement transition ends in 2026: the current FAQ says FIPS 140-2 validations remain on the Active list through September 21, 2026, and only FIPS 140-3 validations remain 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 independently evaluates the module, performs required testing, prepares the report, and submits the package. , jointly managed by NIST and the Canadian Centre for Cyber Security, reviews the submission and makes the validation decision.
algorithm testing supports the package but does not replace module validation. A CAVP certificate identifies a tested algorithm implementation and operational environment. The 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 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, 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; says it does not know whether or when those reports will arrive. The 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.
1 | Scope and design freeze | Vendor | boundary diagram, module/version manifest, interfaces, roles, services, target levels, operational environments | Is the implementation under test unambiguous?
2 | Evidence preparation | Vendor with laboratory input | Security Policy, requirement mapping, algorithm and entropy evidence, self-test results, physical and lifecycle evidence | Is the package ready for independent testing?
3 | Conformance testing | Accredited | test results, reviewed vendor evidence, findings, final test report | Does the tested module satisfy the claimed requirements?
4 | Submission and review | , vendor, and CMVP | submitted package, cost-recovery record where applicable, comments, responses, corrected evidence, and review state | Has CMVP completed review and accepted this exact module and claim?
5 | Publication and release | and vendor | public module record, certificate details, non-proprietary Security Policy, caveats, release claim | Does the shipped configuration match the public record?
6 | Maintenance and reassessment | Vendor, laboratory when needed, and product owner | change-impact record, status check, CVE analysis, updated evidence or revalidation submission | Can the existing validation still be relied on?
Keep module scope, laboratory evidence, CMVP review responses, public claims, status checks, and post-validation changes connected in one accountable workflow.
Convert validation preparation and maintenance decisions into owners, evidence requests, and review gates.
Resolve boundary, service, algorithm, environment, transition, and status questions against cited official material.
Review the module claim, laboratory-readiness gaps, status evidence, and change-control path with Sorena.
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 rules before shipping the old claim.
Section 7.1 of the current 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 independently evaluates the impact and performs the required testing.
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 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 record rather than a supplier slide, an old Security Policy copy, or a 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 policy generally places FIPS 140-3 validations on the Active list for five years; an 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 sooner.
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. means the validation is no longer valid and may not be cited to demonstrate FIPS 140 conformity.
"CMVP is not requiring that the module and associated equipment be free from CVEs"
"validated modules"
"CMVP Historical list should not be used for procurement decisions"