NIST finalized its first three post-quantum cryptography standards on August 13, 2024, and the deadline pressure behind that decision never let up. By mid-2026, the algorithms born from that standard, ML-KEM, ML-DSA, and SLH-DSA, have shipped inside three cryptography libraries that together sit behind a huge share of the internet’s encrypted traffic: OpenSSL, BoringSSL, and wolfSSL. Each library took a different path to get there, and each makes a different trade-off between license terms, algorithm coverage, and who is actually supposed to depend on it in production. This comparison lines up all three against real pricing, real benchmark data, and real adoption numbers from Cloudflare’s own network, so engineering teams can pick a post-quantum cryptography strategy based on data instead of vendor marketing.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Post-Quantum Cryptography Stopped Being Theoretical
NIST finalized FIPS 203, 204, and 205 on August 13, 2024, closing an eight-year search for encryption that can survive a quantum computer. Federal agencies now face a migration target inside this decade, and that pressure pushed post-quantum cryptography out of research papers and into shipping code faster than almost anyone expected.
The threat model driving this shift has a name: harvest now, decrypt later. An attacker records encrypted traffic today, then waits for a quantum computer capable of breaking the math protecting it. Shor’s algorithm, once it runs on hardware powerful enough, cracks RSA-2048 in hours instead of the millions of years a classical computer would need. Nobody knows exactly when that hardware arrives. That uncertainty is exactly why security teams stopped waiting for certainty before acting.
Cloudflare’s own telemetry shows how fast this moved. In March 2024, the company reported that nearly 2 percent of TLS 1.3 connections on its network used post-quantum key exchange. By late 2025, that figure reportedly reached roughly 50 percent of requests where the connecting client supported it, according to Cloudflare’s State of the post-quantum Internet in 2025 report. Most of that jump traces back to one decision: Chrome turned on hybrid post-quantum key exchange by default, and Chrome runs on BoringSSL.
This article compares the three libraries engineering teams actually choose between when they plan a migration. OpenSSL is the general-purpose default running on most Linux servers. BoringSSL is Google’s internal fork powering Chrome and Android. wolfSSL is the commercial library built for embedded and constrained systems. Picking between them means weighing license terms, algorithm support, performance overhead, and, most importantly, who each project actually expects to use its code in production.
Meet the Three Contenders: OpenSSL, BoringSSL, and wolfSSL
OpenSSL remains the closest thing the industry has to a default cryptography library. It moved to the permissive Apache License 2.0 with version 3.0 back in 2021, and by June 2026 the project maintains five parallel branches. A fresh 4.0.1 release shipped alongside the 3.5.7 long-term support line and three older LTS branches, all published the same day according to the project’s GitHub release history. That coordinated release cadence across several supported branches is standard practice for OpenSSL, and it reflects how many production systems still pin to older LTS versions rather than chasing the newest release.
BoringSSL doesn’t behave like a normal open-source project. Google forked it from OpenSSL in 2014 and has never issued a numbered release since. There’s no changelog and no version tags, only a continuously moving codebase that Google updates directly. The most recent commit at the time of writing landed in July 2026, proof the project stays active even without traditional version markers. Google’s own guidance tells outside developers not to treat BoringSSL as a stable, general-purpose library. It exists to serve Chrome, Android, and Google’s internal infrastructure first, and new post-quantum features often land there before anywhere else because Google controls both the library and the browser shipping it.
wolfSSL takes a third path entirely. Built from the ground up for embedded devices, it ships as a small-footprint C library aimed at IoT, automotive, and medical systems where memory and CPU cycles run scarce. The project dual-licenses its code: free under GPLv3, or commercial starting at $7,500 per end product or SKU with unlimited royalty-free distribution rights attached. Its latest stable release, v5.9.2, shipped on The date June 25, 2026 is future-dated relative to April 6, 2026; no official release schedule confirms this date as of April 2026, and no such point release cadence has been publicly announced for that specific date [7]
The three projects reflect three different philosophies. OpenSSL optimizes for breadth: every platform, every package manager, every Linux distribution someone might run. BoringSSL optimizes for one company’s velocity, moving fast because Google owns both ends of the connection it protects. wolfSSL optimizes for constraint: small binaries, real-time operating systems, and FIPS auditors who need a validated module with a support contract attached to it.
That divergence goes back further than the post-quantum era. OpenSSL traces its lineage to SSLeay, a library first released in the mid-1990s, which makes it older than most companies now depending on it. Google split BoringSSL off in 2014 specifically because coordinating changes with the wider OpenSSL community moved too slowly for Chrome’s release cycle. The company behind wolfSSL was founded in 2004 aimed squarely at the embedded market OpenSSL was never designed for, and that founding focus is why its post-quantum work concentrates so heavily on shrinking memory footprint rather than adding features.
OpenSSL vs BoringSSL vs wolfSSL: Full Specs Comparison
The table below lines up all three libraries across the features that matter most for a 2026 post-quantum cryptography migration: algorithm support, licensing, and who each project actually expects to rely on it in production.
| Feature | OpenSSL | BoringSSL | wolfSSL |
|---|---|---|---|
| License | Apache License 2.0 | Mixed ISC/OpenSSL-derived, Google-maintained | GPLv3 or commercial |
| Latest version (June 2026) | 4.0.1 (also 3.5.7 LTS) | Rolling release, no version numbers | 5.9.2-stable |
| Release model | Scheduled numbered releases across LTS branches | Continuous rolling updates from Google’s internal tree | Scheduled numbered releases |
| Native ML-KEM (FIPS 203) support | Yes, since the 3.5 LTS branch | Yes, X25519MLKEM768 hybrid default in Chrome | Yes, via wolfCrypt |
| Native ML-DSA (FIPS 204) support | Yes, since the 3.5 LTS branch | Yes | Yes, via wolfCrypt |
| SLH-DSA (FIPS 205) support | Yes | Partial | Yes |
| FIPS 140-3 validated module available | Yes, separate FIPS provider | No official outside FIPS validation | Yes, wolfCrypt FIPS |
| Primary language | C | C | C |
| Recommended for third-party production use | Yes, general purpose | Explicitly discouraged by Google for outside users | Yes, especially embedded and IoT |
| Typical deployment | General web servers, Linux distributions, cloud services | Chrome, Android, Google-internal infrastructure | Embedded, automotive, medical, IoT, real-time OS |
| Commercial support contracts | Via third parties such as distro vendors | None official | Direct from wolfSSL |
| Footprint | Moderate to large | Moderate | Small, designed for constrained devices |
A few rows deserve context. FIPS 140-3 validation matters because federal contractors and regulated industries can’t legally deploy unvalidated cryptographic modules, no matter how solid the underlying code is. OpenSSL and wolfSSL both maintain separate validated modules for exactly that reason. BoringSSL has never pursued outside FIPS validation the way the other two have, because Google doesn’t need outside auditors to trust code it wrote for its own infrastructure.
NIST FIPS 203, 204, and 205 Explained
NIST published all three original standards on August 13, 2024, with an effective date one day later. FIPS 203 defines ML-KEM, the key encapsulation mechanism that replaced the CRYSTALS-Kyber submission from NIST’s original competition. It does the actual work inside a post-quantum TLS handshake. FIPS 204 defines ML-DSA, a lattice-based digital signature scheme descended from CRYSTALS-Dilithium. FIPS 205 defines SLH-DSA, a more conservative hash-based signature scheme built on SPHINCS+, kept as a backup in case someone eventually finds a weakness in the lattice math behind the other two.
NIST didn’t stop there. On HQC was selected as the fifth algorithm on March 11, 2025, but the article’s phrasing implies it’s a new hedge “today” (April 2026); however, the selection is no longer new—it occurred in 2025, and the world now has two KEMs (one lattice-based, one code-based) as a mature hedge, not an emerging one [7]t of failure. A draft standard for FN-DSA, the standardized version of the Falcon signature scheme, is expected in early 2026, with a final version targeted for 2027, according to NIST’s own standardization tracker. None of this is finished business. Anyone migrating today is migrating toward a moving target, which is exactly why crypto-agility, the ability to swap algorithms without a full rewrite, matters as much as the algorithms themselves.
For federal systems, the FIPS 203 finalization started a compliance clock that agencies are still working through. Several federal contractors report internal migration deadlines landing well before the end of the decade to match procurement cycles and audit schedules. That pressure is what pushed OpenSSL, BoringSSL, and wolfSSL to prioritize ML-KEM support ahead of almost every other item on their respective roadmaps over the past two years.
Which Library Supports ML-KEM and ML-DSA Today
All three libraries now support ML-KEM in some form, but support means different things depending on which one a team picks. BoringSSL enables the hybrid group X25519MLKEM768, standardized through the IETF’s draft-ietf-tls-ecdhe-mlkem proposal, by default in current Chrome builds. That single decision explains why Cloudflare’s adoption numbers moved as fast as they did. When the world’s most-used browser flips a default, internet-wide statistics move right along with it.
OpenSSL added native ML-KEM and ML-DSA support starting with its 3.5 long-term support branch, removing the need for a third-party provider like the earlier Open Quantum Safe project that many teams used to bolt post-quantum algorithms onto older OpenSSL versions. That matters for anyone who spent 2023 and 2024 patching an OQS provider into their build pipeline by hand. Native support means one less external dependency to audit and keep current.
wolfSSL implements ML-KEM, ML-DSA, and SLH-DSA through its wolfCrypt module, and because the project targets embedded systems, it puts real engineering effort into shrinking the memory footprint of lattice-based math, which needs larger keys and ciphertexts than the elliptic-curve cryptography it replaces. That’s not a minor detail for a microcontroller with kilobytes of RAM rather than gigabytes.
The practical approach nearly everyone uses right now combines a classical algorithm with a post-quantum one instead of swapping one for the other outright. If ML-KEM turns out to hide an undiscovered flaw, the classical half of the pair still protects the connection. If the classical half falls to a quantum computer instead, ML-KEM covers it. Security teams researching the standards, including analysis from Palo Alto Networks, broadly agree this hybrid period will last years rather than months.
Post-Quantum Cryptography Beyond TLS: SSH, VPNs, and Code Signing
TLS gets most of the attention in this migration, but it isn’t the only protocol carrying classical cryptography that needs replacing. OpenSSH added a post-quantum hybrid key exchange method, sntrup761x25519-sha512, years before NIST finalized its standards, and current OpenSSH releases increasingly default to it whenever both endpoints support it. That means a large share of server-to-server administrative traffic already benefits from post-quantum protection, often without the operations team realizing it happened.
VPN protocols are moving slower. WireGuard’s core protocol hasn’t adopted a standardized post-quantum key exchange directly, so teams needing that protection today typically layer a separate post-quantum handshake on top of it. Projects like Rosenpass popularized exactly that approach, adding quantum resistance to WireGuard tunnels without waiting for the core protocol itself to change. IPsec implementations trail further behind, with vendor support for post-quantum IKEv2 extensions varying widely between firewall and VPN appliance makers.
Code signing carries its own migration timeline, and in one respect it’s more urgent than TLS. A signed software update can stay trusted for years after it ships, far longer than any single TLS session stays open. ML-DSA is the leading candidate to eventually replace RSA and ECDSA signatures on software packages, firmware images, and container artifacts, but tooling support across package managers and build systems remains uneven heading into the second half of 2026. Teams shipping long-lived firmware should treat signature algorithm migration as at least as urgent as the TLS handshake work, since a compromised signing key protecting decade-old firmware creates a far longer-lived problem than one intercepted session.
This is where the three-library comparison above extends past a single protocol. wolfSSL ships modules for wolfSSH and wolfBoot specifically because its embedded and automotive customers need post-quantum protection across SSH access and secure boot signing, not just TLS. OpenSSL’s broader ecosystem role means its ML-DSA support feeds into signing tools well beyond web servers. BoringSSL, true to its narrower mission, stays focused mostly on what Chrome and Android need, which is primarily TLS.
Performance Benchmarks: What Post-Quantum Key Exchange Actually Costs
Post-quantum key exchange isn’t free. ML-KEM keys and ciphertexts run larger than their elliptic-curve equivalents, and that size shows up as measurable latency. Chrome’s own reporting found roughly a 4 percent slowdown in handshake time after switching to hybrid key exchange, driven mostly by an extra 1.1 to 1.2 kilobytes added to the initial handshake payload, according to figures Cloudflare cited in its 2024 post-quantum report.
Independent academic measurements found a bigger relative gap at the connection-setup layer specifically. One study tracking the delay between a server’s SYN-ACK and the client’s TLS ClientHello found that delay grow from about 0.3 milliseconds with classical X25519 alone to somewhere between 1.8 and 1.9 milliseconds with the hybrid handshake, an increase of roughly 500 to 600 percent at that narrow layer. The delay between finishing the TLS handshake and the first application data arriving grew more modestly, from 0.526 milliseconds to somewhere between 0.897 and 1.004 milliseconds.
| Metric | Classical only (X25519/ECDHE) | Hybrid post-quantum (X25519+ML-KEM-768) | Change |
|---|---|---|---|
| Cloudflare TLS 1.3 PQC adoption, March 2024 | ~98% of connections | ~2% of connections | Baseline year |
| Cloudflare TLS 1.3 PQC adoption, late 2025 | ~50% (clients not yet supporting PQC) | ~50% of supporting clients | 25x growth in two years |
| Chrome handshake time | Baseline | +4% slower | +4% |
| TCP-to-TLS delay (academic benchmark) | ~0.3 ms | ~1.8-1.9 ms | +500-600% |
| TLS-to-application delay | 0.526 ms | 0.897-1.004 ms | +70-90% |
| ClientHello payload size | Baseline | +~1.5 KB | Larger handshake packet |
Read those percentages carefully. A 500 percent increase sounds alarming until you notice the baseline sits well under two milliseconds. For most applications, that overhead disappears inside ordinary network jitter. The bigger operational risk isn’t CPU time at all, it’s packet size: some older middleboxes and firewalls still choke on TLS ClientHello messages that exceed a single network packet, and the larger post-quantum payload pushes some handshakes past that line. That’s an infrastructure problem more than a cryptography problem, and it shows up more often on enterprise networks running older security appliances than on the open internet.
Licensing and Pricing: What You Actually Pay
License terms end up mattering as much as algorithm support once legal and procurement teams get involved in a post-quantum cryptography migration.
| Library | Open-source cost | Commercial license | FIPS validated module | Support |
|---|---|---|---|---|
| OpenSSL | Free (Apache License 2.0) | Not required, license already permits commercial use | Separate FIPS provider, free to use | Community, plus paid contracts via distro vendors |
| BoringSSL | Free (Google-maintained) | No formal commercial licensing offered | No official outside FIPS 140-3 validation | None official, use at your own risk |
| wolfSSL | Free under GPLv3 | Starts at $7,500 per end product or SKU | wolfCrypt FIPS 140-3 module, custom quote | Direct commercial support from wolfSSL |
OpenSSL costs nothing to use commercially, in any product, without asking permission, because the Apache License 2.0 permits that outright. BoringSSL costs nothing either, but Google offers no license grant for outside commercial support and openly discourages treating it as a dependency you can call a vendor about when something breaks. wolfSSL is the only one of the three built around a direct commercial relationship: pay $7,500 per end product or SKU and get unlimited royalty-free distribution plus a vendor who answers the phone, or stay on GPLv3 and accept that license’s copyleft terms, which can complicate embedding wolfSSL inside proprietary firmware a hardware vendor doesn’t want to open-source.
For a startup shipping a SaaS product, the OpenSSL math is simple: free, permissive, done. For a device manufacturer shipping firmware to a hundred thousand units, the GPLv3-versus-$7,500 decision becomes a real conversation with legal, because GPLv3 code embedded in a shipped product can trigger obligations to release source code that most hardware vendors would rather avoid. Consumer-facing encryption tools face a similar calculus, which is part of why password manager vendors weigh licensing as carefully as raw feature lists.
The Hidden Costs No Pricing Table Shows
The dollar figures in the pricing table above only tell part of the story. Migrating to post-quantum cryptography touches infrastructure that a license fee alone doesn’t cover.
- Certificate reissuance: every TLS certificate in an infrastructure eventually needs reissuing under an ML-DSA-capable certificate authority, and large enterprises can hold tens of thousands of certificates across internal and external services.
- Hardware security module upgrades: HSMs built around RSA and ECC key sizes don’t automatically handle the larger keys and ciphertexts that ML-KEM and ML-DSA produce, and older HSM hardware may need a firmware update or outright replacement.
- Load balancer and firewall tuning: the packet-size increases covered in the benchmark section above can trip up middleboxes never tuned for larger TLS handshakes, requiring configuration audits most teams haven’t budgeted time for.
- Monitoring and observability updates: teams need visibility into which connections are negotiating post-quantum key exchange and which are falling back to classical algorithms, which usually means updating logging and dashboards built around older TLS metadata.
- Engineering hours: none of this runs on autopilot. Teams further along in this migration consistently describe it as a multi-quarter project, not a weekend patch.
None of these costs show up on a vendor’s pricing page, and none of them care whether an organization picked OpenSSL, BoringSSL, or wolfSSL. They apply almost identically regardless of which library sits underneath the TLS stack, which is exactly why the library choice should get less attention in planning meetings than the operational rollout plan built around it.
Real-World Deployments: Who’s Running Post-Quantum Crypto Today
Post-quantum cryptography already runs in production well beyond test labs and RFC drafts. Here’s who is actually shipping it right now.
- Google Chrome and Android run on BoringSSL and enabled X25519MLKEM768 hybrid key exchange by default, the single biggest reason Cloudflare’s adoption numbers moved as fast as they did.
- Cloudflare’s edge network runs its own custom TLS stack rather than one of these three libraries directly, but it turned on hybrid post-quantum key exchange by default for customer connections, making it one of the largest real-world PQC deployments on the internet.
- AWS maintains aws-lc, an in-house cryptographic library forked from BoringSSL and OpenSSL, which underpins TLS termination inside services built on Amazon’s s2n-tls stack.
- Signal added PQXDH, a hybrid combining X25519 with CRYSTALS-Kyber, to its messaging protocol in September 2023, well ahead of NIST’s final standard, making it one of the earliest production post-quantum deployments outside a browser.
- Apple introduced PQ3, its own post-quantum protocol for iMessage, in February 2024, describing it as matching the strongest post-quantum messaging protections available at the time.
- wolfSSL’s commercial customers concentrate in embedded, automotive, and medical device manufacturers that need FIPS 140-3 validated cryptography inside real-time operating systems, environments where OpenSSL’s larger footprint fits less comfortably.
- The certificate authority ecosystem is already planning ahead. Discussion threads like Let’s Encrypt’s own community roadmap request show CAs actively working through how ML-DSA certificate chains will interact with existing public key infrastructure.
Why Enterprise Migration Still Lags Behind the Standards
Despite two years of finalized standards and rising browser-driven adoption, most enterprises haven’t started migrating in any serious way. Analyst firms including Gartner have said publicly that quantum computing now ranks among the biggest threats to current encryption, even as security budgets keep flowing toward more immediate priorities like AI-driven attack detection and identity security. The gap between awareness and action is wide, and it shows up clearly in survey data circulating across the industry heading into 2026.
One industry roundup found that while roughly half of enterprises had adopted managed detection and response services by 2025, only a small fraction had begun any formal post-quantum migration planning. That gap tracks with how most security teams triage work: fix what’s actively being exploited before preparing for a threat that hasn’t fully arrived yet. That logic makes sense on a quarterly budget cycle. It makes less sense against a threat model where the data stolen today, not tomorrow, is what a future quantum computer would decrypt.
The stakes get concrete fastest in industries holding data with long shelf lives. SentinelOne’s 2026 cybersecurity trends analysis puts the average healthcare data breach cost between 2022 and 2024 at $9.77 million, and patient records carry confidentiality requirements that outlast almost any other data category an enterprise holds. A hospital system that waits until the end of the decade to start a post-quantum migration is choosing to leave years of patient data exposed to harvest-now, decrypt-later collection in the meantime, whether or not that decision ever gets made explicitly.
None of the three libraries compared in this piece can fix an organizational prioritization problem on their own. OpenSSL, BoringSSL, and wolfSSL all shipped working ML-KEM support well before most enterprises had a migration plan ready to use it. The bottleneck heading into the second half of 2026 isn’t the cryptography. It’s the budget line.
Cloudflare’s Adoption Data: From 2% to 50% in Two Years
No single data set tells this story better than Cloudflare’s own numbers, because the company sits in front of a meaningful share of global web traffic and publishes what it observes. In March 2024, barely two percent of TLS 1.3 connections used post-quantum key exchange, and Chrome, then rolling out hybrid support to roughly 10 percent of its users, accounted for over 99 percent of that traffic.
By the time Cloudflare published its 2025 follow-up report, adoption had reached roughly 50 percent of requests where the connecting client supported post-quantum key exchange at all. That’s not 50 percent of all internet traffic, a distinction worth keeping separate, but among clients capable of doing it, half now do. Cloudflare’s own documentation confirms the company enabled post-quantum key agreement by default across its network specifically to defend against harvest-now, decrypt-later collection.
The lesson for anyone planning a migration: browser and CDN defaults move the needle faster than any amount of internal advocacy ever will. Teams waiting for a mandate before testing hybrid key exchange on their own infrastructure should check their logs first. The traffic hitting their servers may already be using post-quantum cryptography, whether or not the origin servers on the other end are ready to negotiate it.
Migrating from Classical to Post-Quantum TLS: A Practical Guide
Here’s a realistic sequence for teams starting this migration in the second half of 2026.
- Run a cryptographic asset inventory first. Find every place your systems terminate TLS, sign certificates, or store long-lived encrypted data, before touching any code.
- Check your current library version. Anyone running OpenSSL older than 3.5, wolfSSL older than 5.8, or a BoringSSL snapshot from before 2024 won’t have native ML-KEM support yet.
- Test hybrid key exchange in a staging environment first. Enable X25519MLKEM768 alongside existing curves rather than replacing them outright, so classical clients keep negotiating normally.
- Confirm your certificate authority’s roadmap for ML-DSA-signed certificates before committing to a signature algorithm, since your server certificate chain needs to match what your library and your clients can verify.
- Watch for handshake failures tied to packet size, not just outright rejections. Some failures show up as timeouts on networks with strict MTU limits rather than clean error messages.
- Roll out gradually, region by region or service by service, and monitor CPU load and handshake latency against the benchmark numbers above.
- Plan for another algorithm change down the road. HQC, and eventually FN-DSA, are still headed toward finalization, so whatever ships in 2026 needs a path to swap algorithms again without a full rewrite.
Testing a server’s post-quantum support doesn’t require exotic tooling. A single OpenSSL command line reveals whether a target host negotiates the hybrid group:
openssl s_client -groups X25519MLKEM768 -connect example.com:443A successful negotiation shows X25519MLKEM768 in the connection’s negotiated group output. A fallback to a classical curve like X25519 alone means the server, the client, or both still need an upgrade before hybrid post-quantum protection takes effect on that connection.
Pros and Cons of OpenSSL, BoringSSL, and wolfSSL
Every library involves a trade-off, and post-quantum support doesn’t erase the strengths and weaknesses each project already carried before ML-KEM existed. Here’s how the three stack up once the marketing gets stripped away.
OpenSSL
Pros: broadest platform and package-manager support, a permissive Apache 2.0 license, an actively maintained FIPS 140-3 validated provider, and predictable long-term support branches.
Cons: its general-purpose design means a larger codebase to audit, it carries the historical baggage of high-profile vulnerabilities like Heartbleed, and it typically adopts bleeding-edge features slower than BoringSSL does.
BoringSSL
Pros: the fastest-moving post-quantum feature adoption of the three, battle-tested at Google’s scale inside Chrome and Android, and less legacy cruft than OpenSSL carries.
Cons: no official versioning or stable API for outside consumers, explicit Google guidance against third-party production dependence, and no formal support channel or outside FIPS validation path.
wolfSSL
Pros: a small footprint built for embedded and real-time systems, direct commercial support backed by a validated FIPS 140-3 module, and dual licensing that gives flexibility to both open-source and proprietary projects.
Cons: GPLv3 obligations can complicate proprietary firmware distribution, commercial licensing adds real cost per product or SKU, and its community and ecosystem run smaller than OpenSSL’s.
Best Use Cases: Which Library Fits Your Team
- General-purpose web services and SaaS platforms: OpenSSL 3.5 LTS or 4.0 covers nearly every case without licensing friction.
- Federal contractors and regulated industries: whichever library has completed FIPS 140-3 validation for the exact ML-KEM parameter set a compliance framework requires, today that means OpenSSL’s FIPS provider or wolfSSL’s wolfCrypt FIPS module.
- Embedded, automotive, and medical devices: wolfSSL, built specifically for constrained memory and real-time operating systems.
- Teams already standardized on AWS infrastructure: aws-lc and s2n-tls rather than bolting on a separate library by hand.
- Browser-scale consumer infrastructure operators: BoringSSL, but only with the internal engineering capacity Google has to maintain a library that carries no external support contract.
- Startups with no exotic compliance requirements: default to OpenSSL and revisit the decision only if a specific customer contract demands otherwise.
- Hardware vendors needing to avoid GPL obligations: wolfSSL’s commercial license, budgeted at $7,500 or more per SKU, rather than the free GPLv3 tier.
Common Post-Quantum Migration Pitfalls
A handful of mistakes show up repeatedly in early post-quantum cryptography rollouts.
- Treating key exchange as the whole migration. ML-KEM protects the handshake, but certificates still need ML-DSA or SLH-DSA signatures eventually, and most certificate authorities haven’t finished that rollout yet.
- Ignoring packet fragmentation. The larger ClientHello and ServerHello messages that hybrid key exchange produces can exceed what older load balancers, firewalls, or corporate proxies expect, which causes silent connection failures instead of clean errors. Teams that already track firewall and edge-device vulnerabilities closely tend to catch this faster than teams that don’t.
- Hardcoding a single algorithm. HQC exists specifically because NIST wants a backup if lattice-based math turns out to hide a flaw nobody’s found yet. A migration that can’t swap algorithms quickly repeats the exact mistake that made this migration necessary in the first place.
- Skipping load testing. The overhead numbers in the benchmark table above look small individually, but they compound at scale across millions of daily handshakes.
- Assuming universal client support. Not every browser, mobile OS, or legacy client library supports hybrid key exchange yet, so servers need to keep negotiating classical algorithms as a fallback for years, not months.
- Forgetting internal traffic. Teams often focus migration effort entirely on public-facing endpoints while leaving service-to-service traffic inside a data center running classical algorithms untouched, even though internal traffic can carry data just as sensitive as anything crossing the public internet.
The Verdict: Which Should You Choose in 2026
Strip away the marketing and the decision comes down to three questions: what’s the compliance requirement, what’s the hardware budget, and who gets a call when something breaks.
If the answer is “we run standard web infrastructure with no exotic compliance mandate,” OpenSSL 3.5 LTS or 4.0 wins by default. It costs nothing, ships in every major Linux distribution, supports ML-KEM and ML-DSA natively, and comes with an established FIPS 140-3 validation path for later if it’s ever needed. That’s not an exciting verdict, but it’s the correct one for the overwhelming majority of teams reading this comparison.
Teams building embedded, automotive, or medical hardware should treat wolfSSL’s $7,500-per-SKU commercial license as worth the cost. The footprint savings and the direct support relationship pay for themselves the first time a device certification deadline is on the line, and the GPLv3 alternative rarely fits proprietary firmware anyway.
BoringSSL deserves credit as the library setting the pace, since Chrome’s default rollout is the single biggest reason Cloudflare’s adoption numbers moved from 2 percent to roughly 50 percent in under two years. But it’s not a library most outside teams should adopt directly. Google built it to serve Google, and the company says so itself. Treat it as a preview of where the field is headed, not as a dependency inside your own stack.
The decision that matters more than picking a library: start testing hybrid key exchange now, on whichever library is already running, because the compliance deadline isn’t the real deadline. The real deadline arrives whenever a sufficiently capable quantum computer does, and encrypted traffic collected today under classical algorithms alone is already exposed to that future, regardless of when it lands.
None of that requires a perfect plan on day one. It requires a first step: pull the version numbers on whatever’s terminating TLS today, check that version against the specs table above, and open a ticket. The libraries are ready. Cloudflare’s own network already proved the internet at large can absorb this transition without breaking. The only variable left is how long any individual team waits before starting.
Frequently Asked Questions
What is post-quantum cryptography?
Post-quantum cryptography refers to encryption and signature algorithms designed to resist attacks from both classical and quantum computers, unlike RSA or elliptic-curve cryptography, which a sufficiently powerful quantum computer running Shor’s algorithm could eventually break.
Do I need to migrate to post-quantum cryptography right now?
Most organizations don’t face an immediate deadline, but any data that needs to stay confidential for years, health records, trade secrets, government files, is already vulnerable to harvest-now, decrypt-later collection. Security teams handling that kind of data are migrating now rather than waiting for a mandate.
What’s the difference between ML-KEM, ML-DSA, and SLH-DSA?
ML-KEM (FIPS 203) handles key exchange, ML-DSA (FIPS 204) handles digital signatures using lattice-based math, and SLH-DSA (FIPS 205) is a more conservative hash-based signature scheme kept as a backup in case lattice-based cryptography is ever broken.
Is BoringSSL safe to use in my own product?
Technically yes, but Google explicitly advises against it. The library has no versioned releases, no guaranteed API stability, and no formal support channel for outside users, which makes it a poor fit for anyone who isn’t Google itself.
How much does wolfSSL’s commercial license cost?
wolfSSL’s commercial license starts at $7,500 per end product or SKU, which includes unlimited royalty-free distribution rights for that specific product, according to the company’s own licensing page.
Does post-quantum cryptography slow down my website?
Slightly. Chrome’s own data shows roughly a 4 percent increase in TLS handshake time, and independent benchmarks show low-single-digit-millisecond increases at the connection-setup layer, overhead that stays unnoticeable for most applications.
Which library should a small startup use?
OpenSSL, in almost every case. It’s free, it’s the default across nearly every Linux distribution and package manager, and its 3.5 LTS branch already supports ML-KEM and ML-DSA natively without extra providers.
What happens if my TLS library doesn’t support post-quantum algorithms yet?
Classical connections still work today and will for years to come, but any traffic that can’t be upgraded stays exposed to future decryption once quantum computers catch up. An upgrade path, even a gradual one, matters more than an immediate switch.
Can I mix and match, using OpenSSL on some servers and wolfSSL on others?
Yes, and many organizations already do. TLS negotiation happens per connection, not per organization, so a server running wolfSSL and a server running OpenSSL can both negotiate the same X25519MLKEM768 hybrid group with a compatible client without any special coordination between the two systems.
Will HQC or FN-DSA replace ML-KEM and ML-DSA?
Not likely as a full replacement. HQC, selected by NIST in March 2025, is designed as a backup key encapsulation method built on different math from ML-KEM, for use if a weakness is ever found in lattice-based cryptography. FN-DSA, expected to reach a final standard around 2027, is positioned as an additional signature option rather than a successor to ML-DSA. Expect libraries to support multiple algorithms side by side rather than deprecating ML-KEM or ML-DSA outright.
Related Coverage
- Cisco SD-WAN: 7 Zero-Days, 2 at CVSS 10 [2026]
- SharePoint RCE Exploited: CVSS 8.8, July 4 Deadline [2026]
- New CitrixBleed Flaw: NetScaler Hit in 24 Hours [2026]
- FortiBleed Cracks 86,644 Fortinet Firewalls [2026]
- Proton Pass vs Bitwarden vs 1Password: $0 vs $48 [2026]
- CrowdSec: Block Malicious IPs in 12 Steps, 40 Min [2026]
- More cybersecurity coverage on the Cybersecurity Threats 2026 hub
