Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 FIPS 140-2 vs FIPS 140-3

A NIST-grounded comparison of what changed when FIPS 140-3 superseded FIPS 140-2 for cryptographic module validation.

Use it to separate legacy certificate language from current FIPS 140-3 scope, testing, approved functions, and CMVP guidance.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

Use this page when a product brief, procurement response, security policy, or customer questionnaire mixes FIPS 140-2 and FIPS 140-3 language. The comparison focuses on facts supported by NIST and CMVP sources: FIPS 140-3 supersedes FIPS 140-2, is based on ISO/IEC 19790 and ISO/IEC 24759 with NIST modifications, and is validated through CMVP testing by accredited laboratories.

Side-by-side comparison

FIPS 140-3 vs FIPS 140-2 legacy validation: what changes operationally?

Use this comparison to separate legacy FIPS 140-2 references from FIPS 140-3 module requirements, CMVP testing evidence, approved-function evidence, and guidance mappings.

Review all sources
First framework
FIPS 140-3

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 CMVP 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 CMVP guidance topics that need mapping before reuse.

Comparison row 1

Standard basis

FIPS 140-3

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 legacy validation

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.

Operational implication

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.

Comparison row 2

Validation route

FIPS 140-3

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.

FIPS 140-2 legacy validation

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.

Operational implication

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.

Comparison row 3

Requirement areas

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 legacy validation

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.

Operational implication

Build the crosswalk by requirement area, then mark where FIPS 140-3 adds, renames, or relocates evidence expectations instead of copying a legacy checklist.

Comparison row 4

Approved functions

FIPS 140-3

FIPS 140-3 requires conforming cryptographic modules to employ Approved security functions, including approved algorithms, key management techniques, and authentication techniques.

FIPS 140-2 legacy validation

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.

Operational implication

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.

Comparison row 5

Implementation guidance

FIPS 140-3

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 legacy validation

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.

Operational implication

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.

Comparison row 6

Transition language

FIPS 140-3

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 validation

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.

Operational implication

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.

Comparison row 7

Procurement use

FIPS 140-3

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 validation

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.

Operational implication

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.

Comparison row 8

Evidence reuse

FIPS 140-3

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 legacy validation

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.

Operational implication

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.

Comparison row 9

Practical decision rule

FIPS 140-3

Use FIPS 140-3 for current module requirement structure, CMVP validation evidence, approved-function claims, security policy content, and mapped implementation guidance.

FIPS 140-2 legacy validation

Use FIPS 140-2 only as legacy context unless a certificate, customer question, procurement clause, or historical evidence file specifically requires that label.

Operational implication

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.

Practical decision rule

How to choose between FIPS 140-3 and FIPS 140-2 legacy validation

  • Use FIPS 140-3 when the claim concerns current cryptographic module requirements, ISO-based testing, approved functions, or CMVP validation evidence.
  • Use FIPS 140-2 only when a legacy certificate, customer question, or historical evidence file specifically uses that label.
  • For reused evidence, cite the CMVP mapping from the FIPS 140-2 IG topic to the FIPS 140-3 IG or Management Manual section.
Section 1

What changed from FIPS 140-2 to FIPS 140-3?

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 CMVP acts as validation authority.

NIST describes the major changes in FIPS 140-3 as limited to the introduction of non-invasive physical requirements. For comparison work, that means the first question is not whether both labels sound similar; it is whether the module claim, test evidence, and guidance reference point to the superseded FIPS 140-2 regime or to FIPS 140-3 and its ISO-based structure.

  • Treat FIPS 140-2 as legacy language unless a source, certificate, contract, or customer question specifically asks about an older validation.
  • Use FIPS 140-3 when the work concerns a current cryptographic module requirement, CMVP submission, security policy, or approved-function claim.
  • Do not infer current certificate status from the standard text alone; verify module status in the applicable CMVP listing or customer evidence pack.
Section 2

How should teams read legacy FIPS 140-2 references?

A FIPS 140-2 reference is not enough to prove what a module currently satisfies. First identify what the reference is doing: naming an older standard, pointing to an older certificate, citing a FIPS 140-2 implementation guidance topic, or asking for assurance that the module has been tested under CMVP.

Then translate only the supported parts into the FIPS 140-3 frame. The CMVP 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 a procurement shorthand rather than the controlling test requirement.
  • 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 CAVP certificate rather than to a generic compliance statement.
Section 3

What evidence belongs on the FIPS 140-3 side?

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

  • Boundary evidence: module type, hardware, software, firmware, hybrid components, interfaces, and operational environment.
  • Service evidence: roles, services, authentication, approved and non-approved functions, and approved-service indicators where applicable.
  • Test evidence: security policy, laboratory report context, CAVP algorithm certificates, self-test evidence, entropy records, and change-impact rationale.
Section 4

Where can FIPS 140-2 evidence be reused?

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 CMVP 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.
Section 5

