lgkm.org

Field notes · 26 October 2026 · Architecture and strategy

Post-quantum migration starts with a cryptography inventory

In plain words: Future computers may break today's locks, so first find every lock you have, which is much harder than it sounds. Architecture and strategy, explained simply

In short

A timeline from 2026 to 2035: inventories and discovery come first, then the most important migrations, then everything else
A timeline from 2026 to 2035: inventories and discovery come first, then the most important migrations, then everything else

Why there is a deadline at all

Most of the public-key cryptography in use today, RSA and elliptic curves, would be broken by a large enough quantum computer. Nobody can say when one will exist, but two things make the date less important than it sounds. Data copied today can be decrypted later, so anything that must stay secret for ten years or more is already exposed to a future machine. And replacing cryptography across a large estate has always taken years.

The replacements exist. In August 2024 NIST published its first three post-quantum standards: ML-KEM for setting up keys (FIPS 203), and ML-DSA and SLH-DSA for signatures (FIPS 204 and 205). NIST's advice at the time was to "start integrating them into their systems immediately". Its draft transition plan, NIST IR 8547, proposes deprecating today's quantum-vulnerable algorithms in 2030 and disallowing them after 2035.

Other governments have set similar dates. The NCSC's migration timeline, published in March 2025, asks organisations to define their goals, carry out discovery and build a plan by 2028; to finish the highest-priority migrations by 2031; and to complete migration "of all your systems, services and products" by 2035. The EU's coordinated roadmap from June 2025 asks member states to start cryptographic inventories and map dependencies by the end of 2026, to protect high-risk uses by the end of 2030, and to cover as much as possible by 2035.

Why the inventory is the hard part

Cryptography is not a product you can count. It sits in TLS on websites and APIs, in VPNs, in the certificates that devices and services use to prove who they are, in code signing, in database and disk encryption, in hardware security modules, in smart cards and tokens, and inside libraries that applications pull in without anyone choosing an algorithm. A good share of it belongs to suppliers: cloud services, SaaS, payment terminals, medical devices, building controls.

The NCSC is clear that this is not meant to be a formal asset register. What it asks for is an understanding of the estate: the key services, the data each holds and how long it stays valuable to an attacker, how that data is protected in transit and at rest, and the dependencies, including managed service providers. For the services an organisation runs itself, it asks for a more detailed map of cryptographic components, worked both top down from the business services and bottom up from what is actually on the wire and in the code.

That double approach matters. Top down tells you what matters most: the long-lived secrets, the signing keys that devices will trust for fifteen years, the systems that would hurt most if their traffic were read later. Bottom up tells you what is really there, which is usually more than anyone expected: old libraries, hard-coded algorithms, certificates nobody remembers issuing.

What the inventory is for

Ask what will use the inventory before building it. My own view is that it has three jobs.

  1. Ranking. Which systems protect data with a long secrecy life, or carry trust anchors that are hard to replace, such as firmware signing keys or device roots of trust? Those go first, because the 2031 milestone is about them.
  2. Supplier questions. A large share of the change will arrive in vendor releases. The CISA, NSA and NIST quantum-readiness factsheet of 2023 already put "engaging vendors" next to inventories and roadmaps. Knowing which suppliers hold which pieces turns a vague letter into specific questions with dates.
  3. Agility. The aim is to be able to change an algorithm, a key length or a certificate without a project each time. That need is not hypothetical: under the CA/Browser Forum's ballot SC-081, the longest a public TLS certificate may last falls in steps: from 398 days to 200 days in March 2026, 100 days in March 2027 and 47 days in March 2029. An organisation that can renew every certificate automatically, and knows where each one lives, has done much of the groundwork for post-quantum migration as well.

This is why I would rather treat the inventory as a live record fed by scanning, certificate management and software composition analysis than as a consultant's report. A list compiled once in 2027 will be wrong by 2029.

What to do on Monday

The Ascent of Security Architecture on the home page describes later stages as ones that sense and adapt. An estate that cannot change its own cryptography quickly will find those stages hard to reach, whatever else it runs.

Sources

Follow with the feed

Personal work and my own view, not my employer's. Sources are public.