FIPS 140-2 vs FIPS 140-3: Sunset, Changes, Procurement

Since September 2026 every FIPS 140-2 certificate sits on the CMVP Historical list, so the question for buyers is no longer "is it validated?" but "which standard, which status, and can I still use it here?" Many estates still run modules whose only certificate is a FIPS 140-2 one, and many procurement templates, contracts and security plans still say "FIPS 140-2 validated". This guide compares the two standards on three things only: the sunset timeline and what Historical status permits, what actually changed in FIPS 140-3, and what that means for procurement, FedRAMP and your module inventory. It is for security architects, procurement and compliance leads, and product teams selling to federal or regulated customers. For how the Cryptographic Module Validation Program (CMVP) works end to end and how to read a certificate, see the FIPS 140-3 and Cryptographic Module Validation Guide; this page does not repeat it.

Key takeaways

Historical is not revoked. CMVP says Historical modules should not go into new federal systems but can still be procured for legacy systems, and agencies may make a risk determination on continued use. A revoked certificate cannot be cited at all.
The cut-off has passed. CMVP states that FIPS 140-2 modules could be used for new systems until 21 September 2026; after that their certificates move to the Historical list.
The standard changed shape more than substance. FIPS 140-3 adopts ISO/IEC 19790 and ISO/IEC 24759 instead of stating requirements itself. NIST describes few major technical changes, but the detailed requirement set and evidence burden grew.
Your contracts are probably out of date. Language that asks for "FIPS 140-2 validated" now asks for a status CMVP no longer issues for new systems; ask for an Active FIPS 140-3 certificate (or a defined exception path) instead.
Inventory decides the cost. The transition is cheap where a vendor already ships a FIPS 140-3 version and expensive where a Historical module is embedded in hardware or a product you cannot upgrade. You only know which by inventorying modules and certificate numbers.

The short answer

For anything new, specify and accept only modules with an Active FIPS 140-3 certificate, operated in the approved mode their security policy describes. For existing systems that rely on a FIPS 140-2 module now on the Historical list, you are not forced into an emergency replacement: CMVP supports continued purchase and use for existing systems. But you should record a risk decision, plan the move to a FIPS 140-3 module in the next normal upgrade cycle, and stop calling those systems "validated" without qualification. If you sell to US federal agencies or hold a FedRAMP authorisation, expect assessors and agency reviewers to ask for this evidence explicitly.

Dimension	FIPS 140-2	FIPS 140-3
Published	3 December 2002 (superseded)	Approved 22 March 2019; effective 22 September 2019
Where the requirements live	In the FIPS document itself, with its own Derived Test Requirements	ISO/IEC 19790:2012 (with 2015 corrections) for requirements, ISO/IEC 24759:2017 for tests, modified by NIST SP 800-140 to 800-140F
New certificates	None since 1 April 2022	Accepted since 22 September 2020
Certificate status today	Historical (or Revoked)	Active for five years, or two years for interim validations
Use in new federal systems	Not after 21 September 2026	Yes, while Active
Use in existing systems	Permitted; agency risk determination	Yes
Newer algorithms	No route to add them: no new certificates	The only route for newly approved algorithms, including post-quantum ones

The sunset timeline, read carefully

The transition ran for seven years. The dates below are as NIST's FIPS 140-3 transition page and the CMVP project page state them, checked on 14 November 2026.

Date	Event	What it meant in practice
22 March 2019	FIPS 140-3 approved by the Secretary of Commerce; supersedes FIPS 140-2	Start of the transition clock
21 to 22 September 2020	Implementation Guidance and 140-3 management manual released; CMVP begins accepting FIPS 140-3 submissions	First 140-3 modules enter the queue
22 September 2021	No new FIPS 140-2 submissions, except where the vendor was under contract with a lab before 15 June 2021 and CMVP accepted an extension request	Most vendors had to plan 140-3 validations from here
1 April 2022	No FIPS 140-2 submissions for new certificates; only reports that do not change the sunset date	Existing 140-2 certificates could be maintained but never extended
6 June 2024	Two-year interim validations for modules submitted before 1 January 2024	A pressure valve for the long review queue; interim certificates stay Active for two years, not five
21 September 2026	Last date FIPS 140-2 Active modules can be used for new systems	The procurement cut-off
22 September 2026	All FIPS 140-2 certificates placed on the Historical list (transition schedule row)	No 140-2 certificate remains Active

Note on the date: NIST's schedule row says 22 September 2026 for the move to Historical; its narrative and the CMVP page give 21 September 2026 as the last day for new systems. Quote 21 September 2026 as the cut-off and cite the CMVP page.

