| Standard basis | FIPS 140-3 supersedes FIPS 140-2 and is based on ISO/IEC 19790:2012/Cor.1:2015 for requirements and ISO/IEC 24759:2017 for testing, with NIST modifications. | FIPS 140-2 is the superseded standard in this comparison; use its wording only to interpret legacy certificates, old customer language, or mapped implementation guidance. | Start with the standard basis before reusing text. A FIPS 140-2 clause may describe useful history, but FIPS 140-3 controls current requirement and testing structure. |
|---|
| Validation route | FIPS 140-3 modules are validated through CMVP; vendors use independent, accredited Cryptographic and Security Testing laboratories, and NVLAP-accredited laboratories perform compliance or conformance testing. | A FIPS 140-2 reference does not by itself prove a current CMVP result. Treat it as a legacy validation reference until the certificate, module boundary, and status evidence are checked separately. | Compare validation evidence, not only standard names. The useful record names the module, laboratory-tested evidence, certificate context, and whether the claim is legacy or FIPS 140-3. |
|---|
| Requirement areas | FIPS 140-3 names requirement areas for module specification, interfaces, roles, services, authentication, software and firmware security, operating environment, physical security, non-invasive security, sensitive security parameters, self-tests, life-cycle assurance, and mitigation of other attacks. | FIPS 140-2 comparisons should not be reduced to a same-name checklist. FIPS 140-3 states that major changes are limited to non-invasive physical requirements and uses ISO-based requirement and test structures. | Build the crosswalk by requirement area, then mark where FIPS 140-3 adds, renames, or relocates evidence expectations instead of copying a legacy checklist. |
|---|
| Approved functions | FIPS 140-3 requires conforming cryptographic modules to employ Approved security functions, including approved algorithms, key management techniques, and authentication techniques. | A FIPS 140-2-era algorithm or certificate reference must be checked against the applicable approved-function and CAVP evidence before it is used for a FIPS 140-3 claim. | Keep algorithm evidence linked to the module validation record. CAVP evidence can support the module file, but it is not a standalone statement that the module is FIPS 140-3 validated. |
|---|
| Implementation guidance | FIPS 140-3 evidence should cite the applicable FIPS 140-3 IG or management manual section, such as certificate binding, approved-service indicators, entropy caveats, SSP establishment, self-tests, or mitigation of other attacks. | FIPS 140-2 IG citations need mapping. CMVP provides tables that map FIPS 140-2 IG topics to FIPS 140-3 IG entries or FIPS 140-3 Management Manual sections. | Do not translate legacy IG names by hand. Use the CMVP mapping table, then verify the mapped FIPS 140-3 guidance text before reusing old evidence. |
|---|
| Transition language | FIPS 140-3 states relative implementation milestones: effectiveness after Secretary of Commerce approval, a lab preparation transition period, FIPS 140-3 testing beginning later, and FIPS 140-2 testing ending. | FIPS 140-2 legacy references should not be turned into calendar-date claims unless the date comes from a separate verified source for the certificate, transition page, or procurement file. | Use the relative schedule only as context on this page. Verify exact dates and module status elsewhere before publishing a deadline or validation-status statement. |
|---|
| Procurement use | FIPS 140-3 says agencies should develop plans to acquire products compliant with FIPS 140-3 and may purchase products on the CMVP validated modules list. | FIPS 140-2 legacy evidence should not rely on the CMVP Historical list for procurement decisions; the FIPS 140-3 standard says the Historical list is provided for reference only. | For procurement language, separate a current CMVP validated-module-list check from legacy certificate background. Do not present historical-list presence as procurement-ready evidence. |
|---|
| Evidence reuse | FIPS 140-3 evidence must still match the tested module: boundary, security level, operational environment, services, approved functions, and relevant security policy content. | FIPS 140-2 evidence may be useful background only when it describes the same module facts or maps cleanly through the CMVP FIPS 140-2 to FIPS 140-3 guidance tables. | Reuse facts before conclusions. Reuse diagrams or service tables only after confirming they still describe the tested module and the mapped FIPS 140-3 evidence question. |
|---|
| Practical decision rule | Use FIPS 140-3 for current module requirement structure, CMVP validation evidence, approved-function claims, security policy content, and mapped implementation guidance. | Use FIPS 140-2 only as legacy context unless a certificate, customer question, procurement clause, or historical evidence file specifically requires that label. | Do not collapse the two sides into one claim. Say which standard the evidence supports, then link legacy FIPS 140-2 references to mapped FIPS 140-3 guidance when reuse is justified. |
|---|