# IBM Just Cooled Two Fridges Into One Machine. Your Actual Deadline Is Not 2029.

Cloudflare Radar shows 71.1% of human HTTPS traffic using post-quantum key exchange, but only 13.1% of origin servers behind it do. IBM's 2029 machine is not your deadline.

Author: J.A. Watte
Published: August 21, 2026
Source: https://jwatte.com/blog/quantum-fault-tolerance-2029-what-to-do-now/

---

On 19 August 2026 IBM said it had joined two cryogenic modules into a single environment and cooled them together. The combined structure stands more than 8 feet tall and 8 feet wide. It reached 4 Kelvin, the temperature of liquid helium, in under 5 days, and then dropped below 15 millikelvin shortly after. IBM's own framing for that number is more than 180 times colder than deep space.

That is the whole announcement. No new qubit record, no algorithm, no chemistry simulation. Two very large, very cold boxes were bolted together and they got cold on schedule.

That is more interesting than a qubit record would have been, and it is also not the date that belongs on your calendar.

## What actually got built, and why plumbing is the good news

The part of the release that matters is not the temperature. It is the wiring.

Each new module's vacuum enclosure offers up to 12 times more wiring space than IBM's most widely used quantum systems. That sounds like a facilities note. It is closer to the whole problem. A superconducting quantum processor needs control lines running from room-temperature electronics down through several stages of refrigeration to a chip sitting a hair above absolute zero. Every line is a path for heat. Every line takes physical room. The number of qubits you can control is bounded, in a very unglamorous way, by how many wires fit through the neck of the fridge without cooking what is at the bottom.

So the interesting claim in the release is that more wiring space enables more chip-to-chip connections both within and between modules. IBM plans to use what it calls L-couplers to link multiple processors into a larger machine with at least 1,000 programmable qubits by 2027. It will install its Nighthawk processors into the new modules later in 2026 to expand performance testing, and by the time its fault-tolerant system ships, it plans for each cryogenic module to house thousands of qubits.

Here is why I find this encouraging rather than promotional. Refrigeration, vacuum enclosures, cable routing and mechanical joins are engineering problems with known shapes. They have suppliers. They have tolerances. They get solved roughly when the schedule says they will. The reason quantum roadmaps have historically slipped is that they depended on a physics result arriving on time, and physics results do not take deadlines. A milestone that consists of "we joined two fridges and they cooled correctly" is a milestone from the reliable half of the project.

Which is exactly why you should treat the 2029 date as more credible than you would have treated a similar promise three years ago, and still not build your security plan around it.

## The roadmap, and what fault tolerance means here

IBM's public roadmap and its June 2025 technical blog post give the named systems and the years.

| System | Year on IBM's roadmap | What IBM says it does |
|---|---|---|
| Loon | 2025 | c-couplers |
| Kookaburra | 2026 | first module storing information in qLDPC memory with an attached logical processing unit |
| Nighthawk | 2026 | 7,500-gate circuits across up to three 120-qubit modules |
| Cockatoo | 2027 | entanglement between modules |
| Nighthawk (improved) | 2028 | up to 15,000 gates on up to 1,080 qubits, nine modules linked by L-couplers |
| Starling | 2029 | 100 million quantum gates on 200 logical qubits |
| Blue Jay | 2033+ | 2,000 qubits, 1 billion gates |

One caution if you read that roadmap page yourself. IBM groups milestones under year headings that do not match the systems inside them. The tile headed 2030 is where the sentence placing Starling in 2029 actually lives. Cite 2029 for Starling and ignore the tile heading.

Now the distinction that carries the whole article. Nighthawk has 120 programmable qubits on a square lattice with four-degree connectivity. Those are physical qubits: real superconducting circuits on real silicon, each one noisy. Starling is specified at 200 **logical** qubits. A logical qubit is an error-corrected abstraction built out of many physical ones, and the ratio is brutal.

IBM's chosen error correction is a family of bivariate bicycle quantum low-density parity check codes. The one it uses as its worked example, the [[144,12,12]] code it nicknames the gross code, encodes 12 logical qubits into 144 data qubits plus another 144 syndrome check qubits, for 288 physical qubits in total. That is 24 physical qubits per logical qubit, in a code IBM says needs 10 times fewer qubits than the surface code alternative. The efficient option still costs you an order of magnitude.

So "200 logical qubits in 2029" and "120 programmable qubits today" are not two points on the same line. They are different units. Anyone comparing them directly, in either direction, is selling something.

And 200 logical qubits is not a machine that breaks RSA. Breaking RSA-2048 with Shor's algorithm requires substantially more logical qubits than that, and I am deliberately not putting a specific number on the requirement because I could not verify one from a primary source while writing this. IBM does not claim Starling is a cryptographically relevant quantum computer, and nobody serious does. Blue Jay, at 2,000 qubits and a billion gates in 2033 or later, is on the same published roadmap, and 2033 sits inside every deadline in the next section. That is the honest version of the urgency argument, and it does not require overstating a word of what IBM announced.

## Your deadline is not the machine. It is the traffic you are sending right now.

Here is the part that makes 2029 the wrong thing to plan around.

The joint factsheet from CISA, the NSA and NIST states it plainly: threat actors could be targeting data today that would still require protection in the future, using what the document calls a catch now, break later or harvest now, decrypt later operation. Apple made the same argument when it shipped post-quantum iMessage in February 2024, and pointed at the reason it is now practical. Storage got cheap enough that filing away enormous volumes of encrypted traffic, on the chance you can read it later, is an affordable bet.

NIST wrote that logic into its draft transition guidance as well, saying application-specific guidance may require migration to quantum-resistant key establishment before classical schemes are generally disallowed, specifically to mitigate harvest-now-decrypt-later. And the government's own budget memo, OMB M-23-02, tells agencies to prioritise systems holding data that, if recorded now and later decrypted by a quantum computer in 2035, would still be mission sensitive.

Read that criterion again and apply it to your business rather than to an agency. Not "will someone break my TLS session this afternoon." Instead: **what am I transmitting today that would still hurt me in 2035?** Client medical or legal files. Payroll and banking credentials that outlive their rotation schedule. Source code. Contract negotiations. Anything under an NDA with a long tail. For most small businesses the honest answer is that a good deal of it has a secrecy lifetime measured in years, and the interception, if it is happening, has already happened.

That is the entire argument for acting now, and it does not depend on any prediction about 2029 being right.

## The dates that are already published

These are real, they are federal, and they bind a business more than anything on a vendor roadmap.

| Document | Date | What it says |
|---|---|---|
| FIPS 203 (ML-KEM, formerly Kyber) | published 13 August 2024 | key encapsulation standard |
| FIPS 204 (ML-DSA, formerly Dilithium) | published 13 August 2024 | digital signature standard |
| FIPS 205 (SLH-DSA, formerly SPHINCS+) | published 13 August 2024 | hash-based signature standard |
| HQC selected as backup KEM | 11 March 2025 | NIST expects a finalised standard in 2027 |
| FIPS 206 (FN-DSA, based on FALCON) | promised "shortly" in March 2025 | no draft published as of 21 August 2026 |
| NIST IR 8547, transition guidance | initial public draft 12 November 2024 | still a draft as of 21 August 2026 |
| 112-bit RSA, ECDSA, EdDSA, DH, ECDH | per draft IR 8547 | deprecated after 2030, disallowed after 2035 |
| 128-bit-and-above classical parameter sets | per draft IR 8547 | disallowed after 2035 |

NIST's own advice when it published the first three standards was that administrators should start integrating them immediately, because full integration will take time. That was two years ago this month.

Three rows in that table deserve a second look, because they are the parts a vendor slide deck will not show you.

**HQC exists because putting everything on lattices was a risk NIST did not want to take.** HQC is built on error-correcting codes rather than structured lattices, so a future break in lattice mathematics would not take both algorithms down at once. NIST's own description of the tradeoff is that HQC is lengthier than ML-KEM and demands more computing resources. You are not expected to deploy it. You are expected to know a second option is coming in 2027 if the first one develops a problem.

