We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALFIPS 140-3

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

A NIST-cited 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 guidance.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
6 sections8 primary sources
Overview

Use FIPS 140-3 for a new validation or current requirements analysis. A FIPS 140-2 certificate can still be relevant to reviewing an existing deployment or legacy contract requirement, 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.

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

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.

Validation route

FIPS 140-3

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.

FIPS 140-2 legacy validation

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.

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.

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.

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 evidence before it is used for a FIPS 140-3 claim.

Operational implication

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.

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. 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 mapping table, then verify the mapped FIPS 140-3 guidance text before reusing old evidence.

Transition language

FIPS 140-3

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

The transition ended FIPS 140-2 Active-list eligibility on September 21, 2026. From September 22, 2026, only FIPS 140-3 validations remain Active and FIPS 140-2 certificates move to the .

Operational implication

Check the live entry before procurement or deployment. Historical status is not revocation: current CMVP guidance permits procurement for legacy systems, but says Federal Agencies should not include Historical modules in new systems. Record the system context and any agency risk determination about continued use.

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 validated modules list.

FIPS 140-2 legacy validation

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.

Operational implication

For procurement language, separate a current validated-module-list check from legacy certificate background. Do not present historical-list presence as procurement-ready evidence.

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

Practical decision rule

FIPS 140-3

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

FIPS 140-2 legacy validation

Use FIPS 140-2 for a specific legacy certificate, existing deployment, procurement clause, or historical evidence file, and verify its current status.

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 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.
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 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.
  • The transition ended FIPS 140-2 Active-list eligibility on September 21, 2026. From September 22, 2026, only FIPS 140-3 validations remain Active; FIPS 140-2 certificates belong on the . Check the live record for the module you use.
  • A Historical certificate is not revoked, but it is no longer Active. The current validated-modules guidance says Federal Agencies should not include Historical modules in new systems but may procure them for legacy systems. Agencies may separately make a risk determination about continued use based on where and how the module is used.
  • 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.
Section 2

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 contract wording from current validation work. The published transition ended FIPS 140-2 Active-list eligibility on September 21, 2026; check the live record and distinguish continued use from new procurement.
  • 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.
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 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, algorithm certificates, self-test evidence, entropy records, and change-impact rationale.
Recommended next step

Review the module evidence behind the claim

This comparison helps separate legacy FIPS 140-2 wording from FIPS 140-3 module scope, security policy, approved-function, and CMVP guidance evidence.

Assessment workflow
Open Assessment Autopilot for FIPS 140-3

Turn mixed FIPS 140-2 and FIPS 140-3 claims into scoped evidence tasks for module boundaries, security policies, and algorithm certificates.

Explore next step
Research workflow
Research FIPS 140-3 source questions

Use NIST and CMVP source material to resolve supersession, ISO basis, guidance mapping, and evidence questions.

Explore next step
Talk to Sorena
Talk through implementation

Review module scope, legacy wording, public claims, and cited evidence with Sorena.

Explore next step
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 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

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.
Section 6

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.
Primary sources

References and citations

NIST FIPS 140-3 security requirements for cryptographic modules
doi.org10 citations
Referenced sections
  • Supports the public claims that FIPS 140-3 supersedes FIPS 140-2, uses ISO/IEC 19790 and ISO/IEC 24759 as its basis, and defines cryptographic module security areas.
  • Supports the supersession claim, ISO/IEC 19790 and ISO/IEC 24759 basis, cryptographic module scope, and NIST's statement about major FIPS 140-3 changes.
  • Supports the distinction between FIPS 140-2 as the superseded standard and FIPS 140-3 as the current standard basis.
Show 7 more
  • Supports the list of FIPS 140-3 security requirement areas and the CMVP laboratory testing context.
  • Supports why evidence reuse must stay tied to the cryptographic module, security level, and security requirement areas.
  • Supports checklist items for module boundary, security level selection, approved security functions, and laboratory-tested validation context.
  • Supports the warning against unsourced transition-date conversion and the Historical list procurement caveat.
  • Supports the claim that FIPS 140-3 supersedes FIPS 140-2 and uses ISO/IEC 19790 and ISO/IEC 24759 as its document basis.
  • Supports the claim that FIPS 140-2 is superseded and should not be treated as the current technical basis without a separate legacy trigger.
  • Supports the cited FIPS 140-3 claim about supersession, module scope, security levels, ISO-based requirements, approved functions, CMVP validation, or procurement caveats.
