State of the post-quantum Internet in 2025

The quantum threat, quantified

Quantum computers exploit superposition, interference and entanglement to tackle computations that are essentially impossible for classical machines. Their most consequential real-world application, however, is a destructive one: they are exceptionally good at breaking the RSA and elliptic-curve cryptography that still protects the vast majority of Internet traffic.

These are not general-purpose replacements for classical computers. They are specialized accelerators, better understood by analogy to GPUs or neural engines. That specialization is exactly what makes them dangerous for public-key cryptography, and it is why the industry is migrating to post-quantum algorithms designed to resist quantum attacks.

Today's quantum hardware remains far too weak to crack real keys. The largest number factored by a quantum computer without shortcuts is still 15. But that fact invites complacency, and complacency is the real risk here: conservative estimates place Q-day — the moment quantum computers can break RSA-2048 — less than three years after quantum machines first surpass classical ones at factoring. And encrypted traffic harvested today can simply be stored and decrypted later. This harvest-now/decrypt-later threat is why the migration cannot wait for the hardware to mature.

Hardware: more than qubit counts

Measuring quantum progress by qubit count is misleading. Quantum computers are analogue devices, and their qubits suffer from noise. Different physical approaches make different tradeoffs. Silicon-based machines scale well and execute quickly but have noisy qubits; quantum error correction can turn millions of those into a few thousand usable ones. Trapped-ion systems are far quieter but harder to scale. The engineering path matters as much as the raw numbers.

That context explains why the widely publicized progress graphs have looked flat for two years while experts saw something genuinely important. Google's December 2024 Willow announcement was unremarkable on those graphs, but it achieved the first scalable logical qubit in the surface code — a real milestone. As researcher Samuel Jaques put it, the result provoked "chills of 'Oh wow, quantum computing is actually real'," while also noting that "this is more or less where we should expect to be, and maybe a bit late."

Other architectures remain in play. Microsoft's Majorana 1 chip, announced in early 2025, sketches a roadmap for topological qubits that would be far less noise-sensitive — but it does not yet support computation at all, and it is not even clear such qubits can be built at scale. Between these extremes, labs are pursuing neutral atoms, trapped ions and other intermediate approaches.

Software: the bigger leap

The most significant advance of the past two years was not in hardware at all. In June 2025, Craig Gidney published a detailed paper showing that clever software optimisations could break RSA-2048 with fewer than one million superconducting qubits, rather than the roughly 20 million previously thought necessary. The red lines on quantum-computing projections shifted sharply leftward. If one grants an optimistic Moore's-law-style doubling of physical qubits every eighteen months, Gidney's work moved Q-day seven years closer — from 2052 to roughly 2045.

How much further can such optimisations go? Jaques considers anything below 100,000 superconducting qubits implausible and estimates at least 242,000 would be required. At the assumed growth rate, that points to Q-day landing between 2039 and 2041. These are educated guesses, and the estimates could be off in either direction.

There is also the possibility of wholly new quantum algorithms. In April 2024, Yilei Chen published a preprint describing an algorithm for certain lattice problems related to — but not identical with — those underlying deployed post-quantum cryptography. The field braced for the worst: Chen's construction was far more complex than Shor's algorithm, and it took experts time to identify its limitations. Within ten days, they found a fundamental bug. The approach does not work, and the crisis passed.

The episode offers two lessons. Optimistically, it is routine cryptanalytic progress: one avenue of attack on lattice problems turned out to be a dead end, leaving those schemes in better shape for having been examined. Realistically, it is a reminder that the post-quantum ecosystem relies heavily on lattices today. There is no drop-in alternative that works everywhere. Quantum key distribution is sometimes proposed as a solution, but it cannot scale beyond point-to-point links and does not address the fundamental need for public-key cryptography that travels with data.

Speculation about unknown future algorithms is useful, but it should not distract from the certain threat already on the table. Quantum computers will break RSA and elliptic-curve cryptography; the only open question is when. The first line of defense is deploying post-quantum algorithms now, before the hardware catches up.

Expert timelines versus regulator deadlines

For years, the refrain has been that "Q-day is X years away," with X shifting as the years pass. That makes it tempting to treat the threat as perpetually distant. The Global Risk Institute's annual expert surveys offer a more grounded picture. In its 2024 report—conducted before Google's Willow chip and Gidney's recent cost breakthrough—interviewees were asked how likely it is that RSA-2048 will fall within 5, 10, 15, 20, or 30 years.

