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

November 6, 2025

OpenSSL 3.2 support ended in November 2025. If you are still running 3.2, you need to upgrade to a supported version for security patches. OpenSSL is foundational—do not let it become a vulnerability.

Kodi C.

Editor & Research Lead

Fact-checked and reviewed — Kodi C.

Developer pillar illustration for Zeph Tech briefings
Developer enablement and platform engineering briefings

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. To maintain compliance with security standards and ensure continued cryptographic resilience, teams must migrate to a supported version — either the current 3.3 branch or the forthcoming 3.5 long-term support (LTS) line. this analysis reviews the OpenSSL release and support policy, summarizes key innovations in versions 3.2 and 3.3, and guides 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. 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. Understanding these timelines helps teams 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 improvements in OpenSSL 3.3

OpenSSL 3.3, released in April 2024, delivered significant upgrades to protocol support, cryptography and tooling. The release added extensive QUIC instrumentation, including qlog diagnostic logging and APIs to configure idle timeouts, manage stream buffer sizes and query connection status. Developers can now perform non‑blocking polling on QUIC connections, improving observability and reliability for HTTP/3 deployments. A new SSL_write_ex2 API simplifies sending end‑of‑stream markers and helps half‑closed connections, which benefits streaming and WebSocket workloads. Cryptographic improvements include the EVP_DigestSqueeze() function for extendable‑output functions and configurable BLAKE2s output lengths, plus improvements to EVP_PKEY_fromdata() that derive CRT parameters from RSA keys. 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 strong 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 will include mature FIPS modules, full QUIC support and performance optimizations. Teams 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. Teams 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; (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; (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. Teams 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.

This analysis and recommendations

Recommended: that platform and security leaders treat the OpenSSL 3.2 EOL as an opportunity to modernize cryptographic infrastructure. Migrating to 3.3 or preparing for 3.5 will enable 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. This continues monitoring OpenSSL releases and will guide on adopting post‑quantum algorithms and future LTS branches.

Producing cryptographic lifecycle briefings to help engineering leaders plan migrations, maintain compliance and use modern security capabilities.

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

Development recommendations

Development teams should adopt practices that ensure code quality and maintainability during and after this transition:

  • Code review focus areas: Update code review checklists to include checks for deprecated patterns, new API usage, and migration-specific concerns. Establish review guidelines for changes that span multiple components.
  • Documentation updates: Ensure README files, API documentation, and architectural decision records reflect the changes. Document rationale for setup choices to aid future maintenance.
  • Version control practices: Use feature branches and semantic versioning to manage the transition. Tag releases clearly and maintain changelogs that highlight breaking changes and migration steps.
  • Dependency management: Lock dependency versions during migration to ensure reproducible builds. Update package managers and lockfiles systematically to avoid version conflicts.
  • Technical debt tracking: Document any temporary workarounds or deferred improvements introduced during migration. Create backlog items for post-migration cleanup and improvement.

Consistent application of development practices reduces risk and accelerates delivery of reliable software.

More on this topic

Further reading from our research library.

Continue in the Developer pillar

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

Visit pillar hub

Latest guides

  • Secure Software Supply Chain Tooling Guide

    Engineer developer platforms that deliver verifiable provenance, SBOM distribution, vendor assurance, and runtime integrity aligned with SLSA v1.0, NIST SP 800-204D, and CISA SBOM…

  • AI-Assisted Development Governance Guide

    Govern GitHub Copilot, Azure AI, and internal generative assistants with controls aligned to NIST AI RMF 1.0, EU AI Act enforcement timelines, OMB M-24-10, and enterprise privacy…

  • Developer Enablement & Platform Operations Guide

    Plan AI-assisted development, secure SDLC controls, and runtime upgrades using our research on GitHub Copilot, GitHub Advanced Security, and major language lifecycles.

Coverage intelligence

Published
Coverage pillar
Developer
Source credibility
84/100 — high confidence
Topics
OpenSSL · Cryptography lifecycle · TLS · Supply chain
Sources cited
4 sources (openssl.org, raw.githubusercontent.com, linuxiac.com, cloudinsidr.com)
Reading time
5 min

Source material

  1. OpenSSL Release Strategy — OpenSSL project
  2. OpenSSL NEWS for 3.3.0 — OpenSSL project
  3. OpenSSL 3.3 Brings Extended QUIC Support and Advanced API Capabilities — Linuxiac
  4. OpenSSL 3.3 Final Release is Now Live — CloudInsidr
  • OpenSSL
  • Cryptography lifecycle
  • TLS
  • Supply chain
Back to curated briefings

Comments

Community

We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.

    Share your perspective

    Submissions showing "Awaiting moderation" are in review. Spam, low-effort posts, or unverifiable claims will be rejected. We verify submissions with the email you provide, and we never publish or sell that address.

    Verification

    Complete the CAPTCHA to submit.