Post-quantum cryptography has a timing problem. The threat — a quantum computer capable of breaking today’s public-key algorithms — sits at an uncertain point in the future. The work required to prepare for it sits squarely in the present, and it is larger than most organisations assume.
The NCSC has made the sequence clear. By 2028, organisations should have defined their migration goals, completed a discovery exercise and built an initial plan. By 2031, the highest-priority migrations should be complete. By 2035, migration should be finished.
The 2028 milestone is the one that matters now, because everything else depends on it.
Why discovery is harder than it sounds
On paper, discovery is an inventory: find every place cryptography is used, record the algorithm, and note what it protects. In practice, cryptography is everywhere and documented almost nowhere.
It lives in application code and third-party libraries. It lives in TLS configurations, VPN concentrators, load balancers and service meshes. It lives in PKI hierarchies, hardware security modules, code-signing pipelines and firmware. It lives in your suppliers’ products, many of which you cannot inspect directly. And it lives in long-forgotten integrations that nobody currently employed has touched.
Automated tooling helps, but no single tool sees all of this. Effective discovery combines scanning of code, configuration, certificates and network traffic with structured engagement with system owners and suppliers — and that second part takes time.
Why the timing matters now
Two things make this urgent despite the uncertainty about quantum timelines.
The first is harvest now, decrypt later. Data encrypted today can be captured and stored by an adversary, then decrypted once capable quantum computers exist. If your data needs to stay confidential for a decade or more — customer records, intellectual property, government or financial information — the exposure has already begun.
The second is lead time. In a large enterprise, migrating cryptography touches applications, infrastructure, procurement and suppliers. The organisations that find it manageable will be the ones that finished discovery early and used natural refresh cycles, rather than forcing change under deadline pressure.
A practical approach to 2028
Set scope and ownership first. Post-quantum migration fails when it is treated as a purely technical task. It needs an accountable owner, a steering group that includes procurement and the business, and board visibility.
Discover in layers. Start with what you can see — certificates, TLS endpoints, key management systems — and work towards what is harder to reach: embedded libraries, legacy systems and supplier products.
Prioritise by data longevity and exposure. Not everything needs to move at once. Rank systems by how long the data they protect must remain confidential, how exposed they are, and how difficult they will be to migrate.
Engage suppliers early. Ask them for their post-quantum roadmaps now, and build post-quantum requirements into procurement so new purchases do not add to the problem.
Build in crypto-agility. The algorithms standardised by NIST in 2024 — ML-KEM for key establishment, and ML-DSA and SLH-DSA for signatures — will not be the last change. Design so that the next transition is a configuration change, not a programme.
The board conversation
Boards are used to risks with clear deadlines. Post-quantum readiness does not have one for the threat, but it now has one for the preparation. Framing the 2028 milestone as the first, fundable step in a multi-year programme — with clear ownership, a prioritised inventory and a supplier plan — is usually what turns an abstract risk into an approved budget.
Our PQC Discovery & Migration Roadmap engagement is designed around exactly this milestone.