The middle column of that chart is revealing: well over half of the experts surveyed assigned at least a ~50% probability to RSA-2048 being broken within 15 years. Comparing the institute's year-over-year data from 2019 through 2024 shows a slow but steady drift toward greater certainty. Yet there is an apparent contradiction in the answers. When experts are asked about a 15-year horizon, their estimates barely move year to year. But if you instead ask when they expect Q-day with high confidence (say, >70% probability), their answers become largely consistent. For example, roughly one-fifth of experts pointed to 2034 with that level of certainty in both the 2019 and 2024 surveys.

The honest takeaway is that no one knows the date for sure; there are too many unknowns. What matters more than expert guesswork is the calendar set by regulators. The NSA's CNSA 2.0 guidelines, published in 2022, mandate migration to post-quantum cryptography between 2030 and 2033. The US federal government set 2035 as its full-migration target that same year, a deadline the current administration has not altered. Australia moved faster, adopting 2030 as its deadline in 2024. The UK's NCSC settled on 2035 in early 2025, and the European Union published its roadmap in mid-2025 with both 2030 and 2035 deadlines depending on the application. Not every national regulator has published timelines, but those that have predominantly fall in the 2030–2035 window.

Whether the actual Q-day lands in 2034 or 2050, it will almost certainly arrive too soon. Fifty years of cryptographic success means the technology is embedded everywhere—from dishwashers to pacemakers to satellites. Most upgrades will fit naturally into product lifecycles, but a long tail of difficult and costly migrations will remain.

Two distinct migrations, two different urgencies

To prioritize correctly, it helps to recognize that the post-quantum transition is not a single task but two: key agreement and signatures/certificates. They differ greatly in difficulty, impact, and urgency. Consider what happens when a browser establishes a secure connection to a website.

Symmetric cryptography is already safe

The workhorse of any secure connection is a symmetric cipher like AES-GCM. Both parties share a key and use it to encrypt and decrypt messages. What often gets overlooked is that symmetric ciphers are already post-quantum secure. The common advice to double symmetric key lengths due to Grover's algorithm is based on a misconception—on closer inspection, Grover's attack is not practical in real-world use. NIST's own security-level definitions make this clear: each level specifies that a scheme should be as hard to break, classically or quantumly, as an existing symmetric cipher.

The instinct behind recommending AES-256 everywhere is understandable. Doubling symmetric key sizes is cheap, and it eliminates any theoretical risk. But if you insist on AES-256, consistency demands NIST PQC level 5 for public-key cryptography as well—and that's where the advice falls apart. Public-key schemes do not scale gracefully. Moving from level 1 to level 5 typically more than doubles data usage and CPU cost. Since post-quantum signatures at level 1 are already painful to deploy, level 5 would be debilitating. More importantly, organizations have finite resources; prioritizing a marginal upgrade to AES-128 over replacing definitively vulnerable RSA would be a strategic mistake.

Key agreement: urgent but tractable

Symmetric ciphers require a shared secret, and the browser cannot simply transmit one—any eavesdropper would see it. Key agreement mechanisms solve this with clever mathematics in the TLS handshake. As of 2024, nearly all traffic uses X25519, a Diffie–Hellman-style scheme that Shor's algorithm breaks completely on a quantum computer. Any Diffie–Hellman-secured communication recorded today can be decrypted retroactively once a sufficiently powerful quantum computer exists.

This is why upgrading key agreement is urgent: the data is at risk today, even if the decryption happens later. The good news is that post-quantum key agreement is relatively straightforward to deploy. By the end of 2025, Cloudflare was already securing half its requests with post-quantum key agreement.

Signatures and certificates: less urgent, far harder

Key agreement ensures that the browser and server share a secret, but not with whom they agreed. Without authentication, an attacker in the middle could perform separate key agreements with each party and re-encrypt the traffic. Authentication is provided by signatures. When a browser visits cloudflare.com, the server presents a certificate signed by a certification authority, and the server signs the handshake and shared key with the private key matching that certificate. RSA and ECDSA currently serve this role—and Shor's algorithm destroys both, enabling a quantum attacker to forge any signature and impersonate any site accepting non-post-quantum certificates.

Unlike the key-agreement threat, this attack only works after quantum computers can break RSA or ECDSA in practice. On the surface, that makes migrating signatures less urgent—the work just needs to be done before Q-day. The catch is that migrating to post-quantum signatures is much more difficult and will take considerably longer.

How post-quantum cryptography became an Internet priority

Quantum computing's theoretical foundation was laid around 1980, when Feynman and Manin independently proposed the concept. Fourteen years later, Shor published his algorithm demonstrating that a sufficiently powerful quantum computer could break RSA and elliptic-curve cryptography. Yet most of what we now call post-quantum cryptography predates Shor's work entirely.

