up:: In the Protocols MOC

OpenSSL

OpenSSL is the most widely deployed open-source cryptographic and TLS library, split into libcrypto (the primitives) and libssl (the TLS stack), and it gained native support for the NIST post-quantum algorithms ML-KEM, ML-DSA, and SLH-DSA in its 3.5 release on April 8, 2025, while the FIPS-validated OpenSSL module that regulated deployments are required to use is still the pre-quantum 3.1.2.

Because so much of the internet’s server-side TLS terminates on OpenSSL, a huge migration surface inherits its quantum-transition timeline. The load-bearing fact for anyone planning a migration is that OpenSSL has two different post-quantum clocks running at once. The open-source library can do hybrid post-quantum TLS today on the right branch, and the CMVP-validated FIPS module cannot do it at all yet, so open-source availability and FIPS-validated availability are two different dates. Conflating them is the single most common way an OpenSSL PQC plan goes wrong.

The short version:

• OpenSSL 3.5 (April 8, 2025) added native support for ML-KEM, ML-DSA, and SLH-DSA, plus hybrid TLS key-exchange groups including X25519MLKEM768. Before 3.5, PQC was reachable only through the external oqs-provider.
• The hybrid groups pair classical X25519 with ML-KEM-768, so an OpenSSL-terminated TLS session closes its harvest-now-decrypt-later window if either the classical or the post-quantum half holds. See TLS 1.3 Hybrid Key Exchange.
• Availability is opt-in. A deployment that upgraded to 3.5 still runs classical key exchange on the wire until the hybrid groups are enabled in configuration.
• For regulated estates the gate is FIPS 140-3. The CMVP-validated OpenSSL module is still 3.1.2, which predates PQC entirely, so a FIPS-bound system cannot use OpenSSL’s native post-quantum algorithms in a compliant module yet.
• OpenSSL 3.5.4 was submitted for FIPS 140-3 validation on October 9, 2025, and the CMVP certificate is pending, so the compliant PQC path for regulated deployments is a wait on that certificate, not a version upgrade.

Think of OpenSSL as the lock factory for most of the internet, not a single lock. It designs and stamps out the locks that server after server installs on its doors. The factory already knows how to make a quantum-proof lock, and it started shipping them in April 2025. Two things still gate you. You have to install the new lock and turn it on, because owning a better lock and hanging it on the door are separate steps, and if your building is under a code that only accepts locks stamped by an official inspector, the inspector has not yet stamped the quantum-proof model. The factory sent one in for inspection in October 2025, and the certificate is still pending.

What is OpenSSL?

OpenSSL is the de facto open-source reference implementation for TLS and general-purpose cryptography. It ships as two linked libraries, libcrypto for the cryptographic primitives (ciphers, hashes, public-key algorithms, random-number generation) and libssl for the TLS and DTLS protocol stack built on top of them, along with the openssl command-line tool. It descends from Eric Young and Tim Hudson’s SSLeay and is maintained by the OpenSSL Project under the OpenSSL Foundation and OpenSSL Corporation.

Source: OpenSSL Library project site, openssl-library.org.

Since OpenSSL 3.0 the code is licensed under the Apache License 2.0. Two well-known downstream forks, LibreSSL (OpenBSD) and BoringSSL (Google), diverged years ago in feature set and post-quantum posture, so their PQC status does not follow OpenSSL’s and has to be read separately. In practice OpenSSL is the substrate under a very large share of web servers, proxies, load balancers, API gateways, language runtimes, and VPNs, which is why its version posture matters far beyond any single product.

Source: OpenSSL license page, openssl-library.org/source/license.

What does OpenSSL decide for post-quantum security?

Because OpenSSL is a protocol and primitive implementation rather than an application, it decides which key-exchange and signature algorithms a TLS session actually negotiates. That makes its post-quantum posture the posture of everything terminating on it. Two separate cryptographic jobs live inside a TLS handshake, and OpenSSL governs both.

1. Key exchange establishes the shared session keys that encrypt the traffic. This is the confidentiality promise, and it’s the one that carries harvest-now-decrypt-later risk, because an adversary can record an encrypted session today and decrypt it once a cryptographically relevant quantum computer exists.
2. Authentication proves identity with digital signatures, chiefly the certificate signatures that prove a server is the right machine. A forged signature only helps an attacker in real time once the machine exists, so it carries no store-now-decrypt-later analogue and is genuinely less urgent. See Non-HNDL.