"FIPS 140-3 supersedes FIPS140-2"
More quoted passages
"This standard supersedes FIPS 140-2"
"secure design and implementation of a cryptographic module"
"security level to which a cryptographic module is validated"
"Cryptographic modules that conform to this standard"
"Historical list should not be used for procurement decisions"
"FIPS 140-3 is based on ISO/IEC 19790"
"four increasing, qualitative levels of security"
CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov9 citations
Referenced sections
  • Supports CMVP guidance mappings from FIPS 140-2 implementation guidance topics to FIPS 140-3 guidance or management manual sections.
  • Supports the mapping from FIPS 140-2 implementation guidance topics to FIPS 140-3 guidance and management manual sections.
  • Supports using CMVP's FIPS 140-2 to FIPS 140-3 guidance mappings rather than manually translating legacy guidance names.
Show 6 more
  • Supports FIPS 140-3 evidence topics such as certificate binding, approved service indicators, entropy caveats, self-tests, and implementation guidance updates.
  • Supports using CMVP's mapping tables before translating FIPS 140-2 implementation guidance evidence into FIPS 140-3 work.
  • Supports checklist items for FIPS 140-2 IG mapping, CAVP certificate binding, approved functions, entropy, and self-test guidance.
  • Supports the distinction between algorithm certificate evidence and module validation evidence.
  • Supports using CMVP implementation guidance for FIPS 140-3 evidence details once the current standard basis is selected.
  • 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.
"Mapping FIPS 140-2 IGs to FIPS 140-3"
More quoted passages
"FIPS 140-2 IG"
"Binding of Cryptographic Algorithm Validation Certificates"
"FIPS 140-3 IG"
"Implementation Guidance for FIPS PUB 140-3"
NIST Cryptographic Module Validation Program overview
csrc.nist.gov4 citations
Referenced sections
  • Supports the FIPS 140-2 submission cutoff, the September 21, 2026 end of Active-list use for new systems, and the move of FIPS 140-2 certificates to the Historical list after that date.
  • Supports the dates when CMVP began accepting FIPS 140-3 submissions and stopped accepting FIPS 140-2 submissions for new certificates.
  • Supports the September 21, 2026 end of Active-list use for FIPS 140-2 modules in new systems and the September 22 move to the Historical list.
Show 1 more
  • Supports the current FIPS 140-2 and FIPS 140-3 transition dates and Active-list status.
CMVP FIPS 140-3 Management Manual, 9 April 2026
csrc.nist.gov
Referenced sections
  • Section 4.7 permits agencies to make a risk determination about continued use of a Historical module based on where and how it is used; revoked validations cannot demonstrate FIPS 140-3 compliance.
NIST CMVP FAQ, CL-4
csrc.nist.gov
Referenced sections
  • CL-4 specifies the September 21/22, 2026 transition from FIPS 140-2 Active-list eligibility to only FIPS 140-3 validations remaining Active.
NIST Cryptographic Algorithm Validation Program
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

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

Collect FIPS 140-3 approved-mode evidence for a specific module service: boundary, indicator, selected CAVP capabilities, Security Policy entry, and deployment configuration.

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 CMVP Lifecycle and Status Guide

Follow a FIPS 140-3 module from scoping and CST-laboratory testing through CMVP review, publication, Active status, revalidation, and procurement checks.

Show all related guides (28)

FIPS 140-3 compliance guide

A FIPS 140-3 compliance guide grounded in official sources for cryptographic module scope, security levels, 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 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 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 Security Policy Template

Draft the vendor-authored parts of a FIPS 140-3 CMVP Security Policy and prepare the structured module information that CMVP merges into the final policy.

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

Decide whether a changed FIPS 140-3 module still matches its validation or needs a CMVP revalidation scenario, evidence update, or paused claim.

FIPS 140-3 Validation Maintenance Change Workflow

Triage a changed FIPS 140-3 module against current CMVP revalidation scenarios, Security Policy evidence, CAVP testing, operational environments, and CVE handling.

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: 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

Compare FIPS 140-3 Security Levels 1 through 4 by requirement area and document a level claim without extending it beyond the validated module.

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 the tested implementation, operational environment, service use, and CMVP Security Policy record.

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

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.