Earlier exits: certificates are Active for five years, so many 140-2 modules were Historical long before 2026; the 2026 date was the final backstop.

What Historical status does and does not allow

CMVP's validated modules page sets out three statuses.

Status	CMVP position	New systems	Existing systems	Can you cite it as evidence?
Active	On the Active list for five years (two for interim)	Yes	Yes	Yes
Historical	Not revoked; certificate older than five years or moved for programmatic reasons; may not accurately reflect how the module can be used in FIPS mode	Should not be included	Can be procured and used; agencies may make a risk determination	Yes, with the status stated, for existing systems
Revoked	No longer valid; may not be referenced to demonstrate compliance	No	Use no longer permitted	No

The caveat that matters: CMVP warns that a Historical certificate "may not accurately reflect how the module can be used in FIPS mode". Approved algorithms and key sizes have moved on since many 140-2 security policies were written (SP 800-131A transitions, for example). A Historical certificate tells you the module was validated against the rules of its day, not that its approved mode still meets current algorithm requirements. Check its approved algorithm list against what your system actually negotiates.

Outside government: Historical status matters through contracts and frameworks that import the requirement. Read the clause: "FIPS 140 validated", "FIPS 140-3 validated" and "Active CMVP certificate" are different tests.

What actually changed in FIPS 140-3

NIST says the move brought few major technical requirement changes but several procedural ones, because ISO/IEC 19790 and 24759 change how validation is run. Lab material is more specific. The accredited laboratory atsec counted the assurance, vendor evidence and test requirements at Level 1 rising from 187, 172 and 263 under FIPS 140-2 to 238, 241 and 366 under FIPS 140-3, roughly 27 to 40 per cent more. The changes that matter to buyers are below.

Structure and documents: FIPS 140-3 points to ISO/IEC 19790:2012 and ISO/IEC 24759:2017, modified by the SP 800-140 series. SP 800-140B Rev. 1 (November 2023) fixes the security policy content and order, which makes 140-3 policies easier to compare across vendors than 140-2 ones.

Technical requirement changes

Area	FIPS 140-2	FIPS 140-3 (ISO/IEC 19790 as modified)	Why it matters to you
Terminology	Critical security parameters (CSPs)	Sensitive security parameters (SSPs) = CSPs plus public security parameters (PSPs)	Zeroisation and protection now apply to more parameters
Approved service indicator	Not required as such	Every service must indicate when it uses an approved algorithm, function or process	Applications can check programmatically that they stayed in approved mode; ask how the indicator is exposed
Roles	Crypto Officer and User	Crypto Officer is the minimum; User role no longer required	Role models in older policies may not map one to one
Authentication (Level 2 and above)	Could rely on procedures	Module must enforce authentication; default authentication data replaced after first use; mechanisms per SP 800-140E	Change default credentials on HSMs and appliances is now a module requirement, not just guidance
Authentication (Level 4)	Identity-based	Multi-factor identity-based authentication required	Affects operator procedures for the highest-assurance modules
Software and firmware integrity	Integrity test at power-up	Approved hash, HMAC or signature at Level 1; HMAC or signature at Level 2; signature only at Levels 3 and 4; on-demand integrity test service	Stronger evidence that the deployed binary is the validated one
Non-invasive security	Not a separate area	New area: mitigations documented at all levels; tested at Levels 3 and 4 (SP 800-140F metrics)	Side-channel resistance becomes part of the certificate for high-level modules
Zeroisation	CSPs	All unprotected SSPs; status indicator at Levels 2 to 4; Level 4 returns the module to factory state	Decommissioning evidence is easier to obtain
Self-tests	Power-up algorithm tests	Pre-operational tests (integrity, bypass, critical functions); algorithm tests moved to conditional, before first use; a pairwise consistency test can no longer replace a known-answer test	Start-up behaviour and timing can differ between 140-2 and 140-3 versions of the same library
Life cycle	Limited	Vendor functional testing documented, automated security diagnostic tools for software, sanitisation (Levels 1 and 2) or destruction (Levels 3 and 4) procedures at end of life	More vendor evidence exists to request during due diligence

What did not change: there are still four security levels, validation still covers a defined module boundary on tested operational environments, and CAVP algorithm validation is still a prerequisite.

Why newer algorithms force the move

Because CMVP has issued no new FIPS 140-2 certificates since April 2022, any algorithm approved after that date can only appear in a FIPS 140-3 validated module. That includes the post-quantum standards, such as ML-KEM in FIPS 203 (published August 2024). If your roadmap includes post-quantum key establishment in a regulated context, a 140-3 module is a prerequisite. See the ML-KEM Guide and the CNSA 2.0 Transition.

