Quantum readiness: Waiting for Q-Day is not a security strategy.

Quantum computing, (when you strip out all the jargon), comes down to the fundamental difference from today’s computers which store information as a 1 or a 0 (on or off), like a light switch. Whereas, quantum computers work with qubits, which can hold a blend of states at once, a bit like how your own thinking rarely settles on a single binary answer. That difference, scaled up, gives quantum machines the potential to perform certain calculations (including the maths underpinning most modern encryption) at a speed classical computers simply can’t compete with.

I’m talking about a fundamentally different category of computing power.

Right now, quantum computers only exist in highly controlled lab environments. They need extreme cold, total stability, and conditions you are not going to recreate in a corporate server room. Most credible estimates put genuinely disruptive, large-scale quantum computing somewhere in the 10-to-15-year range. Nobody serious is telling clients to rip out their infrastructure and “go quantum” next quarter.

However, that timeline doesn’t buy you the comfort it sounds like it should. Those 10-to-15-year estimates were largely set before generative AI existed in its current form, and AI is now actively accelerating research timelines across the board. A “decade away” prediction made a few years ago might already be ageing faster than anyone bargained for. And because most of the genuinely advanced quantum research is happening behind closed doors (government labs, defence programmes, the sort of places that don’t publish progress updates on LinkedIn) there’s no reliable early warning system and you won’t get a press release.

There’s a name for the moment quantum computing becomes powerful enough to break today’s standard encryption. People call it Q Day, and Q Day comes with no warning shot. There’s no countdown banner and no “end of support” notice. One day, your encryption works exactly as it always has and the next, it simply doesn’t. There is no gradual fade, no grace period, no patch Tuesday, the lock just stops being a lock.

This is where harvest now, decrypt later comes in, and it’s the bit of this conversation that should concern anyone holding sensitive data.

State actors and well-resourced adversaries don’t need to break your encryption today, they just need to copy it.

VPN traffic, encrypted file transfers, intercepted communications, all of it gets quietly harvested and stored, fully scrambled, completely useless to them right now. They are, in effect, patiently filling a warehouse with locked boxes, confident that one day they’ll own a master key that opens every single one at once.

The moment Q Day arrives, that entire stockpile becomes readable, instantly, that’s years of sensitive data.

So, the real question isn’t “are we ready for quantum computing?”, that’s the wrong conversation, and it’s a decade too early to even be useful. The right question is: “How much of the data we’re generating today still needs to be secret in ten or fifteen years?”

If you work in finance, healthcare, government, defence, or anywhere with regulatory retention requirements measured in years rather than months, the answer is, quite a lot of it. Which means the work to protect it has to start now, not when quantum computing finally arrives. By the time it’s front-page news, it’s too late to do anything about the data already sitting in someone else’s archive.

Here’s where this stops being doom and starts being genuinely manageable, because the solution isn’t some exotic, eye-wateringly expensive quantum-proof everything.

It’s mostly about how often you change your keys.

Most organisations rotate encryption keys annually, sometimes less often. That was always going to feel a bit lazy, but it’s about to become actively dangerous. The fix isn’t a new encryption algorithm; it’s re-keying far more frequently, daily, hourly, in some cases per packet, so that even if an adversary is harvesting your traffic today, the value of any single stolen key collapses almost immediately.

For the super-technical people reading this, yes, post-quantum cryptography exists and NIST has publicised new standards for this. However, what I’m suggesting here is that a legitimate mitigation to limit the ‘blast radius’ of any single compromised key is rotation, as AES-256 is considered reasonably quantum-resistant on its own. This ensures the move to Q Day mitigation is accessible and affordable for the vast majority of readers.

There are hardware solutions that handle this automatically, re-keying on a constant cycle without anyone touching a device. There are software and cloud-based equivalents that do the same job for organisations who’d rather not send an engineer driving across the country with a key fob. In most cases, the physical infrastructure you already have can stay exactly where it is, this isn’t a rip-and-replace project. It’s a discipline and process project, which is both less glamorous and considerably cheaper than the alternative.

That, is the actual headline here, this isn’t a problem that needs a multi-million-pound transformation programme. It needs a key management strategy that takes the human element (and all the road trips) out of the equation.

One genuinely interesting note (because I can’t resist a good story), the encryption hardware available to ordinary businesses today is often the exact same kit used in defence and military environments with the same specification and capabilities. The only difference on the military version is a self-destruct button! Which is a slightly alarming sentence to type, but also rather reassuring as it tells you that serious protection isn’t locked away behind some unreachable price tag.

If you’re an IT Director, a CISO, or sat somewhere in the C-suite trying to work out where this lands on an already over-populated risk register, here’s the balanced version.

Quantum computing capable of breaking today’s encryption is not imminent, you don’t need a quantum strategy but you do need a data sensitivity strategy, and you need it now, because adversaries operating on a harvest-now-decrypt-later basis are not waiting for your roadmap to catch up.

Start with three questions:

• What data are we generating today that still needs to be confidential in a decade?

• How often are we rotating our encryption keys?

• And who has clear ownership of that answer?

If you can’t answer all three with confidence, you’re not alone (most organisations can’t), and that’s precisely the gap adversaries are counting on. The good news is that none of those questions require a quantum physicist, a huge budget, or a steering committee. They require an honest data audit and a sensible conversation with whoever owns your encryption estate.

When I first started having these conversations with customers, the most common reaction was “that’s not really a now problem, is it?”. I understand the instinct, it’s a future threat for a future date, and IT teams are drowning in genuinely urgent problems already.

But “harvest now, decrypt later” only works as a strategy because organisations keep treating it as tomorrow’s problem.

So, let me leave you with this, if someone is already collecting your encrypted traffic today, banking on reading it in ten years’ time, does your current encryption policy worry you a little more than it did five minutes ago?