The migration away from cryptography a quantum computer would break, and the obligations starting to attach to it. Long lead time, early supervisory interest, and a discovery problem at the front of it.
What we track
NIST post-quantum standards
US and international. ML-KEM, ML-DSA and SLH-DSA, and the guidance that follows each publication.
PQC in hardware roots of trust
US and international. Guidance for the parts of the estate that cannot be patched into compliance.
Supervisory expectations
EU and international. Central bank and supervisor pressure for cryptographic inventories ahead of migration.
National migration timelines
EU, UK and US. Published roadmaps, the dates in them, and how binding each one actually is.
Export controls on quantum
International. Wassenaar and national controls on quantum and related equipment.
Cryptographic agility
All jurisdictions. Standards work on changing algorithm without changing everything around it.
Who is in scope
No general statute compels migration yet in most jurisdictions. The pressure arrives instead through supervisors, through government roadmaps that bind public sector suppliers, and through procurement questions from customers who have their own timeline.
Financial services is furthest ahead, because central banks and supervisors have started asking for cryptographic inventories directly. Anyone selling into government, defence or critical infrastructure will meet the requirement through a contract before they meet it through a regulator.
Where the deadlines fall
The standards are published, so the sequencing question is now yours to answer. National roadmaps set indicative dates for high-value systems and later dates for the rest, and those dates are becoming procurement conditions.
The date that matters most is not on any roadmap. It is the confidentiality horizon of your own data, because anything that must stay secret for a decade is already exposed to capture now and decryption later.
Where organisations get caught
The inventory. Nobody can migrate cryptography they cannot find. Discovery runs long, because keys and certificates are scattered across code, appliances, hardware modules and supplier products, and never in one register. Supervisors have started asking for the inventory before they ask for a migration plan, which is the right order and an uncomfortable one.
Hardware. Roots of trust, secure elements and embedded devices frequently cannot be updated to new algorithms at all. That turns part of the migration into a replacement programme with a capital cycle attached.
Suppliers. Much of your cryptography is inside products you bought. The migration date you can commit to is constrained by your vendors’ roadmaps, and asking for those roadmaps early is the cheapest thing in this domain.
Questions worth asking now
- Do we have a cryptographic inventory, and does it include what is inside purchased products?
- Which of our data has a confidentiality horizon longer than five years?
- Which systems use cryptography that cannot be changed without replacing hardware?
- What have our major suppliers published about their own migration timelines?
- Could we change a cryptographic algorithm anywhere today without an outage?
- Who owns this programme, and is it funded beyond a discovery exercise?
Related domains
Product security covers the cryptography inside what you ship. Third-party and supply chain risk covers supplier migration timelines. Export controls covers the controls now attached to quantum equipment.