← Back to all briefings
Developer 5 min read Published Updated Credibility 84/100

Developer Enablement Briefing — November 6, 2025

OpenSSL 3.2 support ends on 23 November 2025, requiring organisations to migrate to the newer 3.3 branch or the forthcoming 3.5 LTS release. This briefing summarises the OpenSSL release strategy, explains the innovations in versions 3.2 and 3.3, highlights what is coming in 3.4/3.5, and provides practical migration and governance guidance.

Zeph Tech Research Lead

Research lead, Zeph Tech

Timeline plotting source publication cadence sized by credibility.
4 publication timestamps supporting this briefing. Source data (JSON)

Executive summary. OpenSSL 3.2 will reach end of support on 23 November 2025. After that date the project will no longer provide bug fixes or security updates, exposing any linked applications to unpatched vulnerabilities【151570351443021†L108-L114】. To maintain compliance with security standards and ensure continued cryptographic resilience, organisations must migrate to a supported version — either the current 3.3 branch or the forthcoming 3.5 long-term support (LTS) line. This briefing reviews the OpenSSL release and support policy, summarises key innovations in versions 3.2 and 3.3, and provides guidance on upgrading libraries and adapting build systems, with particular attention to QUIC and TLS.

Release strategy and support cycles

The OpenSSL project follows a predictable cadence: each minor release (3.x) receives support for at least one year after the next release, while LTS branches are maintained for at least three years【151570351443021†L108-L114】. OpenSSL 3.2, released in late 2023, is a non‑LTS branch whose support ends on 23 November 2025. OpenSSL 3.3, released in April 2024, will be supported until April 2026. The 3.4 branch will extend support until October 2026 and 3.5 will be the next LTS release, with support expected through at least 2030【151570351443021†L108-L114】. Understanding these timelines helps organisations plan cryptographic upgrades and ensures they remain compliant with FedRAMP, PCI DSS and SOC 2, which all require use of supported cryptographic libraries.

What OpenSSL 3.2 introduced

OpenSSL 3.2 built on the provider architecture introduced in 3.0 and delivered incremental improvements. It refined provider loading and selection, making it easier to switch between default, legacy, FIPS and third‑party providers. It added new key derivation and encryption algorithms (X9.42 KDF, KMAC‑256/512, extended HKDF options) and improved the EVP API with deterministic ECDSA, EdDSA and SM2 signatures. Memory sanitisation routines were tightened to reduce the risk of secret data lingering in process memory. Finally, 3.2 introduced preliminary QUIC hooks that laid the groundwork for deeper integration in 3.3.

Key enhancements in OpenSSL 3.3

OpenSSL 3.3, released in April 2024, delivered substantial upgrades to protocol support, cryptography and tooling【644687954204231†L304-L417】. The release added extensive QUIC instrumentation, including qlog diagnostic logging and APIs to configure idle timeouts, manage stream buffer sizes and query connection status【644687954204231†L304-L417】. Developers can now perform non‑blocking polling on QUIC connections, improving observability and reliability for HTTP/3 deployments【171981044386452†L58-L90】. A new SSL_write_ex2 API simplifies sending end‑of‑stream markers and facilitates half‑closed connections, which benefits streaming and WebSocket workloads【644687954204231†L304-L417】. Cryptographic improvements include the EVP_DigestSqueeze() function for extendable‑output functions and configurable BLAKE2s output lengths【171981044386452†L58-L90】, plus enhancements to EVP_PKEY_fromdata() that derive CRT parameters from RSA keys【644687954204231†L304-L417】. 3.3 also introduced Y2038‑safe session timing APIs, ignored unknown signature algorithms to improve interoperability and added CMake export targets and an OPENSSL_atexit() function for safer unloads. These improvements make 3.3 more robust for modern TLS and QUIC deployments, while reducing friction in build systems and certificate management.

Looking ahead to OpenSSL 3.4 and 3.5

The forthcoming 3.4 release, expected in late 2024, will continue refining QUIC support and may introduce new post‑quantum key exchange mechanisms. However, it will only be supported until October 2026. The 3.5 branch, targeted for April 2025, will be the next LTS release and is expected to include mature FIPS modules, full QUIC support and performance optimisations. Organisations must decide whether to upgrade first to 3.3 and then to 3.5, or wait for 3.5 and perform one migration. Regardless, continuing to run 3.2 after November 2025 is not an option.

Migration guidance

Moving from OpenSSL 3.2 requires more than swapping library files. Organisations should: (1) inventory all applications and containers linked against 3.2; (2) choose a target version (3.3 or 3.5) based on support periods and feature needs; (3) test QUIC and TLS workloads under the new library, ensuring idle timeouts, packet tracing and stream buffers behave as expected【644687954204231†L304-L417】; (4) update build systems to use new CMake exports or pkg-config files and rebuild applications, taking note of changed APIs; (5) revise cryptographic configuration to align with the new defaults, which disable some legacy ciphers【27194318065905†L38-L61】; (6) validate compliance by ensuring a FIPS provider is available if required and updating risk registers; and (7) implement monitoring and rollback plans for staged deployments. Following these steps reduces the risk of downtime or audit findings.

Governance and compliance implications

Continuing to use OpenSSL 3.2 past its EOL date can violate compliance requirements for FedRAMP, PCI DSS and SOC 2, which all require supported cryptographic components. CVEs discovered after November 2025 will not receive official patches for 3.2【151570351443021†L108-L114】. Organisations should monitor vendor advisories to ensure dependent libraries and applications are updated in time, and review licensing obligations under the Apache License 2.0. Staying current also reduces supply‑chain risk, as many software vendors embed OpenSSL and schedule their updates based on upstream release policies.

Zeph Tech analysis and recommendations

Zeph Tech recommends that platform and security leaders treat the OpenSSL 3.2 EOL as an opportunity to modernise cryptographic infrastructure. Migrating to 3.3 or preparing for 3.5 will unlock improved QUIC instrumentation, certificate management and build-system support. Align the upgrade with other infrastructure changes (such as HTTP/3 adoption, OS upgrades or service‑mesh deployment) to consolidate testing. Automate upgrades by generating SBOMs, scanning for vulnerabilities and running regression suites in CI/CD pipelines. Document migration plans and update risk registers. Zeph Tech will continue monitoring OpenSSL releases and will provide guidance on adopting post‑quantum algorithms and future LTS branches.

Zeph Tech produces cryptographic lifecycle briefings to help engineering leaders plan migrations, maintain compliance and leverage modern security capabilities.

Organisations that operate critical infrastructure or handle regulated data should coordinate upgrades with compliance partners and cloud vendors. Mapping OpenSSL timelines to enterprise risk registers and change management calendars helps ensure continuity and reduces the likelihood of unplanned downtime.

Timeline plotting source publication cadence sized by credibility.
4 publication timestamps supporting this briefing. Source data (JSON)
Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • OpenSSL
  • Cryptography lifecycle
  • TLS
  • Supply chain
Back to curated briefings