Quick answer: OpenSSL’s path to quantum-ready TLS started with pluggable post-quantum providers in v3.2.0 (November 2023), which let third-party providers like oqs-provider add experimental PQC algorithms without modifying OpenSSL itself. That transitional approach has since been superseded: OpenSSL 3.5, released as an LTS version on April 8, 2025, ships native support for ML-KEM, ML-DSA, and SLH-DSA, and defaults TLS 1.3 key exchange to the hybrid group X25519MLKEM768. The recommended action is to upgrade to OpenSSL 3.5 LTS directly rather than building on the older pluggable-provider approach, since native support removes the extra dependency and stays supported through April 2030.
Key Takeaways
- OpenSSL v3.2.0 (November 2023) introduced pluggable PQC providers, letting third-party libraries like oqs-provider add post-quantum algorithms experimentally.
- OpenSSL 3.5, an LTS release from April 8, 2025, replaced that transitional approach with native ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) support built directly into the default provider.
- OpenSSL 3.5’s default TLS 1.3 supported groups list now prefers hybrid PQC key exchange, with X25519MLKEM768 and X25519 as default keyshares.
- ML-KEM requires TLS 1.3 and cannot be used with TLS 1.2 or earlier; SLH-DSA signatures are large (8 to 50 KB), so ML-DSA is generally preferred for certificates where size matters.
- OpenSSL 3.5 LTS is supported until April 8, 2030, covering the period when most global PQC migration deadlines take effect.
The Pluggable Provider Starting Point
In recent years, quantum computing has emerged as a very transformative field. Quantum computers or machines use quantum mechanical processes to solve problems mainly related to mathematical calculations that are difficult for conventional computers. Post Quantum cryptography (PQC) aims to create cryptographic mechanisms that provide security for both quantum and conventional computers and follow existing communication protocols and networks. OpenSSL is a major player in the field of secure communication techniques. In its v3.2.0 release (November 2023), OpenSSL introduced support for pluggable post-quantum cryptography (PQC) signature algorithms and key establishment mechanisms.
Pluggable Signature Algorithms
The most interesting feature of that release was incorporating pluggable signature algorithms. This allowed third-party providers, such as the Open Quantum Safe project’s oqs-provider, to integrate post-quantum cryptographic techniques without modifying OpenSSL’s core codebase. This also enhanced OpenSSL’s adaptability, enabling users to choose PQC schemes aligning with their specific security needs at a time when NIST had not yet finalized its standards. Dilithium (later standardized as ML-DSA) was one of the most notable candidates tested this way, a robust and secure signature algorithm designed to withstand quantum devices’ computational power.
Pluggable Key Establishment Mechanisms
Alongside pluggable signatures, OpenSSL’s provider architecture also supported pluggable key establishment mechanisms (KEMs), introducing algorithms like Kyber (later standardized as ML-KEM) to the TLS ecosystem through third-party providers. This combination positioned OpenSSL as an adaptable, quantum-ready TLS library ahead of formal standardization, letting users experiment with candidate PQC algorithms for signature generation and key establishment during the TLS handshake.
OpenSSL 3.5 LTS: Native PQC Support Arrives
The pluggable-provider approach was always a bridge, not a destination. NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) on August 13, 2024, and OpenSSL brought all three into its default provider with the release of OpenSSL 3.5.0 on April 8, 2025. Unlike the earlier pluggable approach, this support ships natively, with no external provider or patch required.
OpenSSL 3.5 is also a long-term stable (LTS) release, supported with updates for five years through April 8, 2030, a window that covers most of the global PQC migration deadlines organizations are now planning against. The release changed OpenSSL’s default TLS behavior as well: the default supported groups list now includes and prefers hybrid PQC key exchange, with X25519MLKEM768 and X25519 offered as default keyshares. That means organizations running OpenSSL 3.5 with default settings are already negotiating hybrid post-quantum key exchange for TLS 1.3 connections without any additional configuration.
A few practical constraints carry over from the algorithms themselves. ML-KEM requires TLS 1.3 and cannot be negotiated over TLS 1.2 or earlier. SLH-DSA signatures range from 8 to 50 KB depending on the parameter set, considerably larger than ML-DSA signatures, so ML-DSA is the more practical default for TLS certificates where handshake size matters. SLH-DSA remains valuable where its more conservative, hash-based security assumptions are worth the size tradeoff.
Quantum-Ready Flexibility
Between the pluggable providers introduced in v3.2.0 and the native standards support in 3.5, OpenSSL’s TLS library has built real flexibility into the transition. Organizations that experimented early with oqs-provider now have a direct upgrade path to standardized, natively supported algorithms, and organizations starting fresh can adopt OpenSSL 3.5 LTS directly. This flexibility keeps OpenSSL ahead of the evolving cybersecurity landscape and keeps communication channels current with finalized NIST standards rather than draft candidates.
Implementation Considerations
Organizations adopting post-quantum cryptographic algorithms for specific use cases must carefully consider implementation strategies. OpenSSL 3.5’s native support simplifies this considerably compared to the earlier pluggable-provider approach, since the algorithms are already validated and included in every standard build, but proper testing and validation remain essential. This includes benchmarking the real-world cost of larger PQC keys and signatures on your specific infrastructure, verifying interoperability with clients and servers that have not yet upgraded, and confirming whether your deployment needs FIPS-validated builds, since PQC support in the FIPS provider trails the default provider.
Conclusion
OpenSSL’s pluggable-provider architecture in v3.2.0 opened the door to experimental post-quantum cryptography ahead of formal standardization. OpenSSL 3.5, released as an LTS version in April 2025, walked through that door with native, standards-based support for ML-KEM, ML-DSA, and SLH-DSA, now the practical starting point for quantum-ready TLS.
As the cybersecurity landscape keeps evolving, we, Encryption Consulting, stand as a trusted partner who is an expert in guiding organisations to integrate these latest security measures seamlessly.
After collaborating with us, organisations will gain a strategic ally in the battle against evolving cyber threats. Our team is prepared to access, plan, and execute the integration of native post-quantum cryptography with the OpenSSL library. We ensure organisations navigate successfully to secure communications with fortified cryptographic functions.
Frequently Asked Questions
What is the difference between OpenSSL’s pluggable PQC providers and OpenSSL 3.5’s native support?
Pluggable providers, introduced in v3.2.0, let third-party libraries like oqs-provider add experimental post-quantum algorithms without modifying OpenSSL’s core code. OpenSSL 3.5 built ML-KEM, ML-DSA, and SLH-DSA directly into OpenSSL’s default provider, so no external provider is needed and the algorithms are the NIST-finalized standards rather than pre-standardization candidates.
When was OpenSSL 3.5 released, and how long is it supported?
OpenSSL 3.5.0 was released on April 8, 2025, as a long-term stable (LTS) release. It receives security updates for five years, through April 8, 2030.
What is the default TLS 1.3 key exchange in OpenSSL 3.5?
OpenSSL 3.5 defaults its supported groups list to prefer hybrid post-quantum key exchange, offering X25519MLKEM768 and X25519 as default keyshares. Organizations running default configurations are already negotiating hybrid PQC key exchange for TLS 1.3 without extra setup.
Can ML-KEM be used with TLS 1.2?
No. ML-KEM requires TLS 1.3 and cannot be negotiated over TLS 1.2 or earlier protocol versions.
Should I use ML-DSA or SLH-DSA for certificates?
ML-DSA is the more practical default for most certificates, since SLH-DSA signatures run from 8 to 50 KB depending on the parameter set, considerably larger than ML-DSA. SLH-DSA is worth the size tradeoff where its more conservative, hash-based security assumptions matter more than handshake efficiency.
If I already deployed the oqs-provider pluggable approach, do I need to migrate?
Yes, eventually. The pluggable-provider approach was built around pre-standardization candidate algorithms. Migrating to OpenSSL 3.5’s native support gets you the NIST-finalized versions of these algorithms without an external dependency, and removes the maintenance burden of tracking a separate provider project.