**FIPS 206 is late and nobody has said why.** In March 2025 NIST said a draft of the fourth standard, built around FALCON, would be released shortly as FIPS 206. As of 21 August 2026 there is no draft in the NIST publications catalogue, and I could find no NIST statement after March 2025 updating its status. I want to be precise about the strength of that claim: it is an absence of evidence, not a NIST announcement of delay. But seventeen months is a long "shortly."

**The document that tells American business when RSA stops being acceptable has been an unfinalised draft since November 2024.** IR 8547's comment period closed on 10 January 2025. Nineteen months later it is still an initial public draft. Its dates are the ones everyone quotes, including me, and they are not final. Worth knowing before you let a vendor cite "the NIST deadline" at you as though it were law.

One more piece of history in that document is genuinely useful. NIST's earlier guidance, SP 800-57, had projected that public-key schemes offering 112 bits of security would be disallowed outright on 1 January 2031. IR 8547 changes that to deprecation instead, explicitly because organisations need to keep using those schemes while they migrate. The direction of travel on this particular deadline has been to soften it, not tighten it. Anyone telling you these dates only ever move earlier is not reading the same documents.

## The government's own equipment timetable, and the contradiction inside it

If you sell to the federal government, or your customers do, the NSA's Commercial National Security Algorithm Suite 2.0 is the schedule that governs the gear.

| Equipment category | Support and prefer by | Exclusive by |
|---|---|---|
| Software and firmware signing | 2025 | 2030 |
| Web browsers, servers, cloud services | 2025 | 2033 |
| Traditional networking equipment (VPNs, routers) | 2026 | 2030 |
| Operating systems | 2027 | 2033 |
| Niche equipment | 2030 | 2033 |
| Custom applications and legacy equipment | update or replace by 2033 | |

Note which row is tightest on the near end. Traditional networking equipment, meaning your VPN concentrator and your routers, was supposed to support and prefer CNSA 2.0 by 2026. That is this year. It is the earliest hardware date in the entire schedule, and it lands on the least glamorous box in the rack.

Now the contradiction, which you should know about because two different NSA documents are both current and they do not agree. The advisory above sets 2033 for browsers, servers, cloud and operating systems. The NSA's CNSA 2.0 FAQ, version 2.1, dated December 2024, states that policy CNSSP 15 requires all new National Security System acquisitions to be CNSA 2.0 compliant by 1 January 2027, requires equipment that cannot support CNSA 2.0 to be phased out by 31 December 2030, and mandates CNSA 2.0 algorithms by 31 December 2031.

Those are roughly two years tighter than the advisory. The practical reading is that the advisory is the per-category roadmap the NSA gives vendors, while the FAQ carries the policy dates system owners are actually held to. If you are a subcontractor and someone quotes you one of these, ask which document they are reading.

Above all of it sits National Security Memorandum 10, from 4 May 2022, which set 2035 as the government's target for mitigating as much quantum risk as feasible and directed every civilian executive branch agency to produce an annual inventory of systems that remain vulnerable. OMB M-23-02 turned that into a due date: a prioritised cryptographic inventory by 4 May 2023 and annually thereafter until 2035.

For scale, the government's July 2024 report to Congress projects the total cost of migrating prioritised federal non-national-security systems to post-quantum cryptography between 2025 and 2035 at approximately $7.1 billion in 2024 dollars. That same report calls the figure a rough order of magnitude with a high level of uncertainty, and it excludes national security systems entirely. Treat it as a signal of scale, not a budget line.

## The encouraging half: a lot of this already happened without you

This is the section that changes how the problem feels.

**Your browser has done it since 2024.** Chrome enabled a post-quantum TLS key encapsulation mechanism by default on all desktop platforms in Chrome 124, for both TLS 1.3 and QUIC. Firefox 132, released 29 October 2024, added the mlkem768x25519 post-quantum key exchange for TLS 1.3. Cloudflare's current floor for browser support is Chrome 131 or newer, Edge 131 or newer, and Firefox 132 or newer. Chrome 131 hit stable on 12 November 2024. If your staff have updated their browsers in the last eighteen months, that side is done.

Google is also closing the escape hatch. The enterprise policy for turning post-quantum key agreement off in Chrome is available only through Chrome 145 and is removed in Chrome 147. If someone in your organisation disabled it to fix a broken middlebox, that workaround has an expiry date.

**Your SSH client did it before NIST finished writing the standards.** OpenSSH 9.0, released 8 April 2022, made a hybrid post-quantum key exchange the default and said so in the release notes for exactly the reason this article is about: to prevent capture now, decrypt later attacks against recorded session ciphertext. OpenSSH 9.9 added the ML-KEM hybrid mlkem768x25519-sha256 on 19 September 2024. OpenSSH 10.0 made it the default for key agreement on 9 April 2025. And OpenSSH 10.1, on 6 October 2025, added a warning that fires by default whenever a connection negotiates a non-post-quantum key agreement, controlled by a new WarnWeakCrypto option.

That last one is the cheapest audit in this article. Upgrade your SSH client and every login you make becomes a test of the server on the other end.

**Your messaging already did it.** Signal shipped PQXDH on 19 September 2023, hybridising X25519 with Kyber for initial key establishment, then announced the Sparse Post Quantum Ratchet on 2 October 2025, mixing it with the existing Double Ratchet into what it calls a Triple Ratchet so that ongoing messages are protected, not only session setup. Apple announced iMessage PQ3 on 21 February 2024, rolling out with iOS 17.4, iPadOS 17.4, macOS 14.4 and watchOS 10.4, using ML-KEM for initial key establishment and for periodic rekeying.

**Your toolchain got it in a routine release.** OpenSSL 3.5.0, on 8 April 2025, added ML-KEM, ML-DSA and SLH-DSA, changed the default TLS supported-groups list to prefer hybrid post-quantum key encapsulation groups, and made X25519MLKEM768 one of the default keyshares. Anything you build on a current OpenSSL inherits the preference with no configuration change.

## Now the number everyone reads wrong

Cloudflare Radar, observed 21 August 2026, reports that 71.1% of human HTTPS request traffic worldwide used post-quantum key exchange over the trailing seven days. That headline gets quoted constantly and it is true.

On the same page, in a chart most people scroll past, is this: only 13.1% of scanned customer origin servers behind Cloudflare support the X25519MLKEM768 post-quantum key exchange.

Those two numbers describe different legs of the same journey. The 71% is browsers talking to CDN edges, and it is high because Cloudflare enabled hybrid post-quantum key agreement on every domain it serves, on the customer's behalf. The 13.1% is what happens after the edge, when traffic goes on to the server the business actually runs. Six origins out of seven drop back to classical key exchange for that hop.

If you read the 71% and concluded you were covered, you measured the leg somebody else already fixed for you.

I checked a sample of hosts myself on 21 August 2026 using OpenSSL 3.5.6, and the pattern is not what you would guess. Nine hosts negotiated X25519MLKEM768 without complaint: google.com, microsoft.com, aws.amazon.com, ibm.com, cloudflare.com, signal.org, paypal.com, godaddy.com and squarespace.com. Four refused a post-quantum-only handshake outright, returning a TLS alert and no negotiated group: login.microsoftonline.com, outlook.office365.com, api.stripe.com and www.wix.com.

Sit with that list for a moment. Microsoft's own identity endpoint, the thing every Microsoft 365 small business authenticates against all day long, was classical-only, while www.microsoft.com was not. Stripe's API, which carries payment data with a long secrecy lifetime, was classical-only. Meanwhile GoDaddy and Squarespace, the inexpensive end of the website market, both negotiated the post-quantum group.

The predictor is not company size or security sophistication. It is whether that specific endpoint sits behind a modern content delivery network. Which means you cannot infer a vendor's status from its reputation. You have to test the hostname you actually use.

Those four negatives are a snapshot of one day from one machine, they can flip without any announcement, and I would re-run the test rather than quote my list.

And to be fair about my own house: jwatte.com did not negotiate a post-quantum group on 21 August 2026 either. Same test, same result as the four above. I am not going to tell you to run a check I fail myself without saying so out loud.

## What to do this quarter

Free checks first, because they cost nothing and they tell you where you actually stand.

**1. Test your own hostnames, today.** Two ways, both free, neither requiring an account.

