Cryptography Challenges for Post Quantum OT Systems

SECURITY BRIEF: Quantum computing will introduce cryptography challenges for Edge devices now and in the future. Here we look at this challenge relative to the OT environment.

Quantum computing occupies an unusual position in the OT security conversation: it is simultaneously the reason current encryption will eventually fail and one of the technologies proposed to replace it. For OT and embedded environments, both sides of that story collide with the same structural problem — devices built to last ten to twenty-five years, running on hardware that was never sized for the cryptography now being asked of it. This briefing separates the near-term threat from the longer-term defenses, and focuses on what changes at the edge specifically.

2–5× Memory overhead PQC adds on constrained embedded devices

2029–2035 Range of credible CRQC-arrival estimates across assessments

Last OT's expected position in the enterprise PQC migration queue, per CISA

The Threat: Harvest Now, Decrypt Later

Shor's algorithm, run on a sufficiently capable quantum computer, factors the large integers and elliptic-curve problems that RSA and ECC depend on — the asymmetric cryptography underpinning most OT public key infrastructure (PKI), code signing, and certificate-based device authentication. Grover's algorithm offers a smaller but still material advantage against symmetric ciphers, effectively halving the strength of a key — AES-128 behaves like AES-64 against a quantum adversary, which is why NIST's post-quantum guidance pushes toward AES-256 as a baseline.

Neither algorithm requires a quantum computer to exist today to create risk today. In a harvest-now, decrypt-later (HNDL) pattern, an adversary captures encrypted traffic now — firmware update channels, OT-to-IT telemetry, provisioning exchanges — and stores it until decryption becomes feasible. For any OT asset with a service life measured in decades, data protected today may be exposed well before the device itself is retired. This is the piece of the quantum story that has nothing to do with when a cryptanalytically-relevant quantum computer (CRQC) actually arrives.

On timing, credible sources disagree meaningfully, and that disagreement is worth stating plainly rather than picking the most alarming figure. Some vendor and agency commentary points to CRQC capability arriving as early as 2026; other technical assessments place it in a 2029–2035 range. What is consistent across sources is the asymmetry: migration in OT takes years, the threat window is unknown, and HNDL exposure is already live. RAND's analysis of ICS cryptographic risk found that the highest-consequence failure points are concentrated in code-signing and firmware authentication, and at the top and bottom of the Purdue model — supervisory systems and enterprise-facing layers, and the lowest-level field devices.

The threat clock and the migration clock run at different speeds — and OT's migration clock is the slower one.

Quantum as Defense: What QKD Actually Offers the Edge

Quantum key distribution (QKD) is the quantum-as-defense half of this story, and it is frequently oversold in vendor material aimed at industrial buyers. QKD uses the behavior of quantum states to make eavesdropping on a key exchange physically detectable, offering security guarantees that do not depend on the computational hardness of a math problem. That is a genuinely different security model than PQC, and it is attractive for its own reasons.

It is also, for OT edge deployment, largely beside the point today. QKD requires dedicated point-to-point links — typically fiber, sometimes free-space or satellite — specialized transmitter/receiver hardware, and a classical authenticated channel alongside the quantum one. Key generation rates fall off sharply with distance, deployments to date remain concentrated in metro fiber pilots and high-value backbone or data-center-interconnect links, and the cost and integration complexity make it a poor fit for the sensor, PLC, RTU, and controller layer where OT actually lives. Where QKD has a plausible role in an OT architecture, it is protecting a small number of high-value supervisory or inter-site links, not securing the edge fleet.

The Practical Remedy: PQC and Crypto-Agility at the Edge

For the devices that actually populate an OT environment, the operative defense is post-quantum cryptography, not QKD. NIST finalized its first three PQC standards in August 2024: ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for general-purpose digital signatures, and SLH-DSA (FIPS 205), a hash-based signature scheme intended as a structurally different backup should a weakness ever surface in the lattice-based approach. NIST added HQC as a second key-exchange algorithm in 2025, again as a hedge built on different mathematics than ML-KEM.

Why this is harder on embedded hardware

PQC algorithms are not drop-in replacements on constrained silicon. Independent benchmarking shows memory requirements increasing roughly two- to five-fold over classical algorithms, energy consumption rising 15–50% on embedded platforms, and throughput on low-power microcontrollers running one to several orders of magnitude behind server-class hardware. For a device with a fixed BOM cost and a decade-plus deployment horizon, that is not a firmware patch — it can be a hardware sizing problem, and in some cases a hardware replacement problem.

What crypto-agility looks like in practice

The architectural answer is designing for algorithm change rather than for a specific algorithm. In practice that means: cryptographic operations called through a generic interface rather than hard-wired to RSA or ECC; secure boot chains with a field-updatable verification stage rather than immutable mask-ROM logic that can only be replaced with new silicon; and key material held in a secure element or hardware root of trust that can itself receive a firmware update. Hardware vendors are beginning to ship root-of-trust controllers with PQC acceleration built in — evidence the constraint is being taken seriously at the silicon level, though fleet-wide retrofit remains a multi-year undertaking for anything already in the field.

What this costs in practice

Engineering teams evaluating PQC migration typically raise four concerns — higher bill-of-materials cost, higher power and heat, larger form factors, and harder field upgrades. All four hold up, but not always for the reason assumed, and the actual mechanism matters for how a program should be scoped.