The main branches of post-quantum cryptography — lattice-based, hash-based, multivariate, code-based, and isogeny-based — were not originally conceived as quantum-resistant. Code-based and hash-based schemes emerged in the 1970s as contemporaries of RSA. The first multivariate scheme appeared in 1988. Only isogeny-based cryptography was developed specifically with Shor's algorithm in mind. Interestingly, the most successful branch today, lattice-based cryptography, was proposed in 1996, making it Shor's closest contemporary. For perspective, elliptic curve cryptography — the backbone of current Internet security — was first proposed in 1985.

After Shor's publication, cryptographers began reassessing existing schemes to determine what was genuinely broken and what could survive a quantum adversary. The first annual International Workshop on Post-Quantum Cryptography took place in 2006, and an introductory text from that conference remains a reasonable field overview today, with a notable caveat: the Rainbow signature scheme, once a leading multivariate candidate, has since been broken. In that same year, X25519 was proposed; it now secures the majority of Internet connections, either alone or as a hybrid with the post-quantum ML-KEM-768.

NIST's standardization effort

In 2016, NIST launched a public competition to standardize post-quantum cryptography, following the open format used for AES in 2001 and SHA3 in 2012. The field drew 82 submissions, which were narrowed over three rounds to eight finalists. In 2022, NIST selected four for standardization: one KEM and three signature schemes.

The first three final standards were published in August 2024. FN-DSA remains unfinished, a point we will return to.

ML-KEM is the only standardized post-quantum key agreement mechanism. Despite occasional difficulties with its larger key sizes, it functions mostly as a drop-in upgrade.

Signatures present a different challenge. That NIST moved to standardize three simultaneously — with more planned — reflects that none of the proposed schemes is close to ideal. They all produce significantly larger keys and signatures than traditional alternatives.

From a security perspective, SLH-DSA is the most conservative choice though the worst performer. FN-DSA offers the smallest keys and signatures among the three, but implementing signing safely is hard due to floating-point arithmetic. Because of FN-DSA's limited applicability and design complexity, NIST prioritized the other three schemes first. That leaves ML-DSA as the default selection. Detailed comparisons appear below.

Protocol-level integration lags behind the standards

NIST's standards alone are insufficient. Higher-level protocols must also standardize how these algorithms are used. In cases like TLS key agreement, this can be as simple as assigning identifiers. For others, such as DNSSEC, it requires more careful design. Many IETF working groups prepared well before NIST's final standards arrived, expecting integrations to conclude by the end of 2024. That projection proved optimistic: some work is done, much is not.

Starting with what is finished:

• The hybrid TLS key agreement X25519MLKEM768, combining X25519 and ML-KEM-768, is ready and widely deployed. IPsec is similarly adopting ML-KEM in hybrid mode, ready for simple setups. Certain configurations have a downgrade-prevention wrinkle still being worked out.
• For signatures, ML-DSA integration in X.509 certificates and TLS is complete. The X.509 work recently became an RFC; TLS integration does not require one.

It may surprise some that the corresponding RFCs are not yet published. Registering a key agreement for TLS or IPsec does not require an RFC. The RFCs are still being pursued to avoid confusion and, in TLS's case, to mark the key agreement as recommended.

The less encouraging news: as of October 2025, the IETF has not finalized how to construct hybrid certificates — certificates combining a post-quantum and a traditional signature scheme. The work is close, and we expect resolution in early 2026.

If these integrations involve only assigning identifiers, why the delay? The answer is largely about making choices.

The ML-DSA debates: prehashing and private key formats

Two topics dominated discussions on ML-DSA certificates: prehashing and private key format.

Prehashing lets one component of the system hash a message while another component produces the final signature. This is valuable when a large file must not be sent to an HSM for signing. Early ML-DSA drafts supported prehashing with SHAKE256, but that choice was not obvious. NIST's final standard includes two variants: regular ML-DSA and an explicitly prehashed version allowing any hash function. Having multiple variants forces users to choose, creates support fragmentation, and multiplies testing and validation work. Most agree on picking only one, but there is no consensus on which. After significant debate, regular ML-DSA won out.

The second issue was private key format. The original ML-DSA submission cached computation in the private key for better benchmark performance. That made keys several kilobytes larger than necessary and introduced additional validation steps. Some proposed reducing the private key to a bare 32-byte seed. NIST's final standard permits both formats, which is far from ideal — a single choice is preferred. The IETF could not settle on one and added a third option: storing both the seed and expanded private key. Technically, almost everyone agreed the seed alone is superior, but some vendors had already generated keys without preserving the seed. Post-quantum legacy, already. Resolving these two questions took nearly a year.

