up:: For Policymakers
What critical infrastructure is exposed?
Power, water, transport, hospitals, telecommunications, and the industrial equipment underneath all of them. And this is the part of the transition where the usual reassurances stop applying.
There’s one distinction that matters more than anything else on this page, and it changes what a government should be worried about. For most of the quantum story the threat is eavesdropping: data collected now, read later. For critical infrastructure it’s forgery, and forgery happens in real time.
The short version:
- Nobody cares about reading an old command to open a valve. They care about issuing a new one that looks authentic.
- The same mathematics that keeps data private also proves a command came from the control room. Both halves break together.
- Industrial equipment has field lifetimes measured in decades, and cryptography is often fixed in firmware that can’t be updated.
- The new encryption uses larger keys, and many industrial networks were never built to carry them.
- Air gaps don’t solve it, and assuming they do is one of the more common mistakes.
- The realistic path is gateways and shared secret keys, rather than replacing the equipment.
Why is forgery the real concern here?
Because of what these systems actually do.
A control system doesn’t hold secrets worth reading years later. It receives instructions and acts on them: open this breaker, adjust this dosing pump, change this setpoint, throttle this turbine. What protects it is the ability to verify that an instruction genuinely came from an authorized source.
That verification runs on the same mathematics as the privacy half, described at What is encryption? When a quantum computer breaks it, an attacker can produce instructions that carry a valid-looking proof of origin.
The consequence is a difference in timing that policymakers should hold onto. Harvested personal data is exposed retroactively, so the damage is already done and simply gets revealed later. Forged commands are a live capability, arriving the day the machine does and affecting operations from that moment forward.
So for infrastructure, the deadline is genuinely a deadline rather than a reckoning with past exposure.
Why is this sector harder than everything else?
Three reasons, and they compound.
1. The equipment outlives the schedule. Industrial hardware carries field lifetimes measured in decades. Equipment installed today will still be running well past the dates by which current encryption is meant to be retired, and much of what’s already installed was commissioned before any of this was contemplated.
2. There’s frequently no update path. Cryptography is embedded in firmware that was never designed to change. Updating it can mean physically replacing a unit, taking a process offline, or re-certifying a safety-critical system, none of which happen on a software cadence.
3. The new keys are bigger. Post-quantum algorithms use substantially larger keys and messages than what they replace. Many industrial networks were engineered for tiny, predictable, time-critical exchanges, and they were never built to carry kilobyte-scale handshakes. This is where the constraints of the sector collide hardest with the shape of the solution.
Full technical treatment at PQC for OT, ICS, and SCADA.
Doesn’t an air gap protect these systems?
Usually less than assumed, and this is a common and consequential mistake.
Genuine isolation is rare. Systems described as air-gapped routinely have vendor remote-maintenance access, engineering laptops that move between networks, historian databases replicating to corporate systems, wireless links, and update paths somebody set up years ago and documented nowhere.
More importantly, an air gap is a claim about network topology, and it’s a claim that deserves verification rather than assumption. The exercise that establishes it is the same inventory exercise most organizations haven’t done.
Even where isolation genuinely holds, it doesn’t address the firmware and code-signing question: how does the device verify that a software update or configuration change is authentic? That check runs on the mathematics in question.
Which sectors, specifically?
| Sector | What’s exposed | Why it’s hard |
|---|---|---|
| Electricity | Grid control, substation automation, protection relays | Equipment lifetimes of decades, safety certification, service can’t be interrupted casually |
| Water and wastewater | Treatment control, dosing systems, remote monitoring | Small operators with minimal budget and no dedicated security staff |
| Transport | Rail signaling, aviation systems, maritime, road infrastructure | Safety-critical certification, very long asset lives |
| Healthcare | Hospital systems, imaging, implanted and bedside devices | Devices that can’t be updated, dozens of vendors, implants already in bodies |
| Telecommunications | Network equipment underneath every other sector | Long refresh cycles, and everything else depends on it |
| Manufacturing and chemicals | Process control, safety instrumented systems | Continuous operation, and a safety case that changes require re-certifying |
| Space and satellites | Command links and payload control | Hardware that physically cannot be reached after launch |
Detail at PQC for OT, ICS, and SCADA, PQC in 5G and Mobile Networks, PQC in Satellites and Space, and PQC in Medical Devices.
So what can actually be done?
The realistic answer is rarely “replace the equipment,” and that’s worth understanding before writing any requirement.
Gateways. Put a device in front of the legacy equipment that speaks the new cryptography outward while speaking the old protocol inward. It protects the network path without touching the certified device.
Shared secret keys. The half of cryptography that survives a quantum computer is the kind using a single shared secret. Where two endpoints can be given a key in advance through a trusted process, that arrangement is already quantum-resistant, and it suits fixed industrial links far better than it suits the open internet.
Prioritize by consequence. Not every device matters equally. The ones that accept commands capable of causing physical harm are a different category from the ones reporting temperature readings.
Inventory first. Every one of the above depends on knowing what’s actually deployed, which most operators can’t currently answer.
What can a government actually require?
Five things that are within reach, in rough order of how quickly they can be done.
- Mandate an inventory. Require operators to identify where cryptography is used across their estate, with a deadline. It’s the prerequisite for everything, and most cannot do it today.
- Put it in procurement. New equipment entering a decades-long service life should be required to support the new algorithms or carry a dated, contractual upgrade commitment. Every procurement cycle that passes without this locks in another 20 to 40 years of exposure.
- Treat the signature half as the urgent one for this sector, because forgery is the live threat, rather than treating infrastructure the same way as data confidentiality.
- Fund the small operators. Water utilities and regional operators frequently have neither the budget nor the staff, and they’re on the same grid and the same networks as everybody else.
- Require air-gap claims to be evidenced rather than asserted, since a great deal of assumed isolation doesn’t survive inspection.
Questions people ask
Is the grid going to go down when a quantum computer arrives? No, and that framing overstates it. The realistic concern is that an attacker gains the ability to forge authenticated commands, which is a serious capability and a different thing from an automatic failure.
Hasn’t this always been true of industrial systems? Their security has been criticized for years, and this adds a specific new failure mode to a set of known ones, with a published deadline attached.
Can’t operators just patch it like everything else? For a large share of installed equipment there’s no patch mechanism, and applying one would mean interrupting service or invalidating a safety certification.
Is anyone actually working on this? Yes, and it’s early. The gateway and pre-shared-key approaches are established, and deployment across installed infrastructure is at the beginning.
How does this compare to the personal-data problem? The personal-data exposure has already happened and gets revealed later. The infrastructure exposure hasn’t happened yet and arrives with the machine. Different shapes, different remedies.
Where to go next
- What laws and rules already exist? covers what’s already binding.
- Who pays for this? covers the operators without capacity.
- What isn’t legislated yet? covers the gaps.
Go deeper into the technical detail
The technical treatment is PQC for OT, ICS, and SCADA and PQC in Firmware and Code Signing.
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.