FIPS 140-2 sunsets in September 2026
Two fixed dates in September 2026 close out FIPS 140-2 for users of the OpenSSL FIPS Provider. The validated FIPS 140-3 replacement is available now, and the dates do not move.
Two dates in September 2026 matter for anyone running a FIPS-validated deployment of the OpenSSL Library.
On 7 September 2026, the OpenSSL Library 3.0 series reaches end of life, after which the 3.0 line gets no further fixes from the OpenSSL project, security fixes included. Two weeks later, on 21 September 2026, the CMVP moves the remaining FIPS 140-2 validations to its Historical List, among them the OpenSSL FIPS Provider validated under FIPS 140-2 as CMVP certificate #4282, which is the provider that ships with the 3.0 series.
It helps to keep these two events apart. One is a software support boundary: the 3.0 library stops being maintained. The other is a validation-status change: the 140-2 certificate is no longer Active. A given deployment might be touched by one, the other, or both, and the right response depends on which of those constraints actually applies to you.
What moving to the Historical List means
Historical status is not revocation. A certificate on the Historical List has not been withdrawn, and a system already running a module under it does not stop working on 21 September. The CMVP's guidance is narrower than that: modules on the Historical List should not be used in new procurements, and an organization relying on one in an existing deployment is expected to make a risk-based decision about continued use.
In practice that splits in two. A team whose only obligation is to keep an already-authorized system running, with assessors who accept a risk-managed continuation, may not be forced into immediate action by Historical status alone. But where the obligation involves a new procurement, a new authorization, or an assessment that turns on a currently valid certificate, a 140-2 certificate on the Historical List will not satisfy it, and for most organizations carrying ongoing FISMA, FedRAMP, or comparable requirements, that is the case that governs. The conclusion is the same either way: you need a module with an active FIPS 140-3 validation.
Historical status is not revocation.
The validated path is already available
For users of the OpenSSL Library, that module exists today. The OpenSSL FIPS Provider is validated under FIPS 140-3 as CMVP certificate #4985, valid through March 2030, and per the project's stated compatibility it is usable across the 3.x series, including 3.5. The validated path for the September transition is therefore already in place.
Because the FIPS provider and the rest of the OpenSSL Library are separate components, in many cases you can move to the 140-3 module without replacing your whole library line at once, since the provider is the part that carries the validation. That does not retire the 7 September deadline, though. With the OpenSSL Library 3.0 series at end of life, staying on the 3.0 library indefinitely is not a supported posture whichever provider you load. The supported LTS line is 3.5, with security fixes through 2030, and the current major release is 4.0, so the durable targets are 3.5 or 4.0; the 1.x lines and the 3.1, 3.2 and 3.3 series are already past upstream support. So the durable position is both moves together: adopt the FIPS 140-3 module, and get onto 3.5 or 4.0.
For teams that cannot make that move before 3.0 goes end of life, extended support through an Engineering support contract continues security fixes for the older line, which buys time to migrate without running unmaintained cryptography in production. The same upgrade that gets a team onto 3.5 or 4.0 also brings the NIST post-quantum algorithms, with hybrid post-quantum key exchange enabled by default for TLS 1.3 in those releases, so the FIPS migration and the start of post-quantum readiness can be one piece of work rather than two. For FIPS-validated use, the module carrying those post-quantum algorithms is still completing its FIPS 140-3 validation, so validated PQC follows once it lists.
The timeline is the hard part
None of this is difficult in isolation. The difficulty is schedule. Changing the cryptographic module under a validated system is rarely a drop-in swap in a regulated environment: it means re-testing against your own integration, re-producing whatever validation evidence your compliance program requires, updating documentation and authorization artifacts, and fitting the change into change-control windows that often run to months. The dates themselves are fixed and were published years ago, so the only real variable is whether a team gives itself runway or runs the migration against the deadline in September.
The difficulty is schedule.
The migration work, and the module itself, come from the people who maintain the OpenSSL Library. OpenSSL Corporation employs the developers and is the largest single contributor to the OpenSSL Library, with the per-release contribution breakdown published at status.openssl.org, so it can be checked rather than taken on trust.
Both certificates are searchable by number in the CMVP Validated Modules database, #4282 for the 140-2 module and #4985 for the 140-3 module, and the 3.0 end-of-life date is in the OpenSSL Library release strategy.
References
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4985
https://openssl-library.org/post/2025-03-11-fips-140-3/
https://openssl-library.org/policies/releasestrat/
https://status.openssl.org/versions/4.0/