up:: For Policymakers
What should a government actually do?
Most of the useful measures are unglamorous, and several of them cost almost nothing.
That’s worth saying at the start, because the instinct with a technology problem is to reach for funding programs and research initiatives. The binding constraints here are mostly organizational: nobody knows what they’re running, procurement keeps buying equipment that locks in the problem for another 30 years, and the entities least able to comply are on the same networks as everyone else.
The list below is sorted by how quickly it can be done rather than by importance.
The short version:
- Procurement is the highest-leverage lever and the cheapest. Every cycle that passes without a post-quantum requirement locks in decades of exposure.
- Mandate inventories before mandating migration, because nobody can migrate what they can’t find.
- Fund the small operators, since water utilities and regional providers have neither budget nor staff and sit on shared infrastructure.
- Treat forgery as the urgent half for infrastructure, rather than copying the data-confidentiality framing.
- Close the notification gap, because no existing law covers data collected this way.
- Support countries with no capacity at all, which is where an uneven transition becomes everyone’s problem.
What can be done this year, with no new legislation?
These sit inside existing authority in most jurisdictions.
1. Put a post-quantum requirement into public procurement. Any equipment being bought now with a service life measured in decades should be required either to support the new algorithms or to carry a dated, contractual upgrade commitment. This is the single highest-leverage action available, it costs almost nothing, and every procurement cycle that passes without it commits another generation of infrastructure to the problem.
2. Require an inventory from agencies and regulated entities. Give a deadline for organizations to identify where cryptography is used across their systems. Most cannot do this today, which is precisely why it has to come first. A migration mandate issued to organizations that can’t find their own cryptography produces reports rather than migration.
3. Publish a schedule and stick to it. Several countries have. The published dates are what make the rest fundable inside organizations, because a budget request against a dated legal requirement behaves very differently from one against a forecast.
4. Direct existing sector regulators to ask about it. Health, finance, energy, and telecoms regulators already conduct oversight. Adding this to their existing question set reaches thousands of organizations without new law.
5. Say it publicly and repeatedly. Ministerial and agency statements are what move this from a technical curiosity to a board-level item inside regulated firms. This is free.
What needs a legislative cycle?
6. Close the notification gap. Every breach-notification law in existence is built around unauthorized access to a system. Data copied in transit and decrypted years later involves no access and no incident, so no obligation attaches to anybody, ever. That’s a category the law doesn’t contemplate rather than a loophole somebody found, and it means the affected people are never told. See Will anyone ever tell me if it happens?
7. Assign liability. Responsibility when this eventually fails has never been settled between the organization holding the data, the vendor whose product contained the cryptography, the insurer, and the individual. Somebody will decide this, and it’s better decided deliberately than by whichever court hears the first case.
8. Set obligations for long-lived products. Medical devices, vehicles, industrial equipment, and metering are sold into service lives that outrun the deadlines. Requirements at the point of sale are the only moment anybody has leverage over a device that will be in a body or a substation for 15 years.
9. Fund the operators who can’t comply. Small water utilities, regional health providers, and municipal systems frequently have no security staff at all. They connect to the same grids and networks as everyone else, so leaving them behind is a national problem rather than a local one. See Who pays for this?
What does the international dimension need?
10. Align schedules with partners. Encryption is negotiated between both ends of a connection, so a country that finishes early inherits the exposure of a partner that finishes late. Divergent national deadlines produce years of mismatch between systems that have to interoperate. See What are other countries doing?
11. Address the countries with no program at all. The nations with published deadlines are wealthy ones with mature cyber agencies. Most of the world has neither, and an uneven global transition creates permanent weak points that route everyone’s traffic. This is the part with no obvious owner, and it’s where multilateral bodies have a role nobody else can fill. See What happens to countries that can’t afford to migrate?
12. Keep standards trust intact. The algorithms came from an open international competition and are being adopted across jurisdictions, which is a genuine achievement and the reason interoperability is possible at all. Preserving confidence in that shared technical core matters more than any single national schedule.
What’s most often done wrong?
Worth knowing, because these are the failure modes already visible.
| Common mistake | Why it fails |
|---|---|
| Mandating migration without mandating inventory first | Organizations can’t migrate what they haven’t found |
| Setting a deadline with no reporting requirement | Nobody discovers the slippage until the deadline |
| Treating it as an IT problem | Most of the hard part is procurement, vendors, and long-lived equipment |
| Copying the data-privacy framing for infrastructure | For control systems the threat is forged commands, not eavesdropping |
| Exempting legacy systems indefinitely | Legacy systems are where the problem actually lives |
| Funding research instead of migration | The algorithms are finished; deployment is the gap |
What questions should you put to an agency?
Five that produce answers rather than reassurance.
- Can you produce an inventory of where cryptography is used across your systems? If not, when will you be able to?
- Which of the data you hold has a secrecy lifetime longer than the deadline?
- What proportion of your cryptography sits inside vendor products you can’t modify, and what dated commitments do you have from those vendors?
- Which systems in your sector cannot be updated at all, and what’s the plan for those?
- What’s in your next procurement, and does it carry a post-quantum requirement?
Longer version at What should I ask in a hearing or briefing?
Questions people ask
Isn’t this premature if the machine doesn’t exist? The deadlines exist regardless, migrations of this size take a decade, and data collected now is exposed retroactively. Those three facts hold whatever the machine does.
Won’t industry handle it? Partly, and unevenly. Well-resourced firms in regulated sectors are moving. Small operators and long-lived equipment are exactly where market forces are weakest.
What does this cost? For most organizations the dominant cost is the inventory and the labor rather than the technology, since the algorithms are free and already in mainstream software.
Is there a model to copy? Several countries have published schedules and roadmaps worth reading side by side, and Australia’s is the most aggressive. See What are other countries doing?
What’s the single most useful thing? Procurement. It’s cheap, it’s inside existing authority, and it’s the only moment anybody has leverage over equipment that will still be running in 2050.
Where to go next
- What laws and rules already exist? covers what’s already binding.
- What critical infrastructure is exposed? covers the hardest sector.
- What isn’t legislated yet? covers the gaps in more detail.
Go deeper into the technical detail
The technical index of every regulation is The Mandates MOC.
These open the Post-Quantum Field Guide, a separate site written for security professionals.
Last verified 2026-07-30 · Maintained by Addie LaMarr, LaMarr Labs.