Checklist for cleaning up mixed FIPS 140-2 and FIPS 140-3 claims

Use 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 CMVP mapping to a FIPS 140-3 IG or management manual section.
  • Keep CAVP 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.
Section 6

Common mistakes in FIPS 140-2 vs FIPS 140-3 comparisons

Most comparison errors come from treating the two labels as interchangeable. FIPS 140-3 has its own document basis, applicable standards, CMVP guidance, and testing evidence; FIPS 140-2 references need to be checked before they are copied into a current claim.

  • Do not say a module is FIPS 140-3 validated because its algorithms have CAVP certificates; algorithm validation and module validation are related evidence, not the same claim.
  • Do not cite FIPS 140-2 implementation guidance without checking the CMVP mapping to FIPS 140-3 guidance or management manual sections.
  • Do not convert FIPS 140-3's relative transition language into unsourced calendar dates on this page.
  • Do not rely on the CMVP Historical list for procurement decisions; FIPS 140-3 itself warns that the Historical list is for reference.
Primary sources

References and citations

csrc.nist.gov
Referenced sections
  • 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.
"CAVP addresses the testing of Approved Security Functions"
csrc.nist.gov
Referenced sections
  • Official NIST CAVP source for validation testing of approved algorithms and for linking algorithm certificate evidence to FIPS module reviews.
"provides validation testing of Approved"
Related guides

Explore more topics

FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary
Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence.
FIPS 140-3 Algorithm Certificates FAQ
How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence.
FIPS 140-3 Applicability Test
Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence.
FIPS 140-3 Approved and Non-Approved Mode Workflow
Classify FIPS 140-3 module services by approved security service, allowed no-security-claimed use, and non-approved service evidence.
FIPS 140-3 approved-mode evidence workflow
A grounded workflow for collecting FIPS 140-3 approved-mode evidence: module boundary, approved services, service indicators, CAVP certificates, Security Policy entries, and change review.
FIPS 140-3 Certificate Maintenance FAQ
How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records.
FIPS 140-3 Change Impact Review
Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence.
FIPS 140-3 compliance guide
A grounded FIPS 140-3 compliance guide for cryptographic module scope, security-level claims, CMVP validation evidence, and procurement review.
FIPS 140-3 Entropy and DRBG Evidence
FIPS 140-3 entropy and DRBG guidance for module boundary decisions, entropy caveats, Security Policy evidence, ESV references, and DRBG CSP handling.
FIPS 140-3 Entropy Evidence FAQ
How FIPS 140-3 entropy evidence should document entropy source location, GetEntropy access, SP 800-90B testing, Security Policy text, and certificate caveats.
FIPS 140-3 FAQ for Cryptographic Modules
Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence.
FIPS 140-3 Module Boundaries FAQ
Understand how FIPS 140-3 module boundaries affect cryptographic module scope, interfaces, software and firmware components, and bound or embedded validated modules.
FIPS 140-3 Module Boundary Selector Workflow
A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence.
FIPS 140-3 operational environments FAQ
Learn what a FIPS 140-3 operational environment means for software, firmware, and hybrid cryptographic modules, and what evidence to check before relying on a validation claim.
FIPS 140-3 security levels: how to choose and evidence them
A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes.
FIPS 140-3 Security Policy Template
Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence.
FIPS 140-3 Validation Checklist
Checklist for preparing a cryptographic module for FIPS 140-3 validation: boundary, levels, services, approved algorithms, entropy, tests, security policy, and change evidence.
FIPS 140-3 Validation Maintenance
Maintain FIPS 140-3 validation claims by checking module identity, certificate status, boundary changes, operational environments, and CAVP evidence.
FIPS 140-3 Validation Maintenance Change Workflow
A FIPS 140-3 workflow for triaging module changes against CMVP validation scope, Security Policy evidence, CAVP certificates, software loading, and CVE records.
FIPS 140-3 Vendor Affirmation FAQ
When vendor affirmation can support a FIPS 140-3 module claim, what it does not supersede, and which Security Policy, CAVP, CSTL, and test-report evidence to keep.
FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759
Compare FIPS 140-3 with ISO/IEC 19790 and ISO/IEC 24759 for cryptographic module validation scope, evidence, testing, and procurement claims.
FIPS 140-3: CMVP Lifecycle Timeline
Practical FIPS 140-3 guidance for CMVP Lifecycle Timeline: scope, controls, evidence, source-linked decisions, and implementation checkpoints.
FIPS 140-3: Module Boundary and Service Mapping
Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence.
FIPS 140-3: Module Boundary Selector
Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence.
FIPS 140-3: Operational Environment
FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims.
FIPS 140-3: Security Levels Explained
Explain FIPS 140-3 Security Levels 1 through 4, what they cover, and how to document level claims for cryptographic module validation.
FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules
Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence.
How should teams handle approved mode under FIPS 140-3?
Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions.