The ultimate guide to post-quantum security

Who this guide is for (and why now)

Your board just asked whether you're ready for the quantum threat. Or maybe you asked yourself that question, staring at regulatory deadlines creeping closer without quite knowing where to start. Either way, this guide is for you.

I wrote it with two people in mind — people who often sit at the same table but speak different languages:

• The technical reader (security architect, network engineer, PKI lead) wants to know what actually changes in the algorithms and protocols, and where to put their hands first.
• The decision-maker (CISO, security leader, IT director) needs to decide when to move, in what order of priority, and what to demand from vendors.

You can read it start to finish regardless of which one you are. If you're more technical, you'll find "Deep dive" boxes to go further where it matters. If your job is deciding more than building, I've added "Bottom line for decision-makers" boxes at the end of each section, translating the technical detail into priorities, costs, and questions to put to vendors. If you have ten minutes, those alone will give you the strategic picture.

This isn't a cryptography course. It's an operational map: understand the threat, know the deadlines, know what to migrate first and how, and turn all of that into a plan. At the center is a phased playbook; at the end, a checklist, some myths to debunk, and a glossary to come back to whenever you hit an acronym you can't place.

This isn't the first time, and it won't be the last

In 2004 the industry started realizing that MD5, the hash function holding together much of the web's security, had a serious problem. It still took another seven years before browsers truly stopped trusting it, and even today you can find it alive in some system nobody's had the nerve to touch.

The same story repeated with SHA-1, with old versions of SSL, with RSA keys that grew too short for current standards. The script is always identical: an algorithm is born, gets adopted everywhere, ages under the weight of new research, and eventually gets retired. Inventing a new one is the easy part. Rooting the old one out of every corner it's wormed its way into is the hard part.

The migration to post-quantum cryptography is just the latest chapter in this story, but with two differences that make it trickier than the ones before it.

The first is scope: this time we're not retiring a single weakened algorithm, we're replacing the entire family of public-key cryptography, key exchange and signatures together, in one go. The second is timing, and here the clock runs backwards: for part of the threat — data theft where the data stays sensitive for years — the damage happens today but you only discover it tomorrow. You can't afford to wait for the first incident before moving.

There is good news, though, and it's the reason this guide is worth writing. This time the international community didn't get caught flat-footed: the replacement algorithms came out of a public competition that ran for years, the standards are steadily being finalized one after another, and much of the internet has already adopted them without most people noticing.

The direction is already set. There may still be a few twists along the way, but we're far enough along to know how to move strategically.

How this guide is organized

One principle runs through the whole document: the migration needs to start now, because it's a multi-year effort with a chain of dependencies that doesn't forgive delay — not a switch you flip on Q-Day.

Anyone who waits risks being unprepared once it's too late, and for the most urgent part of the threat, "too late" can mean today.

You can read it in order, but every chapter also stands on its own:

• Chapters 1 and 2 lay the groundwork: what a quantum computer is, what it actually breaks and what it doesn't, the two distinct threats, and how much time is left.
• Chapters 3 and 4 move into planning: why there are two migrations rather than one, and which algorithms and names you need to write sensible requirements and talk to vendors.
• Chapters 5, 6, and 7 are the operational part: the phased playbook, the shortcut of post-quantum SASE, and the roadmap of the platform you might build on.
• Chapter 8 is your reference kit: a checklist to work through, myths to take apart, a glossary to come back to.

1. The basics: really understanding the problem

In 1994 a mathematician at Bell Labs named Peter Shor published a paper that, in hindsight, put an expiration date on much of the world's information security. Shor showed that a quantum computer, if one powerful enough ever existed, could quickly break the two mathematical problems that public-key cryptography rests on: factoring huge numbers and the discrete logarithm. At the time it looked like a theoretical exercise, because that computer didn't exist and seemed impossibly far off. Today it isn't, and that's why you're reading this guide.

To understand what's changing and why it matters to you, you need two things: a real grasp of what a quantum computer is, and a reminder of what actually happens today, every time you open a website, behind that padlock in your browser you probably stopped noticing long ago.

What a quantum computer actually is

The computer you're reading this on thinks in bits: switches that can only sit in one of two positions, 0 or 1. Everything it does, from spreadsheets to video games, is a dizzying sequence of these switches turning on and off.

A quantum computer uses qubits instead, and here the physics genuinely changes. Picture a coin tossed in the air: until it lands and you look at it, it's neither heads nor tails, it's both at once. A qubit behaves the same way: until you measure it, it can sit in a combination of 0 and 1 at the same time. This is called superposition, and it isn't a statistical trick or a figure of speech — it's really how matter behaves at that scale.

Now imagine trying to find the way out of a huge maze. A classical computer moves one corridor at a time, and if it hits a dead end it backtracks and tries another. A quantum computer, to simplify quite a bit, can travel down many corridors at once, and then a second phenomenon, interference, makes the dead ends cancel each other out while the right path gets reinforced. There's a third ingredient, entanglement, that links qubits together: touch one and the others react instantly, and this is exactly what holds the computation together while it explores all those paths in parallel.

There's a misconception worth clearing up right away: quantum computers won't replace ordinary ones. If anything, for the vast majority of tasks they're slower, more fragile, and far more expensive. Think of them like a graphics card: a specialized accelerator, formidable at a handful of problems with the right structure, useless for everything else. Nobody will ever check their email on a quantum computer.

Among the few problems with "the right structure" is, in fact, the breaking of most of the public-key cryptography that the internet runs on today. Not because a quantum computer is generically "faster": there's a specific algorithm, Shor's, the one you just met, capable of turning a problem that's impossible today into one within its reach.

What actually happens when the padlock shows up

Every time your browser shows that padlock, behind the scenes a ritual has just played out that takes a few milliseconds and is called the TLS handshake (the modern version is TLS 1.3). In that brief exchange, client and server agree on three distinct things, and quantum computing hits each of them differently. This difference is exactly where the entire migration strategy described in the rest of this guide comes from.

The first is symmetric ciphers, like AES-GCM or ChaCha20-Poly1305. They're the muscle of the connection: once a shared secret key is fixed, they encrypt and decrypt the enormous volume of data flowing between you and the site. They're fast, robust, tested for decades, and they're the "classic" cryptography that comes to mind by instinct when you hear the word.

The second is key agreement, of which X25519 is the most common example today. It answers a question that sounds impossible: how do we exchange the combination to the safe without ever having met, over a line anyone can eavesdrop on? Math finds a way out anyway: client and server jointly derive a shared secret without ever transmitting it in the clear. That secret becomes the key for the symmetric cipher mentioned above.

The third is digital signatures and certificates, like RSA or ECDSA, and they answer a different question: who am I really talking to? Anyone can claim to be bank.com. The certificate, signed by a trusted authority, is the server's ID card: it guarantees authenticity — that the other side really is bank.com and not an impostor sitting in the middle.

What quantum computing breaks (and what it doesn't)

Here we arrive at the point that decides every priority in the rest of this guide. Not everything collapses, and the part that does collapse doesn't collapse the same way.

Symmetric ciphers stay secure. AES-GCM holds up against quantum computing. There's a myth going around that Grover's algorithm requires doubling the length of symmetric keys, but looked at closely, this precaution isn't practical or necessary: the advantage Grover offers is too modest against its real costs to represent an actual threat. NIST itself confirms this, defining its own post-quantum security levels precisely by comparing them against how hard it is to break AES-128, AES-192, and AES-256. In short: symmetric cryptography isn't your problem, and data already encrypted "at rest" with AES stays safe.

Key agreement, on the other hand, is completely broken. This is where the floor gives way. X25519 is a variant of Diffie-Hellman over an elliptic curve, and its security depends entirely on how hard it is to "un-mix" — that is, on the discrete logarithm. Shor's algorithm, run on a large enough quantum computer, solves exactly that problem efficiently. It doesn't weaken it: it demolishes it. The same Shor's algorithm also takes down RSA, which rests on a related mathematical problem, factoring huge numbers.

And this is the urgent part of the story, for a reason that has to do with timing: the attack known in the field as "harvest now, decrypt later" — collect today, decrypt tomorrow — which we'll cover in the next chapter.

Finally, signatures and certificates are also completely broken. RSA and ECDSA, the algorithms used to sign certificates today, also fall to Shor's algorithm. Here the consequences change in nature compared to key agreement, and arguably they're more unsettling: an attacker with a working quantum computer could forge any signature, craft a fake certificate for bank.com that your browser would accept as genuine, impersonate a legitimate server, or falsify a signed software update. The risk is no longer just that someone reads your data: it's that someone becomes whoever they want to be.

Summing up the battlefield in one line: symmetric cryptography stays standing, while key agreement and public-key signatures both fall. Everything else in this guide follows from this asymmetry, and it's worth pinning it down in a table:

If you remember only this table, you already hold the logic of the entire migration: leave symmetric alone, race on key agreement, plan calmly for signatures.

2. The real threat and the deadlines: how much time do I have?

A CISO, or anyone who has to make decisions for a company, almost always asks the same question: is this a problem now, or can I wait a bit longer? The answer changes completely depending on what you mean by "problem," because hidden under the generic label of the quantum threat are two dangers with almost entirely different timelines, targets, and countermeasures.

Two threats not to confuse: harvest today, impersonate tomorrow

Many discussions on this topic fail right from the start by lumping everything into the same pot. Keeping these two threats separate is the most important mental step in this entire chapter.

The first has a name that perfectly describes the tactic: Harvest Now, Decrypt Later, HNDL, harvest today, decrypt tomorrow. An attacker doesn't need a quantum computer today to hit you today. All they need is to intercept your encrypted traffic and store it — even if they can't read it right now — and then wait. When a sufficiently powerful quantum computer arrives, they'll reopen that archive and decrypt everything retroactively. It's the thief who photographs your locked safe, knowing that in a few years he'll get his hands on the universal lockpick.

HNDL attacks confidentiality and concerns key agreement. The detail that almost always gets missed is that this harvesting isn't a future risk: it's already happening, right now, while you're reading this page.

Anyone safeguarding information that must stay secret for years — financial data, medical records, industrial secrets, diplomatic or state communications, intellectual property — has to assume that today's traffic, if not protected with post-quantum cryptography, may already be sitting in an archive, waiting for Q-Day. If a piece of data needs to stay secret for more than a few years, the countdown on its confidentiality has already started.

The second threat is impersonation, the attack on authentication, and here the math changes completely. The attacker needs a working, available quantum computer right away: they need it to forge signatures and credentials and pass themselves off as someone else — a legitimate server, a CA, an authorized user.

It attacks authenticity, concerns signatures and certificates, and unlike HNDL it can't be front-loaded. Nobody forges a signature today that will be verified tomorrow: the attack only becomes possible after Q-Day, not a minute before.

But when that moment arrives, the consequences are catastrophic. Every long-lived authentication key that's been left behind turns into a wide-open door.

• A compromised root certificate lets an attacker issue valid certificates for any domain: the attacker becomes a factory of fake identities.
• A forgeable code-signing key lets an attacker sign malware that the operating system will accept as legitimate vendor software.
• An automatic update mechanism with a forgeable signature stops being a convenience and becomes a remote code execution vector on every machine that receives that update.

The practical difference between the two threats also dictates the order of priorities.

• As long as Q-Day seems far away, the absolute priority remains HNDL — encryption — because data theft is happening today while impersonation isn't yet possible.
• As Q-Day gets closer, the picture flips: data theft remains serious, but compromised authentication becomes the dominant threat, because at that point the attacker no longer needs to steal and wait. They walk in through the front door with a fake key, in real time.

Q-Day got closer: what actually happened

For years, the same joke made the rounds at every security conference: Q-Day is 15 years away. It worked precisely because it was repeated identically year after year — a horizon that never got any closer — and it fed a comfortable crypto-procrastination: if the same amount of time is always left, why move now? Recently, though, the trajectory has changed, and understanding why requires facts, not fearmongering.

Breaking public-key cryptography with a quantum computer doesn't hinge on a single magic number. It requires progress on three independent fronts: hardware, error correction, and software. The tricky part is that progress on each front multiplies with the others: halving the difficulty on two fronts doesn't halve the problem, it divides it by four.

The front that's moved fastest lately is software — the algorithms. Until recently the estimate was around 20 million qubits, with the superconducting approach, to break RSA-2048. Then, in a paper published on May 21, 2025, Craig Gidney showed that with clever software optimizations, fewer than a million would suffice: a roughly 20x factor from smarter software alone, without touching the hardware. That's not an incremental tweak.

And it doesn't stop there: Google has announced that it has also dramatically improved the algorithm for breaking elliptic-curve cryptography (ECC). It published estimates of the resources required, but not the details of the exploitable quantum circuit, instead providing a zero-knowledge proof that it possesses one: an elegant way of saying "we'll tell you how powerful the weapon is, but not give you the blueprint to build it."

The other front is hardware and error correction, which have to be read together. Physical qubits are noisy and fragile, they make mistakes constantly, and to get one reliable logical qubit you have to combine many physical ones in an error-correction scheme — a bit like the redundancy used to recover a corrupted file. The ratio between physical and logical qubits is therefore decisive.

With superconducting chips that have limited connectivity, that ratio is terrible — it takes thousands of physical qubits for one logical one. Research, however, is exploring radically different architectures — neutral atoms, trapped ions, and others — where qubits are far more interconnected. Better connectivity dramatically reduces the number of physical qubits needed to get one reliable logical qubit.

This is where the real multiplier is hiding. An architectural leap in hardware can compress the estimates by orders of magnitude, just as Gidney's work compressed them on the software side. The two fronts don't add up: they multiply.

When these advances stack up, the most informed players react accordingly. Cloudflare has set 2029 as its own readiness target, pulling the timeline forward because the threat is arriving faster than the industry assumed — and a deadline that early only makes sense if you take a near-term Q-Day seriously. It's not an isolated read of the situation: Google, too, has moved up its own migration to 2029, explicitly prioritizing quantum-safe authentication over HNDL defense alone. And Michael Osborne, associated with IBM's Quantum Safe program, goes further in a personal analysis and doesn't rule out a "moonshot attack" on the highest-value targets as early as 2029.

Then there's a subtler problem, one that should keep you up at night more than any estimate. Scott Aaronson — a computer scientist at UT Austin and one of the most prominent theorists in quantum computing — has warned that at some point the people producing these estimates will stop publishing them, so as not to hand information to adversaries. The public signal could therefore go dark before the danger becomes real, and that point, according to Aaronson, may already be behind us.

Anyone waiting for an official Q-Day announcement before starting to plan has already lost.

The regulatory deadlines: the ones that actually matter

Amid all this uncertainty there's still good news: planning doesn't require guessing the exact date of Q-Day. Your obligations — compliance, contractual requirements, procurement tenders — are set by deadlines regulators have already fixed, in black and white. Here's the verified picture:

Most regulators who have weighed in place the final target in the 2030–2035 window, but note: both the United States (CNSA 2.0) and the United Kingdom (NCSC) also set intermediate milestones well before that, starting in 2025. It's not a single distant finish line — it's a sequence of deadlines that starts right away.

3. The two migrations you need to plan

A company that decides today to "go post-quantum" is actually about to take on two distinct projects, with different budgets, urgency, and even different technologies. Treating them as a single block is the fastest way to get priorities wrong, waste budget, and remain exposed exactly where it matters most.

The distinction stems from the same line drawn in the previous chapter: confidentiality (key agreement) and authenticity (signatures) are two different worlds. Now they become two separate workstreams.

Migration 1 — Key agreement (urgent, but relatively straightforward)

Why it's urgent. Post-quantum key agreement exists to counter HNDL, the already-active threat we met in the previous chapter. Every session encrypted with classical Diffie-Hellman that gets intercepted and archived today will become readable at Q-Day: it's a time bomb that's already armed. This isn't about preventing a future attack — it's about stopping a theft that, in all likelihood, is already underway. That's why key agreement comes first chronologically.

The good news: it's the easier of the two. The industry has settled on a single standard, ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism), formalized by NIST as FIPS 203. For the most common use case, TLS, migration often comes down to updating the cryptographic library on client and server. TLS 1.3's negotiation mechanism handles the rest, automatically choosing post-quantum key agreement when both ends support it, without you touching a single line of application code. If your software uses a standard TLS library — OpenSSL, Go's, or the system ones on Apple platforms — your HNDL problem is often solved with a simple update and the right configuration.

"Relatively straightforward" doesn't mean free, and it doesn't mean automatic everywhere. Traffic that doesn't go through standard TLS — proprietary protocols, old VPNs, embedded systems, or aging network hardware — needs dedicated attention. But the backbone of the web is, fortunately, exactly the point where this migration hurts least.

The real-world status is encouraging. This migration is already working at planetary scale: over 71% of human traffic to the Cloudflare network is encrypted with post-quantum cryptography, as of July 2026, and the curve keeps climbing. The majority of human traffic was already post-quantum by October 2025 — a sign that when the standard is clear and the upgrade is a library update, the transition moves fast and at scale.

Migration 2 — Signatures and certificates (less urgent, much harder)

Why it's less urgent. The attack that post-quantum signatures prevent — impersonation — requires a quantum computer that's already up and running. There's no harvest-now angle here: nobody can forge a signature today to use tomorrow.

This leads to a counterintuitive but liberating truth: rolling out post-quantum certificates today provides no security benefit before Q-Day — it only costs you, in effort, performance, and complexity. All that's needed is to be migrated in time, before Q-Day actually arrives. This takes pressure off the planning timeline, but it's not an excuse to delay: this second migration is an order of magnitude harder than the first.

Why it's much harder. The obstacles here aren't a matter of configuration, like flipping on a hybrid key agreement in a TLS library — they're structural, baked into how big the new cryptographic objects are and how many of them a single handshake has to carry. Two problems compound each other, and together they turn a routine-sounding "upgrade" into a real engineering challenge.

• Post-quantum signatures are huge. This is the underlying physical problem: an ML-DSA-44 signature weighs 2,420 bytes, versus 64 bytes for an ECDSA-P256 signature. The public key grows from 64 bytes (ECDSA) to 1,312 bytes (ML-DSA-44), a factor of ~20 on every single cryptographic object. This isn't a minor detail: the size of the TLS handshake has a direct, measurable effect on perceived latency, especially on mobile connections and in the first packets of a connection, where every byte counts because of the initial congestion window.

• A single TLS handshake doesn't contain one signature — it contains several. This is the multiplier that makes the problem serious. The first time you visit a site, the server sends you, on average, 5 signatures and 2 public keys (Cloudflare's count). It starts with the signature the server uses to authenticate the handshake; then the CA signs the leaf certificate binding its public key to the site's identity, bringing the count to two signatures and one public key. The intermediate certificate, needed when the CA has had to rotate its own key, adds another pair: three signatures, two public keys. Finally come the two SCTs (Signed Certificate Timestamps) required by Certificate Transparency, each one a signature from a public log: five signatures in total. Swapping all of them for ML-DSA equivalents effortlessly adds over 14 kB to every initial handshake. Multiply that by billions of connections a day, and the performance cost becomes enormous.

  Deep diveWhy are those signatures there?

  They're not pointless redundancy. The server uses one to authenticate the handshake itself. The certificate chain adds two more: the CA signs the site's leaf certificate, and if the CA has had to rotate its own key, an intermediate certificate acts as a bridge, adding one more signature and public key. SCTs exist for Certificate Transparency: every issued certificate ends up in public, verifiable logs, so a fake or mistakenly issued certificate becomes detectable after the fact — and that's where the last two signatures in the count come from.

  Every signature buys a real security property. And it's precisely because they're all necessary that replacing them wholesale with bulky post-quantum versions hurts so much. (Some handshakes may also include a signature for OCSP stapling, which attests that the certificate hasn't been revoked: it's a separate mechanism that isn't always present, so it's not included in the base count.)

  Deep diveDoing the math on the handshake.

  Let's line up the numbers, because they help convey the scale of the problem. In the classical world an ECDSA-P256 signature weighs 64 bytes, and a public key the same: five signatures and two public keys together add up to a few hundred bytes, a rounding error compared to the rest of the connection. Now swap each object for the most compact standardized post-quantum equivalent, ML-DSA-44: each signature goes from 64 to 2,420 bytes, each public key from 64 to 1,312 bytes. The signatures alone come to 5 × 2,420 ≈ 12.1 kB, plus the public keys, 2 × 1,312 ≈ 2.6 kB. What was a few hundred bytes becomes roughly 14-15 kB added to every single initial handshake.

  The problem is serious because those bytes land at the worst possible point — the start of the connection, when TCP's congestion window is still small and every extra kilobyte can cost an additional network round-trip before the page even starts loading. On a high-latency mobile connection, this translates directly into delay the user can feel.

  Multiply those 14-15 kB by the billions of handshakes that happen every day on the web, and it's clear why a naive "drop-in" upgrade to post-quantum certificates today would be a massive performance cost for zero security benefit before Q-Day.

  The fix isn't to shrink the signatures — none of the standardized post-quantum schemes get anywhere near ECDSA's size, and none will. The fix is to stop sending so many of them on every single handshake. That's the core idea behind Merkle Tree Certificates: sign an entire batch of certificates once, in advance, and let each handshake carry a small proof of membership in that already-signed batch instead of a fresh signature of its own. One expensive signature, amortized over thousands of certificates, replaces thousands of individually expensive ones. We'll walk through exactly how that works in the chapter on the roadmap.

