up:: In the Protocols MOC

PQC for OT, ICS, and SCADA

PQC for OT, ICS, and SCADA is the practice of protecting operational technology, industrial control systems, and supervisory control and data acquisition networks against the quantum threat, where the hardware often can’t run the new algorithms and can’t be replaced on a normal cadence, so the answer usually runs through gateways, symmetric pre-shared keys, and long-horizon planning rather than a straight algorithm swap.

Industrial hardware carries field lifetimes measured in decades, embeds cryptography in firmware that can’t be updated, and sits on networks that were never designed to carry kilobyte-scale handshakes, so the size overhead of post-quantum algorithms collides with the tightest constraints in the whole migration. The reassuring part is that a purely symmetric, pre-shared-key path is already quantum-resistant and lets the vulnerable device avoid any public-key math at all.

The short version:

1. OT and ICS hardware has decade-scale field lifetimes and cryptography baked into firmware, so a device deployed today outlives the quantum-threat horizon and often can’t be updated in place.
2. The “air gap protects us” assumption is usually false, because most industrial networks have some connectivity for monitoring, updates, or remote access, and the gap that exists still doesn’t stop harvested data from being decrypted later.
3. Where a device can’t run post-quantum algorithms, a gateway in front of it can terminate quantum-safe protection on its behalf, wrapping the legacy device without replacing it.
4. A purely symmetric path using pre-shared keys is quantum-resistant today, which is how standards like RFC 8784 give IPsec quantum resistance without the endpoint doing any public-key work.
5. Because the hardware turns over slowly, the planning horizon is the long one, so crypto-agility and the sequencing of physical replacements matter more here than anywhere else in the estate.

Picture a factory full of machines wired together decades ago, each one built to speak a simple, fixed language, none of them able to learn a new one. You can’t teach the old machines a new dialect, and you can’t shut the factory down to rip them all out at once. So you put a translator booth at the doorway of each machine. The booth speaks the new, secure language to the outside world and the old, simple language to the machine behind it, and the machine keeps running exactly as it always did while everything reaching it from outside is now protected. That translator booth is the gateway pattern, and it’s how you make hardware quantum-safe without replacing it.

Why is OT harder to make quantum-safe than IT?

Because operational technology inverts almost every assumption that makes an IT migration manageable, starting with the fact that the hardware can’t be swapped on a software schedule. An IT estate migrates by upgrading libraries and reissuing certificates; an OT estate is full of physical devices welded into processes that can’t stop, running firmware that was frozen at manufacture.

1. Decade-scale field lifetimes. Industrial and operational hardware routinely stays in service 10 to 20 years or longer, so a controller installed today will still be running well past the plausible arrival of a quantum computer. The device has to be trustworthy for a horizon that outlasts the threat it needs to resist.
2. Cryptography embedded in firmware. Many OT devices have their cryptographic primitives compiled straight into firmware with no update path, so the algorithm chosen at the factory is frozen for the device’s life. The U.S. government’s report on the transition names exactly these hardware- and firmware-embedded systems as the most difficult and expensive to migrate.

Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.

3. Tight resource budgets. OT endpoints are frequently constrained devices, short on RAM, flash, and link bandwidth, so the larger post-quantum artifacts strain exactly the resources these devices have least of, and a kilobyte-scale handshake may not fit across an industrial fieldbus at all.
4. Availability over confidentiality. OT prioritizes keeping the process running above almost everything else, so a migration that risks downtime is resisted hard, and changes have to be provably safe for a system that can’t be casually rebooted or rolled back.

The combined effect is that OT is where the migration’s constraints stack up worst, and where the straightforward IT playbook of “upgrade the software” mostly doesn’t apply. The methods that work are the ones that protect the device without requiring it to change.

Does an air gap protect OT from the quantum threat?

Usually not, on two counts, which is why the air gap is the most comforting and most misleading assumption in OT security. The first count is that true air gaps are rarer than believed. Most industrial networks have some form of connectivity for remote monitoring, vendor maintenance, historian data flowing to business systems, or occasional updates, and each of those is a path that carries cryptographically protected traffic an adversary could target or copy.

