Marin Ivezic
A relay, a fused key, and an outage window in 2027
A distribution substation runs a protection relay commissioned in 2019. Its bootloader checks each firmware image against an RSA-2048 public key, and that key is burned into one-time-programmable fuses on the silicon. The relay is supported to 2039. NSA’s CNSA 2.0 timeline puts national security systems on quantum-resistant algorithms exclusively by 2035, four years before that relay reaches the end of its support. The next outage window long enough to touch it opens in 2027, and the one after that is several years out.
Nothing in the standard post-quantum playbook helps here. Inventory your cryptography, adopt crypto-agility, deploy hybrid certificates: every one of those instructions assumes a system whose verification code can be changed. Plenty of operational technology (OT) equipment doesn’t meet that assumption, and the equipment that doesn’t is usually the equipment doing the most safety-relevant work.
So we would start somewhere other than where most migration guides start. Before you build an algorithm inventory, sort your fleet by a single property: whether the thing that checks the signature can ever be changed. That sort produces four classes of asset, and each class gets a different treatment, a different owner, and a different place in the capital plan. Everything else in an OT post-quantum program follows from it.
What quantum actually breaks, and which half you should worry about
Shor’s algorithm, run on a cryptanalytically relevant quantum computer (CRQC), factors large integers and computes discrete logarithms efficiently. That breaks RSA, it breaks elliptic curve cryptography including ECDSA and ECDH, and it breaks classical Diffie-Hellman. Those are the algorithms behind almost every certificate, firmware signature, TLS handshake and IPsec tunnel in your plant.
Symmetric cryptography is in far better shape. Grover’s algorithm offers at best a quadratic speedup against a symmetric key search, and the parallelisation limits make the practical gain smaller still. AES-256 and SHA-384 remain sound choices. If a control link uses a pre-shared symmetric key rather than a public-key handshake, quantum computing doesn’t directly threaten it – though key distribution and key lifetime become the problem instead.
That leaves two distinct exposures, and OT ranks them differently from enterprise IT.
Harvest now, decrypt later (HNDL) is the recording of encrypted traffic today for decryption once a CRQC exists. In IT this drives most of the urgency, because a patient record or a merger document stolen in 2026 is still damaging in 2040. Much OT traffic is not like that. A pump setpoint from 2026 has no value to anyone in 2040. Rank HNDL second for control traffic, but don’t dismiss it: engineering credentials, remote-access material, network topology, safety-system configuration and process recipes all keep their value for a very long time, and they cross the same links.
Trust now, forge later (TNFL) is the one that should shape your program. The logic is uncomfortable. An attacker doesn’t need your signing key today. They need your device to still be checking a breakable algorithm on the day they get a CRQC. A root of trust – the first key a device checks against, held in hardware and usually unchangeable – that you provision in 2027 and cannot rotate is a decision you are making on behalf of an operator in 2047.
Forgery, unlike decryption, produces physical consequences. A forged firmware signature means unauthorised code running on a controller that governs a valve, a breaker or a protective trip. That is the reason NSA’s CNSA 2.0 guidance puts software and firmware signing first among all use cases, ahead of network protocols, and why NIST SP 800-208 approved stateful hash-based signatures for code signing years before the main post-quantum standards were finalised.
The regulatory dates are firming up. NIST published ML-KEM (FIPS 203, formerly Kyber), ML-DSA (FIPS 204, formerly Dilithium) and SLH-DSA (FIPS 205, formerly SPHINCS+) in August 2024, with FN-DSA still to come. CNSA 2.0 requires quantum-resistant algorithms exclusively across US national security systems by 2035.
Set those dates against an asset base with a twenty-year service life and the arithmetic is not subtle. Equipment you specify this year will still be running when the algorithms it depends on are being withdrawn.
The question that sorts everything
A verifier is the combination of code and key material that checks a signature or negotiates a session key. It might be a boot ROM checking an RSA signature over a firmware image. It might be an OpenSSL build inside a historian negotiating a TLS cipher suite. It might be a secure element holding a device identity key.
Every asset in your OT estate answers one question: can that verifier be changed, and at what cost? Four answers, four classes.
Class A, negotiable. The verifier is software on a general-purpose operating system, cipher suites are configurable, and the vendor ships patches on a normal cadence. Firewalls, VPN concentrators, jump hosts, historians, engineering workstations, OPC UA servers running on Windows or Linux. These devices can adopt post-quantum algorithms roughly the way an IT system does, subject to your change control.
Class B, updatable but constrained. The verifier is embedded firmware, but there is a signed update path and the root key sits in rewritable secure storage rather than fuses. The obstacle is resources, not architecture: flash headroom, RAM, CPU cycles, link bandwidth. Most modern controllers, protection relays and remote terminal units land here. Whether they can accept post-quantum algorithms depends on engineering the vendor has to do, and on numbers you should be asking the vendor for now.
Class C, frozen verifier. The firmware can be updated, but the verification algorithm cannot, because the root key or the algorithm identifier is in mask ROM or blown fuses. The device will check RSA-2048 for the rest of its service life, and no vendor patch changes that. You can’t fix the device. You can only move the meaningful check somewhere you control.
Class D, no update path. End of life, vendor gone, or a safety certification that turns any firmware change into a full revalidation exercise. A SIL-rated logic solver frequently belongs here even when it is technically updatable, because the recertification cost exceeds the value of the change.
This sort is not an algorithm inventory. Algorithms tell you what is exposed; verifier class tells you what you can do about it, who has to do it, and roughly what it costs. Two devices running identical RSA-2048 secure boot can belong to different classes and need completely different programs. Sorting by algorithm produces a list. Sorting by verifier agility produces a plan.
Answering the question, device family by device family
You won’t get these answers from a network scan. Cryptographic behaviour in OT lives in firmware, in vendor documentation of varying quality, and in silicon. Work at the level of device family rather than individual asset, and ask five questions of each family.
- What checks the firmware signature, and where is the key? Boot ROM, secondary bootloader, secure element, TPM. Fused, rewritable, or field-provisionable.
- What algorithm and parameter set? RSA-2048, ECDSA P-256, something proprietary, or nothing at all.
- Can the verification algorithm be replaced by a signed update, or only the key? These are different capabilities and vendors conflate them constantly.
- What resource headroom exists? Free flash, free RAM, and the time budget available for a signature verification during boot.
- What does the device use on the wire, and is anything in front of it? A gateway or protocol proxy in the path changes the answer for transport security entirely.
Three sources supply the answers. The best is a cryptographic bill of materials (CBOM) from the vendor. An SBOM (software bill of materials) lists software components; a CBOM lists cryptographic assets – algorithms, key lengths, libraries, certificates, protocol versions, and where each is used. CycloneDX added cryptographic asset support in version 1.6, so there is a machine-readable format to ask for rather than a spreadsheet to negotiate. The second source is your own lab: firmware images can be scanned for cryptographic constants, embedded certificates and library fingerprints. The third is passive observation on the network, which tells you which cipher suites are actually negotiated.
A CBOM describes what a product supports. Your environment runs what it is configured to run, and the two differ more often than not. A device that supports TLS 1.3 with AES-256 may well be sitting in a cabinet negotiating TLS 1.0. Record configured reality alongside vendor capability, and treat the inventory as a living record rather than a one-off exercise.
Worked example: a water utility’s telemetry fleet
Take three hundred remote terminal units (RTUs) at pump and lift stations across a water network. Same model, same firmware baseline, cellular backhaul to a central SCADA cluster. Running the five questions produces this:
Firmware is signed with ECDSA P-256 and verified by a secondary bootloader. The root public key is held in a rewritable secure element and can be re-provisioned in the field with a vendor tool. The device has 512 KB of flash with roughly 40 KB free on the current build. The cellular link delivers about 9,600 bits per second of usable throughput at the weaker sites. Vendor support runs to 2032. In front of the fleet, a cellular gateway cluster terminates the transport before traffic reaches SCADA.
The classification splits. On firmware signing, this family is Class B. The key can be replaced, the verifier is software, and the question is whether the vendor will ship an ML-DSA verification path and whether it fits in 40 KB. That’s a conversation with a named engineering contact, not a procurement letter. On transport, the family is effectively Class A, because the gateway is doing the negotiation and the gateway is a Linux appliance you can patch.
The bandwidth figure changes one decision. An ML-KEM-768 handshake adds a little over 2 KB of key material compared with an elliptic curve exchange. At 9,600 bits per second that is roughly two extra seconds per session establishment. Acceptable for a session that opens once and stays up; a genuine problem for a polling pattern that renegotiates constantly. That is a configuration change you make before the algorithm change, not after.
Worked example: a safety instrumented logic solver
Now a SIL 2 certified logic solver on a batch process. Firmware is signed with RSA-2048, the root key is in fuses, and the vendor’s certification body treats any change to the safety-related firmware as a revalidation trigger.
This is Class C on the frozen-verifier test and Class D in practical terms, because the recertification cost and the process downtime rule out a firmware change outside a major turnaround. There is no cryptographic fix. What you do instead is decide, deliberately and in writing, that this device is protected by isolation rather than by cryptography, and you schedule its replacement against the turnaround calendar rather than against the threat calendar. Recording that decision is the deliverable. An undocumented acceptance of risk looks identical to an oversight when someone audits you in 2032.
Four classes, four treatments
Class A: adopt hybrid now, and use the exercise to learn
Hybrid key exchange combines a classical algorithm and a post-quantum one so that the session key depends on both. An attacker has to break both to recover it. In TLS 1.3 the widely deployed option pairs X25519 with ML-KEM-768. Codepoint naming has shifted as the drafts settled, so confirm which hybrid group your own TLS library and its peers actually negotiate rather than assuming from a name.
Turn it on at the boundaries first: site-to-site tunnels, remote engineering access, any link that leaves your physical perimeter. Those carry the HNDL exposure that is worth taking seriously – credentials, topology, configuration. Internal control-network traffic can wait.
The performance question usually resolves quickly. ML-KEM is fast, comparable to or better than RSA for the same operation, and the added cost is bytes on the wire rather than milliseconds of computation. Measure it anyway, on the actual hardware, over the actual link. That measurement is the evidence you will need when someone asks whether the change is safe on a Class B device later.
Class B: get the numbers from the vendor, then hold them to a date
Class B is where post-quantum migration in OT is won or lost, and where the size figures start to bite.
| Algorithm | Public key | Signature |
|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes |
| ECDSA P-256 | 64 bytes (raw) | 64 bytes (raw) |
| ML-DSA-44 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 1,952 bytes | 3,293 bytes |
| SLH-DSA-SHA2-128s | 32 bytes | 7,856 bytes |
| LMS, common parameter sets | 56 bytes | roughly 1.5–3 KB |
An ECDSA P-256 signature is 64 bytes. Its ML-DSA-65 replacement is 3,293 bytes, a factor of fifty. On a device with a fixed firmware header layout, that alone can force a format change. Certificates grow correspondingly, and a certificate chain that fit inside one protocol message may no longer fit.
For firmware and secure boot specifically, the stateful hash-based signatures approved in NIST SP 800-208 are worth understanding. LMS and XMSS rest only on the security of a hash function, which is why they were approved years ahead of the lattice schemes. They are stateful: each one-time key inside the tree may be used exactly once, and reusing one destroys the security of the scheme. That state management is the signer’s burden – your vendor’s signing infrastructure, not your deployed devices. On the device side, verification is cheap and the verification code is small, which is precisely why these algorithms suit constrained hardware. SLH-DSA offers a stateless alternative at the cost of a much larger signature.
The practical Class B ask has four parts, and it belongs in a technical exchange rather than a compliance questionnaire: current free flash and RAM on the shipping build; measured verification time for the candidate algorithm on the target part; a committed firmware release that adds the verification path; and dual signing in the interim, so images carry both a classical and a post-quantum signature while devices still check only the classical one. Dual signing costs the vendor almost nothing today and gives you a verifiable artifact later.
Most vendor statements about quantum readiness currently describe an intention rather than a shipping capability. Ask for a version number and a date.
Class C: move the check to somewhere you own
If the device will check RSA-2048 forever, stop trying to change the device.
Verify upstream of it. Put a staging service between the vendor and the plant. That service holds the vendor’s post-quantum verification key, checks the ML-DSA or LMS signature on every image, and only then releases the image into the deployment path. The controller still checks its RSA signature, unchanged. An attacker who forges the RSA signature now also has to get the forged image past the staging check, which means compromising a system you control and can patch.
Be precise about what this buys. It defends the update supply path. It does nothing against an attacker already on the control network with direct access to the device’s programming interface. The segmentation is doing that work, and it needs to be real segmentation – enforced at a firewall or a data diode, documented, and tested.
Terminate transport in front of it. A protocol gateway can speak post-quantum TLS on the untrusted side and legacy TLS or plain protocol on the plant side. This is the same pattern as TLS offload, applied to algorithm migration. The gateway becomes a high-value asset and should be treated as one, but upgrading one gateway is tractable in a way that upgrading four hundred field devices is not.
Monitor integrity independently. Periodic external verification of firmware images against known-good hashes won’t prevent a compromise, and it shouldn’t be sold internally as though it would. It shortens the interval between compromise and detection, which for a persistent firmware implant is worth a great deal.
One thing not to do: raising classical key sizes is not a quantum mitigation. Moving from RSA-2048 to RSA-4096 roughly doubles the qubit requirement for the attack, against a threat whose capability grows in the opposite direction. Do it for classical reasons if you like. Don’t record it as quantum risk reduction.
Class D: schedule the replacement and say so out loud
For Class D there is no cryptographic remediation. The work is planning work.
Identify the population, map it to the capital and turnaround calendar, and set a replacement year for each family. Where the replacement year falls after 2035, document the compensating controls and the accepted risk, and put a named owner and a review date on that acceptance. Where a device is genuinely irreplaceable within the horizon, the mitigation is architectural: reduce what it is connected to, remove any path from the enterprise network, and make sure nothing about a safety function depends on a signature that will be forgeable.
The hardest Class D conversation is not about existing assets. It is about the purchase you are about to make. A device specified in 2027, installed in 2029, with a twenty-year life and a fused RSA root of trust, is a replacement project you have already bought and not yet scheduled.
Procurement is where OT cryptography is actually decided
Purchase is the only moment at which the verifier is not yet frozen. After that, every option costs an order of magnitude more.
So write the requirement in terms of verifier agility rather than algorithm names, because algorithm names age and the capability does not. Four clauses do most of the work.
Field-replaceable trust anchors. Root of trust key material must be replaceable in the field through an authenticated process, and the vendor must supply the tooling. Fused, single-key roots of trust should be a documented exception rather than a default.
Selectable verification algorithm. The signature verification algorithm must be replaceable through a signed firmware update, not fixed at manufacture. This is the clause that separates Class B from Class C, and vendors will often answer the first clause while quietly failing this one.
Machine-readable CBOM at delivery and on every release. Algorithms, parameter sets, libraries and versions, certificates, and the location of each. CycloneDX format. Include a requirement to notify you when any of it changes.
Committed dual signing with a date. Firmware images carry both a classical and an approved post-quantum signature by a stated year, with device-side verification of the post-quantum signature by a second stated year.
Ask for the resource numbers at tender stage as well: free flash, free RAM, and verification time headroom for a signature roughly fifty times larger than the current one. A vendor who can’t answer that has not done the analysis, and that in itself is useful procurement information.
Two standards give these requests weight. ISA/IEC 62443-4-2 sets component security requirements including cryptographic integrity, and IEC 62351 does the same for power system communications. Neither yet mandates post-quantum algorithms. Both make cryptographic agility a reasonable reading of existing obligations, which is enough to move a conversation from a favour to a requirement. Where several operators in a sector ask the same vendor the same four questions, roadmaps appear noticeably faster.
The capability this needs from your team
None of the above requires anyone to understand lattice mathematics. It requires a different and more ordinary set of skills, currently thin in most OT organisations.
An engineer running this work needs to read a CBOM and tell what is missing from it. They need to size an ML-DSA signature against a flash budget and a boot-time budget, and know when the answer is no. They need to recognise a hybrid handshake on the wire and confirm it actually negotiated. They need to explain to a vendor account manager why “we support PQC” is not an answer, and what the answer looks like. And they need to classify a device family correctly, because a Class C asset misfiled as Class B produces a migration plan that quietly fails in year four.
If you want a starting point that fits in a quarter, take one device family, run the five questions, and produce a single classification with the evidence behind it. That exercise will tell you more about your real position than a fleet-wide algorithm inventory, and it produces a template your team can apply to the next twenty families.
Quantum Academy’s post-quantum training is built for exactly this work: practitioners who have to make decisions about equipment they can’t replace, on timelines set by turnarounds rather than by patch Tuesdays. You can see the current programs at quantumacademy.com/. For migration methodology at program level, including inventory structure and governance, the PQC Framework is the reference we point people to. And for the deeper technical treatment of the OT cryptographic use cases summarised here, PostQuantum.com goes further into secure boot chains, protocol-level detail and vendor engagement.