• The dependency chain is long and outside your control. Encryption is largely an internal effort, done once; authentication, by contrast, depends on an entire ecosystem: Certificate Authorities need to issue post-quantum certificates, HSMs (the hardware modules that safeguard keys) need to support the new algorithms, CA/Browser Forum audits and policies need to be updated, browsers need to update their trust stores, and third parties and anti-fraud systems need to keep pace. You don't control any single one of these pieces on your own. That's why this migration is measured in years, not months, and needs to start well in advance even though the benefit only arrives close to Q-Day.

  Deep diveWhy you can't "upgrade" a trust chain on your own.

  When you update your server's TLS library to enable post-quantum key agreement, it's entirely your call: if the client is up to date, it works immediately, because confidentiality is negotiated between just two parties at connection time. Authentication is different — it's a collective property: your certificate is only worth something if an entire population of independent parties trusts it. Look at the sequence that has to complete before a post-quantum signing certificate becomes genuinely usable in public:

  1. A CA has to be able to issue it, but can't until its HSMs support the new signature algorithm and the CA/Browser Forum's rules formally allow it.
  2. Browsers have to add the new roots to their trust stores and learn to verify the new signatures, which means waiting for release cycles of software installed on billions of devices, many of which update months late, or never.

  Only once all these links are in place does your post-quantum certificate stop being dead weight and become trusted everywhere. It's a global choreography in which no single player can speed up the others: each one can only prepare in advance, so as to be ready when the chain finally lines up. Here, "start early" isn't generic caution — it's a structural necessity.

A golden rule on priority. Not everything within Migration 2 carries the same urgency. As Q-Day approaches, priority goes to long-lived keys: root certificates, API authentication keys, code-signing certificates, software update signing keys. The reason is simple and unforgiving: if an attacker compromises one, they retain indefinite access until it's discovered or the key is revoked, and these keys, by their nature, stay in service for years. An ephemeral key that lives for an hour isn't worth attacking. A root that lives for twenty years is.

The third step almost everyone forgets: turning off the old stuff

Even the most careful organizations fall into a mental trap: believing that adding post-quantum support finishes the job. If a system keeps accepting quantum-vulnerable cryptography too, maybe for compatibility's sake, it remains exposed to a downgrade attack.

An active attacker positions themselves in the middle of the connection and forces both parties to negotiate the weak algorithm — the one they know how to break — discarding the strong one that both sides would otherwise support. The result is almost mocking: you've spent effort on post-quantum, and you're still just as vulnerable.

Real security only arrives once, after completing the transition, you disable the quantum-vulnerable cryptography and take the downgrade option away from the attacker. One last step remains, often forgotten: once you've closed the old channel, you have to rotate every secret — passwords, access tokens, keys — that passed through the vulnerable system, because you have to assume they may have been harvested. This isn't paranoia: it's the logical consequence of HNDL.

4. The standards you need to know (and put in your RFPs)

In 2016, NIST opened a public competition: it invited cryptographers from around the world to propose algorithms and attack each other's submissions. Eight years of public scrutiny later, in August 2024, the first final standards arrived. The good news is that you don't have to invent anything — you just need to learn the right names and understand when to use each one, so you can talk to vendors and write sensible requirements without getting sold smoke. The open process is itself a guarantee: the algorithms that survived have been targeted for years by the best cryptanalysts on the planet.

The NIST family, algorithm by algorithm

Behind every acronym is a tool with a specific job.

• ML-KEM (formerly Kyber) is today the only standardized post-quantum key agreement, the absolute reference point for Migration 1. Its full name, Key-Encapsulation Mechanism, is no small detail (we explain why in the box below). It comes in three sizes — ML-KEM-512, ML-KEM-768, and ML-KEM-1024 — with increasing strength, and the web has settled on ML-KEM-768 as the sweet spot.

• ML-DSA (formerly Dilithium) is the default choice for signatures: solid, well studied, with reasonable performance across the board. It has three levels — ML-DSA-44 (the most compact and fastest, with NIST category 2 security), ML-DSA-65, and ML-DSA-87 — each progressively stronger and larger. Without a specific reason to choose otherwise, this is what you'll use to sign.

• SLH-DSA (formerly SPHINCS+) rests on hash functions rather than lattices, and that gives it a rare and valuable quality: the highest possible confidence in its security. To forge a signature, an attacker would need to devastatingly break the underlying hash function — an event that would throw half of computing into crisis long before you'd need to worry about it. The price is performance: SLH-DSA is the worst performer on nearly every metric, with large signatures and slow operations. Its ideal home is very-long-lived signatures, or contexts where a future upgrade will be impossible — think firmware on a device that will live for twenty years, or a root key you'll never touch again.

• FN-DSA (formerly Falcon) produces very compact signatures, a valuable advantage given the whole discussion of sizes in the previous chapter. But it has a serious technical Achilles' heel: to be fast, it requires constant-time floating-point arithmetic, notoriously hard to implement without opening side timing channels — tiny differences in computation time from which an attacker can recover the key. The risk is greatest exactly where it matters most: when signatures are generated on the fly during a TLS handshake. That's why it isn't standardized yet — compactness isn't enough if the secure implementation becomes a trap. It remains useful when you produce the signature in a controlled environment, where size is what matters most.