The second count is subtler and specific to the quantum threat. Even a genuinely isolated network doesn’t stop harvest-now-decrypt-later against any data that ever crosses a boundary. If OT data flows out to a monitoring system, a cloud historian, or a corporate network over a quantum-vulnerable channel, an adversary can copy that traffic today and decrypt it once a quantum computer exists. The air gap, where it exists, protects the isolated segment, and it does nothing for the data that leaves the segment or for the day the isolation is bridged for maintenance. Treating the gap as complete protection is how the quantum exposure hides in plain sight.

How do you make legacy OT quantum-safe without replacing it?

You put quantum-safe protection in front of the device rather than inside it, using a gateway that terminates the modern, protected protocol and speaks the device’s old protocol behind it. This is the workhorse pattern for OT, because it decouples the migration from the hardware’s inability to change.

1. A PQC gateway or proxy. A gateway sits between the legacy device and the network, running post-quantum or hybrid protection on the network side and the device’s native protocol on the device side. The device keeps running unchanged while everything reaching it from the outside is quantum-safe, which is the translator-booth pattern made concrete.
2. Network-segment protection. Where individual gateways aren’t practical, protecting the links between segments, with a quantum-resistant tunnel carrying traffic across the boundary, moves the protection to the network layer so the endpoints don’t have to change.
3. The symmetric pre-shared-key path. For point-to-point links, a purely symmetric scheme using pre-shared keys is quantum-resistant without any public-key math on the endpoint, which suits devices that can’t run lattice cryptography at all. This is covered in its own question below because it’s the one method that gives a weak endpoint genuine quantum resistance directly.

The table maps the three methods to the situation each fits, so a mixed OT estate can pick per link.

Method	How it protects the device	Fits when
PQC gateway or proxy	Terminates quantum-safe protection in front of the device, speaks the old protocol behind it	The device has a network front the gateway can sit on
Network-segment tunnel	A quantum-resistant tunnel carries traffic across a segment boundary	Per-device gateways aren’t practical and traffic crosses defined boundaries
Symmetric pre-shared key	Security rests on a shared symmetric secret, so no public-key math runs on the endpoint	Point-to-point links on hardware that can’t run lattice cryptography

The unifying idea is that the legacy device never has to become quantum-safe itself. It has to sit behind something that is, so the quantum-vulnerable public-key operations move off the constrained, unchangeable hardware and onto a gateway that can be upgraded like any modern system. That turns an impossible endpoint migration into a tractable network-architecture change.

Can symmetric pre-shared keys make OT quantum-safe?

Yes, and this is the cleanest quantum-resistant option for hardware that can’t run post-quantum public-key algorithms, because symmetric cryptography survives the quantum transition on its own. The quantum threat to key establishment comes from Shor’s algorithm breaking public-key math, so a channel whose security rests entirely on a shared symmetric secret, rather than a public-key exchange, sidesteps that attack. Grover’s algorithm only halves symmetric strength, so a sufficiently long pre-shared key stays strong against a quantum attacker.

The worked example in a real standard is RFC 8784, which mixes a static post-quantum pre-shared key into IKEv2 so an IPsec tunnel gains quantum resistance without waiting for the endpoints to run post-quantum key exchange. The pre-shared key is exchanged out of band, then stirred into the key material derived during the classical Diffie-Hellman handshake, so even an adversary who later breaks the Diffie-Hellman half with a quantum computer can’t derive the session keys without the symmetric secret they never saw.

Source: S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov, “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,” RFC 8784, June 2020, RFC 8784.

The tradeoff is key management, which is the classic weakness of any pre-shared-key scheme. Distributing, storing, and rotating symmetric keys across many devices is operationally heavy, and it doesn’t scale the way public-key infrastructure does, which is exactly why public-key cryptography was invented. For a bounded set of long-lived, point-to-point OT links, though, the pre-shared-key path is a genuinely quantum-resistant option available today, on hardware that could never run ML-KEM.

Why does the long field lifetime dominate OT planning?

Because the hardware turns over so slowly that the migration is paced by physical replacement cycles rather than software releases, which makes the planning horizon the longest in the whole estate. A device with a 20-year life installed this year is a device you’re committing to defend, or replace, deep into the period when a quantum computer is expected to exist, so the decision made at purchase is load-bearing for decades.

