The editorial argues that with NIST having finalized PQC standards in 2024, browsers already shipping hybrid key exchange, and NSA's CNSA 2.0 pushing enterprises toward PQC by 2030, making ML-KEM and ML-DSA default-on is structurally the right call. Moving from the bolt-on OQS provider approach in 3.x to native default support removes the friction that was slowing adoption.
Submitted the release announcement, highlighting the significance of the first major version bump since the 3.0 release in 2021. The submission framing positions this as a milestone event for the project.
The editorial explicitly warns that 'the upgrade path itself is going to hurt,' noting that OpenSSL 4.0 finishes what 3.0 started by fully removing deprecated functions and the ENGINE interface. The 3.0 transition was already painful for many projects; 4.0 removes the compatibility crutches that let projects defer migration.
The editorial highlights that the hybrid composite pairs ML-KEM-768 with X25519 so that clients not supporting the hybrid group simply fall back to classical key exchange. The ~1.1 KB increase to ClientHello is presented as a modest cost for gaining resistance to harvest-now-decrypt-later attacks with zero configuration changes required from server operators.
The editorial calls it 'the right call' that ML-DSA certificate signature support is available but not default, because the broader certificate ecosystem — CAs, Certificate Transparency logs, and OCSP responders — is not yet prepared to handle post-quantum signature algorithms. Pushing PQC signatures prematurely would create interoperability failures across the PKI chain.
The OpenSSL project shipped version 4.0.0 on April 15, 2026 — the first major version bump since the seismic 3.0 release in September 2021. That release introduced the provider architecture, a new FIPS module, and deprecated hundreds of legacy API functions. OpenSSL 4.0.0 finishes what 3.0 started: the deprecated functions are gone, the ENGINE interface is removed, and post-quantum cryptography moves from optional to default.
The release lands at a moment when the cryptographic landscape is shifting faster than at any point since the TLS 1.3 transition. NIST finalized its post-quantum standards (FIPS 203, 204, and 205) in 2024, browsers and cloud providers have been shipping hybrid key exchange for over a year, and regulatory pressure — particularly from the NSA's CNSA 2.0 timeline — is pushing enterprises toward PQC adoption by 2030. OpenSSL 4.0 makes that transition structurally easier, but the upgrade path itself is going to hurt.
The headline feature is native, default-on support for ML-KEM (formerly CRYSTALS-Kyber) and ML-DSA (formerly CRYSTALS-Dilithium) — the lattice-based algorithms that won NIST's six-year post-quantum competition. In OpenSSL 3.x, you could compile with experimental PQC support or bolt on the Open Quantum Safe (OQS) provider. In 4.0, ML-KEM-768 participates in TLS 1.3 hybrid key exchange out of the box, paired with X25519 in a `X25519MLKEM768` composite.
For most server operators, this means TLS handshakes will get slightly larger (roughly 1.1 KB added to the ClientHello) but gain resistance to harvest-now-decrypt-later attacks without any configuration changes. Clients that don't support the hybrid group simply fall back to classical key exchange — the negotiation is backward-compatible.
ML-DSA support for certificate signatures is available but not yet default for TLS authentication, which is the right call. The certificate ecosystem (CAs, CT logs, OCSP responders) isn't ready for post-quantum signatures, and the size increase for ML-DSA-65 certificates (roughly 2.5 KB for the public key alone, versus 32 bytes for Ed25519) would break assumptions baked into certificate chains, stapled responses, and constrained IoT handshakes. Expect this to become default in a 4.x point release once the CA/Browser Forum finalizes its PQC certificate profiles.
SLH-DSA (SPHINCS+), the hash-based signature scheme from FIPS 205, is also included as a provider. It's slower and produces larger signatures than ML-DSA, but its security rests on well-understood hash function properties rather than lattice assumptions — a conservative fallback if lattice cryptanalysis advances faster than expected.
The API surface that was deprecated in 3.0 and marked for removal is now gone. This is the part that will generate the most GitHub issues across the ecosystem. Specific casualties include:
ENGINE API removal. The old ENGINE interface for loading custom crypto implementations — hardware security modules, PKCS#11 tokens, custom algorithms — is fully removed. If you maintained an ENGINE-based integration, you must port to the provider interface. This affects a nontrivial number of enterprise HSM integrations. Thales, Entrust, and other HSM vendors have had provider-based replacements available since 2023–2024, but plenty of internal deployments never migrated.
Low-level API functions. Direct calls to algorithm-specific functions like `RSA_public_encrypt()`, `EVP_MD_CTX_cleanup()`, and the `DH_*`/`DSA_*` family are removed. The EVP (envelope) API is the only supported interface. This was the direction since 3.0, but many projects — particularly C extensions in dynamic languages — continued using the deprecated functions because they still compiled.
BIO changes. Several legacy BIO methods are consolidated. Custom BIO implementations may need updates to their method tables.
The practical impact cascades through language ecosystems. Python's `ssl` module and `cryptography` package, Ruby's `openssl` gem, PHP's `openssl` extension, Node.js's `crypto` module — all of these link against libssl/libcrypto. When distributions ship OpenSSL 4.0, these bindings need to compile against the new API. The Python `cryptography` package, maintained by the Pyca team, has historically been fast to support new OpenSSL majors, but the ENGINE removal affects packages like `pkcs11` and `python-pkcs11` that relied on the old interface.
OpenSSL's FIPS provider gets updated to align with the FIPS 140-3 standard, including the new PQC algorithms. The FIPS module is now a separately versioned, independently validatable component — you don't need to upgrade your entire OpenSSL installation to get a FIPS-validated crypto module, and vice versa. This decoupling has been requested by enterprise users since the 3.0 FIPS module's troubled validation process, which took until late 2023 to complete.
For teams subject to FedRAMP or similar compliance requirements, this is arguably the most important change in the release. FIPS validation takes 12–18 months on a good day, and decoupling the module means the validation lifecycle doesn't block adoption of other improvements in the library.
If you maintain C/C++ code linking against OpenSSL: Compile with `-DOPENSSL_API_COMPAT=0x40000000L` on your current 3.x build. This will surface deprecation warnings for every function removed in 4.0. Fix those first, then upgrade.
If you deploy on Linux distributions: Don't expect OpenSSL 4.0 in stable distros immediately. Debian, Ubuntu LTS, and RHEL are conservative about major OpenSSL bumps — Debian bookworm still ships OpenSSL 3.0.x. Rolling-release distros (Arch, Fedora Rawhide) will pick it up within weeks. Alpine, which many Docker images use, tends to move faster on OpenSSL majors.
If you run Nginx, Apache, or HAProxy: These projects have historically required patches or new releases to support OpenSSL major versions. Check your reverse proxy's OpenSSL compatibility matrix before upgrading the system library — a silent ABI break will manifest as segfaults, not compile errors, if you swap the .so without rebuilding.
If you use hardware security modules: Verify your HSM vendor has a provider-based integration. If you're still on ENGINE-based PKCS#11, this upgrade is blocked until you migrate. Start now — provider ports are not trivial.
If you care about PQC readiness: This is the most painless way to get hybrid post-quantum key exchange into your TLS stack. For internal services where you control both ends, you can enable ML-KEM-only (non-hybrid) cipher suites for maximum PQC protection, though this sacrifices backward compatibility with classical-only clients.
OpenSSL 4.0 marks the library's transition from "supporting post-quantum" to "assuming post-quantum." The next inflection point will be PQC certificates — when CAs begin issuing ML-DSA-signed certificates and the WebPKI infrastructure adapts. That's a 2027–2028 story at the earliest, but when it arrives, the plumbing will be in OpenSSL 4.x. For now, the immediate task is prosaic: audit your dependency tree, grep for deprecated API calls, check your HSM integrations, and plan your rebuild. The five-year deprecation grace period is over.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.