What moving to the Historical List means for FIPS compliance, and what it does not.

The move of FIPS 140-2 validations to the CMVP's Historical List on 21 September 2026 gets described two ways, as the end of those modules or as a paperwork change that touches nothing. Neither is right, and the accurate reading does not come from splitting the difference. It comes from the CMVP's own definitions: what the Historical List is, the rule that puts a certificate on it, and what federal use of cryptography requires in the first place.

The three states a validation can be in.

A CMVP validation is in one of three states, and they are not interchangeable. An Active validation can be relied on for both new and existing systems, and a module joins the Active list for five years when it is validated. A Revoked validation is the strong case: it is no longer valid and cannot be referenced to demonstrate compliance with the standard at all. The Historical List sits between them. A certificate on it has not been revoked, and the validation still exists; what changes is that federal agencies should not put the module into new systems, while systems already using it may continue.

Why the date falls where it does.

The date is the end of a transition, not an expiry, and reading it that way helps. The CMVP began validating modules against FIPS 140-3 in September 2020 and stopped accepting new FIPS 140-2 submissions in 2022. Existing 140-2 validations were given a defined runway: they remain accepted for federal use through 21 September 2026, after which they move to the Historical List. That runs alongside the general five-year sunset, under which any validation moves to Historical five years after its validation date. For a 140-2 module the effective trigger is whichever comes first, its own five-year mark or the 21 September cutoff that closes the 140-2 era. The date was set years in advance as the scheduled handover from one standard to its successor.

New procurement, and existing systems.

The restriction on new procurement rests on FISMA. Where information is required to be cryptographically protected, the cryptography has to be validated, and NIST's position is that non-validated cryptography provides no protection, so unvalidated cryptography is treated as none at all. A new authorization or acquisition that turns on validated cryptography therefore needs a module on the Active list, and a certificate on the Historical List does not meet that, because the requirement is for a current validation rather than a retired one. That is the mechanism behind the plain-language guidance that Historical modules are not for new procurement.

Existing systems have latitude, but it is bounded. A module on the Historical List may keep running in a system that already uses it, on the condition that the agency makes and records a risk-management decision to keep it, which is itself a FISMA obligation rather than an informal allowance. The latitude ends where the system changes materially: a significant revision, an operating-system upgrade, a re-architecture, or a re-authorization can pull the requirement back to a module on the Active list. An operating-system upgrade is also the change most likely to move a deployment off the operating environments the module's certificate was tested on, which the migration guide in this series covers. Continuing on a Historical module is a decision to document and revisit, not a permanent exemption.

Validated is not the same as compliant.

Two things are easy to merge here and worth keeping apart. A validated module is an input to compliance, not compliance itself. Where cryptography must be validated, running a module on the Active list satisfies that one requirement; it does not by itself make a system compliant, which is a separate determination resting on the system's controls and its assessment. Moving from a Historical module to an Active one closes the validation gap and nothing more. For the OpenSSL FIPS Provider, the certificates moving to the Historical List on 21 September are the 140-2 validations, #4282 and #4811, and the Active replacement is the 140-3 validation, certificate #4985, which is available now.