OpenSSL 3.5, released on 8 April 2025, is a long term stable release that adds the three NIST post-quantum algorithms: ML-KEM, ML-DSA and SLH-DSA. It also adds support for multiple TLS key shares. Whether your service benefits depends on which OpenSSL it actually links against.
What the release announcement says
The OpenSSL project describes 3.5 as an LTS release supported through 8 April 2030. The headline additions are the post-quantum algorithms from FIPS 203, 204 and 205, plus support for multiple TLS keyshares and improved configurability of TLS key establishment groups.
The announcement page we fetched does not say which groups are enabled by default, so do not assume it. Check the documentation for the exact version you run, and test.
Why the version you run matters more than the version that exists
Most services do not use the newest OpenSSL. They use whatever the operating system, container base image or language runtime bundles. Three common situations:
- A container base image ships its own OpenSSL, often older than the current LTS.
- A language runtime (Python, Node, Ruby, Java via a native provider) may link a system library, bundle its own, or use a different TLS stack entirely.
- A load balancer or reverse proxy terminates TLS, so the application never sees the handshake.
The place that decides your key exchange is the TLS terminator, so start there, not in application code.
How to check what you have
- Run the openssl version command inside the container or host that terminates TLS, and record the result.
- Look at which TLS library each language runtime in your fleet uses.
- Review the TLS group list in your server or proxy configuration for explicit settings that pin older groups.
- From a test client, make a connection and read the negotiated group.
- Repeat after any base image update, because the answer can change silently.
Upgrade cautions
A new major or LTS line can change default behaviour, remove deprecated algorithms or alter provider loading. Read the release notes and migration guide before bumping the version in production images. Pin the version in your build, run your TLS integration tests, and keep a rollback image.
Also remember what a library upgrade does not do. It makes post-quantum algorithms available. It does not migrate your certificates, your code signing or your JWT keys. Those need their own plan.
Quick check
Is OpenSSL 3.5 the only way to get ML-KEM in TLS?
No. Other TLS libraries and platforms have their own support and timelines. Check each one you rely on rather than assuming a single upgrade covers everything.
Does supporting ML-DSA in the library mean my certificates are post-quantum?
No. Certificates come from a certificate authority and the wider ecosystem has to support the algorithm. The library can only offer the primitive.
Safeguard's SBOM and dependency scanning records which library versions are present in your images and repositories, and the free scan at gold.safeguard.sh/scan gives a quick view.
Sources
Last reviewed: 19 October 2026.
