OpenSSL 3.0 End of Life: September 7, 2026 — What Actually Breaks, and What Doesn't

Updated: July 2026  ·  EOL Watch — deadline coverage  ·  Dates per the OpenSSL project's published release strategy — methodology

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.

OpenSSL End-of-Life Table (every line)

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 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

1. Upgrade to 3.5 LTS — the default answer; supported to April 2030, ABI-compatible with 3.0.
2. Lean on distro-maintained packages where that's genuinely your situation (verify with openssl version vs. your package manager's records — a surprising number of "distro" copies turn out to be vendored builds).
3. 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 six-week checklist

1. Inventory the bundled copies: openssl version tells you about the system copy; the dangerous ones hide in app directories, containers, and appliances. Scan images and vendor manifests for libssl/libcrypto 3.0.x. Our Stack Scanner flags EOL components across a pasted inventory.
2. Sort into distro-patched vs. self-carried — only the second list is urgent.
3. 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).
4. FIPS estates: confirm certificate strategy before touching versions.

Frequently Asked Questions