Hybrid signatures multiply the decision space

Defining a hybrid ML-DSA signature scheme introduces many more questions. Which traditional scheme should pair with ML-DSA? What security levels should each side use? Within each component scheme, what private key format and hash function? Hybrids also pose new problems: may keys be reused across the hybrid and its components, and can stripping attacks be prevented? Prehashing reappears with a third level — applying the prehash at the hybrid level.

The October 2025 draft of ML-DSA hybrid signatures specifies 18 variants, down from 26 a year earlier. Everyone agrees that is still too many, but reducing further has proved difficult. A recommended list was added to help end-users choose; it started at three options and has itself grown to six. Among those, we expect MLDSA44-ECDSA-P256-SHA256 to see broad support and adoption across the Internet.

With key agreement, however, the standards are settled — and we now turn back to that topic.

Post-quantum key agreement reaches the TLS stack

Software support has followed the standardization effort, though not every ecosystem moves at the same speed. Recent versions of all major browsers, along with many TLS libraries and platforms — including OpenSSL, Go, and recent Apple OSes — have enabled X25519MLKEM768 by default, addressing the store-now/decrypt-later threat.

For TLS, the distinction between key agreement and signatures matters. In key agreement, server and client can enable post-quantum support independently; once both sides support it, negotiation uses the post-quantum scheme. A product that relies on TLS can often close its store-now/decrypt-later exposure with a simple TLS library update.

Post-quantum TLS certificates are a different matter. Unless you control both endpoints, you need two certificates: one post-quantum for new clients, one traditional for legacy clients. TLS lets clients signal supported signature schemes, so a server can serve a post-quantum certificate only to clients that accept it. Most TLS libraries support multiple certificates, but not all servers expose that configuration, and most deployments require a configuration change.

Certificate Authorities face their own timeline. Their hardware security modules need hardware-level post-quantum support, followed by audits, and the CA/Browser Forum must approve the new algorithms. Root programs disagree on timing. One root program is reportedly preparing a pilot to accept one-year ML-DSA-87 certificates, possibly before the end of 2025, and a CA/Browser Forum ballot is being drafted to support that. Chrome, meanwhile, prefers to solve the large certificate issue first. Audits will likely bottleneck early movers, given the volume of submissions expected after NIST publication. First post-quantum certificates should appear in 2026, but broad availability and universal browser trust is unlikely before 2027.

The result is an in-between period: much Internet traffic is protected by post-quantum key agreement, while no public post-quantum certificate is yet in use.

NIST's ongoing post-quantum competitions

NIST continues to standardize post-quantum cryptography through two additional competitions: round 4, for a backup KEM, and the signatures onramp.

HQC wins the backup KEM slot

NIST standardized only ML-KEM as a post-quantum key agreement scheme and wants a second, non-lattice-based option as a hedge. In March 2025, NIST selected HQC from the round 4 finalists.

HQC underperforms ML-KEM on every metric. The lowest security variant, HQC-1, requires 7kB of data on the wire — nearly double the 3kB of ML-KEM-1024, the highest security variant. The CPU gap is similar, and HQC scales worse with security level: while ML-KEM-1024 costs about double ML-KEM-512, the highest HQC security level requires three times the data (21kB) and more than four times the compute.

On security, ML-KEM-768 offers better performance and a larger security margin at level 3 than HQC-1 at level 1. Both schemes share similar algebraic structures over lattices and codes respectively, so a breakthrough against one structure could conceivably affect the other. Codes and lattices feel related even without that algebraic connection. RSA and ECC, which are more dissimilar, are both broken by quantum computers.

HQC may still offer peace of mind as a backup. During the brief period of uncertainty over Chen's quantum algorithm against lattices, replacing ML-KEM was considered — HQC was an option, but an adjusted ML-KEM variant would still have been far more performant.

The search for a second efficient KEM is itself a luxury. A better signature scheme would be far more valuable than a better KEM.

Signatures onramp: still years from standardization

In late 2022, after announcing its first four algorithm picks, NIST opened the "signatures onramp" competition for additional signature schemes. The goals: hedge against cryptanalytic advances against lattice-based signatures, and find schemes that outperform SLH-DSA in size and compute without relying on lattices.

NIST received 40 submissions in July 2023. The community broke many quickly — by February 2024, ten were completely broken and several others severely weakened. In October 2024, NIST selected 14 submissions for the second round.