●       Bill of materials rises — as a new line item, not a per-chip markup. Retrofitting PQC into an existing SoC or flash controller typically means a new silicon mask, which is slow and expensive. The industry's actual response is to add a discrete secure element or coprocessor alongside the existing design. The BOM impact is a new component, recurring across every unit, not a price increase on the parts already there - unless there are aspects such as supply voltage requirements or necessity to increase PCB layers. But those are out of scope for this discussion.

●       Power and heat rise moderately in general, but the binding constraint is a threshold, not an average. Independent benchmarking puts PQC energy overhead at 15–50% on embedded platforms — real, but not dramatic, and hardware acceleration narrows it further. The sharper risk is where that heat lands: sealed, Ex-rated enclosures have no convective cooling and rely on conductive spreading against a fixed temperature class (T1–T6, as low as 85°C for T6). Even a modest added load can push a design toward its T-rating ceiling, which makes this a threshold problem rather than a linear one.

●       Form factor is rarely the binding constraint — recertification is. Modern secure elements are physically small; board space is usually not the limiting factor. The real exposure is regulatory: ATEX certification must be reissued if a manufacturer changes any part, rating, or drawing assessed under the original certificate. Adding a secure element or changing a device's thermal profile can reopen Ex certification even when the enclosure dimensions don't change at all.

●       Field upgrades are the sharpest constraint of the four. Benchmarking of firmware-update tooling (SUIT) on ARM Cortex-M4 hardware showed flash overhead and total update transfer size both increasing by roughly 120% moving from a classical signature (Ed25519) to a post-quantum one (Falcon/SHA3-256). Typical field-device MCUs carry 8–16 kB of RAM against PQC verification routines that commonly need on the order of 50 kB of working memory. Over bandwidth-constrained field links — LoRaWAN, NB-IoT, and similar — this is not a slower update; for genuinely constrained devices it can mean the unit cannot receive or verify new firmware at all without a hardware swap.

The binding constraint is rarely the chip itself — it's what changing the chip triggers downstream: a recertification, a bandwidth ceiling, a temperature threshold.

The implication for planning: cost and design impact from PQC migration should be modeled around these downstream triggers — recertification scope, thermal headroom, and update-channel bandwidth — rather than around per-unit silicon cost alone. A device that looks like a minor BOM change on paper can still force a full Ex recertification cycle or become permanently unreachable over its existing update channel.

Why OT Will Lag — and What That Means for Sequencing

CISA's guidance is direct on this point: OT is expected to be the last domain to reach post-quantum compliance, a consequence of long patch cycles, safety certification requirements, and the sheer difficulty of touching systems that cannot tolerate unplanned downtime. That is not a criticism of OT operators — it is a structural reality that should shape how a migration program is sequenced rather than be treated as a gap to apologize for.

There is a further nuance worth stating: much of the OT protocol layer never had strong cryptography to begin with. Where that is true, the quantum threat is somewhat academic — the exposure already exists today, quantum or not. Practitioner assessments consistently point to the OT-to-IT boundary, rather than deep field-level control loops, as where quantum-relevant cryptographic exposure is actually concentrated, because that is where PKI, TLS, and certificate-based authentication are more likely to be present and doing real work.

A Sequencing Approach

●       Inventory first. Map every cryptographic algorithm, certificate, and key-exchange mechanism in use across the environment before committing to a migration plan; this discovery phase alone commonly takes twelve to twenty-four months in a large estate, and most organizations that haven't started don't yet know the true scope.

●       Prioritize code-signing and the OT-IT boundary. These are the highest-consequence, most quantum-exposed points in the architecture — firmware authentication, certificate roots, and the systems bridging enterprise and control networks.

●       Segment what cannot be upgraded. Long-lifecycle field devices with hardcoded cryptography and no update path are not going to be PQC-capable on any realistic timeline; network segmentation and monitoring are the interim control, not a footnote. In the OT world this is just good practice and should be part of the system topology architecture.

●       Build agility into new procurement now. Specify a field-updatable secure boot path and hardware-isolated key storage as baseline requirements for anything being purchased today with a multi-year service life — retrofitting agility later is far more expensive than specifying it up front.

●       Treat QKD as an enterprise or backbone question, not an edge answer. It has a role in a small number of high-value links; it is not a fleet-wide OT strategy today.

A Structural Parallel: The Assurance Boundary Problem

This is the same failure pattern examined in Nexus's work on AI-augmented test tooling, and it is worth naming directly rather than leaving as an implicit connection. In that analysis, the finding was that AI generation layers sit outside the qualified boundary across every major test-tooling incumbent — tools generate test cases that inflate coverage metrics, but the generation layer itself has never been subjected to the TCL3-equivalent qualification rigor applied to the rest of the toolchain. Coverage goes up. Assurance does not. The gap is invisible until something the AI-generated suite should have caught gets through.

Crypto-agility has the identical shape, one layer down the stack. A device can add ML-KEM and ML-DSA support, tick the PQC box, and still have its actual root of trust — the logic that decides which algorithm to accept as valid — anchored in verification code that was never redesigned for a world where the accepted algorithm set changes over time. If that verification layer is itself immutable, or if it trusts a new algorithm without the same scrutiny applied to the one it replaced, the fleet has gained a checkbox and not gained assurance. In both cases the failure is not the new component; it is that the boundary of what counts as “qualified” or “trusted” never moved to include it.