• HQC is the structural plan B for key agreement — code-based, meaning built on error-correcting codes, a different branch of mathematics from lattices. Its performance is markedly worse: at the highest security level, the public key and ciphertext together weigh about 21.7 kB, versus ~3.1 kB for ML-KEM-1024 — roughly a 7x factor — and no one will pick it first. Its reason for existing is insurance. If a cryptanalytic breakthrough ever emerged capable of demolishing all lattices, HQC would already be standing by as a non-lattice alternative: NIST selected it in March 2025 precisely so as not to put all the eggs in the same mathematical basket.

The hybrid approach: X25519MLKEM768

Cloudflare, like practically every serious early adopter, doesn't use "pure" ML-KEM. It uses a hybrid key agreement that runs the old X25519 and the new ML-KEM-768 in parallel. In TLS this combination has a name and a number, X25519MLKEM768 (TLS identifier 0x11ec), today the recommended and widely deployed standard.

It's natural to wonder why on earth you'd keep alive the very algorithm you're trying to replace. The answer may be the single most important engineering lesson of this whole migration, and it breaks down into two parts.

The first reason is age. Post-quantum cryptography is young: ML-KEM has been studied for years, not for the decades that have battle-tested RSA and ECC. Combining the two buys you a margin. If lattice cryptanalysis made unexpected progress tomorrow and weakened ML-KEM, the classical contribution would keep its proven strength intact. It's no accident that ML-KEM-768, "192-bit" level, is paired with X25519, "128-bit" level: you want plenty of margin precisely on the new side.

The second reason is more counterintuitive, and even more interesting: why keep classical X25519 at all, when quantum computers will break it sooner or later anyway?

1. Protection against a lattice breakthrough. If it were ever discovered that all variants of ML-KEM are insecure, the hybrid would still guarantee X25519's classical security. Adopting it can't make the current situation worse: in the worst case, it just matches it.
2. Protection from your own implementation mistakes. This is the subtler reason, and perhaps the more valuable one. An algorithm can be mathematically flawless and still be implemented badly, and a faulty implementation opens real holes. The KyberSlash case, a timing attack that hit many Kyber/ML-KEM implementations, is the textbook example. In a hybrid system, a bug like that on the ML-KEM side is still neutralized by the presence of X25519: the attacker would have to break both sides at once.

Lattices, the foundation of (almost) everything

There's a word that keeps coming up in these pages: lattice. Most of the NIST standards — ML-KEM, ML-DSA, FN-DSA — are lattice-based, built on the hardness of certain problems tied to mathematical lattices. You don't need to know the math to use them, but a bit of intuition helps you understand why we trust them, and where the risk hides.

The flip side deserves to be stated honestly: today we have too many eggs in one basket. Lattices are the best-performing, most versatile branch of post-quantum cryptography, and that's exactly why we use them almost everywhere. If a crack ever appeared in their security, the shockwave would be enormous. That's precisely why NIST wanted a backup built on different math — HQC, code-based, for KEMs — and opened a separate competition for new non-lattice signatures. Diversification isn't pessimism. It's cryptographic hygiene.

5. The playbook: how to move step by step

You can start on Phase 4, encryption, while Phase 5's authentication is still sitting on the board's table: many phases of this journey overlap, and shouldn't be read as sealed compartments. There is, however, an order you can't invert. Skipping Phase 0 and Phase 1 — governance and inventory — turns everything else into an uncoordinated exercise that burns budget without lowering real risk. The path that follows applies to any organization, regardless of sector, size, or technological maturity, and shows, phase by phase, how Cloudflare shortens the road.

There's a principle that guides every choice Cloudflare makes on this journey, and it's worth adopting as your own compass too: post-quantum security should be the default, free, with no switch to flip. For you, this translates into a concrete advantage. Every post-quantum upgrade Cloudflare ships reaches every customer, on every plan, at no extra cost, and turns itself on: no lever to move, no module to buy, no consultant to call to "switch on" protection.

The history of cryptography has a clear lesson on this point: anything that requires an optional manual step stays switched off in the vast majority of systems. A secure default protects even those who don't know they need protecting.

Phase 0 — Governance: appoint an owner and set a timeline

Before the technology comes responsibility. Post-quantum migrations fail almost always for organizational reasons, not technological ones. No one is clearly accountable. The deadline stays a vague "someday." The topic stays locked inside the security team and never reaches the people who decide budgets.

Appoint a post-quantum migration owner: a named person, with a clear mandate and visibility at the board level. You don't need a cryptographer. You need someone capable of getting infrastructure, application teams, procurement, and legal to talk to each other, and of keeping up the pace over time. Then set an internal Q-Day readiness timeline, aligned with whatever regulatory deadlines apply to you: 2030-2035 (or as early as 2030 if you fall under CNSA 2.0), the U.S. profile for national security systems, which sets intermediate milestones between 2030 and 2033. For a sense of how aggressive that timeline should feel, look at the platform much of this playbook leans on: Cloudflare itself targets 2029 to be fully post-quantum secure — a year or more ahead of the earliest regulatory deadlines, for the simple reason that a platform provider has to be ready before its customers are. Finally, put post-quantum migration on the list of risk topics presented to the board: as long as it stays an internal technical matter for the security team, it will never get the resources it needs.

A tip from the regulators: for governments and agencies, the recommendation is to hand migration coordination to a lead agency, with a clear timeline, while staying focused on security and promoting the international standards that already exist. Inside a company, the same logic applies: one owner, one timeline, open standards. Avoid proprietary solutions and homemade cryptography: during a transition, interoperability and public review of standards remain your best insurance.

Phase 1 — Cryptographic inventory

You can't migrate what you don't know about. Inventory is the most underrated phase of the whole journey, and also the one with the most surprises. Nearly every organization discovers forgotten keys and certificates, tucked away in devices, scripts, or legacy services that no one remembers putting into production. Map where you use quantum-vulnerable cryptography by starting from these questions:

• Where do you use RSA and ECC? Both in key agreement — the key exchange that opens every TLS connection — and in signatures: certificates, JWTs, code signing. Check load balancers, reverse proxies, network appliances, internal microservices. Don't stop at just the web servers exposed to the internet.
• Which are your long-lived keys? Root and intermediate CAs, API authentication keys, code-signing certificates, software update keys. These are the most dangerous, because they live for years: if compromised after Q-Day, they open access that no quick rotation can shut down in time.
• Which data needs to stay confidential for many years? Financial data, health data, industrial secrets, diplomatic communications. Anything that stays sensitive for 10-20 years and today travels over connections not yet protected in post-quantum is already at risk: it can be intercepted today and decrypted tomorrow.
• What are your third-party dependencies? Both direct and indirect, including those critical to the business, such as financial services and utilities. Your cryptographic surface doesn't stop at the boundary of your own network.

Phase 2 — Setting priorities

With the inventory in hand, order the work according to the two migrations: encryption and authentication. They don't share the same urgency, or the same difficulty.

• Long-shelf-life data → post-quantum key agreement right away. This is the absolute priority, because it mitigates Harvest Now, Decrypt Later (HNDL), the only post-quantum threat that is already active today. Every day that passes without protection is another day of data that could already be sitting in an archive, waiting to be decrypted tomorrow.
• Long-lived keys and authentication → high priority, and it grows as Q-Day approaches: root CAs, API keys, code signing. Here the risk isn't retroactive — an attacker can't forge a signature today with a computer that doesn't exist yet. But if they compromise one of these keys the day after Q-Day, the access they gain is effectively unlimited.
• Don't waste resources on low-value work. The classic example is doubling the length of symmetric AES keys: symmetric cryptography is already considered robust against known quantum attacks. Put your energy where the risk is certain — eliminating RSA and ECC.

Phase 3 — Crypto-agility

Crypto-agility is the true enabling factor for the entire migration. History shows that retiring a cryptographic algorithm takes decades. MD5 was declared insecure more than twenty years ago, and it still causes problems in production systems today.

If it takes twenty years to eliminate an algorithm that's already broken, imagine what it takes to replace one at global scale that still works, just one that's vulnerable. The lack of agility is the real bottleneck of the entire transition.

How Cloudflare helps: by building post-quantum encryption directly into the platform, Cloudflare offers crypto-agility as a service. With Cloudflare One, the SASE platform, an organization can move its sensitive network traffic to post-quantum without having to update every application, system, or connection one by one. Traffic is encapsulated and protected at the platform level. Individual applications don't need to know anything about ML-KEM or hybrid algorithms. It's the fastest way to gain agility without rebuilding your infrastructure from scratch — especially valuable for the fleet of legacy applications that will never receive a native cryptographic update.

Phase 4 — Migrating key agreement

This is the fastest, highest-impact move, which is why it should come first. For TLS, in most cases it's just a library update: you enable X25519MLKEM768 on client and server, and protection kicks in. Recent versions of the major browsers, and of many TLS libraries and platforms such as OpenSSL, Go, and recent Apple systems, already have X25519MLKEM768 enabled by default. In many scenarios, most of the road has already been covered without you doing anything at all.

How Cloudflare helps — the three connections. When a user visits a site behind Cloudflare, there are three hops to protect, and protecting only one leaves the chain exposed. Here's the verified status today:

1. Visitor → Cloudflare edge. Since 2022, every site and API served by Cloudflare over TLS 1.3 supports hybrid post-quantum key agreement. The connection is protected only if the client — the browser — also supports PQC: one more reason to keep it up to date.
2. Cloudflare's internal connections. Service-to-service connections between Cloudflare's data centers have been progressively migrated to post-quantum key agreement. At GA, the stated goal was to complete this by the end of 2024. This is the hop the customer never sees, but it protects data as it crosses the global network.
3. Cloudflare edge → origin. Cloudflare also supports hybrid key agreement toward origin servers, though end-to-end protection here depends on the origin itself supporting PQC. If your origin isn't ready yet, put it behind Cloudflare Tunnel: you'll still get a post-quantum connection, without touching the origin server's cryptographic configuration.

Phase 5 — Migrating authentication (and downgrade protection)

This is the long part, the marathon of the migration. Encryption is often solved with a library update. Authentication, on the other hand, touches the entire public-key infrastructure: certificates, CAs, trust chains. A typical plan includes these steps:

• Dual certificates. Unless you control both sides of the connection, you'll need to install two certificates on the same service: a post-quantum one for new clients, a traditional one for old ones. During the handshake, the client signals which signature schemes it supports, so the server serves each one the right certificate. This is the mechanism that lets you migrate without breaking compatibility.
• Automating certificate issuance. Managing a doubled certificate fleet by hand isn't sustainable. If you don't already use automated certificate issuance, now is the time to adopt it: it turns dual management, and future rotations, from a recurring emergency into quiet routine.
• Downgrade protection. Adding post-quantum isn't enough. You also need to actively prevent an attacker from forcing a fallback to weak algorithms. On the web this is achieved with mechanisms like "PQ HSTS" and Certificate Transparency; other protocols use dedicated extensions. Without this protection, offering post-quantum alongside traditional algorithms doesn't reduce risk: the attacker will always target the weakest link.
• Rotating secrets. Once you've disabled the old algorithm, rotate every secret — passwords, tokens, API keys — that was exposed by the vulnerable system. As long as they stay the same, the benefit of the migration remains only partial.

How Cloudflare helps — post-quantum authentication already available toward the origin. As of July 29, 2026, Cloudflare supports post-quantum authentication (ML-DSA signatures) on the Cloudflare→origin connection, through two complementary products:

• Authenticated Origin Pulls (AOP) — Cloudflare presents your origin with an ML-DSA client certificate, so the origin can verify the connection really is coming from Cloudflare and not an impostor: this is the "client" side of mTLS. Free on every plan, at both the zone and individual-hostname level.
• Custom Origin Trust Store (COTS) — lets you upload your own ML-DSA CAs, so Cloudflare trusts the certificates your origin presents when they chain back to that CA: this is the side that makes the origin's authentication toward Cloudflare post-quantum too.

Together, AOP and COTS enable mutually authenticated, fully post-quantum mTLS toward the origin. Cloudflare supports all FIPS 204 (ML-DSA-44/65/87) parameter sets; for most cases the recommendation remains ML-DSA-44, the best trade-off between signature size and security margin.

Watch out for downgrade risk: uploading a CA to COTS replaces the default trust store. Upload only post-quantum CAs — otherwise a mixed trust store leaves the door open to the weaker algorithm. This is the first milestone in Cloudflare's post-quantum authentication roadmap, not the finish line: further steps along the authentication chain will follow.

Phase 6 — Third parties, dependencies, and procurement

Q-Day threatens every system, not just yours. Even if you complete your internal migration flawlessly, you'd remain exposed through your vendors. So assess the impact of a possible Q-Day on your third-party dependencies: not just the ones you obviously "talk cryptography" with, but also those critical to the business, such as financial services and utilities, whose disruption would stop you regardless of the technical details.

• Make post-quantum support a procurement requirement. Put it in RFPs and contracts from the start: it's far easier to demand it before signing than to chase it afterward. And ask vendors for a roadmap, not a generic reassurance.
• Evaluate critical vendors early. Ask yourself the uncomfortable question: what would happen to your business if this vendor didn't migrate in time? The answer tells you how urgently to start the conversation, and whether you need a plan B.
• Stick to basic good practices. Keeping software up to date and automating certificate issuance sound like minor details, yet on their own they go a long way: they make your vendors' post-quantum upgrades arrive automatically, without manual steps someone eventually forgets to take.

6. Deep dive: Cloudflare One and post-quantum SASE

A manufacturing company still runs, today, an ERP system written fifteen years ago. The vendor is gone, the code is too fragile to touch, and that software still talks to TLS libraries that have never heard of ML-KEM. Updating it isn't an option. Yet that traffic can still travel protected from HNDL, because protection doesn't have to start at the application: it can start at the network.

This is the shift in perspective behind Cloudflare One, Cloudflare's SASE platform: instead of chasing down every single piece of software, a potentially endless job especially with legacy systems, you wrap the traffic in post-quantum tunnels. The traffic travels inside an envelope encrypted with cryptography resistant to quantum computers, and what happens inside matters a lot less.

The strength of this approach is easy to state: you get end-to-end protection for private network traffic by routing it through tunnels protected by hybrid ML-KEM, even if the individual applications on the corporate network haven't been updated to PQC yet. That protects even traffic to legacy systems you'll never touch, like the ERP system above, from HNDL. The logic holds up on its own: an attacker who records your traffic today hoping to decrypt it tomorrow with a quantum computer, the "Harvest Now, Decrypt Later" we already discussed, runs into a tunnel already encrypted with ML-KEM. That intercepted traffic stays unreadable even in a quantum future.

Cloudflare One is today the first SASE platform to support standards-compliant post-quantum encryption in the Secure Web Gateway and across Zero Trust and WAN use cases, with hybrid ML-KEM on all major on-ramps and off-ramps. The key word here is hybrid. The key is negotiated by combining a classical algorithm, like X25519 or P-384, with ML-KEM: even if one of the two turned out to be weak, an unlikely but not impossible scenario, the other still holds. A prudent choice, at a moment when confidence in post-quantum algorithms is still being built.

On-ramps: how traffic enters the Cloudflare network

• Clientless browser access — TLS 1.3 with hybrid ML-KEM, if the browser supports it, to self-hosted applications behind Cloudflare Access.
• Cloudflare One Client (formerly WARP) — uses the MASQUE protocol over TLS 1.3 with hybrid ML-KEM from the user's device. The advantage is concrete: traffic entering from a device running Cloudflare One Client stays PQ-protected even if the browser doesn't support post-quantum.
• Cloudflare IPsec — IPsec tunnels from network devices to Cloudflare.

Off-ramps: how traffic exits toward destinations

• Cloudflare Tunnel (via cloudflared) — TLS 1.3 with hybrid ML-KEM.
• Cloudflare IPsec — to the corporate network.

A concrete scenario: the ERP system nobody can update

Let's go back to the manufacturing company's ERP system from the opening. It runs on an on-premise server and will never get a cryptographic update: the vendor no longer exists, and the code is too fragile to touch. It still talks to outdated TLS libraries that can't negotiate ML-KEM. Updating it is out of the question. And yet it holds data that matters: production formulas, contracts, exactly the kind of material a competitor would pay to intercept today and decrypt tomorrow.

Here's what happens once post-quantum SASE enters the picture, step by step:

1. User → PQ on-ramp: the employee opens the ERP system from their laptop. The traffic doesn't head straight for the server: Cloudflare One Client captures it and wraps it in a MASQUE tunnel over TLS 1.3 with hybrid ML-KEM. Already at this first hop, the traffic is protected from HNDL.
2. On-ramp → Cloudflare network: the tunnel reaches the nearest Cloudflare point of presence. The session key is negotiated hybrid-style. Even an attacker recording every packet along the Internet path won't be able to decrypt it, not today and not with a future quantum computer.
3. Cloudflare network → off-ramp: inside the Cloudflare network, traffic gets routed to the Cloudflare Tunnel (via cloudflared) installed alongside the legacy ERP system, or to a Cloudflare IPsec tunnel toward the corporate network. This leg also uses TLS 1.3 with hybrid ML-KEM.
4. Off-ramp → legacy application: only in the last, very short stretch, from the cloudflared connector to the server, usually over an already segmented and controlled private network, does the traffic reach the ERP system as-is. The application never notices a thing: it keeps speaking its outdated protocol, unaware that it's been wrapped in a post-quantum tunnel for the entire public leg of the journey.

The outcome is clear-cut: the company gets HNDL protection on a system that, left to itself, will never become post-quantum. The cryptography moves to where it can be updated, the network, and leaves alone what can't be changed.

Post-quantum Secure Web Gateway (SWG)

For traffic heading out to the Internet, Cloudflare Gateway acts as the post-quantum SWG. Two distinct connections are involved: client→Gateway, via a post-quantum on-ramp like Cloudflare One Client or IPsec, and Gateway→origin, post-quantum only if the destination site supports PQC.