Cloudflare Radar's website support checker at [radar.cloudflare.com/post-quantum](https://radar.cloudflare.com/post-quantum) performs a TLS handshake against any host and port you give it and reports whether a post-quantum key exchange was negotiated. It defaults to port 443 and accepts other ports, so it works for mail servers, DNS-over-TLS on port 853, and internal services on 8443, not only websites. The same page will also tell you whether the browser you are reading this in supports post-quantum key agreement.

If you have OpenSSL 3.5 or newer installed, one line does it locally:

```
echo | openssl s_client -connect HOST:443 -servername HOST -groups X25519MLKEM768
```

A capable host prints `Negotiated TLS1.3 group: X25519MLKEM768`. A non-capable host returns an alert and prints `Negotiated TLS1.3 group: <NULL>`.

There is a trap in that command and it matters. **Without the `-groups` flag, a non-post-quantum host prints no group line at all rather than an error.** That reads like your tooling failed instead of like a finding, and you will move on thinking the test was inconclusive. Forcing the group is what makes a negative result legible.

**2. Upgrade your SSH client to OpenSSH 10.1 or later and leave the warning on.** From then on, every server you connect to that negotiates a weak key agreement announces itself. That is a continuous, zero-effort inventory of your own infrastructure.

**3. Write down what you send that must still be secret in 2035.** This is the federal test from M-23-02 applied to a business with fewer than fifty people. One page. Client files, financial records, credentials, contracts, code, anything under NDA. Rank it by secrecy lifetime, not by how sensitive it feels today. Data with a two-year lifetime is not a harvest-now problem. Data with a fifteen-year lifetime is.

**4. Ask your vendors four specific questions.** Vague questions get vague answers, so use these words:

- Does your service negotiate a post-quantum hybrid key exchange such as X25519MLKEM768 on the specific hostnames my systems connect to? Which hostnames do not?
- Is post-quantum key exchange enabled between your edge and your origin servers, or only at the edge?
- What is your published date for supporting FIPS 203 in the product I license, and does that date come from your roadmap or from a standards deadline?
- For VPN and router firmware: which release supports CNSA 2.0, and what is your date for the 2030 exclusive-use requirement?

The fourth is the useful filter. Networking equipment carries the earliest hardware deadline in the NSA schedule, support and prefer by 2026, exclusive by 2030, and a vendor with no answer for it has not started.

**5. If your site sits behind a CDN, check the origin leg specifically.** That is the 13.1% number turned into a task. Your visitors may already be protected as far as the edge while the hop to your own server is not.

## How to tell a real requirement from a manufactured one

There is money in this topic now, and where there is money there is a particular kind of pitch: a countdown clock, an invented date for "Q-Day", and a quote in the low five figures for an assessment.

Three tests separate a real requirement from a sales cycle.

**Does the deadline come with a document number?** Every date in this article traces to a specific publication: FIPS 203, 204 and 205 from 13 August 2024, draft NIST IR 8547 from 12 November 2024, the NSA's CNSA 2.0 advisory and its FAQ, NSM-10 from 4 May 2022, OMB M-23-02 from 18 November 2022. If a vendor's urgent date has no document behind it, it is a marketing date.

**Does the vendor sell the remedy its own statistic implies?** The 71.1% and 13.1% figures I used come from Cloudflare, which sells the edge service that produces the 71.1%. That does not make the numbers wrong, and I have no reason to think they are. It does mean the framing of the gap flatters the seller, and you should notice when a company's headline measurement happens to also be an advertisement for its product. I used those figures because I could not find an equivalent measurement anywhere else at that scale, and I would rather tell you the interest is there than pretend it is not.

**Is the fix something you already own?** Most of the actual remediation in this article is a version number. Update the browser. Update OpenSSH. Ask the host to turn on a setting they already support. The paid work is real for large estates with custom cryptography and hardware that cannot be replaced quickly. For a business running a website, email, a VPN and some SaaS, the honest scope is an afternoon of testing, a one-page inventory, and four questions in an email.

The last thing to keep hold of is this. The IBM announcement is genuinely good engineering news, and good engineering news about quantum computing is exactly the kind that tends to arrive on time. Starling in 2029 will not break your encryption. Blue Jay, in 2033 or later, sits inside every published deadline in this article. The traffic you send today is the part you cannot go back and fix. So test the hostnames, note what has a long secrecy lifetime, and get the version numbers current. That is a Monday, not a project.