The upgrade story below is mostly about the key-exchange channel, because that’s where the near-term post-quantum urgency sits and where OpenSSL’s hybrid support has landed. Post-quantum certificate signatures are a slower, ecosystem-wide change tied to the certificate authorities and the wider PKI.

How did OpenSSL go post-quantum?

OpenSSL 3.5, released on April 8, 2025, added native support for the three NIST-standardized post-quantum algorithms directly in the library, ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). The ML-KEM and ML-DSA implementations were derived from BoringSSL’s C code.

Source: OpenSSL 3.5 final release announcement, openssl-library.org/post/2025-04-08-openssl-35-final-release; OpenSSL 3.5 CHANGES, github.com/openssl/openssl.

For TLS specifically, the important addition is the set of hybrid key-exchange groups. OpenSSL 3.5 ships X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, each pairing a classical elliptic-curve key agreement with an ML-KEM key encapsulation. This is the same hybrid pattern the rest of the ecosystem adopted, and the reason is straightforward. A hybrid session stays confidential as long as either the classical half or the post-quantum half resists attack, which hedges against a still-young lattice scheme turning out to have a flaw.

Source: OpenSSL 3.5 CHANGES, github.com/openssl/openssl.

Before 3.5, OpenSSL had no native post-quantum algorithms. The only path was the external oqs-provider from the Open Quantum Safe project, plugged in through OpenSSL’s provider interface. That worked for experimentation, but it meant carrying a separate, non-default dependency rather than getting PQC from the mainline library. The 3.5 release is what moved the algorithms into the standard distribution most systems actually deploy.

One caveat governs the whole upgrade. The hybrid groups are opt-in, not on by default in most deployed configurations, so upgrading the OpenSSL package is a prerequisite, and enabling the hybrid TLS groups in configuration is the step that actually puts post-quantum key exchange on the wire. An application that links libssl and relies on TLS group negotiation gains the hybrid without any application-code change once the groups are enabled, which is crypto-agility working as intended.

Why are open-source PQC and FIPS-validated PQC two different dates?

This is the distinction that governs any regulated OpenSSL migration, and it’s the one people most often get wrong. Shipping an algorithm in the open-source library and having that algorithm inside a CMVP-validated FIPS 140-3 module are two separate events on two separate timelines.

1. The open-source date is April 8, 2025. That’s when OpenSSL 3.5 made ML-KEM, ML-DSA, and SLH-DSA available in the mainline library. Any non-regulated system on a 3.5-or-later branch can enable hybrid post-quantum TLS from that point.
2. The FIPS-validated date has not arrived. The only OpenSSL cryptographic module that currently holds a FIPS 140-3 validation is version 3.1.2, certificate #4985, valid through March 10, 2030. That module predates PQC and contains none of the post-quantum algorithms. A federal or otherwise FIPS-bound deployment is required to use a validated module, so for those systems the PQC algorithms in 3.5 are not usable in a compliant way, regardless of the fact that the code exists.

Source: OpenSSL 3.1.2 FIPS 140-3 validation announcement, openssl-library.org/post/2025-03-11-fips-140-3; OpenSSL 3.5 final release announcement, openssl-library.org/post/2025-04-08-openssl-35-final-release.

The gap is on a clock of its own. OpenSSL 3.5.4 was submitted for FIPS 140-3 validation on October 9, 2025, and the CMVP certificate is still pending, with the OpenSSL Project describing final CMVP review and certificate issuance as the last remaining step. FIPS validation is a multi-year process in practice, not a quick formality: the OpenSSL Project began the 3.1.2 FIPS validation effort back in 2022 and only saw the certificate issued in March 2025. So the compliant post-quantum path for a FIPS-bound OpenSSL deployment is a wait on the CMVP certificate for a 3.5-series module, not a version upgrade a team can schedule on its own.

Source: OpenSSL 3.5.4 FIPS 140-3 submission announcement, openssl-library.org/post/2025-10-09-ossl3.5.4-fips-submission; OpenSSL 3.1.2 FIPS 140-3 validation announcement, openssl-library.org/post/2025-03-11-fips-140-3.

What does the FIPS gap mean for a regulated deployment?