The practical result is this: even if the user's browser doesn't support post-quantum, traffic entering via Cloudflare One Client or a post-quantum IPsec tunnel stays protected. It's the classic "break and rebuild": the connection is terminated and re-established at the Gateway, and each half is protected with the best available option. Even when the origin is still stuck on classical cryptography, the client→Gateway leg, the one most exposed to interception on public networks and shared Wi-Fi, is already safe from HNDL.

7. Cloudflare's 2029 roadmap

On 29 July 2026, Cloudflare hit the first milestone of its post-quantum roadmap: ML-DSA authentication on the edge-to-origin connection became generally available, in the form of AOP and COTS. It's the first piece of a bigger plan: Cloudflare has accelerated its roadmap and is targeting 2029 to be fully post-quantum secure, post-quantum authentication included.

That "authentication included" hides the truly difficult part of the problem. Post-quantum encryption, meaning protecting data confidentiality from a future quantum computer, is already largely solved and deployed: the hybrid key exchange mechanism runs by default on most traffic.

Post-quantum authentication, meaning verifiably proving who you're actually talking to using quantum-resistant signatures, is instead still very much a work in progress. It runs into size and performance constraints that encryption alone doesn't have. A roadmap with specific dates exists precisely to clarify when each piece of this puzzle will close.

Here are the intermediate milestones as stated (still subject to change):

Each row of the table isn't an isolated promise: it closes off, one at a time, a different front of the attack surface. It starts from the most controllable point, Cloudflare's connections to origins, and works toward the most exposed and fragmented one, the entire population of browsers on the public web.

How this connects to the three-connection chain

To understand what each milestone closes, it helps to revisit the "three-connection chain" we saw earlier:

On the encryption front, these connections are already largely covered. On the authentication front, though, timelines stretch out and diverge, and that's exactly what the roadmap lays out.

The mid-2026 milestone closes post-quantum authentication on the edge → origin connection: when Cloudflare presents itself to your origin server, it can already prove its identity with quantum-resistant signatures (ML-DSA). This connection got there first for two structural reasons that don't apply anywhere else in the chain. First, Cloudflare is the client here, which means it controls the connection: it can pool requests from across its whole network into a smaller set of long-lived connections to each origin, so the extra weight of a post-quantum signature gets amortized over many requests instead of being paid on every single handshake. Second, trust between Cloudflare and an origin runs through a private relationship — a Cloudflare account — rather than the public WebPKI, so there's no need for the intermediate certificates and Certificate Transparency overhead that the public web requires. Cloudflare could simply use a custom PKI built for the job, without waiting for Merkle Tree Certificates or any change to how browsers trust certificates. The early 2028 milestone extends PQ authentication to the Cloudflare One SASE suite, effectively covering internal connections and client-to-service connections within the corporate security platform. The most ambitious milestone, the mid-2027 one, tackles the visitor → Cloudflare (edge) connection. It's the hardest: the "client" here isn't controlled by Cloudflare, it's anyone's browser, in any version, and post-quantum signatures, much larger, risk bloating every single TLS handshake. This is where Merkle Tree Certificates come in.

Merkle Tree Certificates (why they matter for the web)

The bottleneck for post-quantum authentication on the public web is size: 5 signatures and 2 public keys per handshake, with signatures roughly 20 times larger, tank performance. A "drop-in" upgrade to PQ certificates brings no benefit before Q-Day, in fact it makes things worse: that's why it remains difficult to enable it by default today.

                 ROOT
             (final hash)
              /        \
         H(A|B)        H(C|D)
         /    \        /    \
      H(A)   H(B)   H(C)   H(D)
       |      |      |      |
     cert1  cert2  cert3  cert4

