Somewhere in the next decade or so, a sufficiently capable quantum computer will be able to break the public-key encryption that protects most of the world's data, including yours. The UK's National Cyber Security Centre has told every organisation to have a migration plan by 2028. This is not science fiction, and it is not only a big-company problem.

The thirty-second version of the physics

You don't need to understand quantum mechanics to govern this risk, any more than you need to understand combustion to insure a building. Here is the whole of it:

Most encryption in daily use (the padlock in your browser, VPNs, digitally signed contracts, encrypted backups) relies on mathematical problems that today's computers can't solve in any useful timeframe. Quantum computers attack those specific problems differently, and a large enough one will solve them quickly. Nobody knows exactly when such a machine will exist; credible estimates cluster in the 2030s. The cryptography community has already built replacement algorithms; the US standards body NIST published the first finalised post-quantum standards in August 2024. This is a migration problem rather than an unsolved-science problem. Migrations take years, which is why the deadlines start now.

"Harvest now, decrypt later": why the timeline is misleading

The intuitive response is: wake me up when the machine exists. The flaw in that logic has a name, and it's the reason security agencies are pushing so hard, so early.

Encrypted data can be stolen today and stored cheaply for years. An adversary who exfiltrates your encrypted files in 2026 doesn't need to read them in 2026. They need to read them whenever the decryption capability arrives. That means the relevant question for your board is not "when will quantum computers exist?" but "which of our data still needs to be secret in ten or fifteen years?"

For most organisations, that list is longer than expected: pension and HR records, medical information, long-term contracts, intellectual property, legal files, anything with a decades-long confidentiality obligation. Data with a short shelf life (this quarter's pricing, last month's management accounts) largely takes care of itself. Data with a long shelf life is already exposed, today, to harvest-now-decrypt-later collection.

The NCSC's three deadlines

In March 2025 the NCSC published formal migration timelines, and they apply to organisations of every size, explicitly not just government and critical infrastructure:

  • By 2028: complete a discovery exercise, so you know where your organisation uses cryptography and which systems matter, and have a written migration plan.
  • By 2031: complete the highest-priority migrations.
  • By 2035: finish. All quantum-vulnerable cryptography replaced.

Read those dates as a director rather than a technologist and the first one should hold your attention: 2028 is a planning deadline, and it is close. A plan requires an inventory, an inventory requires someone to do the work, and the work has to compete with everything else on your IT function's list. That's a resourcing decision, and resourcing decisions are board business.

Why a UK board should care before its suppliers force it to

Three pressures will arrive whether or not you prepare:

  1. Supply chain questionnaires. If you sell to banks, insurers, government, or any large enterprise, post-quantum readiness questions are beginning to appear in procurement and vendor-risk reviews. "We have no plan" is an answer that loses tenders. The trend line here is the same one we've already watched with Cyber Essentials and ISO 27001.
  2. Insurers and regulators. Cyber insurers price what they can measure, and NCSC guidance gives them a measurable benchmark. Expect proposal forms to start asking.
  3. Long-lived liabilities. If personal data you hold today is harvested now and decrypted in 2034, the breach happens then, under whatever the data protection regime looks like at the time, but the decision not to plan happened on your board's watch, now.

The board's job is a plan, not physics

Your board does not need a quantum expert. It needs to ask five questions and minute the answers. In practice, almost all of the technical work lands on your IT provider and software vendors. Your job is to establish that someone is holding them to it.

  1. Do we have an inventory of where we use cryptography? (Websites, VPNs, email, backups, signing certificates, payment flows. If the answer is "no", that's the 2028 work, and it can start as a half-day exercise.)
  2. Which of our data must still be confidential in 10–15 years? That subset defines your priority list.
  3. What are our key suppliers' post-quantum roadmaps? Most firms' cryptography lives inside Microsoft 365, Google Workspace, AWS, and their line-of-business software. One letter to each major vendor asking for their PQC migration statement does most of the discovery for you.
  4. Who owns this? A named person, reporting back on a stated date, not "IT generally".
  5. When do we look at this again? Annually is fine. Put it in the forward calendar now.

One warning about the sales pitches

A growing industry sells "quantum-safe" products with urgency dialled to ten. Some are legitimate; plenty are repackaging. Two rules of thumb serve a board well: anything claiming you must buy hardware to be quantum-safe deserves scepticism (for most organisations this is overwhelmingly a software and supplier-management exercise), and any vendor who can't tell you which NIST-standardised algorithms they implement isn't ready for your money. The NCSC's own guidance is calm, free, and vendor-neutral; it is the benchmark to hold every pitch against.

Quantum risk is that rare thing in governance: a major threat with a published, official, dated to-do list. Boards that treat 2028 as real will find the work modest: an inventory, some supplier letters, a named owner, an annual agenda item. Boards that don't will eventually do the same work in a hurry, at someone else's deadline, with a tender or an insurance renewal hanging on it. The first option is cheaper. It always is.