FIPS 140-2 Goes Historical Today – What Actually Changes and What Doesn’t

Today, September 21, 2026, is the last day FIPS 140-2 validations remain eligible for new systems. After this date, NIST’s Cryptographic Module Validation Program moves every remaining FIPS 140-2 certificate to the Historical list. The date has been on the calendar since CMVP published its transition schedule after FIPS 140-3 was approved in March 2019. Seven years of runway. And many vendors still lack a FIPS 140-3 certificate for the products their federal customers deploy.

The bottom line: FIPS 140-2 modules keep running in the systems that use them, but federal buyers should stop specifying them for new ones. For new federal procurement, a Historical certificate no longer satisfies controls and contracts that are read to require an Active validation. For existing systems, CMVP explicitly supports continued purchase and use. Fewer systems are affected than most coverage suggests, but buyers of new systems have to choose from a FIPS 140-3 validated-module supply that has not caught up with the demand this date creates.

What Historical Status Actually Means

CMVP’s validation-status categories are Active, Historical, and Revoked. Active modules meet the current standard and can be specified in new procurements. Revoked modules have a specific security failure on record. Historical is the middle ground – the module passed its validation lifecycle, and CMVP’s operative language says federal agencies “should not include” Historical modules in new acquisitions.

That language is a recommendation, and it covers new systems only. NIST’s own transition page states it directly: “Even on the historical list, CMVP supports the purchase and use of these modules for existing systems.” It goes further, acknowledging that “for several years there may be a limited selection of FIPS 140-3 modules from which to choose,” and recommending that purchasers consider all modules on the validated list regardless of whether they were validated against FIPS 140-2 or FIPS 140-3.

When a Historical module is excluded from procurement for a new system, the exclusion comes from agency and contractual policy, meaning the contracting officer’s reading of the requirement. CMVP does not prohibit it. Whether an existing deployment on a Historical certificate may continue is a separate question, decided under the applicable agency or contractual risk policy. An auditor, a C3PAO, or a FedRAMP assessor will answer that question by reading the specific control language in the system’s authorization boundary.

A system running FIPS 140-2 validated modules yesterday will run the same modules tomorrow. The cryptography does not change. The compliance posture might.

The FIPS 140-3 Supply Gap

Seven years looked like a comfortable margin. In practice, the CMVP review stage became a bottleneck.

CMVP stopped accepting new FIPS 140-2 submissions on April 1, 2022 – itself a date that was extended from the originally planned September 22, 2021, to give vendors already under contract with a testing lab more time. The extension moved only the submission deadline. Every certificate granted during the extension window still goes Historical today on the same schedule.

The FIPS 140-3 validation queue then became the constraint. The CMVP review process historically ran twelve to eighteen months from submission to active certificate – and longer before the interim scheme took effect. The delay is built into a process that involves accredited lab testing, CMVP review, comment resolution, and cost recovery. By mid-2024, over 300 cryptographic modules were waiting in the queue.

NIST recognized the problem. In February 2024, CMVP announced an interim validation scheme – a fast-track path for modules submitted before January 1, 2024, where the accredited testing lab had notified CMVP before October 1, 2024. Under this “trust but verify” approach, modules recommended for validation by their lab could receive interim certificates valid for two years, with CMVP completing its full review afterward. The program began processing requests on June 3, 2024, with additional structural changes: automation to identify non-conformances, simplified review stages, and transition guidance updated as recently as April 13, 2026.

These measures helped substantially. According to SafeLogic, FIPS 140-3 certificates accounted for just 3% of all FIPS 140 certificates issued in 2023; by the first half of 2024, that share had risen to 45%. Independent data from KeyPair Consulting shows that 204 of 261 FIPS 140 certificates posted in 2024 – 78% – were FIPS 140-3. By January 2026, CMVP reported queue backlog had dropped to 180 days, with an average of 348 days for the last 30 validations, and a near-zero backlog target of July 1, 2026. As of July 2026, FedRAMP’s FAQ cited 285 modules in active CMVP review, 234 in laboratory testing, and 614 vendors with full FIPS 140-3 certification.

