Most security risks are about what could happen tomorrow. Post-quantum cryptography is unusual: the threat is years away, but the deadline to act is already here. That contradiction is why so many leaders file it under "later" — and why later is the wrong answer.
Here's the situation in plain terms. Almost everything that keeps digital life private relies on public-key cryptography — RSA and elliptic-curve maths that secures your website's TLS, your VPNs, your signed software updates, and the keys protecting your data at rest. A sufficiently powerful quantum computer would break that maths. One doesn't exist yet, and might not for years. So where's the urgency?
"Harvest now, decrypt later"
The urgency is that attackers don't need the quantum computer yet to attack you now. A well-resourced adversary can capture your encrypted traffic and data today and simply store it — then decrypt it the day a capable quantum machine arrives. It's called harvest now, decrypt later, and it quietly changes the maths of risk: any information that must stay confidential for the next decade or more is, in effect, already exposed. Patient records, legal and financial data, IP, state and infrastructure secrets — none of it benefits from the quantum computer being late if the ciphertext has already been copied.
That reframes the question from "when will quantum break encryption?" to "how long does my most sensitive data need to stay secret?" If the answer is longer than the time it takes quantum to mature, you have a problem today.
The good news: the replacements are ready
This isn't a research problem anymore. In 2024, NIST finalised the first post-quantum standards — ML-KEM for key exchange, and ML-DSA and SLH-DSA for digital signatures — algorithms designed to resist both classical and quantum attack. Standards bodies and governments have followed with migration guidance: the UK's NCSC lays out a path with milestones through 2028, 2031 and 2035, and, helpfully for a Microsoft-first estate, Microsoft is already building these algorithms into Windows and Azure. The tools are arriving; the work is being ready to use them.
You don't implement the maths — you get ready
For almost every organisation, PQC migration is not a cryptography project. You will not be writing lattice algorithms. Your job is readiness, in four moves:
- Inventory your cryptography. The single most valuable — and most skipped — step. Where is encryption used across your estate, by which systems and vendors, and how long must each dataset stay confidential? You cannot migrate what you cannot see, and the inventory is what turns a vague fear into a prioritised plan.
- Prioritise by data longevity and exposure. Long-lived secrets that cross untrusted networks go first; short-lived, low-sensitivity data can wait. Spend the effort where the harvest-now risk is real.
- Demand crypto-agility. The real deliverable isn't "install algorithm X" — it's building and buying systems that let you swap cryptographic algorithms without re-architecting. Today's PQC choices will themselves be revised; agility is what makes the next migration cheap.
- Press your vendors and cloud providers. Most of your cryptography lives in software and platforms you buy. Ask every critical vendor for their PQC roadmap now — their timelines are your timelines, and asking creates the demand that moves them.
During the transition, expect hybrid schemes — classical and post-quantum algorithms used together — so you keep today's guarantees while adding quantum resistance. That's a feature of a careful migration, not a delay.
Where this fits
Post-quantum readiness isn't a standalone panic; it's part of the same identity-first, evidence-led security posture behind our Cybersecurity & Resilience work — and it runs on the same foundation as an identity inventory and the governance discipline every serious programme needs. A cryptography inventory is just another asset inventory, pointed at your keys and algorithms.
The bottom line
Quantum computing will break today's encryption eventually, but "harvest now, decrypt later" makes it a 2026 planning problem, not a 2035 emergency. The standards exist, the platforms are adopting them, and the first step costs you a spreadsheet, not a supercomputer: find out where cryptography lives in your estate and how long your data must stay secret. Start the inventory now and you migrate calmly over years. Wait, and you'll do it in a panic — after the harvesting is already done.
Want help turning "we should look at quantum" into a costed, prioritised cryptography inventory? Let's talk.