The US just put a 2030 deadline on post-quantum, and it is worth having on your radar

28 June 2026 · Carl Heaton · Security Commentary

Some of the data your business sends out encrypted today could be readable by someone in ten years' time. Not because the encryption is weak now, but because an attacker can record it now and wait for the technology to catch up. For anything with a long shelf life, customer records, financial data, legal files, that is a risk worth understanding, even though nobody is asking you to act on it this week.

The reason it is in the news is a US executive order, EO 14409, signed on 22 June. It sets two hard dates for American federal agencies and their suppliers: move encryption key exchange to post-quantum cryptography by 31 December 2030, and digital signatures by 31 December 2031. That is a US order on a US timetable, and you are not bound by it. But it puts a date on a problem that does cross borders, and the first step it forces on everyone is the same step you will eventually have to take, so it is worth having on your radar now rather than discovering it later.

Let us take the jargon apart, because the headline is doing a lot of hiding.

What "post-quantum" actually means

Most of the encryption that protects data today, the padlock in your browser, the encryption on your VPN, the signatures that prove software is genuine, relies on maths that ordinary computers cannot crack in any reasonable time. A large enough quantum computer could. One does not exist yet at the scale needed. The expectation is that one eventually will.

Post-quantum cryptography (PQC) is the replacement: new encryption built on different maths that a quantum computer cannot break either. The US National Institute of Standards and Technology finalised the first PQC standards in August 2024. They have names you will start seeing in security questionnaires: ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures. The standards have existed for nearly two years. What the executive order adds is a schedule with consequences.

Why this belongs on your radar now, not in 2030

The risk in that opening paragraph has a name: "harvest now, decrypt later". An attacker, usually a nation state, records your encrypted data today, when they cannot read it, and stores it. They are betting that a quantum computer will eventually exist to decrypt it. For data that stays sensitive for years, medical records, legal files, financial data, intellectual property, that is a real bet. You do not need a quantum computer to exist yet to be exposed to one. You only need an attacker patient enough to keep a copy.

That is why the 2030 deadline is not the start of the problem. The problem started the moment "harvest now, decrypt later" became worth doing. The deadline is just the point by which the US government wants its own data off the old encryption. The harvesting, if it is happening, is happening now.

The one task that comes before everything else

Read the executive order closely and the same instruction appears before any actual migration: find out what cryptography you are running and where.

The order tells agencies to build a cryptographic inventory. Within 30 days, each agency must name someone to own it. Within 90 days, they must review their inventories and submit a migration plan. There is even a new artefact mandated: a "cryptographic bill of materials", a machine-readable list of the cryptographic assets inside a piece of hardware or software, so you can find weak algorithms when it is time to swap them.

This is the whole game, and it is worth understanding why. You cannot replace encryption you cannot find. Cryptography is buried everywhere: in applications, in libraries those applications depend on, in hardware, in protocols, in certificates, in things bought a decade ago that nobody has looked at since. The reason the order spends so much effort on inventory before migration is that the inventory is the hard part. The swap, once you know where to swap, is comparatively mechanical.

The order calls the goal "crypto-agility": the ability to change your encryption on a deadline, which you can only do if you know where it all is.

There is a quieter benefit here, and it is the real reason a small business should bother. Working out where your cryptography lives is just good housekeeping, and it surfaces the same legacy systems you would want to deal with anyway. The old server still using a protocol nobody has reviewed since it was installed, the application the vendor stopped updating, the certificate that has been auto-renewing on autopilot for years: a cryptographic stocktake finds all of these. Post-quantum is the reason you finally do it, but most of what you find is ordinary technical debt you would have wanted to clear regardless. The quantum angle just gives you a reason to look.

Why a UK business should care about a US order

You are not bound by EO 14409. But three things flow downhill from it.

Your suppliers and tools will move. The software you buy, the cloud services you use, the libraries your developers depend on, many of them sell to the US government or its contractors. They are now on a clock. Their PQC migration becomes updates you receive, defaults that change, and certificates that get reissued. You will be migrated, in part, whether you plan for it or not. It helps to know it is coming.

The questions will reach you. The order folds cryptographic requirements into US contractor obligations, including a future rule that tests for "missing encryption" and "non-FIPS algorithms". UK regulators and the NCSC are on the same path. The NCSC has already published guidance on the timelines for migrating to post-quantum cryptography. If you sell into regulated sectors, or into US-facing supply chains, the supplier questionnaire will eventually grow a post-quantum question. It is the kind of thing that is much easier to have half an answer to in advance than to start thinking about when a customer's procurement team asks.

The inventory task is yours regardless. Whatever timeline you end up on, the first step is identical to the federal one: know what cryptography you run and where. That is not a quantum project. It is a know-your-own-systems project, and it pays off well before any quantum computer exists, because you cannot manage what you have not mapped.

What to actually do this quarter

Nobody is asking a small UK business to migrate to post-quantum cryptography this year. That would be premature, and the standards in your tools are not all ready yet. But a few things are worth starting now, and none of them is expensive or fancy.

Start a rough cryptographic inventory. Not the full machine-readable bill of materials the US government is mandating. A start: where does your business rely on encryption that protects data which still matters in five or ten years? Customer data, financial records, anything covered by long-tail confidentiality obligations. List the systems that hold it and how that data is protected in transit and at rest. This is the single most useful thing you can do, and it is the thing every future deadline will demand first. You do not need anything fancy to do it. A spreadsheet and an afternoon is a perfectly good first version.

Know that some of the fix already exists. This is the part that should take the pressure off. Post-quantum is not all years away in a lab. The NIST standards are finalised, and viable options are already shipping: modern browsers, some VPNs, messaging apps, and major cloud platforms have started turning on post-quantum protection for the connections they handle, often without you doing anything. So part of your exposure gets addressed simply by keeping software current and letting those defaults switch on. That is another reason the inventory matters: it tells you which systems are modern enough to inherit these fixes for free, and which old ones never will and are the real items on your list.

Ask your key suppliers one question. When you next speak to your main software and cloud vendors, ask what their post-quantum migration timeline is. You are not testing them. You are finding out when your own encryption will change underneath you, and flagging that you are paying attention. The good ones will have an answer. The ones who look blank have told you something useful too.

The temptation with anything labelled "quantum" is to file it under "not yet, and not me". The harvest-now-decrypt-later angle is why that instinct is wrong for any data with a long shelf life. You do not have to act fast. You do have to start the inventory, because everyone, on every timeline, has to do that first.

How Steelwise can help

Working out where your business actually relies on encryption, and which of that protects data with a long enough shelf life to worry about, is a sensible first step that does not require a quantum project. It is the kind of scoping review we do. Get in touch.