Harvest Now, Decrypt Later: The Data Breach That's Already Happening

Somewhere on a server you'll never see, a copy of your encrypted data might already be sitting in a queue. Not to be cracked today — nobody can do that yet — but stored, patiently, until the tools exist to open it. Your customer records, your legal correspondence, your intellectual property, your health data. All scooped up while it's protected, all waiting for the day the protection stops mattering.

This is called Harvest Now, Decrypt Later, and it is not a plot device. It's the working assumption behind serious national security policy in the UK, the US and across the EU. The logic is simple and uncomfortable: if data will still be sensitive in ten years, and if a quantum computer capable of breaking today's encryption is expected within that window, then intercepting and storing that data now is a rational move for any well-resourced attacker. State actors have the storage, the patience and the motive.

The part most business owners miss is the timing. People hear 'quantum' and mentally file it under 2035, or 'not my problem'. But the harvesting is happening in the present tense. And according to DigiCert's most recent research, only around 7% of organisations have actually deployed quantum-safe certificates. Ninety-three percent are exposed to a risk that's already in motion.

Why 'we'll deal with it later' doesn't work here

Most security threats give you a chance to respond after the fact. Ransomware hits, you restore from backup. A phishing email gets clicked, you reset credentials and tighten training. Painful, but recoverable.

Harvest Now, Decrypt Later removes the recovery option entirely. If someone copies your encrypted data today and decrypts it in 2032, there is nothing to restore, no password to change, no incident to contain. The breach already happened — you just find out about the consequences years later, when a data set you assumed was safe turns up somewhere it shouldn't.

That changes the maths on urgency. The right question isn't 'when will quantum computers arrive?' It's 'how long does my data need to stay secret, and does that window overlap with the arrival of quantum decryption?'

Run that calculation for a typical UK SME and it gets uncomfortable fast. Medical records must be kept for years. Financial records: at least six years for tax purposes. Employment records, conveyancing files, pension data, contracts, trade secrets — all have shelf lives measured in decades, not months. If your data has a ten-year sensitivity horizon and credible estimates put cryptographically relevant quantum computers somewhere in the early-to-mid 2030s, the overlap is already here. Data you encrypt this afternoon could be decrypted well within its protected lifespan.

The deadlines are already written down

This isn't just a theoretical worry that standards bodies are mulling over. The rules are being set.

In August 2024, NIST published its first finalised post-quantum cryptography standards — including ML-KEM for key exchange and ML-DSA for digital signatures. These are the algorithms designed to withstand quantum attacks, and they're no longer drafts. They're the new baseline.

The US National Security Agency's CNSA 2.0 timeline sets firm expectations, pushing for quantum-resistant algorithms across software and firmware signing by 2025 and broad adoption through the end of the decade. Closer to home, the UK's National Cyber Security Centre has published its own migration guidance, laying out a phased approach with milestones stretching to 2035 — but with the clear message that discovery and planning should be happening now, not at the deadline.

For UK SMEs, the practical upshot is that this will filter down whether you follow the standards bodies or not. Your enterprise customers will start asking about your cryptographic posture in tenders and supplier audits. Cyber insurance questionnaires will add quantum-readiness questions. Regulated sectors — finance, healthcare, legal — will find it baked into compliance frameworks. Being in the 93% won't be a quiet gap for much longer.

Why so few have moved

If the risk is real and the standards are set, why is deployment stuck at 7%?

Part of it is perception — the 2035 framing has made it easy to defer. Part is complexity. Cryptography is buried deep in systems: TLS certificates on your websites and services, VPNs, code signing, email encryption, the certificates baked into applications you didn't even know used them. You can't protect what you can't see, and most organisations have no clear inventory of where cryptography lives across their estate.

There's also a genuine fear of breaking things. Swap out an algorithm carelessly and you can take down a service, block legitimate users or break integrations with partners. That fear is reasonable, which is exactly why the work needs to start early and move methodically rather than in a panic when a deadline looms.

A crypto-inventory-first plan you can start this quarter

You don't need to rip everything out tomorrow. You need to know what you have and build a path. Here's a sequence any SME can begin with, ideally alongside an IT partner who can do the heavy lifting.

1. Build a cryptographic inventory. This is the foundation, and it's the step almost everyone skips. Catalogue every place cryptography is used: TLS certificates and their expiry dates, VPN configurations, encrypted databases and backups, code-signing certificates, email encryption, any bespoke applications. Automated discovery tools exist to help — you shouldn't be doing this on a spreadsheet from memory. The goal is a single map of your cryptographic footprint.

2. Classify by data lifespan. For each system, ask how long the data it protects needs to stay confidential. A marketing landing page: not much. A client health record or a fifteen-year contract: a lot. This tells you where the harvest-now risk actually bites, so you can prioritise instead of trying to boil the ocean.

3. Identify your highest-risk, longest-lived data. Cross-reference the inventory with the classification. Anything holding long-shelf-life sensitive data over the public internet or across networks that could be intercepted goes to the top of the list. These are your first migration candidates.

4. Pressure-test your suppliers. Much of your cryptography is inherited from vendors — your cloud provider, your SaaS tools, your certificate authority. Ask them directly: what's your post-quantum roadmap, and when will you support the NIST standards? Their answers should shape your timeline, and their silence should worry you.

5. Pilot quantum-safe certificates. Start with a contained, non-critical service and deploy quantum-safe or hybrid certificates that combine classical and post-quantum algorithms. Hybrid approaches let you gain protection now without betting everything on one algorithm. Learn where the friction is before you scale up.

6. Build crypto-agility into everything. The lasting goal isn't a single migration — it's the ability to swap algorithms quickly whenever standards shift again. Systems designed so cryptography can be changed without a rebuild will handle the next transition, and the one after that, far more easily.

Start with the inventory, start this month

The honest position is that most UK SMEs are exposed, most don't know the size of their exposure, and the harvesting doesn't wait for anyone to feel ready. You can't decrypt someone else's copy of your data back into safety. The only lever you control is making sure the data you protect today is genuinely protected against tomorrow's tools.

The 7% who've deployed quantum-safe certificates didn't get there by waiting for 2035. They started by finding out what they had. That first step — a proper cryptographic inventory — costs you nothing but attention, and it's the difference between being able to plan and being caught out. If you'd like help mapping your cryptographic estate and building a migration plan that fits an SME budget, that's a conversation worth having now, while the timeline is still on your side.