OpenSSL 3.5 Ships with Post-Quantum Cryptography On by Default
10 April 2025 — The OpenSSL Project released version 3.5.0 on April 8, 2025, with native support for all three NIST-standardized PQC algorithms: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). The release changes default TLS behavior: the default supported groups list now includes and prefers hybrid PQC key encapsulation, with X25519MLKEM768 and X25519 as default keyshares.
This is an LTS (Long Term Stable) release, supported until April 8, 2030. That five-year support window means systems deploying OpenSSL 3.5 today will receive security updates through the end of the decade, covering the period when most global PQC migration deadlines take effect.
The default configuration changes are worth spelling out. TLS key exchange now defaults to hybrid mode (X25519MLKEM768), meaning any TLS connection between two endpoints running OpenSSL 3.5 will negotiate a post-quantum key exchange without any explicit configuration by the administrator. Rarely used legacy groups have been removed from the default list. The default symmetric cipher for command-line utilities (req, cms, smime) has changed from des-ede3-cbc to aes-256-cbc.
The release also adds server-side QUIC support (RFC 9000), but the PQC integration is the change with systemic consequences.
OpenSSL underpins a majority of the internet’s TLS infrastructure. NGINX, Apache, HAProxy, and the vast majority of Linux-based server infrastructure depend on it. When OpenSSL changes its defaults, the effect cascades across millions of servers as distributions update their packages.
My Analysis
New algorithm standards are important. Government mandates set deadlines. Corporate commitments from Google and Cloudflare demonstrate intent. But none of that moves the adoption curve as directly as the world’s most widely deployed cryptographic library shipping PQC turned on by default. Organizations that have been waiting for a “mature” PQC implementation before acting have lost their last credible excuse.
Two things about this release matter beyond the headline.
The default-on design inverts the adoption model. Most PQC deployments so far have required explicit opt-in: install a plugin (like the Open Quantum Safe provider), edit configuration files, test compatibility, deploy. OpenSSL 3.5 flips this. PQC is the default. Administrators who want classical-only key exchange now need to explicitly opt out. This design choice follows the principle that security defaults should be the secure option. PQC adoption will climb passively as Linux distributions ship OpenSSL 3.5 in their package updates, without requiring individual administrators to take affirmative action.
The LTS designation through 2030 aligns with the regulatory timeline. NIST IR 8547 proposes deprecating 112-bit classical algorithms in 2030. CNSA 2.0 requires exclusive PQC use for networking equipment by 2030. An organization that deploys OpenSSL 3.5 today and keeps it updated through its LTS lifecycle will have PQC key exchange running through these deadlines. That’s not full migration (signature migration, certificate chain updates, and application-layer changes still require separate work), but it covers the HNDL risk for data in transit, which is the most time-critical component.
A third development to watch: the path to FIPS 140-3 validation for OpenSSL 3.5. For US federal agencies and their contractors, deploying cryptographic modules without FIPS validation is not an option. Once a validated OpenSSL 3.5 FIPS module becomes available, organizations can deploy PQC through the same library they’ve used for decades, without switching to a proprietary cryptographic stack. That validation timeline will determine how quickly the federal ecosystem can adopt.
What remains to be done after OpenSSL 3.5 deployment: TLS key exchange is only one piece of the migration. Digital signature migration (certificates, code signing, PKI hierarchies) requires separate work and depends on CA support for PQC certificates, which is still maturing. Application-layer cryptography (database encryption, API authentication, document signing) requires individual application updates. And the infrastructure challenges of PQC deployment (larger key sizes, larger handshakes, bandwidth constraints on low-power devices) require testing in each environment.
But the foundation is in place. The excuse that PQC tooling isn’t ready for production use no longer holds.
Quantum Upside & Quantum Risk - Handled
My company - Applied Quantum - helps governments, enterprises, and investors prepare for both the upside and the risk of quantum technologies. We deliver concise board and investor briefings; demystify quantum computing, sensing, and communications; craft national and corporate strategies to capture advantage; and turn plans into delivery. We help you mitigate the quantum risk by executing crypto‑inventory, crypto‑agility implementation, PQC migration, and broader defenses against the quantum threat. We run vendor due diligence, proof‑of‑value pilots, standards and policy alignment, workforce training, and procurement support, then oversee implementation across your organization. Contact me if you want help.