## Fact-check notes and sources

- **The cryogenic milestone**, the dimensions, the cooldown times and the wiring-space figure all come from [IBM's newsroom release of 19 August 2026](https://newsroom.ibm.com/2026-08-19-ibm-connects-its-first-modular-cryogenic-systems-in-milestone-toward-fault-tolerant-quantum-computing). The "more than 180 times colder than deep space" comparison is IBM's own framing, not an independent measurement, and the "up to 12 times more wiring space" is stated relative to IBM's own most widely used systems rather than to any competitor's.
- **Starling's specification** of 100 million gates on 200 logical qubits by 2029, the bivariate bicycle qLDPC error correction, the [[144,12,12]] gross code with 288 physical qubits, and the Loon, Kookaburra and Cockatoo roadmap years come from IBM's technical post, [How IBM will build the world's first large-scale, fault-tolerant quantum computer, 10 June 2025](https://www.ibm.com/quantum/blog/large-scale-ftqc). The "10 times fewer qubits than the surface code" claim is IBM's own.
- **The roadmap years** for Nighthawk in 2026 and 2028 and for Blue Jay in 2033 or later come from the [IBM Technology Atlas quantum roadmap](https://www.ibm.com/roadmaps/quantum/), observed 21 August 2026, and Nighthawk's 120 programmable qubits from [IBM's quantum technology page](https://www.ibm.com/quantum/technology), observed the same day. Read that roadmap carefully: the year headings on the tiles do not always match the systems described inside them, and the tile headed 2030 is where the sentence placing Starling in 2029 actually sits.
- **I could not verify a figure for how many logical qubits breaking RSA-2048 would require**, so I have not given one. Published estimates exist in the academic literature and vary considerably with assumptions about error rates and runtime. I would rather leave a gap than quote a number I did not check.
- **The three finalised NIST standards**: [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final), [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) and [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final), all published 13 August 2024, with NIST's "start integrating immediately" advice from its [announcement of the same date](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards).
- **HQC** was selected on 11 March 2025 with a finalised standard expected in 2027, per [NIST's announcement](https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption). That same announcement said the FALCON-based FIPS 206 would be released "shortly". My statement that no FIPS 206 draft exists as of 21 August 2026 rests on the NIST publications catalogue returning no publication for it. That is an absence of evidence rather than a NIST statement that the standard is delayed, and it should be read that way.
- **The 2030 deprecation and 2035 disallowance dates** come from Tables 2 and 4 of [NIST IR 8547, initial public draft, 12 November 2024](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf). Two caveats, both load-bearing. First, this is a draft whose comment period closed on 10 January 2025 and which has no final version at the time of writing, so the dates are proposed rather than settled. Second, the tables are easy to misread out of the PDF because the transition column separates from its parameter row in extracted text; the pairing I have used (112-bit security deprecated after 2030 and disallowed after 2035, 128-bit and above disallowed after 2035) is the one confirmed by the surrounding prose of the same document. The earlier SP 800-57 plan to disallow 112-bit schemes on 1 January 2031 is described, and superseded, in that same draft.
- **The harvest-now-decrypt-later framing** is stated by the joint [CISA, NSA and NIST factsheet on quantum readiness, August 2023](https://www.cisa.gov/sites/default/files/2023-08/Quantum%20Readiness_Final_CLEAR_508c%20%283%29.pdf), by NIST IR 8547, and by [Apple's PQ3 announcement of 21 February 2024](https://security.apple.com/blog/imessage-pq3/). I have used a government source for the risk claim rather than a vendor one, deliberately.
- **The CNSA 2.0 category deadlines** are from the NSA advisory [Announcing the Commercial National Security Algorithm Suite 2.0](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF). The tighter CNSSP 15 dates of 1 January 2027, 31 December 2030 and 31 December 2031 are from the [NSA's CNSA 2.0 and quantum computing FAQ, version 2.1, December 2024](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF). Both documents are current and they disagree by roughly two years. I have printed both rather than picking one. The NSA also states in the FAQ that it intends all National Security Systems to be quantum-resistant by 2035.
- **The 2035 government target** is from [National Security Memorandum 10, 4 May 2022](https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/), and the annual inventory requirement with its 4 May 2023 first due date from [OMB M-23-02, 18 November 2022](https://bidenwhitehouse.archives.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf), whose footnote 11 contains the "recorded now, decrypted in 2035, still mission sensitive" test I have adapted for small businesses.
- **The $7.1 billion figure** is from the [July 2024 report to Congress required by the Quantum Computing Cybersecurity Preparedness Act](https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/07/REF_PQC-Report_FINAL_Send.pdf). It covers prioritised federal systems between 2025 and 2035 in 2024 dollars, excludes national security systems, and the report itself calls it a rough order of magnitude with a high level of uncertainty. It is a projection, not an accounting.
- **The 71.1% and 13.1% adoption figures** were observed on [Cloudflare Radar's post-quantum page](https://radar.cloudflare.com/post-quantum) on 21 August 2026. Read them with the source in mind: this is measurement of traffic across one company's network, published by a company that sells the edge service producing the high number, and the origin figure covers scanned customer origins behind that same network rather than the internet as a whole. It is the best measurement at that scale I could find, and it is not a probability sample of businesses.
- **Browser support**: the [Chrome Platform Status feature record for X25519Kyber768 key encapsulation](https://chromestatus.com/feature/5257822742249472) documents the Chrome 124 default and the enterprise policy being available through Chrome 145 and removed in Chrome 147. The Chrome 131 floor is carried by Cloudflare Radar's browser-support text rather than by Google, because Chrome 131's own [release notes](https://developer.chrome.com/release-notes/131) contain no mention of post-quantum cryptography at all. Chrome 131 reached stable on 12 November 2024 per those notes. [Firefox 132's release notes, 29 October 2024](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) document mlkem768x25519.
- **OpenSSH** dates and behaviours come from the [OpenSSH release notes](https://www.openssh.com/releasenotes.html): 9.0 on 8 April 2022, 9.9 on 19 September 2024, 10.0 on 9 April 2025 and 10.1 on 6 October 2025. **OpenSSL 3.5.0** on 8 April 2025 from the [3.5 series notes](https://openssl-library.org/news/openssl-3.5-notes/). **Signal**: [PQXDH, 19 September 2023](https://signal.org/blog/pqxdh/) and [the Sparse Post Quantum Ratchet, 2 October 2025](https://signal.org/blog/spqr/).
- **My own handshake measurements** were taken on 21 August 2026 on one machine using OpenSSL 3.5.6, testing fourteen hostnames in total. Nine negotiated X25519MLKEM768 and five refused a post-quantum-only handshake. This is a single sample from a single day on a single network path, not a survey, and any of those results can change without announcement, which is exactly why the article tells you to run the test yourself rather than trust my list. jwatte.com was among the hosts that did not negotiate a post-quantum group on that date.

## Related reading

- [Post-quantum cryptography for small sites](/blog/blog-tool-pqc-analyzer/): the practical migration path, and a browser-side tool that checks your own site.
- [Why the PQC migration plan generator exists](/blog/blog-tool-pqc-migration-plan-generator/): turning the inventory step above into an actual written plan.
- [DNSSEC post-quantum posture audit](/blog/blog-tool-dnssec-pqc-posture-audit/): the layer underneath TLS, which almost nobody checks.
- [Crypto wallet quantum risk audit](/blog/blog-tool-crypto-wallet-quantum-audit/): if you hold digital assets, the exposure model is different and worse.
- [What quantum did and did not do to the data center bet](/blog/quantum-vs-data-center-energy/): the other half of the quantum story, where the noise was louder than the physics.

*This post is informational and is not legal, security or financial advice. Standards documents, roadmaps and vendor support statuses are as published on the dates cited and change frequently, and at least one of the documents quoted here is still a draft. No affiliation with any vendor mentioned is implied, and mentions are nominative fair use.*


---

Canonical HTML: https://jwatte.com/blog/quantum-fault-tolerance-2029-what-to-do-now/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/quantum-fault-tolerance-2029-what-to-do-now.webp