30+ Days to FIPS 140-2 Sunset: The CMVP Validation Backlog Compounds the Calendar

Thirty-one days separate August 21, 2026 from the date every FIPS 140-2 validated cryptographic module moves to the historical list maintained by the Cryptographic Module Validation Program. A program that has not already submitted a module for FIPS 140-3 validation will not hold a certificate by that date. The queue runs on laboratory submission, cost recovery payment, and analyst assignment, and none of those steps compress to fit an external calendar. The useful move in the remaining month is not to accelerate a submission. It is to enumerate which modules are in scope, separate the ones already in the queue from the ones that were never filed, and write down what the program does about the difference.

Historical status is also narrower than most program offices assume. The caveat CMVP applies to a historical certificate reads: "The referenced cryptographic module should not be included by Federal Agencies in new procurements. Agencies may make a risk determination on whether to continue using this module based on their own assessment of where and how it is used." Fielded systems do not stop working on September 22. New procurement is the door that closes.

That distinction shapes the entire plan. A program running fielded systems on FIPS 140-2 modules inherits a documentation and risk-acceptance problem. A program buying new capability after the date inherits an acquisition problem, and the only clean answer there is a module with a current FIPS 140-3 certificate.

What the date does and does not change

The sunset date appears two ways in official material, and both are correct enough to plan against. FedRAMP guidance states that all FIPS 140-2 certificates are set to historical on 21 September 2026. The NIST FIPS 140-3 Transition Effort page frames the same event as September 22, 2026, five years after CMVP began accepting FIPS 140-3 submissions. One day in either direction changes nothing operationally, and a program that treats September 21 as the hard edge will not be wrong.

What changes is the evidence a validator or assessor accepts. Before the date, a FIPS 140-2 certificate number in a system security plan closes the control. After the date, that same number points at a historical entry, and the assessor asks what the program intends to do next.

What does not change is the cryptography inside the module. FIPS 140-3 is the validation regime, not a new algorithm set, so a module that is sound on the day before the sunset is equally sound on the day after. The certificate expires in usefulness, not the mathematics.

Downstream regimes inherit the shift rather than restate it. Contractors preparing for CMMC Phase 2 enforcement in November 2026 will be assessed against FIPS-validated cryptography for controlled unclassified information, and a C3PAO reviewing that evidence after September 21 sees the same historical entry a federal assessor sees.

The queue is a pipeline with named phases, not a line

The CMVP publishes two public lists, and reading them correctly is most of the queue math. The Implementation Under Test list holds modules a laboratory has engaged but not yet submitted. The Modules In Process list holds submitted modules and tracks each one through named states: Pending Review, Review, Comment Resolution with the laboratory, Comment Resolution with CMVP, Pending Resubmission, Finalization, Cost Recovery, and Hold.

As of late August 2026, the Modules In Process list carries roughly two hundred modules across those states. CMVP publishes no service-level target for any phase, and the program itself notes on the transition page that the queue of validation submissions has been increasing while the process is overhauled.

The gate that surprises programs sits between Pending Review and Review. CMVP states that a report moves into active review only after the laboratory pays the NIST cost recovery fee, and then only as analyst resources become available. A module can sit in Pending Review with every technical artifact complete.

The honest characterization is qualitative. Movement through the CMVP pipeline is measured in months across multiple states, with resubmission cycles that restart portions of the work, and no published mechanism converts thirty-one days of calendar pressure into a certificate. A vendor promising a certificate before September 21 for a module not already deep in the pipeline is describing a hope, not a schedule.

Separating what is in flight from what is not

Three buckets cover every module a program touches.

The first bucket holds modules with a current FIPS 140-3 certificate. These require only that the program record the certificate number, the validated version string, and the operational configuration that keeps the module in its approved mode. Running a validated module outside its approved configuration produces the same audit finding as running an unvalidated one.

The second bucket holds modules on the Implementation Under Test or Modules In Process lists. For each, the program records the list, the current state, the date the module entered that state, and the vendor point of contact. A module in Finalization in August is a different risk than a module that entered Pending Review in July, and the system security plan should say which one it is.

The third bucket holds modules with no filing anywhere. Nothing the program does in thirty-one days changes their status. The work here is deciding whether the capability gets replaced with a validated alternative, gets carried forward under a documented risk determination, or gets removed from the boundary.

What a program writes down for the gap

FedRAMP addresses the gap directly and declines to make the choice for cloud service providers, stating that the decision belongs to the provider. The three paths it describes are migrate to an approved FIPS 140-3 module through the established change process, continue running the legacy module and document it as an open item, or move early to an uncertified FIPS 140-3 version and track that risk.

Each path is defensible and each produces different paperwork. Continued use of a historical module needs a written risk determination naming where the module runs, what data it protects, and what compensating controls apply. Early migration to an in-process version needs the Modules In Process entry cited by name and state.

The failure mode is silence. An authorization package that names a FIPS 140-2 certificate and says nothing about September 21 tells an assessor the program has not looked. Programs working ATO timelines for federal cloud migration should fold the determination into the existing package.

Cryptographic agility is a property of how key material binds to data

Module transitions hurt in proportion to how many places in an architecture know about the module. When encryption is a property of a transport session, a storage volume, and an application library independently, a module change is three coordinated changes with three separate regression surfaces.

When key material and policy bind to the data object itself, the number of places that break is smaller. A data-centric zero trust design concentrates cryptographic enforcement at the point where an object is wrapped and unwrapped, which makes the set of affected components enumerable rather than discovered during cutover. Lattix builds on that model, and the practical benefit is a shorter list of things to retest.

This claim has a hard limit worth stating plainly. Object-level wrapping does not exempt anything from validation. The module performing the wrap is itself in scope for FIPS 140-3, appears in the same CMVP lists, and waits in the same queue. Architecture reduces the blast radius of a module change; it does not substitute for a certificate, and any vendor implying otherwise should be asked for the certificate number.

The same logic applies to the longer transition already underway. Programs planning post-quantum key encapsulation face a second module change within a few years, and the design decision that shortens the FIPS 140-3 cutover shortens that one too.

The sequence for the next thirty-one days

Build the module list first, scoped to the authorization boundary rather than to the program's product catalog. Assign every entry to one of the three buckets, with a CMVP certificate number, a Modules In Process state, or an explicit note that no filing exists.

Then write the determination for the third bucket and get it signed by the official who owns the risk. Stage configuration changes only after that. Programs that already track key management as a data-layer concern will find much of the inventory work done.