Use FIPS 140-3 for a new validation or current requirements analysis. A FIPS 140-2 certificate can still be relevant to an existing deployment or procurement decision, but its module, version, operational environment, certificate status, and transition date must be checked in records. FIPS 140-3 supersedes FIPS 140-2, uses ISO/IEC 19790 and ISO/IEC 24759 with NIST modifications, and is validated through CMVP review of testing performed by accredited laboratories.
Side-by-side comparison
FIPS 140-3 vs FIPS 140-2 legacy validation: what changes operationally?
This comparison helps separate legacy FIPS 140-2 references from FIPS 140-3 module requirements, testing evidence, approved-function evidence, and guidance mappings.
FIPS 140-3 is the current standard column: use it for cryptographic module scope, security levels, ISO/IEC 19790 and 24759 basis, approved functions, and validation evidence.
Second framework
FIPS 140-2 legacy validation
FIPS 140-2 is the legacy-reference column: use it only to understand superseded standard language, older certificate wording, and guidance topics that need mapping before reuse.
FIPS 140-3 vs FIPS 140-2 legacy validation: what changes operationally?
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.
FIPS 140-3 modules are validated through ; 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 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.
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.
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 evidence before it is used for a FIPS 140-3 claim.
Keep algorithm evidence linked to the module validation record. evidence can support the module file, but it is not a standalone statement that the module is FIPS 140-3 validated.
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.
began accepting FIPS 140-3 submissions on September 22, 2020 and stopped accepting FIPS 140-2 submissions for new validation certificates on September 22, 2021.
FIPS 140-2 validations may remain Active through September 21, 2026. says they move to the on September 22, 2026, when only FIPS 140-3 validations remain Active.
FIPS 140-2 legacy evidence should not rely on the for procurement decisions; the FIPS 140-3 standard says the Historical list is provided for reference only.
For procurement language, separate a current validated-module-list check from legacy certificate background. Do not present historical-list presence as procurement-ready evidence.
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 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.
Use FIPS 140-3 for current module requirement structure, validation evidence, approved-function claims, security policy content, and mapped implementation guidance.
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.
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.
FIPS 140-3 modules are validated through ; 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 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.
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.
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 evidence before it is used for a FIPS 140-3 claim.
Keep algorithm evidence linked to the module validation record. evidence can support the module file, but it is not a standalone statement that the module is FIPS 140-3 validated.
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.
began accepting FIPS 140-3 submissions on September 22, 2020 and stopped accepting FIPS 140-2 submissions for new validation certificates on September 22, 2021.
FIPS 140-2 validations may remain Active through September 21, 2026. says they move to the on September 22, 2026, when only FIPS 140-3 validations remain Active.
FIPS 140-2 legacy evidence should not rely on the for procurement decisions; the FIPS 140-3 standard says the Historical list is provided for reference only.
For procurement language, separate a current validated-module-list check from legacy certificate background. Do not present historical-list presence as procurement-ready evidence.
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 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.
Use FIPS 140-3 for current module requirement structure, validation evidence, approved-function claims, security policy content, and mapped implementation guidance.
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.
How to choose between FIPS 140-3 and FIPS 140-2 legacy validation
Use FIPS 140-3 for a new submission and for current module requirement, approved-function, and validation-evidence work.
Use a FIPS 140-2 claim only for a specific legacy certificate, deployment, contract, or customer question. Check its current status and the September 2026 Active-list transition before relying on it.
For reused evidence, cite the mapping from the FIPS 140-2 IG topic to the FIPS 140-3 IG or Management Manual section.
FIPS 140-3 supersedes FIPS 140-2 in its entirety. It keeps the same broad subject, security requirements for cryptographic modules, but bases the technical requirements on ISO/IEC 19790:2012/Cor.1:2015 and the testing basis on ISO/IEC 24759:2017, with NIST documents modifying the annexes and test evidence where acts as validation authority.
FIPS 140-3 characterizes its major changes as limited to introducing non-invasive physical requirements, but it also adopts an ISO-based document and testing structure. For a real module claim, identify the standard on the certificate, the module version and boundary, the tested operational environments, the approved services, and the certificate's current status.
Use FIPS 140-3 for new module submissions and current requirement work. has not accepted FIPS 140-2 submissions for new validation certificates since September 22, 2021.
As of July 24, 2026, says FIPS 140-2 modules may remain on the Active list through September 21, 2026. On September 22, 2026, only FIPS 140-3 validations remain Active; FIPS 140-2 certificates move to the .
A Historical certificate is not revoked, but it is no longer Active. says the should not be used for procurement decisions.
Check the entry instead of inferring status from the standard or certificate PDF. Confirm the exact module, version, operational environment, certificate status, sunset information, and any caveats.
How should teams read legacy FIPS 140-2 references?
A FIPS 140-2 reference does not prove what a module currently satisfies. First identify whether it names the old standard, a specific validation certificate, a FIPS 140-2 implementation guidance topic, or a contract requirement. Then check the certificate in 's validated-module search; the same product name can cover different module versions, boundaries, and operational environments.
Then translate only the supported parts into the FIPS 140-3 frame. The implementation guidance includes mappings from FIPS 140-2 guidance topics to FIPS 140-3 guidance or management manual sections, including certificate binding, approved and non-approved functions, entropy caveats, key establishment, self-tests, mitigation of other attacks, and revalidation-related topics.
Separate legacy label checks from current validation work; a FIPS 140-2 phrase may be procurement shorthand, but a certificate can remain Active until the transition date.
Map FIPS 140-2 guidance citations to the FIPS 140-3 IG or management manual mapping before reusing old evidence.
When evidence mentions algorithms, bind the claim to the relevant approved security function or certificate rather than to a generic compliance statement.
FIPS 140-3 evidence should follow the cryptographic module and the security areas named in the standard. The standard covers module specification, interfaces, roles, services and authentication, software and firmware security, operating environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks.
For validation evidence, the context matters. NIST states that vendors use independent, accredited Cryptographic and Security Testing laboratories, and that NVLAP-accredited laboratories perform cryptographic module compliance or conformance testing. A public claim should therefore name the module boundary, security level, approved functions, testing basis, and certificate or submission context that supports it.
Reuse is safest for factual artifacts that still describe the same module boundary, algorithm implementation, operational environment, role or service table, or security policy text. Reuse is weaker when an artifact exists only because a FIPS 140-2 guidance item had a different name, structure, or test expectation.
The IG mapping is the first reuse check. It shows where FIPS 140-2 implementation guidance moved into FIPS 140-3 guidance or management manual sections. If a legacy topic is not mapped to the same technical question, preserve it as background evidence instead of treating it as FIPS 140-3 proof.
Reusable with caution: diagrams, service tables, algorithm implementation descriptions, operational environment records, and security policy sections that still match the tested module.
Requires remapping: FIPS 140-2 IG citations such as certificate binding, entropy caveats, key establishment, and known-answer/self-test topics.
Not enough by itself: a prior FIPS 140-2 label, marketing claim, or customer spreadsheet cell with no certificate scope or module boundary.
Checklist for cleaning up mixed FIPS 140-2 and FIPS 140-3 claims
Review this checklist before publishing a FIPS claim, answering a procurement question, or preparing a validation evidence pack that references both standards.
State whether the claim is about FIPS 140-3, an older FIPS 140-2 certificate, or a contract clause that still uses FIPS 140-2 wording.
Attach the claim to a cryptographic module boundary, security level, operational environment, and approved security functions.
Check whether any cited FIPS 140-2 IG topic has a mapping to a FIPS 140-3 IG or management manual section.
Keep algorithm certificates separate from the module validation claim unless the evidence shows how they are bound to the module.
Avoid unsupported status language; verify module listing and procurement status outside this page before relying on it.
Common mistakes in FIPS 140-2 vs FIPS 140-3 comparisons
Treating the two labels as interchangeable causes most comparison errors. FIPS 140-3 has its own document basis, applicable standards, guidance, and testing evidence. Check each FIPS 140-2 reference before copying it into a current claim.
Do not say a module is FIPS 140-3 validated because its algorithms have certificates; algorithm validation and module validation are related evidence, not the same claim.
Do not cite FIPS 140-2 implementation guidance without checking the mapping to FIPS 140-3 guidance or management manual sections.
Use 's current transition page for calendar dates instead of deriving dates from FIPS 140-3's relative transition language.
Do not rely on the for procurement decisions; FIPS 140-3 itself warns that the Historical list is for reference.
Supports the cited CMVP claim about FIPS 140-3 implementation guidance, CAVP certificate binding, approved-service indicators, entropy, self-tests, or FIPS 140-2 guidance mappings.