The Merkle Tree Certificates (MTC) solve the problem by trimming signatures and public keys down to the bare minimum. If the client is up to date enough, the handshake only requires 1 signature, 1 public key, and 1 inclusion proof, light even with post-quantum algorithms. The underlying idea: a Merkle Tree CA produces certificates without a signature in batches. Instead of a signature, the certificate carries proof of inclusion in a signed Merkle tree, and the "landmarks" (the tree's heads) reach browsers out of band.

Cloudflare is implementing MTCs and trialing them together with Chrome Security, without touching WebPKI's trust relationships, thanks to the bootstrap certificates that anchor every MTC to an existing certificate from a trusted CA. The work is also moving forward at the IETF: the PLANTS working group is standardizing the MTC draft. The technical expectation is that MTCs could even shrink handshake size compared to today's non-PQ certificates.

This isn't just about paying a smaller price for the move to post-quantum. The potential payoff is more striking than that: coming out the other end with handshakes lighter than today's, which rely on classical signatures. It's one of the rare cases where a security migration, usually a costly one, translates into a performance gain, and that's exactly what makes the MTC approach so compelling for the public web at scale, where every extra byte, multiplied across billions of connections, adds up.

8. Checklist, myths to bust, and glossary

Actionable checklist

No company switches off RSA with a single command on a Friday evening. Post-quantum migration is a multi-year program that runs through people, processes, and technology, not a switch you flip once and forget.

The checklist below is organized by area: read it as a set of workstreams advancing in parallel, not as a list to clear top to bottom in one sitting. Each group opens with the goal it serves, so you know why you're checking those boxes, not just what you're doing.

Governance Without a name attached to the project in writing, migration dies at the first competing priority — it's the story of a thousand half-finished security initiatives. This group exists to give the migration an owner, a deadline, and visibility at the top, turning a cryptography problem into a corporate program with clear accountability.

• Appointed an owner for the post-quantum migration
• Defined an internal timeline aligned with regulatory deadlines (2030–2035 / 2030)
• Added PQ migration to board-level risk reporting
• Defined a dedicated multi-year budget, separate from routine maintenance
• Assigned operational responsibilities to teams (network, PKI, applications, procurement)

Inventory You can't protect what you don't know you have, and RSA and ECC often hide in places nobody remembers anymore. This group builds a complete map of where vulnerable cryptography lives and which data carries long-term risk — it's the foundation every prioritization decision that follows rests on.

• Mapped where RSA and ECC are used (key agreement and signatures)
• Inventoried long-lived keys (root CAs, APIs, code-signing, software updates)
• Identified long-shelf-life data traveling over non-PQ connections
• Listed critical third-party dependencies
• Identified custom trust stores and certificate pins scattered through the codebase
• Cataloged legacy systems that can't be upgraded and need to be isolated

Encryption (Migration 1 — urgent) Someone, somewhere, may already be storing your encrypted traffic while waiting for the right computer to open it: that's Harvest Now, Decrypt Later, the most immediate threat of all. This group protects the confidentiality of traffic today, before it ends up in an archive waiting to be decrypted. It's also the fastest part to complete, since often all it takes is a software update.

• Enabled X25519MLKEM768 on clients and servers wherever possible
• Updated TLS libraries (OpenSSL, Go, etc.)
• Protected legacy origins (e.g., via Cloudflare Tunnel) or queued them for upgrade
• Encapsulated sensitive corporate traffic in PQ tunnels (SASE) where appropriate
• Verified the absence of middleboxes that break the hybrid handshake (post-quantum blocking)

Authentication (Migration 2 — marathon) Here speed doesn't matter — endurance does. The goal is to bring the entire chain of trust — certificates, CAs, signatures — into the post-quantum world, starting with the keys that live the longest. This is the slow part, dependent on third-party vendors, and it takes years of work, not weeks.

• Adopted automated certificate issuance
• Planned a dual-certificate strategy (PQ + traditional)
• Prioritized long-lived keys (root, API, code-signing)
• Enabled PQ authentication to the origin where available (ML-DSA / AOP / COTS)
• Verified ML-DSA support in the HSMs and cryptographic modules in use
• Shortened certificate lifetimes to increase crypto-agility

Downgrade and lockdown Turning on post-quantum while leaving the old algorithm switched on too is like installing an armored door and never locking the wooden one right next to it: an attacker will always use the weaker one. This group closes the door on vulnerable algorithms and cleans up the secrets that traveled through them.

• Planned the deactivation of quantum-vulnerable algorithms
• Enabled downgrade protection where available
• Planned rotation of secrets exposed by vulnerable systems
• Defined controlled fallback criteria for legacy clients, without weakening modern clients

Third parties Your cryptographic attack surface doesn't end where your code ends — it extends to every vendor you exchange data with. This group turns post-quantum support into a contractual requirement, so you're not held hostage by vendors who don't migrate. The supply chain is almost always the slowest link in the chain, and it needs to be managed years in advance, not at the last minute.

• Made PQC support a procurement requirement
• Assessed critical vendors and the risks of their failing to act
• Agreed PQ roadmaps and adaptation clauses with strategic vendors

Myths to bust

• ❌ "Q-Day is always 15 years away, I can wait." ✅ The trajectory has changed: software improvements (Gidney, May 2025: from ~20 million to <1 million qubits for RSA-2048) and progress on more connected hardware architectures have moved Q-Day closer. Google is targeting 2029; a researcher linked to IBM Quantum Safe doesn't rule out targeted attacks as early as 2029. And sensitive data is already at risk from HNDL. The "15 years" estimate has been circulating for more than a decade, and that's exactly why it always seems to stay put, like a horizon that never gets any closer. But that number isn't a physical constant — it's a forecast that gets revised with every scientific leap, and the latest leaps have shortened it considerably. The parameter to watch isn't the date the quantum computer arrives, but the deadline by which you must have already finished migrating, which falls much earlier. Waiting means betting that none of the more aggressive estimates will come true — a bad bet when the data at stake needs to stay confidential for years.

• ❌ "I'll wait for the final standards." ✅ The final NIST standards have been published since August 2024 (ML-KEM, ML-DSA, SLH-DSA). Crypto-procrastination is no longer justifiable. For key agreement, updating the TLS library is often all it takes. For years it was wise not to bet on algorithms still under selection, since they could change or be withdrawn at any moment. But that period of prudent waiting is over: the standards exist, they're final, and each has a name and a FIPS number stamped on it. Anyone still "waiting" today is doing so out of habit, not for any real technical reason. And the most urgent part — protecting confidentiality — is also the easiest: often there's nothing to redesign, just a library to update and a configuration flag to flip.

• ❌ "I need to double my AES keys." ✅ The idea that Grover's algorithm requires doubling symmetric key sizes isn't practical. AES-GCM is already post-quantum secure. Don't waste resources here instead of eliminating RSA/ECC. The myth stems from too literal a reading of the theory. On paper, Grover's algorithm halves the effective strength of a symmetric key, and from there comes the temptation to "double everything." The problem is that this reading ignores just how expensive it really is to run Grover against a 128-bit key: it would require such an enormous number of sequential operations that it remains unfeasible even with a quantum computer. Focusing on this point is dangerous, because it burns attention and budget on a theoretical risk while the real threat — RSA/ECC asymmetric cryptography, which Shor genuinely breaks — remains untouched. Symmetric crypto is fine as it is. Asymmetric crypto is the problem.

• ❌ "I need quantum hardware or QKD to defend myself." ✅ No. Post-quantum cryptography runs on today's hardware. Quantum Key Distribution (QKD) requires specialized hardware or dedicated physical links, doesn't scale beyond point-to-point connections, and the NSA, Germany's BSI, and the UK's NCSC have all warned against relying on it exclusively. The myth thrives on a misleading assonance: if the threat is "quantum," the defense should be too. It's an elegant idea, but false. Post-quantum cryptography is simply classical mathematics, based on problems that not even a quantum computer can solve, which is why it runs perfectly well on ordinary CPUs, smartphones, and existing servers. QKD, often confused with PQC, is something else entirely: it shifts the problem onto the physical layer, requires dedicated fiber or special equipment, doesn't travel over the Internet as we know it today, and doesn't solve the authentication problem at all. It's no coincidence that national security agencies advise against using it as the sole line of defense.

• ❌ "Just add post-quantum support and you're done." ✅ Not enough: without disabling vulnerable algorithms you remain exposed to downgrade attacks. And afterward, secrets need to be rotated. The myth is seductive because "adding" is a positive, visible action: you enable a new algorithm, the PQ traffic graph goes up, it looks done. The blind spot is that security isn't determined by the best option you offer, but by the worst one you still accept. As long as old RSA or ECC remains negotiable, an active attacker can force both parties down to it, and all the work you've done goes up in smoke. There's also a second step almost everyone forgets: secrets that lived on vulnerable channels must be treated as potentially compromised and regenerated. Adding is just the beginning. Disabling and rotating is what actually closes the door.

• ❌ "It's a one-time migration, like a software update." ✅ Encryption, pretty much yes. But authentication has a long chain of dependencies (CAs, HSMs, audits, third parties): it takes years, not months. The misunderstanding stems from the fact that the most visible part — traffic confidentiality — really does behave like an update: you swap the library, restart, and it works. From there comes the idea that the whole migration proceeds at the same pace. But authentication lives in a different world, made up of certificates that depend on certificate authorities, hardware modules, audit processes, and vendors who all need to move together. You can't "update" a chain of trust shared with the rest of the Internet on your own: you have to coordinate, wait for trust stores to update, for HSMs to support the new algorithms, for partners to adapt their systems. It's a years-long marathon, not an afternoon sprint.

• ❌ "If I haven't been hit by a quantum attack yet, it's not urgent." ✅ This is the most dangerous reasoning of all, because it confuses the absence of visible damage with the absence of an attack. Harvest Now, Decrypt Later produces no observable symptom today: the attacker isn't "breaking" anything right now, they're simply copying and storing the encrypted traffic that passes by. The theft is already underway, silently, and decryption will happen only once the quantum computer is ready. This completely flips the logic of defense: protecting data after Q-Day is pointless, because by then the copy archived years earlier will simply be opened. The only defense that works is encrypting in a post-quantum way before the data is transmitted — that is, now. For any information that needs to stay confidential longer than the Q-Day horizon, "not urgent yet" effectively means "already too late."

• ❌ "Just buy a solution and you're covered." ✅ No single product "solves" post-quantum, for the same reason no single product solves security in general: it isn't a component, it's a property distributed across the entire organization. A platform can dramatically accelerate the traffic-encryption piece, but it can't do your inventory of where you use RSA in your code, can't appoint the program owner, can't negotiate with your vendors, and can't disable vulnerable algorithms in your legacy systems for you. Migration is a multi-year transformation made of governance, inventory, third-party management, and the orderly retirement of the old. The risk of the "buy it and you're done" myth is that it creates a false sense of security: you buy a tool, check a mental box, and stop working, leaving exposed exactly the parts that are slowest and hardest to outsource.

• ❌ "Post-quantum slows things down too much, better to wait." ✅ This fear is based on outdated intuition more than current numbers. For key agreement (the urgent part), the overhead of the hybrid approach is a few extra bytes per handshake and a negligible amount of computation — so small it's already the default behavior for most human web traffic, without users noticing. The performance concern is more real for authentication, where post-quantum signatures and keys genuinely are larger; but even there, research — particularly Merkle Tree Certificates — is explicitly aimed at shrinking that footprint until handshakes are no heavier than today's. Waiting "because it's slow" therefore means giving up protection that's already essentially free on the urgent front, in hopes of saving a cost that technology is already erasing on the slow front.

Quick glossary

• Q-Day — the day a quantum computer capable of breaking today's widely used cryptography (e.g., RSA-2048) exists. It isn't a date marked on a calendar, but a threshold: the moment the theoretical threat becomes a real capability.
• CRQC — Cryptographically Relevant Quantum Computer: a quantum computer powerful enough to pose a genuine cryptographic threat. It doesn't exist yet. Current quantum devices have far too few stable qubits to attack RSA or elliptic curves.
• HNDL (Harvest Now, Decrypt Later) — an attack in which encrypted traffic is archived today for decryption after Q-Day. It leaves no visible trace in the present, which is why defending confidentiality is urgent now.
• Key agreement — the mechanism by which two parties agree on a shared secret key (e.g., X25519, ML-KEM). It's the part of the handshake that protects traffic confidentiality, and the priority of Migration 1.
• Digital signature / certificate — the mechanism that guarantees the authenticity of the other party (e.g., RSA, ECDSA, ML-DSA). It's what assures you that you're really talking to the right site and not an impostor.
• ML-KEM (FIPS 203) — the NIST standard for post-quantum key agreement (formerly Kyber), lattice-based. It's the algorithm that, combined with X25519, protects confidentiality today against HNDL.
• ML-DSA (FIPS 204) — the NIST standard for post-quantum signatures (formerly Dilithium), lattice-based, the default choice. It's the leading candidate to replace RSA and ECDSA in authentication.
• SLH-DSA (FIPS 205) — a hash-based post-quantum signature scheme (formerly SPHINCS+), maximum confidence but weaker performance. It relies solely on the robustness of hash functions, which makes it conservative but with large, slow signatures.
• FN-DSA — a post-quantum signature scheme (formerly Falcon), compact but tricky to implement securely; not yet standardized. Its small signatures make it attractive, but it requires floating-point arithmetic that's hard to make secure.
• HQC — a non-lattice backup KEM, selected by NIST in March 2025. It serves as a mathematically distinct fallback, so as not to depend solely on lattices in case of future breakthroughs.
• Hybrid (e.g., X25519MLKEM768) — the combination of a classical algorithm and a post-quantum one in parallel, for "belt-and-suspenders" security. It stays secure as long as at least one of the two algorithms holds, covering both quantum risk and potential flaws in the new scheme.
• Crypto-agility — the ability to swap out a cryptographic algorithm without rewriting the system. It's the property that makes the next migration — not just this one — fast and painless.
• Downgrade attack — an attack that forces the parties to use a weaker algorithm that's still supported. It's why adding post-quantum support isn't enough unless the old option is disabled.
• Certificate Transparency (CT) — an ecosystem of public logs that makes mis-issued certificates detectable. Every trusted certificate must appear in these verifiable registries, so a fraudulent issuance doesn't go unnoticed.
• Merkle Tree Certificates (MTC) — a proposal for compact post-quantum certificates that shrink signatures and public keys down to a minimum for the handshake. They use a tree structure so that post-quantum doesn't weigh down the handshake.
• MASQUE — a tunneling protocol (Multiplexed Application Substrate over QUIC Encryption) used by the Cloudflare One Client. It lets traffic be encapsulated inside modern QUIC connections, useful for delivering end-to-end PQ protection.
• SASE — Secure Access Service Edge: the convergence of networking and security delivered as a cloud service. It lets you encapsulate corporate traffic in post-quantum tunnels without managing hardware on-site.
• TLS 1.3 — the latest version of the protocol that encrypts most web traffic. It's the foundation on which hybrid post-quantum key agreement travels in modern handshakes.
• Handshake — the initial phase of a connection in which the parties negotiate algorithms and keys. It's the exact moment when it's decided whether the connection will be post-quantum protected or not.
• Diffie-Hellman — the classic method by which two parties generate a shared key over a public channel. It's the idea behind modern key agreement, but in its classical form it's vulnerable to Shor's algorithm.
• X25519 — a modern, efficient elliptic-curve variant of Diffie-Hellman. On its own it's quantum-vulnerable, but paired with ML-KEM it forms the X25519MLKEM768 hybrid.
• RSA — the historic asymmetric algorithm based on the difficulty of factoring large numbers. It's the main target of Shor's algorithm and needs to be eliminated from chains of trust.
• ECDSA — an elliptic-curve signature algorithm, compact and efficient. Like RSA, it's broken by Shor's algorithm and destined to be replaced by ML-DSA.
• AES — the standard symmetric cipher for protecting data once a key has been established. It's already considered post-quantum secure at typical key lengths.
• Shor's algorithm — a quantum algorithm that breaks RSA and ECC by efficiently solving factoring and discrete logarithm problems. It's the real reason this entire migration exists.
• Grover's algorithm — a quantum algorithm that speeds up exhaustive search, theoretically weakening symmetric keys. In practice it doesn't make AES insecure at current key lengths.
• Lattice / Learning With Errors — a family of mathematical problems based on lattices, hard even for quantum computers. It's the foundation of ML-KEM and ML-DSA, the leading PQ standards.
• KEM (Key-Encapsulation Mechanism) — a mechanism by which one party "encapsulates" a secret key by encrypting it for the other. It's the modern model for post-quantum key agreement, as used in ML-KEM.
• mTLS — TLS with mutual authentication, where the client also presents a certificate. Common between internal services, it too needs to be made post-quantum on the authentication front.
• HSM — Hardware Security Module: a dedicated device that stores and uses private keys in a protected way. It must support the new algorithms (e.g., ML-DSA) for authentication migration to proceed.
• Trust store — the set of root certificates a system trusts in order to validate others. Updating it is essential for new post-quantum certificates to be accepted.
• Inclusion proof / Merkle proof — a compact cryptographic proof that an element is present in a Merkle tree. It's the mechanism that lets schemes like MTC and CT prove membership without transmitting the entire tree.
• Downgrade protection — mechanisms that prevent an attacker from forcing the use of weaker algorithms. It's the direct countermeasure to downgrade attacks and should be enabled wherever available.
• SCT (Signed Certificate Timestamp) — a signed receipt attesting that a certificate has been included in a Certificate Transparency log. It's proof that a certificate has been made publicly detectable.
• OCSP stapling — a technique in which the server attaches proof of its certificate's validity (not revocation) during the handshake. It avoids the client having to query the authority separately, improving privacy and speed.
• CNSA 2.0 — the suite of post-quantum algorithms specified by the NSA for U.S. national security systems. It sets deadlines and approved algorithms, and also serves as a reference point outside government.
• WebPKI — the public key infrastructure underpinning browser trust in websites. It's the ecosystem of CAs, certificates, and trust stores that Migration 2 needs to make post-quantum.
• Landmark (MTC) — a periodic reference point in the Merkle Tree Certificates ecosystem against which inclusion proofs are anchored. It allows compact certificates to be validated against a shared public state.
• Bootstrap certificate — a traditional certificate used as a fallback when an MTC certificate isn't yet available or verifiable. It ensures continuity during the transition to compact certificates.
• Control plane / Data plane — the separation between the layer that handles configuration and decisions (control plane) and the one that carries actual traffic (data plane). Distinguishing them helps identify where to intervene in the migration and which components to update first.

Conclusion

More than 71% of human traffic to Cloudflare already travels over post-quantum encryption. This isn't a forecast — it's a snapshot of today: the transition isn't a future event to wait for, it's already underway. Post-quantum encryption is now the new baseline standard of the Internet, while post-quantum authentication remains the hardest challenge, one that's only just begun. If there's a single idea to take away from this guide, it's exactly this asymmetry:

• Half the work (encryption) is largely done and nearly free.
• The other half (authentication) is a marathon that needs to start years in advance.

Confusing the two — treating them as a single, undifferentiated "quantum problem" — is the mistake all the others follow from.

Let's return for a moment to where we started: this isn't the first cryptographic migration in history, and the hard part has never been inventing the new algorithm, but replacing the old one everywhere it has taken root. Inventory, governance, the chain of dependencies in authentication, third-party management, the grind of disabling the old — everything you've read so far is the concrete expression of this truth.

Post-quantum algorithms, paradoxically, are the part that's already solved. They exist, they're standardized, they run on today's hardware. The real challenge is you: your organization, your ability to move in an orderly way before the clock runs out.

For anyone starting now, the operational message comes down to four moves:

1. Distinguish the two migrations. Encryption is urgent because of HNDL, the silent theft that may already be underway, but it's often a quick win: sometimes all it takes is a library update. Authentication is less urgent in a chronological sense, but it's a marathon with dependencies outside your control, so start it early, beginning with the keys that live the longest.
2. Build crypto-agility. It's the investment that pays off beyond this single transition. Infrastructure where algorithms change via configuration, not by rewriting the system, will be ready for the next migration too — the one we can't yet imagine. Post-quantum SASE offers one way to get there without rebuilding your infrastructure from scratch.
3. Don't stop at "adding PQ." Turning on the new algorithm is just the beginning. Real security arrives when you switch off the old one, taking the downgrade option away from the attacker, and then rotate the secrets that traveled over vulnerable channels. It's the step almost everyone skips, and it's the one that actually closes the door.
4. Look beyond your own perimeter. Third parties and critical dependencies weigh on your risk as much as your own systems do. Make post-quantum support a procurement requirement, and have the uncomfortable conversations with strategic vendors now.

Above all of this is a way of thinking that matters more than any checklist: don't wait for the signal. The estimate of when a quantum computer capable of breaking cryptography will arrive keeps getting shorter, and at some point public estimates might stop coming out altogether. Planning around "when the announcement comes" is a losing strategy from the start. Planning backward from the deadlines you can control — your long-term confidentiality needs, your regulatory obligations between 2030 and 2035 — is the only approach that doesn't depend on guessing the future.

Cloudflare shortens this path in a very specific way: post-quantum by default, free, with no switches to flip. It's the same philosophy that, a decade ago, made TLS encryption free and automatic, taking the web from "mostly unencrypted" to "encrypted by default." That transition proved that when security is the default rather than an optional cost, the entire ecosystem moves fast.

Free, automatic post-quantum cryptography aims to do, against the quantum threat, exactly what free TLS did against classical eavesdropping: secure it quietly, for everyone, before the danger comes knocking.

At this point, the right question isn't whether to migrate or when, but whether you'll start moving while you still have time to do it in an orderly way, or wait until you have to do it in a rush. The transition is already in motion around you. The best time to get on board was yesterday; the second-best time is now.

Sources (official Cloudflare documentation and blog posts)

• PQC documentation (About PQC): developers.cloudflare.com/ssl/post-quantum-cryptography/
• PQC status across Cloudflare products: pqc-cloudflare-products
• PQC in Cloudflare One (Zero Trust/SASE): pqc-and-zero-trust
• PQC to the origin: pqc-to-origin
• Cloudflare targets 2029 for full post-quantum security (roadmap): blog.cloudflare.com/post-quantum-roadmap/
• State of the post-quantum Internet in 2025: blog.cloudflare.com/pq-2025/
• The state of the post-quantum Internet (2024): blog.cloudflare.com/pq-2024/
• Post-quantum cryptography goes GA: blog.cloudflare.com/post-quantum-cryptography-ga/
• Cloudflare One is the first SASE with post-quantum encryption: blog.cloudflare.com/post-quantum-sase/
• Post-quantum encryption for Cloudflare IPsec is GA: blog.cloudflare.com/post-quantum-ipsec/
• Post-quantum authentication to origins is now supported: blog.cloudflare.com/post-quantum-authentication-to-origins/
• Introducing Merkle Tree Certificates: blog.cloudflare.com/bootstrap-mtc/
• You don't need quantum hardware for post-quantum security: blog.cloudflare.com/you-dont-need-quantum-hardware/
• Prepping for post-quantum: a beginner's guide to lattice cryptography: blog.cloudflare.com/lattice-crypto-primer/
• Real-time PQ adoption (Cloudflare Radar): radar.cloudflare.com/adoption-and-usage#post-quantum-encryption