Preparing your cryptography for post-quantum computing
Some of the messaging around quantum computing suggests an impending catastrophe. We would put it differently.
The risk is real, but it is manageable if you start early and work through it in the right order.
In a recent webinar, we asked attendees from central government and the private sector about their current position:
Seventy-three per cent were aware but had no formal plans.
Twenty per cent had started planning
Seven per cent were actively preparing.
This shows organisations are facing a real challenge in figuring out where to begin.
Helpfully, structured guidance does exist. Five governments have now published migration timelines, and they set out a clear order of work rather than just a deadline.
Where we currently are – the current global guidance
Five jurisdictions have now published formal migration timelines, and they broadly agree on the shape.
The UK National Cyber Security Centre (NCSC) sets three phases: discovery and planning to 2028, high-priority migration to 2031, and full completion by 2035.
The National Institute of Standards and Technology's (NIST) transition guidance deprecates RSA and elliptic curve after 2030, meaning they remain usable during migration but not for new deployments, and disallows them entirely after 2035.
Canada and the EU follow broadly the same 2031 and 2035 pattern, with EU member states due to produce national roadmaps by the end of this year.
Australia is the most demanding. The Australian Signals Directorate (ASD) expects traditional asymmetric cryptography to be retired outright by 2030, five years ahead of the point at which everyone else prohibits it.
Practical steps you can take now
Identify the locations where people use cryptography.
Public Key Infrastructure (PKI) grows organically. This means that cryptography is integrated into applications, devices, and cloud services, often without a central record. You should begin with your external systems, followed by identifying cryptographic touchpoints by exploring a "day in the life" of key user personas. Neither should require specialist tooling.
Together these build towards a cryptographic inventory. We have written separately on the discovery methods that reach the parts a network scan misses. As the picture matures, formalise it into a Cryptographic Bill of Materials (CBOM).
Ground every decision in risk.
Three timelines determine your exposure: when a cryptographically relevant quantum computer becomes available, how long your data and embedded systems must stay secure, and how long migration will take you.
The two variables within your control are where the attention should go. That also puts the decision at the right level, because it rests on a judgement about data and assets rather than about algorithms.
Note these artefacts are sensitive in their own right. An inventory that shows where your cryptography is weakest is useful to you and equally useful to an attacker, so classify and protect it accordingly.
Embed PQC into existing architecture governance.
Build the requirement into decisions you are already making. Separate cryptographic functions from applications using centralised services and APIs. This is what crypto agility requires in practice, and it is what makes every future algorithm change more manageable via a configuration change.
Add post-quantum capability to procurement specifications, so post-quantum cryptography (PQC) readiness is factored into every refresh cycle.
Know your data.
The question conventional classification does not answer is how long sensitivity lasts. Data that loses value in a year carries a very different risk profile to data that stays sensitive for thirty, and only the second category is exposed to harvest-now-decrypt-later.
In most organisations that category is far smaller than expected, which is what makes the scope manageable.
Apply a recognised application portfolio framework.
Models such as Gartner TIME (Tolerate, Invest, Migrate, Eliminate) sort applications based on technical fitness and business value. They fall into four groups: tolerate, invest, migrate, or eliminate. In PQC planning, this shows which systems should be upgraded, which will retire soon, and which will keep running but can't be changed.
The third group is the one that may catch you out, and it is far cheaper to find now than during delivery.
Conclusion
Global guidance mostly agrees on this approach: start with discovery and planning. Then, prioritise key systems and address everything else by the mid-2030s. The dates differ by jurisdiction, but the order stays the same.
This shows that the first phase is about visibility, not technology.
The 73% figure we opened with does not reflect a lack of awareness. It reflects a problem that sits across infrastructure, security, identity and application teams, where each holds a dependency and none holds the whole. Without a named owner, the work has no natural home and tends not to start.
The discovery and assessment described above require attention rather than budget, and they produce the evidence every subsequent decision depends on.