That shifts where the leverage is. For OT, crypto-agility at design time, buying devices whose cryptography can be reconfigured and whose firmware can be securely updated, is worth far more than it is in IT, because the alternative is a physical swap. New OT procurement is the moment to require post-quantum readiness and agility in the contract, per procurement language, because it’s the only point of leverage before the device is frozen into a process for 20 years. And the devices that can’t be made agile become the long tail that has to be sequenced for physical replacement, planned years ahead so the replacements land before the threat does rather than in a panic after. The whole discipline of OT quantum planning is sequencing slow hardware turnover against a deadline that doesn’t move.

Common misconceptions

1. “Our OT is air-gapped, so quantum doesn’t affect us.” True air gaps are rare, and even a real one doesn’t stop harvested data leaving the segment from being decrypted later. Any OT data that crosses a boundary over a quantum-vulnerable channel is exposed regardless of the gap.
2. “We’ll just upgrade the OT firmware to post-quantum algorithms.” Many OT devices have cryptography compiled into firmware with no update path, so there’s nothing to upgrade in place. The realistic move is a gateway in front of the device or a scheduled physical replacement.
3. “Post-quantum algorithms will run fine on our controllers.” OT endpoints are often constrained devices, and the larger post-quantum artifacts may not fit their memory or their fieldbus bandwidth. Fit is the binding constraint rather than speed, and for the tightest devices a symmetric path may be the only option.
4. “There’s no quantum-safe option for hardware that can’t run ML-KEM.” A symmetric pre-shared-key scheme is quantum-resistant and needs no public-key math on the endpoint, as RFC 8784 shows for IPsec. It trades key-management overhead for working on hardware that could never run lattice cryptography.
5. “OT can migrate on the same timeline as IT.” OT is paced by decade-scale hardware replacement, not software releases, so its planning horizon is the longest in the estate. The devices bought today have to be defended or replaced deep into the quantum era, which makes procurement and agility decisions unusually consequential.

Questions people ask

Can you make OT quantum-safe without replacing the hardware? Often yes, by putting a gateway in front of the legacy device that runs quantum-safe protection on the network side and the device’s old protocol behind it. The device runs unchanged while everything reaching it is protected, which turns an impossible endpoint upgrade into a network-architecture change.

Does an air gap make OT safe from the quantum threat? Not reliably. Genuine air gaps are rare, and even a real one doesn’t protect data that leaves the segment. OT data flowing to monitoring or corporate systems over a quantum-vulnerable channel is exposed to harvest-now-decrypt-later no matter how isolated the source segment is.

What’s the simplest quantum-resistant option for a device that can’t run ML-KEM? A symmetric pre-shared-key scheme, which is quantum-resistant without any public-key math on the endpoint. RFC 8784 does exactly this for IPsec by mixing a post-quantum pre-shared key into IKEv2, so the tunnel is quantum-safe even though the endpoints run classical key exchange.

Why can’t I just swap the algorithm on an industrial controller? Because the cryptography is frequently compiled into firmware with no update path, so there’s nothing to reconfigure. The device’s algorithm was frozen at manufacture, which is why the answer is usually a gateway or a planned physical replacement rather than an in-place swap.

How long do I have to plan for with OT? The longest horizon in the estate, because industrial hardware runs 10 to 20 years or more. A device bought today has to be defended or replaced deep into the quantum era, so the agility and post-quantum readiness you require at purchase are decisions with a two-decade tail.

Is the size overhead a real problem for industrial networks? Yes, often more than in IT. OT links can be low-bandwidth fieldbuses where a kilobyte-scale handshake spans many frames or won’t fit at all, and constrained controllers may not have the RAM to buffer a large signature. The size overhead is a first-order constraint here, which is part of why gateways and symmetric paths are so useful.

When should I require post-quantum readiness in OT procurement? At every new purchase, because that’s the one moment of leverage before the device is frozen into a process for decades. Requiring crypto-agility and a secure update path in the contract, per procurement language, is what keeps a device from becoming part of the unmigratable long tail.

---

Everything here is the map, given freely. When your team needs its OT and ICS estate mapped by device lifetime and update capability, its air-gap assumptions tested, and a gateway-and-replacement sequence planned against the threat horizon, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.