FIPS203
ML-KEM
Key encapsulation
Module-Lattice key encapsulation — the post-quantum key exchange standard that protects traffic against record-now, decrypt-later attacks.
Post-Quantum Readiness
Quantum-safe, built in.
The NIST post-quantum standards are already in the OpenSSL Library — and the team that implemented them helps you migrate. Hybrid post-quantum key exchange is the TLS default, so protection comes without application changes.
— Built in
The three NIST standards, shipping today.
FIPS204
ML-DSA
Digital signatures
Module-Lattice digital signatures — quantum-resistant signing for certificates, code, and long-lived artefacts.
FIPS205
SLH-DSA
Hash-based signatures
Stateless hash-based signatures — a conservative alternative built only on hash functions, a fallback if lattice schemes are ever broken.
TLS default
Connections negotiate X25519MLKEM768 automatically — post-quantum protection with no application changes.— Why now
Harvest now, decrypt later.
Encrypted traffic captured today can be stored and decrypted the moment a cryptographically-relevant quantum computer exists. Anything that must stay secret for years is already at risk — which is why the migration starts now.
Today
Traffic captured
An adversary records encrypted data off the wire.
Years
Stored, waiting
Ciphertext sits in storage — patient, untouched.
Quantum era
Decrypted
A quantum computer breaks the classical key — secrets exposed.
Hybrid PQ stops thisX25519MLKEM768 protects today's traffic against tomorrow's computer.
— How it works
Two secrets, one handshake.
The default TLS 1.3 group, X25519MLKEM768, runs a classical and a post-quantum key exchange together and combines them. An attacker would have to break both — so a future quantum computer can't decrypt traffic captured today.
Client
generates key shares
Classical · X25519
Post-quantum · ML-KEM-768
HKDFone shared secret
Server
encapsulates & derives
— Fast enough to be the default
Post-quantum, without the penalty.
Hybrid key exchange runs in the same order of magnitude as classical X25519 — tens of thousands of operations per second on a single core. The overhead is negligible at connection setup.
Classical · X25519Hybrid · X25519MLKEM768 (TLS default)
Key generation
56% of classical speed
Encapsulation
86% of classical speed
Decapsulation
66% of classical speed
Operations per second, single core. Source: openssl speed -kem-algorithms · live graphs at openssl-library.org/performance
— The timelines are set
Deadlines you can plan around.
Now
NIST urges teams to start the migration.
2030
The EU roadmap targets high-risk systems, and US national-security systems carry a deadline under CNSA 2.0.
2035
The EU roadmap targets broad completion of the migration.
— The library today
Release support at a glance.
The current Long Term Support release is OpenSSL 3.5, supported through April 2030. Anyone can download OpenSSL and rely on best-effort community support; a commercial contract adds continued security fixes past end of life — available for 1.1.1 and any 3.x release a customer needs. An LTS release receives fixes and security updates for five years, with the final year security-only.
0.9.x – 1.1.0Unsupported
1.1.1Extended support available
3.0 LTSEOL Sep 2026 · extended support
3.1FIPS 140-3 module maintained
3.2EOL · extended support
3.3EOL · extended support
3.4Through Oct 2026
3.5 LTSThrough Apr 2030
3.6Through Nov 2026
4.0Through May 2027
4.1Planned Oct 2026
4.2 LTSPlanned Apr 2027
5.0Planned Oct 2027
SupportedExtended supportPlannedUnsupported
— What's in the library
Modern cryptography, maintained.
01
Post-quantum cryptography, built in
ML-KEM, ML-DSA and SLH-DSA — the three NIST PQC standards. TLS now defaults to hybrid post-quantum key exchange (X25519MLKEM768), so connections gain post-quantum protection with no application changes.
02
Native server-side QUIC
QUIC (RFC 9000) server support, plus support for third-party QUIC stacks. Session resumption with 0-RTT is available over TLS-over-TCP; 0-RTT for QUIC is in active development.
03
Stronger defaults out of the box
AES-256 replaces 3DES in the CMS, S/MIME and req tools, with finer control over TLS group configuration.
04
Provider-based architecture
Pluggable cryptographic backends (since 3.0) — the same mechanism our FIPS module and rebrand offering build on. OpenSSL 4.2 will make providers the only pluggable extension mechanism and bring new features like ECH.
— How we help
Migrate with the people who wrote it.
Plan and run the migration
We help customers plan and run the post-quantum migration — done by the people who implemented it.
A direct line to the maintainers
Work directly with the team that writes the cryptographic code, not a third party in between.
Extended LTS
Security fixes for releases past upstream end of life, so teams upgrade on their own schedule.
Embargoed advisory notice
Advance, embargoed notice of High and Critical advisories at the Engineering tier and above — the same notice given to the OS distributions, so fixes are ready before disclosure.