Progress on post-quantum signatures has been substantial, but standardization remains distant. None of these onramp schemes is likely to be standardized before 2028, assuming they survive scrutiny. As Eric Rescorla, editor of TLS 1.3, put it: "You go to war with the algorithms you have, not the ones you wish you had."

ML-KEM in the real world

The widely deployed X25519MLKEM768 deserves closer scrutiny.

ML-KEM was submitted to NIST as CRYSTALS-Kyber. Despite being a US standard, its designers span industry and academia across France, Switzerland, the Netherlands, Belgium, Germany, Canada, China, and the United States.

ML-KEM versus X25519

Most clients currently use the traditional X25519 key agreement.

^{Size and CPU compared between X25519 and ML-KEM. Performance varies considerably by hardware platform and implementation constraints, and should be taken as a rough indication only.}

ML-KEM-512, -768 and -1024 aim to match AES-128, -192, and -256 resistance against quantum attacks, respectively. Even at the AES-128 level, ML-KEM is far larger than X25519: 800+768=1,568 bytes over the wire versus X25519's 64 bytes. However, ML-KEM-1024 is typically significantly faster than X25519, depending on platform and implementation.

Why deploy X25519MLKEM768?

Early adopters, including Cloudflare, favor a hybrid approach combining X25519 and ML-KEM-768. This may raise two questions.

1. Why combine X25519 (128-bit security) with ML-KEM-768 (192-bit security)?
2. Why include the non-post-quantum X25519 at all?

The apparent mismatch is a hedge against improved cryptanalysis of lattice-based schemes. X25519's security, matching AES-128, is trusted and sufficient. While ML-KEM-512 is comfortable today, cryptanalysis could improve over decades, so keeping a margin makes sense.

X25519 serves two purposes in the hybrid. First, if a breakthrough defeats all ML-KEM variants, X25519 still provides pre-quantum security — the post-quantum migration doesn't make things worse. Second, and more importantly, implementation attacks are a concern, not just algorithm attacks. The KyberSlash timing attack affected many Kyber implementations, including Cloudflare's own, though not Kyber as used in TLS. An implementation flaw affecting TLS would likely require an active attacker aiming not to decrypt data years later, but to steal a cookie or inject a payload. X25519 prevents such attacks.

Performance and protocol ossification

Google began post-quantum experiments in 2016, the same year NIST opened its competition. A larger joint Cloudflare and Google experiment in 2018 tested two hybrid schemes: CECPQ2 (NTRU-HRSS combined with X25519) and CECPQ2b (SIKE combined with X25519). NTRU-HRSS is similar in size to ML-KEM but more computationally taxing on clients. SIKE has very small keys but is computationally expensive and was completely broken in 2022. X25519+NTRU-HRSS handshake performance was very good.

A small but significant fraction of clients, however, experienced broken connections with NTRU-HRSS. The cause was keyshare size. The client's first TLS message, the ClientHello, almost always previously fit in a single network packet. The TLS specification allows larger messages, but middleboxes, load-balancers, and other software tacitly assume the ClientHello stays within one packet — protocol ossification striking again.

The server-side picture

Browsers are only half of the equation. Server support has been ramping up as well. Cloudflare enabled post-quantum key agreement for essentially all customers back in 2022, and Google followed for most of its servers (excluding GCP) in 2023. Since then, adoption has grown steadily. Jan Schaumann's regular scans of the top 100k domains show PQ support at 39% as of September 2025, up from 28% just six months earlier. His data reveals not only large service providers like Amazon, Fastly, Squarespace, Google, and Microsoft rolling out support, but also a growing number of self-hosted servers at Hetzner and OVHcloud.

That covers the publicly accessible web. What about servers sitting behind a service like Cloudflare?

Support at origins

Cloudflare added the option for customers to enable post-quantum key agreement on connections to their origins in September 2023, securing connection (3) in the following flow:

^{Typical connection flow when a visitor requests an uncached page.}

Back then, only 0.5% of origins supported post-quantum key agreement. Through 2024 that number barely moved. In 2025, however, support has begun to pick up as software updates roll out, and the figure now stands at 3.7%.

^{Fraction of origins that support the post-quantum key agreement X25519MLKEM768.}

That 3.7% looks weak next to the 50% for clients and 39% for public servers, but it's not a fair comparison. Origins are far more diverse than clients, with many more parties needing to act to move the number up. Still, it's a more than seven-fold increase, and it's worth remembering that just last year the industry celebrated reaching 1.8% client support.

For customers, origins aren't always easy to upgrade. That doesn't have to mean missing out on post-quantum security, though. Running a Cloudflare Tunnel as a sidecar to an origin secures the connection between Cloudflare and the origin.

