OpenSSL 3.0 End of Life: September 7, 2026 — What Actually Breaks, and What Doesn't
OpenSSL 3.0 reaches end of life on September 7, 2026 — five years to the day after its release, exactly as the OpenSSL project's LTS policy promised. After that date the 3.0 line receives no further public security fixes. It is the library terminating TLS connections in a staggering share of the world's software, and its EOL lands four days before the EU Cyber Resilience Act's vulnerability-reporting obligations switch on (September 11, 2026) — a calendar collision we've been flagging since our CRA analysis.
Key Dates at a Glance
- OpenSSL 4.0: end of life 2027-05-14
- OpenSSL 3.6: end of life 2026-11-01
- OpenSSL 3.5: end of life 2030-04-08
- OpenSSL 3.4: end of life 2026-10-22
- OpenSSL 3.3: end of life 2026-04-09
- OpenSSL 3.2: end of life 2025-11-23
OpenSSL End-of-Life Table (every line)
| Version | Released | Support ends | Type | Status |
|---|---|---|---|---|
| OpenSSL 4.0 | Apr 14, 2026 | May 14, 2027 | — | Approaching |
| OpenSSL 3.6 | Oct 1, 2025 | Nov 1, 2026 | — | Approaching |
| OpenSSL 3.5 | Apr 8, 2025 | Apr 8, 2030 | LTS | Supported |
| OpenSSL 3.4 | Oct 22, 2024 | Oct 22, 2026 | — | Approaching |
| OpenSSL 3.3 | Apr 9, 2024 | Apr 9, 2026 | — | EOL |
| OpenSSL 3.2 | Nov 23, 2023 | Nov 23, 2025 | — | EOL |
| OpenSSL 3.1 | Mar 14, 2023 | Mar 14, 2025 | — | EOL |
| OpenSSL 3.0 | Sep 7, 2021 | Sep 7, 2026 | LTS | EOL |
| OpenSSL 1.1.1 | Sep 11, 2018 | Sep 11, 2023 | LTS | EOL |
| OpenSSL 1.1.0 | Aug 25, 2016 | Sep 11, 2019 | — | EOL |
| OpenSSL 1.0.2 | Jan 22, 2015 | Dec 31, 2019 | LTS | EOL |
| OpenSSL 1.0.1 | Mar 14, 2012 | Dec 31, 2016 | — | EOL |
| OpenSSL 1.0.0 | Mar 29, 2010 | Dec 31, 2015 | — | EOL |
| OpenSSL 0.9.8 | Jul 5, 2005 | Dec 31, 2015 | — | EOL |
Live version pages with risk scores: endoflife.ai/openssl.
The autumn pile-up nobody has noticed
September 7 is not an isolated date — it's the start of a cascade. OpenSSL 3.1, 3.2 and 3.3 are already end-of-life. Then within eight weeks of 3.0's retirement, 3.4 dies on October 22 and 3.6 dies on November 1. By early November 2026, every 3.x line except one is out of support. The survivors: 3.5 LTS (supported to April 2030) and the new 4.0 line (to May 2027). For anyone planning a migration, that arithmetic makes the target obvious — 3.5 LTS is the only 3.x destination that buys real runway.
Who actually has a problem on September 8
- Not (immediately) the major distros' packages. RHEL, Ubuntu LTS, Debian and SUSE ship distro-maintained OpenSSL packages and backport security fixes on the distribution's support timeline, independent of upstream's. A patched-by-vendor OS package is a different risk category from an abandoned upstream line.
- Anything that bundles OpenSSL. Language runtimes (Node.js famously carries its own copy), Python distributions built against pinned OpenSSL, vendored copies in commercial appliances, VPN clients, IoT firmware, and statically linked Go/Rust/C binaries with OpenSSL in the build. These don't inherit distro patches — they inherit upstream's EOL.
- Container images. An image built on a maintained base (debian:13, ubuntu:24.04) keeps receiving fixes via rebuilds; an image that compiles or vendors its own 3.0 does not. The
FROM-line audit we described for Docker base images applies verbatim. - FIPS deployments — the awkward case. A large population validated against the OpenSSL 3.0 FIPS provider and stayed on 3.0 because of the certificate. If that's you, the jump to 3.5 involves checking the FIPS provider status for your compliance regime before anything else — the crypto module certificate, not the library version, is your real constraint. The dates are in the FIPS section below: the 140-2 certificate goes Historical on September 21, 2026.
The FIPS deadline two weeks later: September 21, 2026
The 3.0 line's end of life is not the only date a regulated OpenSSL estate has to plan around. The OpenSSL FIPS Provider that ships with the 3.0 series is validated under FIPS 140-2 as CMVP certificate #4282 (software versions 3.0.8 and 3.0.9), and NIST's CMVP lists that certificate's sunset date as September 21, 2026 — the day the validation moves to the Historical List, fourteen days after 3.0 itself stops receiving fixes.
Historical is not revoked. A system already running the 140-2 module does not stop working on September 21, and an existing authorization does not evaporate overnight. What changes is the paperwork for everything new: procurements, authorizations and assessments that require an active validation will not accept a certificate on the Historical List. For anyone selling into, or operating inside, a FIPS-mandated environment, that makes September 21 the harder of the two deadlines.
The replacement already exists. The OpenSSL FIPS Provider is validated under FIPS 140-3 as CMVP certificate #4985 — initial validation March 11, 2025, updated November 21, 2025, sunset March 10, 2030 — and OpenSSL states the 140-3 module is usable across the 3.x series, including 3.5 LTS. So the migration is two moves, not one: the library to 3.5, and the FIPS provider to the 140-3-validated module. Treat them as separate line items; the provider swap is the one with a compliance sign-off attached.
Sources: NIST CMVP certificate #4282 and certificate #4985; OpenSSL Corporation, “FIPS 140-2 sunsets September 2026” (July 16, 2026). Checked August 23, 2026.
The good news: 3.0 → 3.5 is not the 1.1.1 → 3.0 nightmare
The 1.1.1-to-3.0 migration burned teams badly (deprecated engines, provider architecture, API breaks) — and that memory makes people overestimate this one. Within the 3.x series, OpenSSL maintains API and ABI compatibility: for most applications, moving from 3.0 to 3.5 is a rebuild-and-retest, not a rewrite. Deprecated-API warnings you ignored since 3.0 still apply, but the provider model, the configuration format, and the ABI carry straight over. Budget a test cycle, not a quarter.
The CRA collision, restated plainly
From September 11, 2026, manufacturers selling products with digital elements into the EU must report actively exploited vulnerabilities to ENISA on a 24-hour clock. Four days earlier, the most widely embedded cryptographic library's 3.0 line stops receiving public fixes. A vendor shipping a product with bundled OpenSSL 3.0 after that date owns a reporting obligation for a component that can no longer be publicly patched — the definition of the trap we described in our CRA × EOL analysis. The component inventory work (which products bundle 3.0?) is the same work either way; the only choice is doing it before or after the reporting clock starts.
Options for the estate that can't move by September
- Upgrade to 3.5 LTS — the default answer; supported to April 2030, ABI-compatible with 3.0.
- Lean on distro-maintained packages where that's genuinely your situation (verify with
openssl versionvs. your package manager's records — a surprising number of "distro" copies turn out to be vendored builds). - Commercial extended support as a bridge. The OpenSSL project's own corporate arm sells premium support with security fixes for out-of-support lines (it already does for 1.0.2 and 1.1.1), and enterprise extended-support vendors cover bundled-OpenSSL exposure as part of broader legacy coverage. Bridges, not destinations. Compare extended-support options →
The checklist before September 7
- Inventory the bundled copies:
openssl versiontells you about the system copy; the dangerous ones hide in app directories, containers, and appliances. Scan images and vendor manifests forlibssl/libcrypto3.0.x. Our Stack Scanner flags EOL components across a pasted inventory. - Sort into distro-patched vs. self-carried — only the second list is urgent.
- For the self-carried list: rebuild against 3.5 LTS where you control the build; open vendor tickets today where you don't (appliance vendors' queues will be long in September).
- FIPS estates: the 140-2 certificate (#4282) goes Historical on September 21, 2026 — confirm the move to the 140-3-validated provider (#4985, active to March 2030) before touching library versions.
OpenSSL currently carries an EOL Risk Score™ of 75/100 — Grade D, high risk, recalculated at every site build from EOL recency, attack surface, CISA KEV exposure, and extended-support availability. Per-version scores and dates are on the OpenSSL lifecycle page.
The right response comes down to one question: how many more years does this system need to run? Under a year, extended support (where it exists) is usually cheaper than an emergency migration. One to three years, migrate — support fees paid repeatedly cost more than doing the project once. Indefinitely, migrate now and plan the next one before it surprises you. Extended support is often the more expensive choice over a multi-year horizon — a bridge, not a destination. And if this deadline feels like vendor caprice, it isn’t — why end of life is inevitable for every version, with the receipts.
Frequently Asked Questions
When does OpenSSL 3.0 reach end of life?
September 7, 2026 — five years after its September 2021 release, per the OpenSSL project's published LTS policy. After that date the 3.0 line receives no further public security fixes. The next LTS line, 3.5, is supported until April 8, 2030.
Do I need to worry if my OpenSSL comes from Ubuntu, RHEL or Debian?
Generally the distribution keeps patching its packaged OpenSSL on the distro's own support timeline, independent of upstream EOL — a distro-maintained package is not stranded on September 7. The exposure is software that bundles its own OpenSSL copy: language runtimes, appliances, container images that vendor the library, and statically linked binaries.
How hard is the OpenSSL 3.0 to 3.5 upgrade?
Far easier than the notorious 1.1.1-to-3.0 migration. OpenSSL maintains API and ABI compatibility within the 3.x series, so 3.0 to 3.5 is typically a rebuild-and-retest rather than a code rewrite. The main caveats are long-ignored deprecation warnings and, for FIPS deployments, the crypto-module certificate question.
Which OpenSSL versions are still supported after November 2026?
Only two: 3.5 LTS (until April 2030) and 4.0 (until May 2027). OpenSSL 3.1, 3.2 and 3.3 are already EOL; 3.0 dies September 7, 3.4 on October 22, and 3.6 on November 1, 2026.
Is extended support available for OpenSSL 3.0 after EOL?
The OpenSSL project's corporate arm offers paid premium support that includes security fixes for out-of-support versions — it already provides this for 1.0.2 and 1.1.1, and 3.0 becomes eligible for the same treatment at EOL. Enterprise extended-support vendors also cover bundled-OpenSSL exposure within broader legacy-support agreements.
What happens to OpenSSL’s FIPS 140-2 validation in September 2026?
The OpenSSL FIPS Provider's FIPS 140-2 validation, CMVP certificate #4282, has a sunset date of September 21, 2026, when it moves to the CMVP Historical List — two weeks after OpenSSL 3.0's end of life. Historical status does not stop existing systems working, but new procurements, authorizations and assessments that require an active validation will not accept it. The FIPS 140-3 validation, certificate #4985, is active until March 10, 2030 and is the replacement.
What does OpenSSL 3.0 EOL have to do with the EU Cyber Resilience Act?
The CRA's vulnerability-reporting obligations begin September 11, 2026 — four days after OpenSSL 3.0's end of life. Manufacturers selling into the EU with bundled OpenSSL 3.0 will owe ENISA 24-hour reports on actively exploited vulnerabilities in a component that no longer receives public patches.