Procurement impact

Contract and RFP language: replace "FIPS 140-2 validated" with wording that asks for what you can actually verify. A workable clause asks the supplier to name every cryptographic module that protects your data, give its CMVP certificate number, standard (140-2 or 140-3), status and sunset date, state the tested operational environments, and confirm the product runs the module in approved mode by default or document how to enable it. CMVP itself advises asking the vendor for a signed letter stating the product or module is validated and citing the certificate number, and warns that a mismatch with the CMVP entry means the vendor is not offering a validated solution.

Do not accept proxy claims: "FIPS compliant", "FIPS ready", "uses FIPS-approved algorithms" and a CAVP algorithm certificate on its own do not satisfy FIPS 140. CMVP states that implementing an approved function and obtaining algorithm certificates does not make a product meet FIPS 140-2 or 140-3. FedRAMP's cryptographic module policy goes further and bars providers from using ambiguous terms such as "FIPS compliant".

Supplier position	What it means	New system	Existing system
Active FIPS 140-3 certificate, matching version and platform	Meets current expectations	Accept	Accept
Active FIPS 140-3 interim certificate	Validated; Active for two years	Accept; track the sunset date	Accept
FIPS 140-2 certificate, now Historical	Not revoked; legacy use only	Do not accept for federal systems	Accept with a recorded risk determination and replacement plan
FIPS 140-3 module in process	Not yet validated	Only with contractual remedies and a dated plan	Use as the replacement target
CAVP certificates only, or "FIPS compliant"	Not a FIPS 140 validation	Reject where validation is required	Treat as unvalidated cryptography
Revoked certificate	Cannot be cited	Reject	Replace

FedRAMP and federal implications

FedRAMP's Policy for Cryptographic Module Selection and Use (version 1.1, January 2025) refers to "FIPS 140" rather than either revision. Key points:

Update stream or validated module stream: the policy defines an update stream (latest patches regardless of validation status) and a validated module stream (latest FIPS-validated versions). The provider must state its default in the system security plan and should not switch casually.
Vulnerabilities beat stale validation: FedRAMP generally prefers removing known vulnerabilities through patches, stating that known vulnerabilities can create risks that outweigh the assurance validation provides. Where an update is not possible, a POA&M entry is required.
Resubmission timing: the policy expects updated major versions to be submitted to the CMVP within six months of release.
Consolidated Rules for 2026: FedRAMP's Rev5 Class C ruleset includes CMU-CSO-CMD (document the modules protecting federal customer data and whether each is validated or an update stream of a validated module), CMU-CSO-UVM (should use modules or update streams with active validations) and CMU-CSO-CAT (default agency tenants to validated cryptographic services). It notes that an update stream adding algorithms never validated is not in scope. As published, these rules are optional from 4 July 2026 and apply to certification from 1 January 2027, with a grace period to 1 June 2027.

The reference to active validations is why the Historical move matters to cloud providers: a FIPS 140-2 module is no longer active, so a provider relying on one should document it as a gap with a remediation date. Map this to NIST SP 800-53 Rev. 5 SC-13 Cryptographic Protection, together with SC-8(1) and SC-28(1), which the FedRAMP policy names. For the wider programme see the FedRAMP Guide and FedRAMP 20x.

Building the module inventory

A cryptographic bill of materials gives you the base; this inventory adds the validation layer. See the Cryptographic Inventory and CBOM Guide.

Scope the systems: list systems where a contract, authorisation or regulation requires validated cryptography (federal systems, FedRAMP boundaries, CUI enclaves, regulated payment or health systems).
Find the modules: for each system, record operating system crypto libraries, language runtime providers, TLS terminators, VPN and SSH implementations, database and storage encryption, HSMs and cloud KMS or HSM services. Include modules embedded in appliances and SaaS used inside the boundary.
Record certificate facts: module name and exact version, CMVP certificate number, standard, status, sunset date, security level, tested operational environments, and whether approved mode is enabled. On Linux, check distribution FIPS mode; see the Linux System-Wide Crypto Policies and FIPS Mode Guide.
Classify each entry: Active 140-3; Active interim; Historical 140-2 with a 140-3 successor available; Historical with no successor; unvalidated or revoked.
Decide per class: upgrade in the next maintenance window where a successor exists; record a risk determination and replacement date where it does not; replace immediately anything revoked or unvalidated where validation is required.
Test before cut-over: run the 140-3 version in a pilot ring. Watch start-up time (self-test changes), rejected cipher suites and key sizes, and applications that call non-approved algorithms. Keep the previous package and configuration available for rollback, and record any rollback as a POA&M or risk item.
Keep it current: re-check status quarterly and at each major vendor release.