Ossification concerns

Support is one thing, but protocol ossification — the same issue that plagued browser experiments — is a real concern with origins. There are two ways to enable post-quantum key agreement: the fast way, where post-quantum keys are sent immediately, and the slow but safer way, which postpones sending them by one roundtrip using HelloRetryRequest. All major browsers use the fast method. If an origin doesn't support post-quantum, both approaches fall back safely to traditional key agreement.

Regular scans of all origins show that every origin supports the safe, slower method. The fast method is another story: 0.05% of connections would break. That's too high to enable by default. Cloudflare has enabled the safer method by default for non-enterprise customers, with enterprise customers able to opt in.

The goal remains fast post-quantum for everyone by default. Cloudflare plans to automatically enable the fast method for all customers once scans confirm it's safe to do so.

Internal connections

So far, the focus has been on connections between Cloudflare and external parties. There are also many internal connections within Cloudflare (marked 2 in the diagrams above). A major push in 2023 to upgrade internal connections to post-quantum key agreement proved to be the biggest internal job yet: every engineering team had to stop, inventory the data and connections their products secure, and upgrade them. In most cases, the upgrade itself was trivial — many teams were already done after pulling in software updates. Figuring out that the work was already complete often took the longest.

The majority of internal connections are now upgraded, but a long tail remains. The most significant connection that didn't get upgraded in 2023 was between the WARP client and Cloudflare, which was finally addressed in September 2025 by moving from Wireguard to QUIC.

What's next

Post-quantum key agreement, despite early ossification troubles, has proven straightforward to deploy. In most cases, it's an uneventful software update. With 50% deployment and rising, it has become the new security baseline for the Internet.

The second migration — upgrading the signatures used on the Internet — is the harder problem.

The state of post-quantum signatures

A deep dive from November 2024 covered the field of post-quantum signature schemes in detail. Most of that analysis still holds, but there have been some notable developments. Here's a look at the available options at the AES-128 security level: ML-DSA-44, the two variants of SLH-DSA, plus FN-DSA-512 (which will be standardized soon) and a sample of nine promising onramp schemes. For reference, Ed25519 and RSA-2048, both in wide use today, are included as baselines.

^{Comparison of various signature schemes at the security level of AES-128. CPU times vary significantly by platform and implementation constraints and should be taken as a rough indication only. ⚠️ FN-DSA signing time when using fast but dangerous floating-point arithmetic — see warning below. ⚠️ SQISign signing is not timing side-channel secure.}

None of the post-quantum schemes is close to being a drop-in replacement for Ed25519 (comparable to ECDSA P-256), mostly because their signatures are far bigger. The exceptions from the onramp — SQISign, MAYO, SNOVA, and UOV — come with their own drawbacks: MAYO, SNOVA, and UOV have large public keys, while SQISign demands heavy computation.

FN-DSA's catch

Looking ahead, the best of the first competition appears to be FN-DSA-512. Its combined signature and public key size is just 1,563 bytes, with reasonable signing time. But FN-DSA has an achilles heel: acceptable signing performance requires fast floating-point arithmetic. Without it, signing is about 20 times slower. Worse, that floating-point arithmetic must run in constant time — otherwise, the private key can be recovered by timing signature creation. Writing safe FN-DSA implementations has proved challenging, making it risky when signatures are generated on the fly, as in a TLS handshake. This only affects signing; verification requires no floating-point arithmetic and has no private key to leak.

Signatures everywhere

The biggest difficulty in migrating the Internet to post-quantum signatures is the sheer number of signatures involved, even in a single connection. Visiting this website for the first time sends five signatures and two public keys.

The majority belong to the certificate chain: the CA signs the intermediate certificate, which signs the leaf certificate, which in turn signs the TLS transcript to prove server authenticity. That accounts for three signatures — leaving two more.

Those remaining two are SCTs required for certificate transparency. CT is a key but lesser-known part of the Web PKI ecosystem. Its purpose is to publicly log every issued certificate so misissuance can be detected after the fact. It powers sites like crt.sh and Cloudflare Radar, and it recently proved its worth again by surfacing a rogue certificate for 1.1.1.1.

CT works by having independent parties run CT logs. Before issuing a certificate, a CA must submit it to at least two different logs. An SCT is a log's signature, serving as a receipt proving the certificate has been logged.

Matching schemes to roles

Two aspects of how a signature is used matter for choosing a scheme: whether the public key is included with the signature, and whether the signature is created online or offline.

