We wrote about the threat in Your Encrypted Data Is Already Being Stolen, and the reaction from most readers was reasonable: understood, but we are a shipping agency with forty people, what exactly do you expect us to do on Tuesday? This is that list. It is shorter than the subject's reputation suggests, and most of it costs nothing.
Where the clocks actually stand
Three sets of dates govern this, and none of them depends on when a quantum computer arrives.
NIST finalised the first post-quantum standards on 13 August 2024: FIPS 203 for key encapsulation, FIPS 204 and FIPS 205 for signatures. A fourth, FIPS 206, has remained in development. Separately, NIST IR 8547, still a draft through 2026, proposes that the public-key algorithms providing 112-bit security, which means RSA-2048 and ECC P-256 and their relatives, be deprecated after 2030 and disallowed after 2035.
In Europe, the Commission and member states published a coordinated roadmap on 23 June 2025. By the end of 2026 member states are expected to have national strategies, to have started cryptographic inventories and dependency maps, and to have launched pilots for high and medium risk use cases. By the end of 2030 critical infrastructure is expected to have migrated for high-risk use cases, with as much as possible of the rest by 2035.
Read together, that is a ten-year transition with the discovery phase ending in about three months. Nobody is going to fine a forty-person shipping agency in January. But the questionnaires arriving from your larger customers are going to start asking, because they are the ones inside the roadmap, and supply-chain security is how their obligations become yours.
Step one: the inventory. It is dull, not hard
You cannot migrate what you cannot list, and almost nobody has the list. It does not need a product. It needs someone to spend two days writing down, for each item, what algorithm is in use, who owns it, and who would have to change it.
- TLS. Every public endpoint and every internal one. A scanner will tell you the certificate algorithm and the key exchange in an afternoon.
- Certificates. Where they come from, how they are renewed, and whether anything is pinned, because pinning is what will hurt during a migration.
- VPN and remote access. The key exchange your concentrator negotiates, and whether the vendor has published a post-quantum position.
- Signing. Code signing, document signing, qualified electronic signatures, firmware signing on anything you manufacture or embed.
- Stored data. Backup encryption, database encryption, archive encryption, and specifically what protects the key rather than the data.
- SSH. Host keys and user keys, their algorithms and ages.
- Hardware. Smart cards, tokens, HSMs, door systems. These are the long-lead items, because they are replaced on a hardware cycle rather than a software one.
One column is worth more than all the others: who would have to change it. Most of the answers will be a supplier, and that tells you where your real programme lives.
Step two: rank by data lifetime, not by system importance
The instinct is to start with the most critical system. For this specific problem that instinct is wrong, because the threat model is harvest-now-decrypt-later: traffic captured today, stored, and decrypted when the capability exists.
The question to ask of each data flow is how many years its contents must remain secret. Board minutes, crew medical records, legal advice, merger discussions, long-term commercial terms, personal data with a statutory retention of a decade: if the answer is more than about ten years, that material is already exposed, and no future migration recovers it. A press release protected by the same TLS session is not worth an hour of anyone's attention.
This reordering is the single most useful thing in this article. It moves the programme away from infrastructure and towards a handful of flows that actually matter, which is usually three or four, and which a small company can genuinely fix.
Step three: the free wins, most of which are already on
Here is the part that surprises people. The most important transitional control is hybrid key exchange, where a classical and a post-quantum algorithm are combined so that the session is safe if either survives. It is not a future product. It is running now.
X25519MLKEM768 has been the default key exchange in Chrome since version 131 in November 2024 and in Firefox since version 132 in October 2024. It was standardised for TLS 1.3 as RFC 10024 in August 2026. OpenSSL 3.5 and later support it, as do Go and the major content delivery networks, and by April 2026 more than two thirds of human-generated TLS traffic reaching one large network was using it. Recent OpenSSH releases negotiate a hybrid exchange by default as well.
So the practical action for this quarter is not to buy anything. It is to make sure you are not the party holding it back: update your web servers, load balancers and reverse proxies to versions that support hybrid key exchange, verify it is negotiating rather than assuming, keep your SSH implementations current, and stop terminating TLS on appliances that are three major versions behind. For a typical company that is a patching exercise with a checklist, not a project.
Step four: five questions for every supplier
Your migration is mostly other people's migration. Put these in every renewal and every new procurement, starting now, and keep the answers in the same file as the inventory.
- Which post-quantum algorithms does the product support today, and in which versions?
- What is your published timeline for the parts that are not yet covered?
- Is the product crypto-agile, meaning can algorithms be changed by configuration rather than by replacing the product?
- For long-lived data you hold on our behalf, what protects it at rest and when will that change?
- Will you notify us when your cryptographic posture changes, and under what contractual term?
The value of question three is worth spelling out. Crypto-agility, not any particular algorithm, is the actual deliverable of this decade. Standards will move again. A product where the algorithm is a configuration value ages gracefully; one where it is welded in becomes a replacement project at the worst possible moment.
Step five: what to leave alone
Do not implement anything yourself. Use the standard implementations in your platform. This is not the field in which to be inventive.
Do not buy a box labelled quantum-safe. The market for post-quantum theatre is warming up, and a device that solves a problem your inventory has not yet described is a purchase made in the dark. Quantum key distribution in particular solves a different problem than the one most organisations have.
Do not rewrite your symmetric encryption. AES-256 and modern hashes are not the exposure. The threat is to public-key cryptography: key exchange and digital signatures. If your programme is spending effort on the symmetric side, it has been mis-scoped.
Do not wait for FIPS 206. The signature migration is the slower half of this transition anyway, and the standards you need for key exchange are final.
A calendar an ordinary company can keep
The rest of 2026: finish the inventory, rank the flows by data lifetime, confirm hybrid key exchange on your public endpoints, and add the five questions to your procurement template. That is the discovery phase the European roadmap expects to be done, and for a small organisation it is a matter of days, not budget.
2027: close the gaps the inventory found, with hybrid key exchange everywhere it is available, replacement plans for anything that cannot be upgraded, and supplier commitments written into contracts rather than promised in meetings.
2028 to 2030: the signature and hardware work, which is the expensive part, aligned to your normal refresh cycles so that it is absorbed rather than funded separately. This is also where long-lived archives are re-encrypted, if they can be.
There is a version of this subject that is thrilling, involves a countdown and sells conference tickets. The version that protects you is an inventory, a patching exercise, five questions in a procurement template and a note about which three data flows have to stay secret for longer than the clock allows. Do those, and you are ahead of most of the companies asking you about it.
Sources: NIST FIPS 203, 204 and 205, approved 13 August 2024; the draft NIST IR 8547 on transition to post-quantum cryptography standards; the EU coordinated implementation roadmap of 23 June 2025; RFC 10024 on hybrid key agreement for TLS 1.3 (August 2026). Related reading: Your Encrypted Data Is Already Being Stolen and our white paper on the PQC transition.