Decision guidance

Replace now when the system is new, the module is revoked, the requirement explicitly says FIPS 140-3 or Active, or the Historical module's approved mode allows algorithms or key sizes your policy no longer accepts.
Replace in the next cycle when a 140-3 successor exists and the system is stable: plan it with ordinary upgrades rather than as a project of its own.
Accept and document when the module is embedded in hardware or a product with no successor, the system has a defined end of life, and the risk determination shows the cryptography still meets current algorithm requirements.
Size: small organisations mostly rely on vendor-supported operating systems and cloud services with 140-3 certificates; large ones need a central inventory, a standard clause and an exception register.

Worked scenario

A FedRAMP Moderate SaaS provider's November 2026 inventory shows container base images on an operating system with an Active FIPS 140-3 certificate, keys in a cloud HSM service with an Active FIPS 140-3 Level 3 certificate, and load balancers terminating TLS with a FIPS 140-2 library now Historical. Only the load balancers need action. The vendor ships firmware with a 140-3 interim-validated module; a non-production pilot shows two legacy clients failing on a cipher suite the new approved mode refuses, so the provider agrees a client deadline, records a POA&M item naming the Historical and target certificate numbers and the date, and states its validated module stream in the system security plan.

Detection and measurement

Coverage: percentage of in-scope systems with every cryptographic module recorded with a certificate number.
Currency: percentage of in-scope modules with an Active FIPS 140-3 certificate; track Historical and interim separately.
Exceptions: number of Historical or unvalidated modules with a recorded risk determination and replacement date, and the number past that date.
Sunset horizon: modules whose certificate leaves the Active list in the next 12 months (interim certificates first).
Approved-mode drift: hosts or services found running outside approved mode, from configuration scans or the approved service indicator where the module exposes it.

Common failure patterns

Treating Historical as revoked: ripping out working modules in existing systems at high cost and risk, when CMVP permits continued use with a risk determination.
Treating Historical as Active: putting a 140-2 module into a new federal system after 21 September 2026 because the datasheet still says "FIPS 140-2 validated".
Version drift: claiming the certificate while running a different version or platform from the one tested, which CMVP says means the solution is not validated.
Validated module, unapproved mode: the library holds a certificate but the application negotiates algorithms listed outside the approved set, or FIPS mode was never switched on.
Forgetting interim expiry: interim certificates are Active for two years; treating them like five-year certificates creates a second, quieter sunset.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	SC-13 Cryptographic Protection	Defines the types of cryptography required; federal baselines rely on validated modules
NIST SP 800-53 Rev. 5	SC-8, SC-28, SC-12	Transmission and at-rest protection and key management that the validated module implements
NIST SP 800-53 Rev. 5	SA-4 Acquisition Process, SR-5	Put certificate, status and approved-mode requirements in contracts
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory, SA-22 Unsupported System Components	Module inventory and handling of components past their validation life
NIST SP 800-171 Rev. 3	03.13.11 Cryptographic Protection	Cryptography protecting controlled unclassified information
NIST CSF 2.0	ID.AM-02, PR.DS-01, PR.DS-02, GV.SC-05	Inventory, data protection at rest and in transit, supplier requirements in contracts
FedRAMP	Cryptographic Module Policy v1.1; CMU-CSO-CMD, CMU-CSO-UVM, CMU-CSO-CAT	Documentation, active validation and tenant defaults for cloud services

Practitioner checklist

Replace "FIPS 140-2 validated" in policies, RFPs and contract templates with a clause requiring an Active FIPS 140-3 certificate number and a signed vendor letter.
Inventory every module in scoped systems with certificate number, standard, status, sunset date and tested platforms.
Record a risk determination and replacement date for every Historical module still in use.
Check Historical modules' approved algorithms against current algorithm requirements, not just the certificate.
Track interim certificates separately; they leave the Active list after two years.
Confirm approved mode is on and verify it with the approved service indicator where available.
For FedRAMP, state your update or validated module stream in the system security plan and raise POA&M items for gaps.
Pilot 140-3 versions before cut-over and keep a documented rollback.
Make a 140-3 module a prerequisite in any post-quantum migration plan for regulated systems.

FIPS 140-2 vs FIPS 140-3: Sunset Dates, Changes and Procurement Impact