For SCTs and the root's signature on the intermediate, the public key is not transmitted during the handshake. That makes schemes with smaller signatures but larger public keys — such as MAYO, SNOVA, or UOV — particularly well-suited. For the other signatures where the public key travels along, minimizing the combined public key plus signature size is more important.

The handshake signature is the only one created online; all others are generated ahead of time. The handshake signature is created and verified just once per connection, while the other signatures are typically verified many times by different clients. For the handshake signature, balancing signing and verification time matters since both are in the hot path. For the rest, favoring faster verification at the cost of slower signing is the better trade-off — one advantage RSA still holds over elliptic curve signatures.

Mixing different signature schemes is an interesting puzzle, but it carries costs. Multiple schemes expand the attack surface, since a single algorithmic or implementation vulnerability can compromise the whole. The entire ecosystem also has to implement and optimize several algorithms, which is a considerable burden.

The Cost of Bigger Signatures

With today's draft standards, the choices for a post-quantum TLS upgrade are limited. Replacing the handshake signature with ML-DSA-44 adds roughly 15 kB of server-to-client data. That is a heavy toll for every connection. A future switch to FN-DSA-512 for all but the handshake signature would bring that down to about 7 kB, but that scheme is difficult to implement safely without leaking secrets through timing side channels. Stateful hash-based signatures offer a similar performance edge but carry their own implementation risks, as we have detailed previously.

What is Coming Next

The NIST onramp submissions include a few interesting candidates. SQISign I has the smallest signature of the bunch, even beating RSA-2048. The catch is performance: both signing and, crucially, verification are too slow for general use. The scheme is also complex to implement securely in constant time. Progress has been steady in simplifying the algorithm and speeding up verification, but SQISign is not ready for TLS adoption yet.

A more conservative candidate is UOV (unbalanced oil and vinegar), a multivariate scheme that has held up well despite decades of cryptanalysis. It offers tiny 96-byte signatures but a large 66.5 kB public key. Several attempts to shrink that key by adding structure (Rainbow, GeMMS) were broken dramatically. In 2025, a new "wedges" attack was found against UOV itself, though it barely affects UOV while hitting structured variants like SNOVA and MAYO harder. The attack is notable mainly because it relies on a simple idea that had been overlooked for years. Pairing UOV for the root and SCTs with ML-DSA-44 elsewhere would yield a handshake overhead of about 10 kB.

MAYO versus SNOVA

Among the newer multivariate entries, MAYO and SNOVA stand out for performance, though their fortunes have diverged over the past year.

MAYO lets you trade signature size against public key size. The proposed variants are MAYO_one (454-byte signatures, 1.4 kB public key) and MAYO_two (216-byte signatures, 4.3 kB public key). Verification is fast; signing is slower than ECDSA but far better than RSA. Combining the two variants gives a total overhead of 4.3 kB. Those numbers crept up slightly after the authors adjusted parameters in response to new attacks.

SNOVA has been hit harder by cryptanalysis. Its response was more aggressive: the designers not only tweaked parameters but also modified the scheme's internals to counter the attacks, which brought a performance improvement. Combining the SNOVA_(37,17,16,2) and SNOVA_(24,5,23,4) variants yields a total of just 2.1 kB of added handshake data.

The tradeoff is clear: SNOVA is much smaller but riskier, while MAYO is more conservative but larger. Both are too risky to deploy now — the recent wedges attack shows the field still yields surprises. Neither is likely to be standardized by 2029, so they cannot be part of the initial migration to post-quantum authentication.

Do Those Extra Bytes Actually Matter?

Cloudflare handles roughly 18 million new TLS connections per second. Upgrading all of them to ML-DSA-44 would consume about 2.1 Tbps, or 0.5% of total network capacity. That is a manageable cost in aggregate. The issue is how the added bytes affect individual connections, particularly those on slow or unreliable links. A 15 kB increase is trivial next to the JavaScript and images on a typical page, but it hits every TLS connection, including time-critical API calls. On a spotty cellular connection, the extra data can make the difference between a successful page load and a timeout.

Connection success is also a concern. Experiments from 2021 showed that some clients and middleboxes reject certificate chains larger than 10 kB. That undermines the "single-certificate" migration strategy, where a post-quantum certificate is embedded in a non-critical extension of a traditional certificate. Clients that ignore the extension would still break if the chain exceeds their limits, so that approach is a non-starter. There is also a steep performance drop at 10 kB due to the initial congestion window.

We measured the impact of a 9 kB certificate chain: TLS handshake time would increase by roughly 15%. We consider that workable but not ideal; it is noticeable enough that operators might postpone deployment. Chrome takes a stricter view, targeting no more than a 10% regression in handshake time, and reports that post-quantum key agreement alone (about 1.1 kB server-to-client and 1.2 kB client-to-server) has already incurred a 4% slowdown. That slowdown is proportionally larger than ours for 9 kB, likely due to slower upload speeds.

