Only 23% of companies say they can swap their own cryptography quickly. What’s missing from the spreadsheet is the right to change.

The side that managed to change

At the end of September, Cloudflare published a figure I find more revealing than any forecast about quantum computers. Roughly 70% of browser-generated traffic crossing its network already uses post-quantum cryptography, the new generation of algorithms built to withstand those machines. On the other end of the connection, on company servers, the share is about 15%.

The gap has nothing to do with available technology. The algorithms are the same ones, standardised by NIST in August 2024. It has to do with who is able to make the switch.

Google turned on post-quantum protection by default in Chrome in 2024. Apple added it to iMessage the same year and, according to Cloudflare's annual review, iOS 26 helped lift the post-quantum share of traffic from 29% to 52% over the course of 2025. Signal had done it in 2023. Companies that control their own software stack, from the code to the update on the customer's device, changed in months.

Everyone else is still trying to work out where to change.

Ten to twenty years

NIST, the US standards institute, is not given to drama. Even so, in a November 2024 document (the draft of NIST IR 8547) it wrote that the path from standardising an algorithm to actually integrating it into systems can take 10 to 20 years. In the same text, it proposed that RSA and elliptic-curve cryptography, the foundation of internet security today, be deprecated after 2030 and disallowed after 2035.

Recent history bears out the timeline. SHA-1, a cryptographic hash algorithm in use since 1995, was deprecated by NIST in 2011. The first practical collision, the proof that it was broken, came in February 2017. Its official retirement is set for the end of 2030. TLS 1.0, the protocol that had protected web connections since 1999, was only formally prohibited in March 2021, 22 years after it was born.

When the White House estimated, in July 2024, what it would cost to migrate US federal government systems to post-quantum cryptography between 2025 and 2035, the figure came to about $7.1 billion. The same report concedes that automated tools may not find every place where the old cryptography is in use.

The bottleneck isn't the algorithm

Capgemini surveyed executives at 1,000 large companies in 13 countries for its July 2025 report "Future encrypted". Seven in ten organisations were already assessing or deploying some form of post-quantum protection. Among executives at the companies that had started, only 35% said they keep a centralised inventory of every key, algorithm and certificate in use. Only 23% agreed that their IT infrastructure was designed to allow rapid updates or replacements.

And just 40% said they could respond effectively to a critical flaw in a library such as OpenSSL, a component that sits inside a large share of the world's servers.

DigiCert repeated the exercise in May 2026, with 1,001 IT and security decision-makers in the United States, the United Kingdom and Australia. Eighty-seven per cent are planning, testing or implementing the migration. Only 7% have deployed. The most frequently cited barrier was the complexity of legacy systems.

Nearly everyone plans. Switching is another matter.

Decision debt

We know the idea of technical debt well: the shortcut that works today and charges interest later. What the post-quantum migration exposes is a cousin of it, which I would call decision debt. These are choices that were reasonable when they were made but that nobody designed to be undone. Hardware that will stay on the factory floor for 15 years. A ten-year contract built on a proprietary API. An algorithm scattered across hundreds of systems, each implemented its own way.

In December 2025, NIST published the final version of a document devoted entirely to this, CSWP 39. It defines crypto-agility as the ability to replace and adapt algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. Note that the definition says nothing about choosing the best algorithm. It talks about being able to replace it without bringing the business to a halt.

In the Capgemini report there is a line from Luciano Carolino, of Bradesco (one of Brazil's largest banks), that sums up the shift in mindset: crypto-agility is a core objective for the bank. It is not about picking the right algorithm. It is the ability to switch when it stops being right.

Perfect security is also rigidity

Here is a view that tends to irritate people who buy technology. The solution that is most secure, cheapest or fastest on the day of purchase may be the most expensive to abandon. The deeper a technology reaches into the business, and the more it is optimised and customised, the harder it becomes to remove.

I am not arguing for buying worse. I am saying that replaceability has become a product attribute, as concrete as performance and cost. And almost no vendor evaluation I know of scores it.

Three choices to win back the right to change

1. Put the exit into the procurement evaluation. Before you sign, ask the vendor how you would replace the algorithm, the key or the vendor itself, how long it would take and what it would cost. If the answer is vague, that is an answer too.

2. Concentrate cryptography instead of scattering it. Algorithms chosen inside each system, by each team, are the scenario that turns a switch into a multi-year project. When cryptography runs through a central point, switching becomes a matter of configuration.

3. Time a real switch. Pick a critical certificate or algorithm and simulate replacing it. How long did it take to find where it was? Who had to be called in? This is the rehearsal that separates the 40% who can respond to a critical flaw from the 60% who would find out on the day.

The question for the next contract

At the next renewal of an important system, ask a question that rarely makes it onto the table: if three years from now this technology, or this vendor, stops being a good choice, how much time and money will it take us to get out?

Browsers are already past 70%. Company servers are close to 15%. The difference was not courage. It was who had managed to keep the right to change.