For a non-regulated system, OpenSSL’s post-quantum story is close to finished: get to a 3.5-or-later branch, enable the hybrid TLS groups, and the harvest-now-decrypt-later window on that endpoint’s key exchange closes. For a FIPS-bound system, the same estate splits into two tracks that move at different speeds.

1. The non-FIPS track is deployable now. Systems that don’t operate under a FIPS mandate can upgrade to 3.5, turn on the hybrid groups, and gain hybrid post-quantum TLS immediately.
2. The FIPS track is gated on the CMVP certificate. Systems that must run a validated module stay on the pre-quantum 3.1.2 module until a 3.5-series module is validated, because using the unvalidated 3.5 build would break the FIPS requirement itself. Their post-quantum readiness is a vendor-and-certificate dependency, not an internal engineering task.

The reason this matters for migration timing is that OpenSSL sits under so much infrastructure that any lag in a validated PQC module extends the migration lead time for every FIPS-bound system that depends on it. A team that treats the April 2025 feature date as the moment its regulated systems could migrate would plan against a date that doesn’t apply to them, which is exactly why the two dates have to be kept separate on a roadmap.

Which PQC algorithms does OpenSSL ship, and what’s the FIPS status?

OpenSSL 3.5 ships all three NIST-standardized post-quantum algorithms plus the hybrid TLS groups built on ML-KEM. The status column is the one that carries the weight, because “native in the library” and “in the FIPS-validated module” are entirely different guarantees.

Algorithm or group	Role	NIST standard	Native in OpenSSL	In the FIPS-validated module?
ML-KEM (e.g. ML-KEM-768)	Key encapsulation / TLS key exchange	FIPS 203	3.5 (Apr 8, 2025)	No, validated module is 3.1.2 (pre-PQC); 3.5.4 pending CMVP
ML-DSA	Digital signature	FIPS 204	3.5 (Apr 8, 2025)	No, same 3.1.2 gap
SLH-DSA	Hash-based signature	FIPS 205	3.5 (Apr 8, 2025)	No, same 3.1.2 gap
X25519MLKEM768 and sibling hybrid groups	TLS 1.3 hybrid key exchange	IANA-registered hybrid	3.5 (Apr 8, 2025)	No, same 3.1.2 gap
RSA, ECDH, ECDSA (classical)	Legacy key exchange and signatures	long-standing	All supported branches	Yes, present in the validated 3.1.2 module

Source: OpenSSL 3.5 CHANGES, github.com/openssl/openssl; OpenSSL 3.1.2 FIPS 140-3 validation announcement, openssl-library.org/post/2025-03-11-fips-140-3; OpenSSL 3.5.4 FIPS 140-3 submission announcement, openssl-library.org/post/2025-10-09-ossl3.5.4-fips-submission.

Two facts about that status carry weight. The deployed TLS forms are hybrid constructions, X25519MLKEM768 rather than raw ML-KEM-768, so a FIPS claim about them has to be evaluated against NIST’s hybrid guidance and not assumed from the fact that ML-KEM-768 is FIPS 203. And the presence of an algorithm in the source code says nothing about module validation; only the CMVP certificate does.

What are the deployment realities?

The rule that governs all applied PQC holds here too: a protocol is only as quantum-safe as its weakest deployed endpoint, and OpenSSL is deployed on a lot of endpoints. Several concrete traps sit between “OpenSSL supports PQC” and “my traffic is quantum-safe.”

1. Upgrading the branch is not enabling the hybrid. The 3.5 hybrid groups are opt-in. A system on 3.5 that never enabled the hybrid TLS groups still negotiates classical key exchange on the wire and is still exposed to harvest-now-decrypt-later.
2. Both endpoints have to be capable. Hybrid key exchange only negotiates when the client and the server both offer it. A modern OpenSSL server talking to an old peer falls back to classical key exchange, so the migration is a fleet-wide rollout tracked endpoint by endpoint.
3. The FIPS branch is a separate, slower track. Regulated systems cannot adopt the 3.5 PQC path in a compliant module until a 3.5-series module is CMVP-validated, so those endpoints stay on the pre-quantum 3.1.2 module by requirement, not by neglect.
4. Vendor-frozen builds are where it stalls. A large share of OpenSSL lives inside appliances, embedded devices, and vendor products that link an older OpenSSL and ship on the vendor’s cadence. Those inherit the vendor’s upgrade timeline rather than the upstream one, so the transition tends to stall on firmware and product release cycles rather than in the OpenSSL codebase.

