On 7 September 2026 the OpenSSL Library 3.0 series reached the end of life. After that date the OpenSSL project issues no further fixes for the 3.0 line, security fixes included. The release strategy has carried the date since 3.0 shipped, so it is not a surprise, but it is a hard line at the source: upstream stopped, on that day, for good.
What end of life means here
An unmaintained cryptographic library is not simply old. It is the one component in a system where the next vulnerability has no patch coming, in the part of the stack whose whole purpose is to hold under attack. The failure does not arrive on the day support ends. It arrives the first time a flaw is found afterward, when there is no fix to apply. For most production systems that is the constraint that forces a move, with or without a compliance requirement attached.
The failure does not arrive on the day support ends. It arrives the first time a flaw is found afterward, when there is no fix to apply.
Where your 3.0 comes from decides whether the date reaches you
The first difficulty is knowing whether it applies to you at all, because the OpenSSL Library is rarely something a team chose on purpose. It arrives underneath the things you did choose: the operating system, the language runtime, the container base image, and the appliances and products your vendors ship. The 3.0 line is the one most likely to be sitting there, because it is the core system cryptography in the enterprise Linux releases of that generation. Red Hat Enterprise Linux 9 and its derivatives, Ubuntu 22.04 LTS, Debian 12, and SUSE Linux Enterprise 15 SP4 all carry the 3.0 series as their core system cryptography, which puts it under a large share of deployed software whether or not anyone installed it directly.
- Language runtime
- Container base image
- Operating system
- Vendor appliances and products
Whether the 7 September date reached a given system then depends on who maintains that particular build. A distribution still inside its own support window backports fixes to its 3.0 packages on its own schedule, so a supported distribution install does not go dark the moment upstream stops. The exposure is concentrated where no one is backporting: cryptography built from upstream 3.0 source, embedded and appliance firmware that froze a 3.0 build at ship time, container images pinned and forgotten, and anything running on a distribution that is itself past support. Those are the places the date bites, and they are the places it is easiest to lose track of. The honest first step is to map it: find where 3.0 is in what you build, run, and ship, and establish who maintains each instance. Only then does the question of moving become answerable.
Supported distribution install
A distribution still inside its own support window backports fixes to its 3.0 packages on its own schedule, so a supported distribution install does not go dark the moment upstream stops.
Where no one is backporting
Cryptography built from upstream 3.0 source, embedded and appliance firmware that froze a 3.0 build at ship time, container images pinned and forgotten, and anything running on a distribution that is itself past support.
The two ways off it
For the systems that need to move, there are two supported paths. The first is to get onto a line that remains under support. The supported LTS release is 3.5, with security fixes through 8 April 2030, the durable target for most deployments. OpenSSL 4.0, the current major release, carries security fixes only through 14 May 2027, so it suits teams that want the newest capabilities and are prepared to plan a further move on that shorter horizon; the short cycle releases between LTS versions are shorter still and are not migration destinations. Moving to either line brings the current capabilities, including the post-quantum algorithms implemented in 3.5, so support and post-quantum readiness can be one piece of work rather than two.
The second path, for teams that cannot move on that timeline, is Extended LTS, which continues security fixes for the 3.0 line and for earlier end-of-life versions, delivered outside the public releases to organizations under a support agreement. It is the bridge for the regulated, embedded, and self-maintained systems that cannot re-qualify or re-ship by the deadline, and it keeps them patched while the migration runs on a schedule they can meet.
If you also run FIPS
For organizations running the OpenSSL FIPS Provider on 3.0, the 7 September end of life came two weeks before the FIPS 140-2 validation will move to the CMVP Historical List on September 21st. They are different events, a maintenance boundary and a validation-status change, but they land on the same systems within a fortnight, so they are best planned as one piece of work rather than two.
If you are on 3.0 and have not completed the move before September, Extended LTS keeps you patched while you migrate. Contact OpenSSL Corporation to talk through which path fits your systems.
Still on 3.0 after 7 September?
Extended LTS keeps you patched while you migrate. Contact OpenSSL Corporation to talk through which path fits your systems.
Related reading: Migrating to FIPS 140-3 with the OpenSSL FIPS Provider, and getting your own certificate · The Cyber Resilience Act (CRA) and your cryptography dependencies · What moving to the Historical List means for FIPS compliance, and what it does not
Sources: OpenSSL Library release strategy and 3.5 LTS announcement (3.0 security fixes through 7 September 2026; 3.5 LTS supported to 2030); Red Hat, the experience of bringing OpenSSL 3.0 into RHEL and Fedora (the 3.0 series as a core system library in RHEL 9).