The standards exist now. NIST finalised the first three post-quantum algorithms last August — ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures — and the draft transition guidance in NIST IR 8547 sets out a timetable that is considerably shorter than it looks: classical public-key cryptography deprecated after 2030, disallowed after 2035. That sounds distant. It is not, because cryptographic migrations in large estates have historically taken five to ten years, and almost nobody can currently answer the first question the migration requires.
You cannot migrate cryptography you cannot find. Most organisations do not have an inventory of where their public-key cryptography lives, and the inventory is the multi-year part
Here is what the planning actually involves this year, and what does not need to be done yet.
The threat that justifies acting before the machine exists
Harvest-now-decrypt-later. An adversary capturing encrypted traffic today can store it and decrypt it when a cryptographically relevant quantum computer becomes available. That makes the relevant question not when the machine arrives, but how long your data stays sensitive. For most commercial traffic, the answer is short enough that this is not urgent. For anything with a long confidentiality life — legal matters, health records, intellectual property, state and defence material, long-term contracts, personal data with statutory retention — the exposure is live now, and that is the population worth prioritising. Signatures behave differently. A signature verified today cannot be retroactively forged by a future machine, so signing infrastructure is a 2030-timetable problem rather than a today problem, with one exception: anything issuing long-lived certificates or firmware signatures that will still be trusted in a decade.
Four things worth doing this year
Build the cryptographic inventory. Where you use public-key cryptography, in what, with which algorithm and key length, under whose ownership. This includes the embedded uses nobody documents — device certificates, code signing, backup encryption, hardware security modules, and every vendor product in the estate. This is the long pole and it should start now. Establish crypto-agility as a procurement requirement. Every new system acquired from this point should be able to change its algorithms without being rebuilt. Writing that into contracts now costs nothing and avoids buying another decade of rigidity. Classify by confidentiality lifetime. Not by sensitivity — by how long it must remain secret. That single reclassification tells you what to migrate first and saves you from treating everything as urgent. Ask your vendors, in writing, for their roadmap. Most of your cryptography is inside somebody else's product. Your migration is largely a function of their release schedules, and the answers you get this year will tell you which suppliers have thought about it.
What not to do yet
Do not rip out working cryptography. Do not deploy proprietary post-quantum schemes that were not standardised. Do not buy a quantum-safe product from a vendor who cannot name the specific standardised algorithms it implements. And do not let this become a board-level programme before you have the inventory, because you will be asked questions the inventory is meant to answer.
| Inventory dimension | Question |
|---|---|
| Use | Where are key establishment and signatures embedded? |
| Ownership | Who controls keys, software and vendor dependencies? |
| Lifetime | How long must the data or signed artefact remain protected? |
| Change path | Can algorithms change without replacing the whole system? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Crypto Agility Assessment
- Start the cryptographic inventory now; it takes longer than the migration.
- Classify data by confidentiality lifetime, not sensitivity label.
- Prioritise long-life confidential data against harvest-now-decrypt-later.
- Treat signatures as a 2030 problem, except long-lived certificates.
- Write crypto-agility into procurement from this quarter.
- Request written vendor roadmaps and keep the answers.
- Pilot hybrid key establishment on one internal path.
- Avoid non-standardised schemes whatever the marketing says.
The Regional Angle
The first factor here is that national direction is likely to arrive before commercial pressure does. Saudi Arabia and the United Arab Emirates both run national cybersecurity authorities that issue binding controls for government and critical sectors, and both have national programmes with an explicit interest in quantum technologies. The realistic expectation is a regional mandate for government entities and regulated industries ahead of any market-driven adoption, with suppliers to those entities inheriting the requirement through contract. Organisations selling into the public sector here should assume post-quantum requirements will appear in tender documents before they appear in their own risk registers, and the cryptographic inventory is what lets you answer a tender question in a week rather than a quarter. The second concerns where the cryptography actually sits in regional estates, which is disproportionately inside purchased systems rather than internally developed ones. A typical Gulf enterprise runs vendor platforms, partner-implemented integrations and localised modules built by a systems integrator — and in that last category the cryptography is frequently undocumented, sometimes hardcoded, and owned by a partner who may no longer be engaged. Include partner-built interfaces explicitly in the inventory scope, and ask the integrator for the cryptographic detail while the relationship is still live. This is considerably easier to do during an existing support contract than after it lapses. The third is about a sector concentration specific to this region. Energy, ports, aviation, utilities and sovereign financial institutions dominate the regional critical-infrastructure picture, and their operational technology carries equipment with decade-plus service lives and cryptographic implementations fixed in firmware. A refinery control system or a port handling platform installed this year will still be running in 2035, when the classical algorithms are scheduled to be disallowed. For those environments the crypto-agility procurement requirement is not paperwork — it is the only intervention available, because the alternative is a hardware replacement programme timed to a regulatory deadline. Put the requirement into operational technology procurement specifically, where it is most often omitted.
The objection worth taking seriously
The strongest objection is that this is a solution in search of a timetable. No cryptographically relevant quantum computer exists, credible estimates of its arrival range across two decades and have been doing so for twenty years, and the security industry has a durable commercial interest in a deadline nobody can falsify. Spending budget this year on inventories and agility requirements, while phishing and unpatched edge devices account for essentially all actual losses, is a misallocation dressed up as prudence. The scepticism about the timeline is entirely reasonable, and the point about where losses actually occur is correct. What the argument does not account for is that the recommended actions are not a bet on the timeline. The cryptographic inventory is a general security asset — organisations that build one routinely discover expired certificates, deprecated algorithms still in use, keys owned by people who left, and systems nobody knew were doing encryption at all. That finding pays for the exercise regardless of quantum computing. Crypto-agility in procurement costs nothing at contract time and is expensive only when retrofitted. Neither requires accepting a date. What would be a misallocation is buying quantum-safe products now, running a board programme before the inventory exists, or diverting staff from patching to this. Do the two cheap durable things, and let the timeline resolve itself.
Common Questions
Should we deploy hybrid key exchange now?
On internal paths carrying long-life confidential data, and where your platform supports it without operational risk, yes — it is low cost and it exercises the migration path. Across the estate, not yet.
Which standard applies to what?
ML-KEM for key establishment, which is the harvest-now priority. ML-DSA and SLH-DSA for signatures, which follow the longer timetable.
How long will migration take?
Plan on several years for a large estate, most of it spent finding the cryptography and waiting for vendors. That is why the inventory starts now and not in 2029.
What should we expect over the next twelve months?
Expect further NIST guidance through this year and next as the transition documents are finalised. Expect the major platform and browser vendors to enable hybrid key establishment by default. Expect post-quantum clauses to start appearing in government tenders. And expect a wave of vendor marketing that considerably outpaces the standards it claims to implement.
Crypto Agility Assessment — we find where your cryptography actually lives, then rank the migration by how long your data has to stay secret.