Source: OpenSSL 3.5 final release announcement, openssl-library.org/post/2025-04-08-openssl-35-final-release.

Common misconceptions

• “OpenSSL doesn’t support post-quantum yet.” It has shipped native ML-KEM, ML-DSA, and SLH-DSA since release 3.5 on April 8, 2025, along with hybrid TLS groups like X25519MLKEM768. The confidentiality channel has a real near-term path on any 3.5-or-later branch.
• “If OpenSSL 3.5 has ML-KEM, my FIPS systems can use it.” The CMVP-validated OpenSSL module is 3.1.2, which contains no PQC. A FIPS-bound deployment cannot use the 3.5 algorithms in a compliant module until a 3.5-series module is validated, and that certificate is still pending.
• “Upgrading to 3.5 turns on post-quantum TLS.” The hybrid groups are opt-in. Upgrading the package is necessary, and enabling the hybrid TLS groups in configuration is the step that actually puts ML-KEM on the wire.
• “ML-KEM in OpenSSL means the connection is FIPS-approved.” The deployed TLS form is a hybrid construction, and the code carrying it isn’t in a validated module, so a FIPS claim has to trace to a specific CMVP-certified build rather than to the presence of ML-KEM in the source.
• “LibreSSL and BoringSSL inherit OpenSSL’s PQC status.” They’re separate forks that diverged long ago in feature set and post-quantum posture, so each has to be assessed on its own rather than assumed to match OpenSSL.
• “The hybrid group is the permanent design.” The classical X25519 half is exactly what a quantum computer breaks, so it’s carried as a transitional hedge and is meant to retire once ML-KEM is trusted on its own.

Questions people ask

Which OpenSSL version do I need for post-quantum TLS? Release 3.5 (April 8, 2025) or later, because that’s the branch that added native ML-KEM and the hybrid TLS groups. Anything earlier has no native PQC and could only reach it through the external oqs-provider.

Is my traffic quantum-safe just because I upgraded to 3.5? Not automatically. The hybrid groups are opt-in, so you also have to enable them in your TLS configuration, and both ends of the connection have to support the hybrid for it to negotiate. Until then the session can still fall back to classical key exchange.

Can my FIPS-compliant systems use OpenSSL’s post-quantum algorithms? Not yet in a compliant module. The validated FIPS 140-3 OpenSSL module is 3.1.2, which predates PQC, and the PQC-bearing 3.5.4 was submitted for validation on October 9, 2025 with its CMVP certificate still pending. Regulated deployments wait on that certificate.

How long does FIPS validation take? It runs multiple years in practice. The OpenSSL Project began the 3.1.2 FIPS validation in 2022 and only saw the certificate issued in March 2025, which is why the compliant PQC module is a wait rather than a schedulable upgrade.

Do I have to change my application code to get hybrid PQC? No. An application that links libssl and relies on TLS group negotiation gains the hybrid once you upgrade OpenSSL and enable the hybrid groups in configuration, with no application-code change. You only touch code if you’re using the primitives directly through the provider interface.

What’s the difference between ML-KEM and X25519MLKEM768 in OpenSSL? ML-KEM-768 is the standalone FIPS 203 algorithm, while X25519MLKEM768 is the hybrid TLS group that runs classical X25519 and ML-KEM-768 together. OpenSSL deploys the hybrid form for TLS so a session stays safe if either half holds.

What about post-quantum certificate signatures? Those are a slower, ecosystem-wide change. OpenSSL 3.5 ships ML-DSA and SLH-DSA as algorithms, but moving certificate signatures to PQC depends on certificate authorities and the wider PKI, and it carries no harvest-now-decrypt-later urgency because a signature can’t be forged retroactively.

Where do OpenSSL PQC migrations actually stall? Rarely in the OpenSSL codebase. They stall on vendor-frozen and embedded builds that link an older OpenSSL and ship on the vendor’s release cadence, and, for regulated estates, on the pending CMVP certificate for a validated 3.5-series module.

---

Everything here is the map, given freely. When your team needs its OpenSSL-terminated services inventoried by branch, its hybrid TLS groups checked for whether they’re actually negotiating, and its FIPS-bound systems sequenced against the pending validated module, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.