On September 21, 2026, the status of FIPS 140-2 validated cryptographic modules will change when they are moved to the NIST historical list. OpenSSL stresses that the date does not automatically invalidate existing installations. At the same time, another important deadline is approaching: OpenSSL 3.0 will reach the end of its regular lifecycle on September 7, 2026.
For companies and organizations that use OpenSSL In safety-critical or regulated environments, September means two important changes to consider.
The first applies OpenSSL 3.0, which reaches End of Life on September 7, 2026. 
The second applies FIPS 140-2, where the validations concerned the September 21, 2026 is moved to the historical list within the American NIST Cryptographic Module Validation Program, CMVP.
However, OpenSSL emphasizes that the transition should not be interpreted as making all existing FIPS 140-2-based systems suddenly invalid.
FIPS 140-2 won't disappear overnight
FIPS 140 is an American security standard for cryptographic modules and is of great importance in, among other things, the public sector, defense, finance and other businesses with high demands on information security and regulatory compliance.
When a FIPS 140-2 validation is moved to the historical list on September 21, it does not mean that the certificate is revoked.
Existing systems using a previously validated cryptographic module therefore do not need to be automatically taken out of service due to the change.
For already deployed and authorized environments, continued use may be possible depending on the organization's regulatory requirements, risk assessment, and the rules that apply to the current operation.
However, the situation is different for new systems, procurements and security approvals. There, FIPS 140-3 the standard that organizations need to adhere to when active FIPS validation is required.
OpenSSL has already transitioned to FIPS 140-3
For organizations using OpenSSL, there is already a validated solution for the new standard.
OpenSSL FIPS Provider 3.1.2 is validated according to FIPS 140-3 through the NIST and Canadian CSE joint Cryptographic Module Validation Program.
The validation has CMVP certificate number 4985 and is valid until March 10, 2030.
According to OpenSSL, the FIPS validated provider can be used with multiple versions within the OpenSSL 3.x series.
This means that organizations can plan the transition to FIPS 140-3 without necessarily having to treat the change as a complete replacement of their entire cryptographic infrastructure.
For large organizations, this can be significant. A migration in regulated environments often involves much more than installing a new software version.
OpenSSL 3.0 reaches End of Life on September 7th
The FIPS change is not the only important issue for OpenSSL users in September, however.
The September 7, 2026 when OpenSSL 3.0 end of its normal life cycle.
After End of Life, organizations should not expect regular security updates for the version within the normal support cycle.
This means that companies still using OpenSSL 3.0 need to distinguish between two separate issues:
Software lifecycle and support, which is affected by OpenSSL 3.0 reaching End of Life.
FIPS validation, which deals with which cryptographic module is used and what status it has within CMVP.
The fact that a FIPS validation may still be relevant for an existing system does not automatically mean that the underlying OpenSSL version should continue to be used after it reaches the end of its support period.
OpenSSL 3.5 is LTS version
For organizations planning their long-term OpenSSL strategy, OpenSSL 3.5 particularly relevant.
The version is a Long Term Support version, LTS, with a longer planned support period.
This means that companies still using older OpenSSL versions may need to view the upcoming FIPS change as part of a larger modernization of their cryptographic infrastructure.
Instead of simply migrating from FIPS 140-2 to FIPS 140-3, organizations can simultaneously evaluate which OpenSSL version will underpin their infrastructure in the coming years.
The biggest challenge may be the validation around
The technical upgrade itself doesn't have to be the most time-consuming part of the work.
In regulated operations, a change to cryptographic components can also impact documentation, security architecture, internal controls, testing, risk assessments, and external approvals.
There may also be dependencies in applications, operating systems, networking products, security platforms, and other systems where OpenSSL used indirectly.
Organizations should therefore not only check which OpenSSL versions are installed directly on servers.
They also need to map where OpenSSL and FIPS-validated components are used as part of larger products and platforms.
Four questions IT organizations should ask now
Ahead of September, companies and authorities should above all obtain a clear picture of their current environment.
Where is OpenSSL 3.0 used?
Systems that are still dependent on the version need to be identified before End of Life on September 7th.
Where are FIPS 140-2 validated modules used?
This applies to both direct installations and cryptographic components included in other systems.
What environments require active FIPS 140-3 validation?
Requirements may differ between existing systems, new installations, procurements and future projects.
How long does the organization's own approval process take?
In regulated operations, testing, documentation, and security reviews can take significantly longer than the upgrade itself.
No hard limit, but a clear shift
OpenSSL's message is that September 21st should not be considered a day when all FIPS 140-2-based infrastructure must suddenly be shut down.
But the change still marks a clear shift.
FIPS 140-3 is the new generation of the standard, while older OpenSSL versions are gradually leaving their regular support periods.
For IT managers, security managers, system owners and organizations with regulatory requirements, the issue is therefore bigger than a single date in September.
It is about ensuring that the cryptographic infrastructure is supported, validated and sustainable even for future systems and security requirements.
Organizations that still rely on OpenSSL 3.0 or FIPS 140-2 therefore have reason to inventory their environments now, prioritize affected systems, and create a clear plan for the transition to a modern and continued supported OpenSSL environment.
Swedish 
Danish 
Norwegian 
Finnish 
English 
German 
Dutch 