CMVP is processing modules faster, but by September 21, 2026, the validated supply also has to be broad enough to cover the specific products that organizations deploy. For many vendors and many products, it is not. A vendor that started a FIPS 140-3 program in mid-2025 – factoring in lab testing, submission, and queue time – could reasonably expect an active certificate by late 2026 or early 2027. The window to prepare for this date closed well before the date arrived.

FedRAMP, CMMC, CJIS, and Payment HSMs After the Sunset

The sunset affects every compliance framework that references FIPS-validated cryptography. Expect the first questions from assessors whose frameworks call for an Active validation.

Federal civilian agencies under FISMA and FedRAMP. Controls SC-13 (cryptographic protection), SC-28 (protection of information at rest), and IA-7 (cryptographic module authentication) all require validated modules. A module still in process typically requires explicit treatment in the authorization package – often a POA&M or documented risk decision. After today, a FIPS 140-2 certificate raises the same question: NIST no longer recommends this module for new procurement. Cloud service providers in the middle of an authorization now have extra documentation to produce for a status change that leaves the module’s cryptography untouched.

Defense contractors under CMMC. NIST SP 800-171 Requirement 3.13.11 requires FIPS-validated cryptography to protect the confidentiality of CUI. After today, a Historical certificate as the basis for 3.13.11 compliance may draw scrutiny where an assessor examines how the organization satisfies that requirement. CMMC Phase II – the start of third-party Level 2 assessments, originally scheduled for November 10, 2026, seven weeks after the sunset – was supposed to compound this pressure. That timeline was suspended on July 13, 2026, by the Department of War (DoW) CIO’s memorandum. The CMMC Reform Task Force was directed to deliver its final report within 60 days; no published recommendations have appeared as of this writing. During the Phase II suspension, only self-assessment designations at Levels 1 and 2 may be used, which lowers the immediate audit pressure. Requirement 3.13.11 is unchanged, so a contractor self-assessing under a contract that requires validated cryptography still has to account for each module on a Historical certificate.

Criminal justice (CJIS). The CJIS Security Policy requires validated modules for Criminal Justice Information. State and local agencies accessing CJI face the same question as federal agencies: a Historical module may not satisfy a control that requires an Active validation, and the next assessment cycle will ask.

Financial services. Payment HSMs have both a FIPS certificate and a PCI PTS HSM approval. The FIPS 140-2 sunset intersects with the PQC migration at the HSM layer – both transitions touch the same hardware, and planning them as one refresh avoids paying for the same hardware change twice. PCI PTS HSM v5.0, published May 18, 2026, is the current major version, with v4.x requirements listed as expiring in June 2027. An institution running payment HSMs on FIPS 140-2 certificates faces a three-way decision: move to FIPS 140-3 alone, add a new PCI PTS approval in the same step, or wait for PQC-capable firmware and make all three changes at once. The best timing depends on product support, contractual obligations, key-management architecture, and the availability of validated PQC services.

The PQC Overlay

The FIPS 140-2 sunset does not exist in isolation. It arrives alongside the first validated post-quantum cryptographic modules – and 102 days before the CNSA 2.0 acquisition gate on January 1, 2027.

As of this writing, at least five active FIPS 140-3 certificates list post-quantum algorithms as approved services. A CMVP search on the day of publication may turn up more:

• Certificate #5247, the Go Cryptographic Module (Geomys LLC), is a FIPS 140-3 Level 1 software module validated on April 27, 2026, covering ML-KEM (KeyGen and EncapDecap; no ML-DSA).
• Certificate #5298, the AWS-LC 3 Cryptographic Module (dynamic), is a FIPS 140-3 Level 1 software module validated on June 3, 2026, covering ML-KEM (KeyGen and EncapDecap).
• Certificate #5314, the AWS-LC 3 Cryptographic Module (static), is a FIPS 140-3 Level 1 software module validated on June 5, 2026, covering ML-KEM.
• Certificate #5450, the Luna T7 Cryptographic Module (Thales Trusted Cyber Technologies), is a FIPS 140-3 Level 3 hardware module whose validation Thales announced on July 29, 2026, covering ML-KEM, ML-DSA, and LMS in firmware version 7.15.1.
• Certificate #5497, the QASM Cryptographic Module (Crypto4A Technologies), is a FIPS 140-3 Level 3 hardware module validated on August 19, 2026. It covers ML-KEM, ML-DSA, SLH-DSA, and LMS. Its Security Policy states that the module does not establish sensitive security parameters using an approved KEM but exposes ML-KEM functionality for an external application to use.