Some argue the focus on handshake time is misplaced. Session resumption can avoid sending certificates on subsequent connections, and data-heavy sites swamp the added bytes. Amazon researchers simulated data-heavy TLS connections in 2024 and concluded that for transfers of hundreds of kilobytes, the handshake overhead becomes negligible. But how typical are such connections?

Looking at QUIC connections with at least one HTTP request, 27% are resumptions that reuse key material from a previous TLS session. For non-resumed connections, the median server-to-client transfer is 8.1 kB, while the average is 583 kB. Only 15.5% of connections transfer more than 100 kB. A small number of data-heavy transfers skews the averages.

The median certificate chain today (with compression) is 3.2 kB. On more than half of non-resumed QUIC connections, certificates account for nearly 40% of all server-to-client bytes. Replacing the classical signatures with ML-DSA-44 would more than double the transmitted bytes on those connections. We will keep investigating how this translates to user-facing metrics like largest contentful paint and monthly data usage, but the initial picture shows that post-quantum certificates are a real cost for the majority of connections, not just a theoretical concern.

The Road Ahead for Post-Quantum Authentication

Migrating the Internet's authentication systems to post-quantum cryptography is a murkier path than key agreement. Performance remains the sticking point: unless it approaches today's TLS handshake speeds, most operators will simply leave post-quantum authentication off. Waiting until Q-day is imminent is risky—we may only discover the real-world problems after it is too late to fix them. The goal, therefore, is to make post-quantum authentication performant enough to enable by default.

Several ideas are being explored to slash the number of signatures involved, ordered by increasing ambition: dropping intermediate certificates, KEMTLS, and Merkle Tree Certificates (MTC). The most traction so far is with MTC, a proposal where, in the common case, all signatures except the handshake signature are replaced by a short Merkle tree proof under 800 bytes. This could make post-quantum authentication faster than traditional certificates of today. Cloudflare and Chrome plan to trial it before the end of the year.

Beyond TLS

Even within TLS, this discussion has skipped Encrypted ClientHello, and the migration story is broader still. DNSSEC, which secures domain name resolution, presents its own challenges.

Beyond the standard primitives of key agreement and signatures, the ecosystem has seen increased adoption of esoteric cryptography for advanced use cases: unlinkable tokens via Privacy Pass or PAT, anonymous credentials, and attribute-based encryption. For most of these schemes, no practical post-quantum alternative is known yet. The one bright spot is anonymous credentials, which have seen meaningful recent progress in the post-quantum space.

Preparing for the Quantum Threat Today

Two migrations matter most: key agreement and certificates.

Key agreement. To defend against store-now/decrypt-later attacks, moving to post-quantum key agreement is a software update on both ends. With the rapid uptake of X25519MLKEM768 across software and services, you might already be protected. You can verify browser support via Cloudflare Radar, check individual sites as you browse (Firefox users have an extension for this), scan your own website, or inspect traffic in Wireshark.

But spot checks are not a migration. The real work starts with mapping where cryptography is actually used. Most organizations struggle to track all software, services, and vendors they rely on. Some systems will prove difficult to upgrade or will have external dependencies, yet many others are simpler than expected. A common outcome is spending time discovering the work is already done.

Since figuring out what to do is most of the job, it is tempting to break that into a first milestone: building a detailed inventory, or cryptographic bill of materials (CBOM). Do not let the inventory become a goal in itself. The end state is the migration, not the list. Once you know what to do for a particular case, act on it rather than context-switching. Progress will be incremental—a marathon, not a sprint—but starting early yields surprising gains.

Certificates. As of October 2025, the final standards for post-quantum certificates are not yet settled. While waiting for resolution, there is preparatory work you will not regret: keep software current, automate certificate issuance, and make sure you can install multiple certificates.

Do not hold back out of fear of protocol ossification. The final standards will look close to the drafts. Testing with preliminary implementations or large dummy certificates today is a safe and useful exercise.

This migration is unusual. Past cryptographic breaks were either sudden or gradual enough to ignore for a while—but always rushed at the end. The quantum threat gives us certainty of the need to replace widespread cryptography and the time to do it deliberately. Treat it not as a chore but as a rare opportunity to perform long-overdue maintenance on systems that rarely get touched, allowing us to revisit past design choices rather than apply hotfixes.

Provided you start now. If you hit obstacles during your migration, the research team at Cloudflare is reachable at [email protected].