I recently had the privilege of attending a roundtable dinner hosted by Avella, where a room full of people who think about this for a living discussed where quantum computing, AI and cyber security collide. Good food, better conversation, and one discussion thread that really stuck with me.
Almost every conversation about the quantum threat to encryption is about the encryption. New algorithms, new libraries, new hardware. Find everything running RSA, swap it for something with a lattice in the name, and tick it off before the deadline.
That makes post-quantum cryptography look like two things: a purely technical exercise, and an obsolescence problem. A very large, very expensive version of replacing the Windows 10 laptops before support runs out.
It's the wrong framing.
Your traffic is already in someone's loft
The reason is harvest now, decrypt later. A well-resourced adversary doesn't need a quantum computer today to benefit from one tomorrow. They just need storage, and storage is cheap. Intercept the traffic now, box it up, put it in the loft and wait for the maths to catch up.
To be precise, the exposure sits with public-key cryptography: the RSA and elliptic curve key exchange that protects almost everything crossing a network, from TLS sessions to VPN tunnels. AES-256 sitting quietly on a disk is not what keeps cryptographers up at night. But "anything that has crossed a network under today's key exchange" still covers most of what most organisations care about.
So the uncomfortable assumption is this: if it has already left the building, you should assume someone may eventually read it. No number of shiny new algorithms changes what was captured last Tuesday.
Which means the question isn't "when will we have migrated?" It's "what are we holding that will still matter when someone can read it?"
Not every secret ages the same way
I spent a long time in the RAF working with material classified SECRET, and one thing you learn quickly is that a classification is a snapshot, not a life sentence.
Take an operation. The plan itself (the timings, the targets, where the aircraft are and when they'll be somewhere else) is acutely sensitive right up until it isn't. Once the mission has flown and the assets have moved on, that information is history. Interesting to historians, of limited use to an adversary.
The material underneath the plan is a different animal. The tactics. What the aircraft can really do, and what it can't. How the pieces fit together. That stays SECRET for years, sometimes decades, because it's just as useful to someone planning against the next operation as it was for the last one.
Every organisation holds both kinds, whether or not it has ever seen a protective marking in its life.
The only sum that matters
Michele Mosca framed this neatly years ago. Take how long your data needs to stay confidential. Add how long it will take you to migrate. If the total is longer than the time until a cryptographically relevant quantum computer turns up, you already have a problem. Not a future problem. A current one.
The beauty of this is that you don't have to win the argument about when Q-Day arrives. Nobody credible will give you a date, and debating one is a very sophisticated way of doing nothing. You only need to be honest about the two numbers you actually control.
For context, the NCSC's own timeline runs to 2035 for full migration. If you hold data that needs to stay secret for ten years or more, do the sum.
So what are you actually holding?
In defence, the answer is fairly obvious: technical documentation, capability data, intelligence, and the IP that runs through the supply chain. But this isn't only a national security problem.
Think about special category personal data. Health records, biometrics, information about someone's ethnicity, sexuality or beliefs. None of that stops being sensitive in five years. A medical history exposed in 2035 does exactly the same damage as one exposed today, and the regulator is unlikely to be impressed that the breach simply happened in slow motion.
Commercial organisations have their own long-lived secrets too: deal material, product roadmaps, source code, contract terms. Some of it goes off quickly. Some of it really doesn't.
Start with the data, not the algorithms
None of this means the cryptographic migration doesn't matter. It does, and it will take most organisations years. But if you start from an inventory of algorithms, you'll end up replacing things in the order they were easiest to find rather than the order they matter.
Start instead by asking two questions about each category of data you hold. How long does this need to stay secret? And has it ever crossed a network? That gives you a migration priority list grounded in business impact, not in whichever system happened to shout loudest.
It also surfaces the cheapest post-quantum control there is. Data you've deleted can't be decrypted as long as it hasn’t left your network boundary. If you're sitting on special category data you no longer need, or a decade of project archives nobody has opened since they were zipped, the best quantum-safe algorithm available to you is the delete key. Your data protection officer will thank you too.
Quantum-safe encryption will protect what you send tomorrow. For everything you sent yesterday, the only defence left is knowing which of those secrets still matter. Because someone else may already have a copy.