Three Level 1 software modules and two Level 3 hardware HSMs, the day the old standard sunsets. More PQC modules are in the queue, among them SafeLogic’s own AWS-LC-based PQC module, submitted to CMVP on May 19, 2026. In FIPS-required environments, an organization can put PQC into production only through a module whose certificate lists the post-quantum operation as an approved service. The FIPS 140-3 and PQC migrations require changes to the same hardware in the same procurement cycle. Running them as separate programs means two rounds of procurement, testing and disruption on the same hardware.

On January 1, 2027, new acquisitions for National Security Systems in scope of CNSA 2.0 must support ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, unless an exception or other qualification applies. The gate applies to acquisition events after the date, not to the delivery date alone. Agencies and their vendors now have to handle the FIPS 140-2 sunset, the FIPS 140-3 supply gap, and the CNSA 2.0 acquisition gate at the same time. Together they make up one of the largest transitions in federal cryptography since the adoption of AES.

The Triage

Organizations whose cryptographic modules go Historical today face a three-way decision, made system by system.

Migrate now. For systems entering new procurement, new authorization, or new assessment cycles, a FIPS 140-3 validated module is the only defensible answer. Check the CMVP validated-modules search for the specific product, version, and certificate. A vendor’s marketing page, a press release, or “FIPS compliant” language in a datasheet does not show that the module has an Active FIPS 140-3 certificate. Validation is a certificate tied to a module version and a tested operating environment. FIPS mode is a configuration; validation is a certificate.

Ride Historical under documented risk acceptance. For existing systems where no FIPS 140-3 module yet covers the deployed product, CMVP’s own guidance supports continued use. Document the risk acceptance decision: name the module, its Historical certificate number, the system it protects, the vendor’s FIPS 140-3 timeline, and the date by which the replacement must be in place. NIST itself contemplated this posture when it acknowledged the limited FIPS 140-3 supply. The documented-risk-acceptance route is narrower for National Security Systems, where the accreditation authority’s room to accept an interim posture is constrained by CNSSP 15.

Fold into the PQC refresh. For systems whose HSM or cryptographic module is approaching end-of-life, or whose vendor has signaled PQC-capable firmware on a known timeline, the economically rational move is to skip the FIPS 140-3-only upgrade and plan one transition that covers both the standard migration and the post-quantum algorithm migration. Run the FIPS 140-3 and PQC programs for these systems as one workstream with a shared budget, vendor engagement track, and set of test environments. The systems that justify this path are the ones where the FIPS 140-3 module the vendor ships next year will be superseded by a PQC-capable module the year after.

A single enterprise might run all three tracks at once across different parts of its infrastructure.

What to Do Now

The FIPS 140-2 sunset has been treated for years as a deadline, but the validation queue set the practical limit: it consumed the eighteen to twenty-four months before September 21, 2026. A vendor that started its FIPS 140-3 program in early 2025 might have a certificate by now. A vendor that waited is looking at a gap that runs well into 2027.

For CISOs and procurement teams, the action item as of today is an inventory. Which modules went Historical? Which vendors have an active FIPS 140-3 certificate for the same product? Which are in the queue, and where? Which systems can run under a documented risk acceptance, and for how long? And which of those systems are heading toward a PQC refresh that should be planned together with the FIPS 140-3 move?

The answers are per-product and per-certificate, and they start at the CMVP validated-modules search page, not at a vendor’s website. The FIPS 140-2 sunset is the first of these hard dates. The next one – CNSA 2.0’s acquisition gate – is 102 days away.