This morning I was scrolling the CISA ICS feed and one entry stopped me. The advisory for Siemens Mendix Runtime, ICSA-26–209–02, came back as Update A. The update is one bolded sentence at the top. The advisory is revoked. Re-investigation confirmed the reported behavior is expected platform configuration and does not expose the protected attribute.

The original entry carried a CVSS v3 score of 9.1, a weakness class of Insecure Inherited Permissions, an affected range written as vers:all/*, and a sector tag of Critical Manufacturing, deployed worldwide. That is about as loud as an ICS advisory gets. Two months later it is gone. I want to use this one revocation to make a forecast about the next 12 to 18 months, because I think it is an early sample of a pattern that will get much larger, and eventually reach the post-quantum migration work that most of us in this field are preparing for.

What a revocation actually costs

A revoked advisory feels harmless. Nobody was breached. The vendor did the right thing by re-investigating. Yet every asset owner who ingested the original CSAF file between July and September did real work. A score of 9.1 on a product marked vers:all/* matches every Mendix deployment in every inventory. Vulnerability management tools raise it as critical. Change boards get asked about emergency windows. Somebody writes a compensating control memo for an application that turns out to be behaving exactly as designed.

The arithmetic of 9.1 is instructive too. On the CVSS 3.1 calculator you land on 9.1 with network access, low complexity, no privileges, no user interaction, and high confidentiality and integrity impact with no availability impact. That is the profile of an unauthenticated data exposure. When the finding is later explained as “expected configuration”, the mismatch sits between what the scoring assumed and what a correctly configured tenant actually exposes.

The deeper point is that the scoring system has no field for “depends on how the customer set it up”. Low-code platforms like Mendix push a lot of the security model into application-level configuration, entity access rules, and role inheritance that the customer’s developers define. A researcher who finds an attribute reachable through inherited permissions is looking at a real observation. Whether it counts as a vendor vulnerability or a customer configuration choice is a judgment call, and this time the judgment flipped after publication.

The feed is getting wider

Look at what else crossed the same feed this month. The supporting advisories are a useful cross-section of what CISA’s ICS program now covers.

Two of those six are consumer robot vacuums and a dashcam. One is an open-source PLC runtime used heavily in research and training. One is a low-code application platform. The traditional ICS core, meaning firmware on controllers and field devices, is a minority of the sample. The OpenPLC entry (ICSA-26–265–09) is the only one where the stated impact explicitly reaches “the physical processes it drives”.

I read this as a program whose intake has broadened faster than its triage model. Firmware bugs tend to be binary. A path traversal in SIMOVE Fleetmanager below 3.1.13 either exists or does not, and the version boundary tells you exactly who is affected. Platform software is different. The behavior depends on tenant configuration, deployment mode, and what the customer built on top. As the share of platform and IoT software in the feed rises, the share of advisories whose truth depends on configuration rises with it. Revocations are the visible tip of that.

A small model for triage noise

It helps to put a number on why a single revocation matters to an operator who runs hundreds of sites. Think of the feed as a classifier that labels product behaviors as vulnerabilities, and each operator as someone who pays a fixed triage cost for every label that matches their inventory.

Here N_k is the number of matched assets for revoked advisory k, t_k is the triage hours per asset, and w is the loaded hourly cost. The important term is N_k. An advisory scoped as vers:all/* maximizes it by construction. A revoked advisory with a narrow version range costs almost nothing. A revoked advisory that matched every install of a platform costs the full fleet.

Precision in the ICS feed has historically been high enough that most operators treat an advisory as ground truth. My real concern is what happens to operator behavior if precision drifts down for the platform-software slice. People start discounting advisories by vendor or product family. That discounting is rational locally and dangerous globally, because the next 9.1 on the same platform might be real.

Where the revocation has to travel

The mechanics of retraction matter as much as the decision. CISA publishes CSAF, and the Mendix revocation lives in an updated JSON document on GitHub. Whether an operator’s tooling actually clears the finding depends on whether that tooling re-polls the document, parses the revision history, and understands that a revoked status should close the ticket rather than simply stop updating it.

The loop from K back to E is the part that worries me. In my experience with plant-floor inventories, stale findings do not get deleted. They get risk-accepted, and a risk acceptance is a document that someone renews each year without rereading. A 9.1 that was never real can sit in a register for a long time and quietly distort where remediation budget goes.

CSAF 2.0 already has the vocabulary to fix this. The VEX profile lets a vendor say a product is known not affected and attach a justification, including that the vulnerable code is not reachable or that inline mitigations already exist. The ISA/IEC 62443–4–1 secure development lifecycle already expects suppliers to publish security guidelines, including hardening guidance, alongside the product. The missing link is joining the two, so that “expected configuration” points at a specific hardening statement the operator can verify in their own tenant.

The post-quantum version of this problem

Here is the hop that makes this more than a Mendix story. The PQC migration in industrial systems will be dominated by exactly this class of dispute, configuration versus vulnerability, at a scale that dwarfs low-code permissions.

Consider what a typical hybrid deployment looks like over the next two years. A gateway or engineering workstation ships with TLS 1.3 support for a hybrid key exchange pairing ML-KEM with X25519. For compatibility with older PLCs and historians, classical-only negotiation stays enabled by default. A researcher shows that an on-path attacker can strip the hybrid group from the ClientHello and force a classical handshake, which is fully exposed to harvest-now-decrypt-later collection. Is that a vulnerability, or expected configuration? The vendor will say the fallback is documented and configurable. The researcher will say the default leaves every long-lived OT session recordable. Both are partly right, which is precisely the Mendix situation with more at stake.

Constrained devices make this harder. On the class of microcontrollers I work with, the byte cost of ML-KEM public keys and ciphertexts is large compared with classical elliptic-curve keys, and lightweight protocols built for these links have tight message budgets. Vendors will ship PQC as an option that is off by default on the smallest devices for good engineering reasons. Every one of those defaults is a future advisory argument waiting to be scored.

What I expect by March 2028

Here is the forecast, written so it can be scored. I am treating September 2027 as the 12-month mark and March 2028 as the 18-month mark.

My primary call is that revocation and scope reduction become a routine, visible category in the CISA ICS feed. By March 2028 I expect at least five more ICS advisories to be revoked or materially rescoped through an Update notice, and I expect the majority of them to concern platform or web-application software whose behavior depends on configuration, rather than controller firmware. If I see fewer than three, I was wrong about the trend and Mendix was an outlier.

My second call is on tooling. By the 12-month mark, I expect Siemens ProductCERT to be publishing VEX-style “known not affected” statements with justifications in machine-readable form for at least some Mendix and SIMATIC software findings, and at least one major OT visibility vendor to advertise automatic closure of findings on CSAF revocation or VEX status. If both are still absent at 18 months, the stale-finding loop in the diagram remains the industry default.

My third call is the branching one, and it concerns post-quantum crypto. By March 2028 I expect the first ICS vendor advisory, from any vendor, where the core issue is a classical fallback or downgrade in a hybrid-PQC-capable product. If that advisory lands with a clear CVSS score and a fix that disables fallback by default, the feed has learned from cases like Mendix. If it lands and is later revoked as “expected configuration”, we will have imported the low-code dispute directly into the quantum transition, and asset owners will have to build their own policy on what counts as a crypto defect. My honest estimate is that the second branch is slightly more likely.

Reading the next bolded sentence

I keep going back to that one sentence at the top of Update A. It is short, precise, and it closes a 9.1 without explaining which configuration made the behavior expected or how an operator could confirm their own tenant matches it. That gap is the forecast in miniature. If in a year the revocations carry justifications I can check against my own deployment, and the first hybrid-PQC downgrade advisory is scored and fixed rather than argued away, I will count this piece as too pessimistic and be glad of it. If the next bolded sentence reads the same way and concerns key exchange rather than an attribute, then we will have eighteen months of warning that we did not use.

A bipartisan Senate bill landed yesterday called the Quantum-GUARD Act, and it would direct federal agencies to evaluate quantum-related cybersecurity risks, help electric utilities move to post-quantum cryptography, and improve coordination between grid operators and government partners. I read the summary twice. Then I opened the CISA ICS advisory feed from the same week, because that is where I go when I want to know what is actually breaking, and the contrast was hard to unsee.

Here is my position, stated plainly. The Quantum-GUARD Act is a good bill solving the second-hardest problem the grid has, and it will produce a decade of compliance activity that does not move the risk needle much, because the cryptographic layer of grid control systems is not where the grid is exposed. The exposure is in the device layer beneath the crypto, in field equipment that runs unauthenticated protocols, ships with root-privilege command injection bugs, and cannot be patched without a scheduled outage. A quantum computer that can break P-256 in 2033 is a real threat. An adversary who can already run arbitrary OS commands as root on a gateway sitting between a substation and a cloud service does not need one.

What the advisory feed said the same week

Look at what CISA published on August 13, 2026, alongside the bill announcement. The Haiwell IoT Cloud HMI Gateway advisory, ICSA-26–225–02, describes a flaw allowing an attacker to inject and execute arbitrary OS commands with root privileges. That is a gateway product whose entire job is bridging local HMI and PLC traffic to a cloud service. The ANDRITZ HIPASE-250 advisory, ICSA-26–225–05, covers four CVEs in a protection and control platform used in hydro and industrial generation, allowing an attacker to read data from the device or reach affected engineering workstations. The Siemens Desigo controller advisory, ICSA-26–225–08, describes a denial of service triggered by malformed BACnet packets where recovery requires a physical device reset.

None of those four vulnerability classes is affected by which key exchange you run. Command injection does not care whether the TLS session that carried the request used X25519 or ML-KEM-768. A malformed BACnet packet that wedges a controller until someone drives out and power-cycles it is a parsing bug in an unauthenticated protocol that has no cryptographic layer to upgrade in the first place. BACnet, DNP3 in its most widely deployed configurations, and Modbus were designed with the assumption that the network was the trust boundary. Adding a post-quantum handshake to a protocol stack that never had a handshake is not a migration, it is a redesign.

So when the bill’s summary says post-quantum cryptography will help ensure our power grids are resistant to quantum attacks, that sentence is true and narrow at the same time. It is true for the cryptography that exists. It is silent on the very large fraction of grid control traffic where no cryptography exists at all.

The harvest-now-decrypt-later argument, examined honestly

The strongest case for urgency is harvest-now-decrypt-later. An adversary captures encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists. For that threat to matter, the captured data has to still be valuable at decryption time. That is the piece I think grid advocacy consistently skips.

Write the risk as a product of three terms. Let P_Q(t) be the probability a cryptographically relevant machine exists by year t, let S(t) be the fraction of intercepted material that retains operational value after t years, and let C be the consequence if it is exposed.

For a bank, S(t) stays high for a decade. Account identifiers, medical records, and long-lived identity data age slowly. For a SCADA telemetry stream, S(t) collapses. A megawatt reading from a feeder in 2026 tells an attacker nothing useful in 2034. What survives that decay is a narrow and specific set: substation topology, protection relay settings, engineering credentials that get rotated rarely or never, and firmware signing keys. That last category is the one that genuinely deserves alarm, because a firmware signing key compromised by a quantum-capable adversary lets them push authenticated malicious firmware to every device in a fleet. The device authenticates it. The device is supposed to authenticate it.

That is a real quantum problem and the bill would help with it. My objection is that the bill’s framing spreads effort across the whole cryptographic surface rather than concentrating it on the sliver where S(t) stays near one.

Where the money should go instead

Consider what a utility actually faces when it tries to comply. Migration cost is not dominated by algorithm selection. It is dominated by device inventory, firmware availability from vendors, and outage windows. A protection relay with a fifteen-year service life installed in 2019 will still be in the field in 2034. Whether it can run ML-DSA is decided by its microcontroller, not by federal guidance.

Here are the numbers that shape that decision, drawn from NIST FIPS 203 and 204 and from published measurements on Cortex-M4 class hardware, which is what most modern relays and meters use.

The compute story is manageable. ML-KEM encapsulation is genuinely competitive with X25519 on the same core. The problem is the middle column. A 2420-byte signature against a 64-byte one is a 38x growth in every authenticated message. IEC 61850 GOOSE messages, which carry protection trip signals between substation devices, run under a 4 millisecond end-to-end budget and are typically sized to fit a single Ethernet frame. You cannot append a 2420-byte signature to a GOOSE frame and keep both the frame size and the timing budget. That is a physics-and-protocol constraint that no amount of federal coordination dissolves.

This is why I think the bill’s theory of change is off. It assumes the bottleneck is utility awareness and inter-agency coordination. The bottleneck is that a meaningful fraction of deployed grid equipment cannot run the new algorithms at all, and the replacement cycle is measured in decades of capital budget.

What a better bill would have said

If the goal is grid resilience against a quantum-capable adversary, the highest-leverage federal action is not a PQC transition mandate. It is a procurement requirement with teeth, applied at the point where devices enter the fleet.

Three things would matter more than what the current text does. Require cryptographic agility as a purchasing condition, meaning any device sold into bulk electric system service after a set date must support field-updatable signature and key-establishment algorithms with a documented rollover procedure. That single requirement converts the 2034 problem from a hardware replacement problem into a firmware problem, which is two orders of magnitude cheaper. Require a machine-readable cryptographic bill of materials alongside the software BOM already being asked for, so a utility can answer “which of my 40,000 field devices use RSA-2048 for firmware verification” with a query rather than a two-year consulting engagement. And prioritize the signing infrastructure, the code-signing roots and the certificate authorities that gate firmware distribution, ahead of session encryption, because that is where S(t) stays high.

The ISA/IEC 62443 work I have been involved with through ISA99 already has the structural hooks for the first two of those, in the component security requirements and the security level framework. Aligning federal procurement language with the existing standard would have cost less legislative effort than creating a parallel evaluation program, and utilities are already building 62443 conformance into supplier contracts.

The part of the bill I would keep

I want to be fair to what the bill gets right, because the coordination provision is genuinely useful and is the piece most likely to survive contact with reality.

Grid operators do not currently have a shared view of which vendors have PQC roadmaps and which do not. A relay vendor telling one utility that a post-quantum firmware branch is coming in 2029 and telling another that it is not planned is a market failure that federal convening power can actually fix. If the coordination mandate produces a public vendor-readiness registry, that alone justifies the bill. It changes procurement leverage. A utility with 200 relays on a contract renewal can push a vendor much harder when it can point at three competitors who have shipped.

The risk-evaluation mandate is the part I would rewrite. An evaluation that inventories cryptographic algorithms will produce a report saying the grid uses a lot of RSA-2048 and ECDSA P-256, which we already know. An evaluation that inventories which devices have the memory headroom, the update mechanism, and the vendor support to accept new algorithms would produce something nobody has, and it is the input every subsequent decision depends on.

Back to the advisory feed

The week the Quantum-GUARD Act was announced, CISA published advisories covering a root command injection in a cloud-connected HMI gateway, four vulnerabilities in a generation protection platform, a remotely exploitable code execution path in a video management server used across utility physical security, a privilege escalation in a license server, and a controller that any attacker on the network segment can wedge with a malformed packet. Every one of those is exploitable today, by an adversary with a laptop, against equipment that is in the field right now.

I am not arguing the grid should ignore post-quantum cryptography. I have spent enough time on PQ-EDHOC in the IETF LAKE work to believe the constrained-device migration is solvable and worth solving. I am arguing that a bill named for grid resilience against quantum-powered hacks should be honest that the quantum part is the smaller half of the problem, and that the money it directs will do the most good if it is spent on cryptographic agility and firmware-signing infrastructure rather than on a broad transition program whose first output will be a report.

When the first cryptographically relevant quantum computer arrives, the grid’s problem will not be that its TLS sessions were the wrong algorithm. It will be that a third of its field devices never had a session to protect, and that we spent the intervening decade writing reports about the other two thirds.

A few weeks ago I was rereading a vendor whitepaper on securing field devices against the quantum threat, and one sentence stopped me. It claimed, in the confident tone these documents always use, that hardware acceleration for post-quantum cryptography means “committing silicon to a chosen algorithm.” The implication was that if you want the speed of a coprocessor, you give up the ability to swap algorithms later. You bet the board on ML-KEM, or on Falcon, and you live with it for the fifteen-year service life of the device.

I have heard some version of this in enough hallway conversations that it has hardened into received wisdom. It shows up when someone argues we should wait before building PQC hardware, because NIST might still shift, because a scheme might get broken, because standardizing silicon around a moving target is reckless. And it has a real basis. Most published PQC accelerators do target one family. A Keccak-heavy datapath for SLH-DSA looks nothing like an NTT-heavy datapath for ML-DSA. So the trade-off feels physical, almost thermodynamic. I want to test that claim against a specific piece of work, because a paper posted to arXiv this week takes direct aim at it.

Naming the claim before testing it

The claim, stated plainly, is this. On a constrained device you can buy PQC performance with dedicated hardware, or you can keep crypto-agility in software, but you cannot have both in the same silicon budget. Call it the crypto-agility tax. The tax is supposedly paid in area, because supporting five very different algorithms in hardware means five sets of datapaths, and no embedded designer working inside a few tens of thousands of logic cells can afford that.

This matters far outside academic curiosity. The devices that will carry PQC the longest are exactly the ones with the least room to spare. Look at the ICS advisories CISA published this month. An ABB Advant Master Online Builder flaw, a Rockwell 1715-AENTR EtherNet/IP adapter that an attacker could use to change I/O states, an ABB T-MAC Plus with multiple CVEs. These are the endpoints that authenticate firmware and negotiate keys on the grid. When the migration to post-quantum signatures reaches them, whatever crypto they run has to fit in the area and energy that was budgeted years earlier. If the crypto-agility tax is real, most of that installed base gets locked into whatever scheme looked safest at design time.

HORCRUX, the RISC-V extension in the paper, is interesting precisely because it refuses to pay the tax. It targets a single, unified instruction-set extension that supports every NIST-approved PQC algorithm at once. ML-KEM, ML-DSA, SLH-DSA, HQC, and Falcon all run on the same tightly coupled coprocessor. The design bet is that the tax was never charged on the algorithms themselves. It was charged on our habit of accelerating them one at a time.

The shared-kernel insight

The move that makes this work is looking underneath the algorithm names. A signature scheme is a marketing label for a pipeline of arithmetic kernels, and those kernels repeat across families more than the family boundaries suggest. Keccak permutations sit under both the hash-based SLH-DSA and the sampling stages of the lattice schemes. Polynomial arithmetic and number-theoretic transforms drive ML-KEM and ML-DSA. Rejection sampling, modular reduction, and fixed-weight vector generation recur with small variations. If you accelerate the kernel instead of the scheme, one coprocessor can serve algorithms that look unrelated at the API level.

Seen this way, the five algorithms are not five hardware problems. They are three or four kernel problems wearing five names. The coprocessor exposes new RISC-V instructions that the core issues as it walks through any of the schemes, and the tight coupling means there is no bus round-trip to a loosely attached accelerator on every kernel call. That coupling is what keeps the energy cost down, which is the constraint that actually binds on a battery-limited or thermally-limited field device.

I want to be careful not to accept the design story just because it is elegant. Elegance is a common failure mode in security engineering. The right test is whether the numbers hold when you build it, so let me turn to the measurements the authors report from a Zynq UltraScale+ FPGA and a 65 nm ASIC synthesis.

Before the speedups mean anything, they need a baseline. In related work I ported FIPS 203 and FIPS 204, the ML-KEM and ML-DSA standards, to an ATmega328P with 2 KB of SRAM, and measured roughly 136 ms per signature in pure software. That is an 8-bit part, more constrained than most modern OT endpoints, but it sets the shape of the problem. Software PQC on a small microcontroller is not unusably slow for an occasional handshake. It becomes a problem when a device signs or verifies frequently, or when it has an energy budget measured in microjoules per operation, or when the handshake sits on the latency-critical path of a protective relay. That is the regime where a coprocessor stops being a luxury.

Testing the claim against the measurements

Here is where the received wisdom should either survive or break. If the crypto-agility tax were real, a design supporting all five families in one small extension would show weak speedups, or a large area, or both. The reported figures point the other way.

The area cost for all of that is under 21k LUTs and 4.4k flip-flops on the FPGA, with ASIC characterization done in 65 nm CMOS. To put 21k LUTs in perspective, that is a small fraction of a mid-range Zynq part, the kind of budget a designer might allocate to a single-purpose accelerator. The unified extension is asking for roughly what the received wisdom said one algorithm’s accelerator would cost, and it is covering the whole approved suite.

The uneven speedups are the honest part of the story, and they are worth reading closely rather than averaging away. Hash-based signing gains the most because SLH-DSA is dominated by enormous numbers of Keccak permutations, and Keccak is the kernel that maps most cleanly to fixed hardware. Lattice schemes gain the least in relative terms because their software implementations are already well tuned, and because more of their runtime sits in control logic and memory movement that a kernel accelerator does not touch. A 9x improvement on ML-DSA is not a disappointment. It is what Amdahl’s law predicts once the arithmetic kernel stops being the bottleneck.

Where the popular framing actually breaks

The framing breaks at a specific point. It assumed the cost of hardware PQC scales with the number of algorithms you support. The data says it scales with the number of distinct kernels, and the kernels are far fewer than the algorithms. Once you accept that, the trade-off the whitepaper described stops being physical and starts being a consequence of how you chose to partition the problem.

Amdahl’s law makes the ceiling explicit. If a fraction p of an algorithm’s runtime lives in kernels you can offload to the coprocessor at a per-kernel speedup of k, the whole-algorithm speedup is bounded by

For SLH-DSA, p is close to one and k is large, so S climbs toward the 129x figure. For a lattice signature where control and memory traffic keep p lower, the same coprocessor yields a single-digit S no matter how fast the kernel runs. The number that decides your outcome is p, the share of work that is actually shared arithmetic, and that share is a property of the algorithm, not of your willingness to spend silicon. A unified extension does not beat this bound. It does something better. It reaches the bound for every approved algorithm simultaneously, out of one area budget, so the choice of which scheme to deploy moves back into firmware where it belongs.

That is the real refutation. Crypto-agility was never fundamentally opposed to hardware acceleration. It was opposed to per-algorithm hardware acceleration, which is a design pattern we adopted for convenience and then mistook for a law. When you accelerate kernels, the agility comes for free, because switching from ML-DSA to Falcon after a cryptanalytic scare is a firmware change that reissues different instructions to the same coprocessor. No respin, no new tapeout, no stranded devices in the field.

There are caveats I would want addressed before treating this as settled. FPGA LUT counts and 65 nm synthesis numbers do not translate directly to a modern low-power node, and the energy figures that matter most for battery devices deserve their own scrutiny under real duty cycles. Side-channel resistance is its own question, because a shared datapath that touches secret material across five algorithms is a rich target, and constant-time behavior has to be proven per kernel, not assumed. None of these undercut the central claim. They are the engineering work that follows once the architectural objection has been answered.

The sharper version of the claim

So I will restate the received wisdom the way the evidence forces me to. The old claim said you must choose between PQC performance and crypto-agility on a constrained device. The sharper version is that you must choose between per-algorithm acceleration and crypto-agility, and per-algorithm acceleration was the wrong default all along. Accelerate the shared kernels, keep the algorithm selection in software, and the trade-off the whitepaper treated as fundamental turns out to be a self-inflicted one.

This is not a small distinction for the people who have to migrate the installed base. Go back to those CISA advisories. The relays, adapters, and controllers named in them will still be running when the first cryptographically relevant quantum computer is a live concern rather than a slide. If we tell their designers that PQC hardware means betting on one algorithm, many of them will reasonably defer, and the grid inherits a fleet that either cannot accelerate PQC or is locked to a scheme that may not survive the decade. If instead the design language is kernel acceleration with software-selectable algorithms, the same device can carry SLH-DSA today and pivot to whatever replaces a broken lattice scheme tomorrow, without anyone climbing a substation tower to swap a board.

That sentence in the whitepaper still bothers me, but for a different reason now. It was not wrong about the physics. It was wrong about the partition, and the partition was a choice we were free to make differently the whole time. A compact extension that holds all five approved algorithms in under 21k LUTs is not a clever trick around the crypto-agility tax. It is the quiet argument that the tax was never owed.

A few days ago I was reading through Q-CTRL’s Q2B Tokyo write-up and one line kept pulling my attention back. Not the defense sensing announcement, and not the workforce program either. It was the sentence framing Fire Opal as a “hardware-agnostic performance layer.” That phrasing is doing more work than it looks. When a small firm quietly ships a runtime abstraction that sits between algorithm and silicon, and it works well enough that IBM users are running materials chemistry through it, something is shifting in how the field organises itself.

I want to write down what I think the next twelve to eighteen months will look like if that framing holds. Pin this piece, and score me on it in July 2027.

The week itself was ordinary. The direction was not.

The Tokyo demo was materials simulation on IBM Quantum hardware, with Fire Opal handling error suppression. Q-CTRL also folded in updates on defense sensing pilots and a workforce readiness push. Taken piece by piece it looks like a regular product cadence. Taken together it reads like a company that has stopped pretending the near term is about qubit counts and has started competing on the fidelity of what already exists.

That matters for anyone tracking the transition from experimental quantum systems to critical-infrastructure-adjacent ones. The moment a performance layer becomes a default assumption, the entire NISQ conversation moves from “when do we have a fault-tolerant machine” to “what can we do this quarter with the machine we already have, dressed differently.” Vendor procurement cycles run on the second question, not the first.

I ran a small QML classification experiment on ibm_fez, a 156-qubit Heron device, last year and published the results in IEEE Access. The AUC gain over a matched classical SVM was small but statistically stable across two testbeds. My takeaway from that work was that the delta was real, and that most of the practical variance came from device drift and readout error rather than from the model. A better performance layer would have absorbed most of it. Fire Opal, and the class of tools it belongs to, is where that absorption goes to live.

The forecast on error suppression

Here is the first prediction. By the end of 2027, at least one of the three major western QPU stacks (IBM, Quantinuum, IonQ) will ship a Fire-Opal-style performance layer as a default runtime option, not an add-on the customer bolts on themselves. The economic argument is straightforward. If a suppression layer buys you an effective per-gate error reduction of roughly a factor of three on a device that costs seven figures a year to keep useful, no procurement team is going to leave it off.

Q-CTRL is well positioned but not certain to be the winner. IBM has its own Qiskit runtime primitives. Quantinuum has published dynamic decoupling schedules. The winner may be the vendor that first agrees to a public benchmark and lets others verify it. Absent that, we get vendor-locked “utility” claims that never quite reproduce off-platform.

The second prediction is about workloads. In the same window I expect the first cross-verified quantum-plus-classical hybrid result on a materials or logistics problem that a serious industrial buyer signs off on. A signed pilot, not a preprint. When that lands, the conversation stops being about Nobel-track physics and starts being about procurement.

The reason the flow above matters for a security engineer is the last two boxes. Once quantum-enhanced sensing and signal processing reach procurement, they enter the same OT supply chain that runs SCADA, substation automation, and satellite ground segments. A quantum magnetometer for grid current sensing is still a networked device with firmware. It sits on the same asset inventory as everything CISA has been publishing advisories about for a decade.

The critical infrastructure hop

This is where the forecast gets uncomfortable. Last month CISA issued advisories on Gardyn IoT Hub (ICSA-26–183–03), ST Engineering iDirect iQ-Series satellite terminals (ICSA-26–183–01), CubeSpace CW0057 reaction wheels (ICSA-26–183–02), and Frangoteam FUXA SCADA/HMI (ICSA-26–181–02). Each of these is a routine advisory. Each is also a preview of the class of asset that will inherit quantum sensing modules in the next procurement cycle.

The CubeSpace advisory is the one I keep returning to. It flagged arbitrary firmware upload on a reaction wheel, a component that will absolutely appear on satellites carrying quantum-derived timing or magnetometry payloads within the next two years. The moment a satellite bus supplier adds a low-noise quantum sensor to differentiate a product line, the sensor inherits every weakness of the bus. A Fire Opal on the ground station does not fix a firmware upload flaw in orbit.

The ST Engineering iDirect advisory covers Evolution iQ and 3315 terminals through firmware 4.5.2.1. These terminals sit in the ground segment for a large chunk of commercial satellite comms. If a defense customer adopts quantum key distribution or quantum-augmented ranging on the same physical network, the perimeter defence assumptions inherited from the classical stack propagate straight through. New physics does not repair a legacy TLS handshake weakness.

The rough math I have been carrying around looks like this. If a suppression layer reduces the effective per-gate error by a factor of eta below one, and the circuit contains G two-qubit gates at raw error rate epsilon, the probability of a successful shot is approximately

For a circuit with roughly a thousand two-qubit gates, a raw error rate of five parts in a thousand, and a suppression factor eta of 0.3, this pushes P from around 0.007 to 0.22. That is the difference between a curiosity and a demo you can put on a slide with a straight face. It is also the difference between a sensing algorithm that stays in a lab and one that ships in a grid inspection drone.

The PQC crossover timeline

The other clock ticking here is the post-quantum crypto migration timeline. NIST finalised FIPS 203, 204, and 205 in 2024. Federal civilian agencies were pushed to complete inventory of quantum-vulnerable cryptography by 2027 under CNSSP-15 style guidance. The IETF LAKE working group, which I sit on for the PQ-EDHOC design track, has been shipping post-quantum extensions for constrained device handshakes. The question I want the reader to hold in mind is whether these two clocks, one measuring quantum capability and one measuring migration completion, are converging or diverging.

My forecast is that they will diverge unpleasantly. Migration will complete in the easy places (federal web, TLS 1.3 at cloud provider edges) and stall at the hard places (OT firmware, satellite ground segments, industrial PLCs). Meanwhile Fire-Opal-class layers will keep raising the practical utility ceiling of NISQ. Neither clock hits the doomsday deadline in 18 months, but the gap between “we can now do useful things with quantum” and “we have migrated our legacy fleet” will visibly widen and enter congressional testimony language.

The last row is the one I would score most harshly on. If we get through July 2027 without a single CISA advisory that touches a quantum-adjacent component, my model of how quickly quantum sensing enters procurement is wrong and I will need to slow my forecast by twelve months. If we see the advisory before mid 2027, procurement has been faster and quieter than I thought, and the migration gap is worse than my current worry.

What to score me on

If you are reading this in July 2027, here is the checklist. Is a Fire-Opal-class performance layer now a default runtime primitive on at least one of IBM, Quantinuum, or IonQ. Has a cross-verified industrial pilot been announced with a signed buyer, meaning something beyond a vendor press release. Has the PQ handshake footprint inside constrained OT firmware crossed the twenty percent line. Has any US transmission owner disclosed a quantum sensing pilot. Has a CISA advisory referenced a quantum-adjacent component.

Four out of five and I called this well. Two or fewer and I was too aggressive on the quantum side and probably too pessimistic on the OT migration side. If none of them landed, the entire Q-CTRL week I built this forecast around was a plateau signal that I misread as an inflection point. I think the odds of misreading it are real. I also think the shape of the last three months of Q-CTRL, Quantinuum, and IBM announcements makes the four-out-of-five outcome the base case.

The thing I keep coming back to is the sentence I started with. “Hardware-agnostic performance layer.” When infrastructure providers start calling themselves layers, the field they sit in is standardising underneath them. That standardisation is what pulls quantum computing into the same procurement pipelines that already produce every CISA advisory I read on Monday mornings. Q-CTRL’s quiet week was a marker on the road to that pipeline meeting, and the pipeline meeting is where security engineers earn their salaries.

A few weeks ago a CISA advisory landed for the Mitsubishi MELSEC iQ-F Series FX5-ENET/IP Ethernet module, and a small phrase in the summary stopped me. The advisory says a flood of packets prevents the internal anomaly-detection processing from being performed. That is a denial-of-service finding on a small PLC communications module, on its face routine. The mechanism it implies is anything but routine. The attacker never crashes the device. The crash arrives later, from the device’s own supervisor, after the safety task it was supposed to lean on has gone quiet for too long.

I want to walk through that mechanism carefully. The CVE is CVE-2026–8806, listed against all firmware versions of the FX5-ENET/IP. The behavior it describes shows up in a lot of small industrial network stacks, and once you understand the queue dynamics that produce it, you can reason about the next twenty advisories that look like it.

What the device actually is, and why the watchdog matters

The FX5-ENET/IP is an add-on module for the MELSEC iQ-F compact PLC family. It carries EtherNet/IP traffic into the PLC backplane. In a typical plant it sits between the controller and remote I/O drops, drives, or vision systems. Its CPU is small, on the order of a few hundred MHz, with a handful of megabytes of RAM. There is no general-purpose OS in the way most engineers think of one. There is a real-time scheduler, a TCP/IP stack tuned for industrial protocols, and a set of cyclic tasks that handle the cyclic and explicit messaging that EtherNet/IP requires.

One of those tasks is the anomaly-detection routine the advisory names. In Mitsubishi’s documentation this is the function that flags malformed frames, suspicious connection rates, and protocol-level violations. It is the local equivalent of a watchdog plus a tiny intrusion sensor. It is also a periodic task, and that periodicity is what the attack exploits.

When you read the CISA text closely, the attacker is not exploiting a buffer overflow or a parser bug. They are exploiting scheduling. They send packets fast enough that the lower-priority anomaly task never gets its slice, because the higher-priority packet handler keeps preempting it. Eventually the device decides the communication function is unhealthy and stops it. The intrusion sensor never got a vote.

A short tour through the queue

To see why this happens, picture the data path through the module. A frame arrives at the MAC. A DMA engine moves it into a receive ring buffer. An interrupt service routine wakes the protocol task, which validates the L2 and L3 headers, hands the payload to the EtherNet/IP session manager, and signals the anomaly task that there is a new event to inspect.

Each step has a cost, measured in microseconds of CPU time. Each step also has a queue in front of it. The receive ring buffer is one. The protocol task’s work queue is another. The anomaly task’s event queue is the third. Under normal traffic the queues stay short, because the service rate of every stage exceeds the arrival rate. Under attack the arrival rate climbs past the protocol task’s service rate, and the protocol task starts spending all of its budget on incoming frames. Because the protocol task runs at higher priority than the anomaly task, the anomaly task is preempted indefinitely.

That is the core insight. The device can still handle individual packets, the parser does not blow up, no malformed frame triggers a fault. The anomaly check is simply starved of CPU before any packet is dropped, and the defensive layer goes dark while the offensive load is still being politely accepted.

Modeling it like an M/M/1 queue, with the priorities included

Let me put numbers on this. A reasonable first-cut model treats the protocol task as a single-server queue with arrival rate \lambda packets per second and service rate \mu_p packets per second. The utilization of the protocol task is \rho_p = \lambda / \mu_p. When \rho_p approaches one, the average queue length grows without bound and the task occupies the CPU continuously.

The anomaly task runs only when the protocol task yields. Its effective service capacity is the residual CPU after the protocol task finishes its work. If we call the fraction of CPU consumed by the protocol task U_p, then the anomaly task can spend at most 1 — U_p of the CPU on its own work. With a periodic deadline of T_a seconds and a per-cycle compute budget of C_a seconds, the anomaly task meets its deadline only while:

Rearranging, the attack succeeds the moment U_p > 1 — C_a / T_a. For a typical small PLC module, C_a might be 2 milliseconds and T_a might be 10 milliseconds, so the anomaly task survives only while the protocol task consumes less than 80 percent of the CPU. Push it past that and the anomaly task misses its deadline. After a few consecutive misses, the device’s internal supervisor decides the communication function is unhealthy and shuts it down. That is the DoS the advisory describes.

The model is rough. Real industrial stacks have interrupt coalescing, priority inheritance, and watchdog windows that smear the boundaries. The shape of the failure is right though. There is a clean threshold in arrival rate, below which everything works and above which the safety task starves.

A worked example, with packets per second on the x axis

Suppose the protocol task can process 50,000 minimum-size EtherNet/IP frames per second when it owns the CPU. Suppose the anomaly task needs 2 milliseconds out of every 10 to do its work. The threshold utilization for the protocol task is 0.8, which means the attack tips over at 40,000 packets per second of sustained flood. On a 100 megabit link, 40,000 minimum-size frames per second is roughly 27 megabits per second of traffic. That is well within what a single laptop on the OT segment can produce, and easily within reach of any compromised HMI or engineering workstation already inside the cell.

Here is what the device sees as the load climbs.

Read across the table and you can feel the cliff. There is no graceful degradation curve, no warning indicator that climbs as load increases. The anomaly check is fine until it is not, and the device’s own shutdown logic is triggered by the missed-deadline counter rather than by detecting the attacker.

Why the fix is harder than it looks

If you sketch the obvious mitigation, you write something like “give the anomaly task a guaranteed CPU reservation”. On paper that works. In practice it does two awkward things. It caps the throughput the protocol task can deliver under heavy legitimate load, which matters in plants where a startup transient or a controller reboot can briefly push real traffic above the cap. It also moves the failure mode from “anomaly task silent” to “legitimate packets dropped”, which is operationally worse for an EtherNet/IP cyclic connection running with a 10 millisecond requested packet interval.

A better fix shapes the input rather than the schedule. The MAC and DMA layer can be configured to drop frames once a per-source rate threshold is exceeded, before the protocol task even sees them. That preserves the anomaly task’s CPU budget without choking legitimate traffic. The cost is a small amount of silicon and firmware complexity, and most low-cost industrial Ethernet modules skip it because the threat model assumes a benign LAN. The MELSEC iQ-F advisory, like several others Mitsubishi has published this year, lives in the gap between that assumption and the reality of flat OT networks.

Mitsubishi published a companion advisory the same week on a related TCP connection-exhaustion bug in the iQ-F CPU module itself, ICSA-26–169–05, which describes improper memory access under rapid TCP connection establishment. The shape is similar. The attacker exploits the scheduling and resource accounting of a small stack rather than a parser bug. Compare that with Schneider’s EasyLogic T150 advisory the same day, which is about file-access exposure, a completely different class of bug rooted in authorization rather than timing. The Mitsubishi findings sit in the timing family. The defensive instincts that work for parser flaws do not help here.

What an operator should actually do this week

The patch advice in the CISA bulletin will be to update firmware once Mitsubishi publishes a fix. Until then the practical mitigation is network-layer. Put the FX5-ENET/IP behind a managed switch that supports per-port storm control and ingress rate limiting. Set the storm-control threshold below the cliff in the table above, with a margin for legitimate bursts. A reasonable starting point is 25 percent of the link rate, which on a 100 megabit port is 25 megabits per second, comfortably below the 27 megabit per second flood that tips the device over.

Segmenting the EtherNet/IP cell from the rest of the OT network earns its keep here. If the only hosts that can reach the FX5-ENET/IP are the controller and the I/O drops it talks to, the flood has to originate from inside that segment, which raises the bar on the attacker considerably. Most plants I still walk into have a flat layer-2 broadcast domain across the controls VLAN, which is exactly the topology the threat model of these modules quietly assumes is gone.

The deeper lesson is the one I keep coming back to with these small-stack advisories. The interesting attack surface in industrial Ethernet is no longer the protocol parser. It is the scheduler. Modern fuzzers find parser bugs quickly, and vendors patch them. The bugs that remain are the ones that emerge from the interaction between a periodic safety task and an aperiodic adversary, and those bugs do not show up in a static analysis pass.

That is what made the small phrase in the advisory stick with me. The communication function stops because the anomaly check could not run. The device shuts itself down, in the order its designers specified, after the part of the device that was supposed to notice the attack had already been quietly silenced. The packets are still arriving when the lights go out.

How a Packet Flood Silences a PLC’s Own Watchdog was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few weeks ago I was reading through a batch of CISA ICS advisories that landed on the same day, and a pattern caught my attention. On June 4, 2026, five advisories went out at once. A buffer overflow in Hitachi Energy MACH HiDraw that can reach arbitrary code execution. Availability faults in the RTU500 line. An OPC-UA server in a B&R PPT30 operating system that an attacker can make simply disappear. A SOAP method in a NAVTOR NavBox that a local attacker can reach without authorization. None of these are exotic. They are the ordinary weather of operational technology.

What struck me was the gap between that weather and the conversation happening one layer up. The same week, I was reading a tutorial paper on blockchain as the coordination layer for embodied AI, the kind of world-model robotics that will soon be generating petabytes of sensor data that somebody, somewhere, has to trust for decades. The paper’s thesis is elegant and increasingly common. I want to test it, because I think the popular version of it is wrong in a specific and fixable way.

The claim everyone is repeating

Here is the received wisdom, stated as plainly as I can. A post-quantum blockchain gives embodied AI a trustworthy data economy. Put consensus and quantum-safe signatures under the data, and you get provenance you can rely on, cross-organizational governance you can audit, and incentive-compatible sharing across parties who do not trust each other. The ledger becomes the trust layer for cyber-physical-social systems.

I have a lot of sympathy for this framing. It is the natural reading of the recent arXiv tutorial that ties embodied AI, quantum threat, and distributed ledgers into one story, and the underlying logic is sound as far as it goes. Long-lived verification really does demand crypto-agility. A robot fleet trained on data captured today will be making safety decisions on that data in 2040, and the signatures protecting that provenance must survive an adversary with a cryptographically relevant quantum computer. That much I will defend without reservation.

The problem is the word “trustworthy.” A blockchain can guarantee that a record has not changed since it was written. It can guarantee who wrote it, if the writer’s key is sound. It cannot guarantee that the record was true at the moment of writing. Those are different properties, and the popular framing quietly collapses them into one. The ledger secures the journey of the data. It says nothing about the birth of the data.

Where the framing breaks

Look back at those CISA advisories. Every one of them describes a device that sits below the ledger, at the point where physical reality becomes a number. The RTU is the thing reading current and voltage off a substation bus. The OPC-UA server is the thing publishing machine state to whatever consumes it. The NavBox is the thing a vessel’s systems talk to. These are the witnesses. They are exactly the components that an embodied AI data economy would treat as ground truth.

If an attacker exploits the buffer overflow in MACH HiDraw and achieves code execution, they do not need to break the blockchain. They feed it. They sit at the witness and emit values that are false but perfectly well formed. The ledger receives them, hashes them, signs them with an immaculate ML-DSA signature, and commits them forever. What you have built is a tamper-evident, quantum-resistant, eternally auditable record of a lie. The cryptography did its job flawlessly. That is the danger.

Read that table as an inventory of trust roots, not as a patch list. Three of the four entries are availability or integrity faults at the precise layer the data economy treats as authoritative. A coordination architecture that secures the ledger and assumes the witness is honest has secured the easy half of the problem. The hard half lives in firmware that ships with memory-safety bugs and reaches end-of-support while the data it produced is still being trusted.

This is the part the popular framing skips. It treats provenance as a property of the storage layer. Provenance is actually a property of the capture layer, and the storage layer can only preserve whatever quality the capture layer handed it. Garbage in, signed garbage out, and now the garbage is immutable.

The quantum clock starts at capture

The standard way to reason about migration urgency is Mosca’s inequality. Let me write it in the terms that matter here.

The meaning is simple. If the time your data must stay confidential or verifiable, plus the time it takes you to migrate your systems to post-quantum cryptography, is greater than the time until a quantum adversary arrives, you already have a problem today. The harvest-now-decrypt-later attacker is collecting your traffic now to break it later, and for signatures the analogous worry is forge-later, where a captured public-key relationship is broken after the fact to fabricate provenance.

Embodied AI makes the left side of that inequality enormous. A robot’s training corpus and the safety case built on it are not transient. They have to verify for the operational life of the fleet, which is measured in decades. That pushes the shelf-life term up. Meanwhile the migration term for operational technology is brutal, because the witnesses are constrained devices on long replacement cycles, many of which appear in advisories like the ones above precisely because they are old. When both the shelf-life term and the migration term are large, the inequality is satisfied long before the quantum computer is real. The clock that matters started ticking at the moment of capture, not at the moment of consensus.

So the received wisdom is half right in a way that is worse than being simply wrong. It correctly identifies that the cryptography must be quantum-safe. It incorrectly locates where that cryptography has to live. Putting ML-DSA on the validators while the RTU still signs with a classical key, or worse signs nothing and is trusted by position, leaves the longest-lived and most exposed link in the chain unprotected. The CNSA 2.0 timeline that mandates this migration does not exempt the edge. The edge is where the timeline is hardest to meet.

Push the crypto down, not the consensus up

The fix is not a better ledger. It is crypto-agility pushed down to the witness, so that the device which first turns physics into a number is also the device that signs it with a key the quantum era cannot forge. The honest objection is that these devices are tiny. People assume post-quantum signatures are too heavy for an 8-bit microcontroller, and they say so often enough that it has become its own piece of received wisdom.

It is testable, so I tested it. In related work I benchmarked ML-DSA, the FIPS 204 standard, signing on an ATmega328P with 2 KB of SRAM, and measured 136 ms per signature. That is a constrained part by any definition, the kind of microcontroller that sits in a metering node or a simple sensor. A 136 ms signing operation is entirely workable for a device that reports on the order of seconds. The feasibility claim is not aspirational. The primitive runs where it needs to run.

The dotted path in that diagram is the one the popular framing ignores and the one the CISA advisories keep illuminating. If the witness is compromised at the firmware level, signing at capture does not save you either, because the attacker now holds the signing key. That is the real reason memory safety and crypto-agility are the same project, not two adjacent ones. The signature is only as trustworthy as the integrity of the thing holding the private key, which means secure boot, attestation, and timely patching at the edge are preconditions for the ledger to mean anything.

There are worked examples of this intersection done end to end. In a quantum-resilient blockchain design for IoT energy metering I went through the full path, where the metering node signs with a post-quantum primitive at the point of measurement and the ledger settles those signed readings. The lesson from building it was blunt. The ledger was the straightforward part. Getting trustworthy, attestable, quantum-safe signing onto the constrained node at the moment of capture was the part that actually decided whether the system could be believed.

A sharper version of the claim

So where does the data leave the received wisdom. Not discarded. Sharpened. A post-quantum blockchain does not give embodied AI a trustworthy data economy. A post-quantum blockchain preserves, immutably and verifiably, whatever trust the capture layer was able to establish. Trust is manufactured at the witness or it is not manufactured at all. The ledger is the warehouse, not the inspector.

That reframing changes what you fund and what you measure. If you believe the popular version, you invest in consensus, validator security, and on-chain governance, and you treat the edge as someone else’s procurement problem. If you believe the sharper version, you invest first in memory-safe firmware, secure boot, device attestation, and post-quantum signing at the point of capture, and you treat the ledger as the comparatively easy second half. The ISA/IEC 62443 work on industrial security and the post-quantum signature standards are not two separate conversations. The integrity of the witness and the longevity of the signature are the same requirement seen from two ends.

Which brings me back to those five advisories that arrived on one ordinary day in June. Each one names a device that an embodied AI data economy would happily treat as a source of truth, and each one describes a way to make that device lie or fall silent. No blockchain in the world fixes that from above. The honest version of the claim is the one that starts at the bottom of the stack, at the witness reading current off a bus, and only then works its way up to the ledger that will remember whatever that witness said for the next forty years. Get the bottom right and the rest is engineering. Get it wrong and you have built a perfect, permanent, quantum-proof memory of things that were never true.

What a Post-Quantum Blockchain Cannot Fix at the Grid Edge was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week I had two browser tabs open on the same monitor. One held the Digital Journal roundup of five quantum computing developments from May 2026, written in the now-familiar register of qubit counts climbing and milestones falling. The other tab was the CISA advisory list for the same week, where ABB had just shipped six separate bulletins. AC500 V2 PLCs leaking fragments of old Modbus telegrams. Terra AC wallboxes vulnerable to heap memory pollution that could rewrite firmware. Ability Camera Connect installing a years-old VLC 2.2.4 component. Zenon Remote Transport accepting unauthenticated OS reboot calls. LVS MConfig handing application secrets to anyone with local network access. The juxtaposition was hard to unsee.

Here is my position. The quantum advantage scorecard, as currently framed, has become the wrong axis to watch. Counting raw qubits and celebrating fidelity demos says very little about when the cryptographic horizon actually arrives, and almost nothing about whether the systems we need to protect will be ready when it does. The honest signal is buried inside measured benchmark studies on real workloads, not press releases. And the loud noise this month was not coming from a quantum lab. It was coming from a vendor of industrial controllers that still leaks Modbus state to whoever asks nicely.

The headline metric is not the cryptographic horizon

The five-developments framing keeps the conversation on the same axis it has been on since 2019. Qubit counts, gate fidelities, error correction milestones, and the occasional Random Circuit Sampling claim. These are real and they matter, but they are not what determines when a cryptographically relevant quantum computer becomes operational. That date is governed by overhead, and overhead is governed by the distance of the surface code you need to push physical errors down to a logical error budget small enough for Shor’s algorithm to finish.

A defensible estimate for breaking RSA-2048 with surface-code-protected Shor sits near 20 million physical qubits at current two-qubit gate error rates around 10^{-3}. The loudest 2026 announcements live two to three orders of magnitude below that. Atom Computing’s neutral-atom systems, IBM’s Condor and Fez generation, Quantinuum’s H2, Google’s Willow follow-on, all live in a hardware regime where logical qubit counts are measured in the low double digits at best.

So when an article frames five developments as steps on “the path to true quantum computing,” I want to know which axis those steps actually moved along. Did the surface-code distance budget improve. Did the magic state distillation overhead drop. Did anything happen that compresses the 20 million number. Usually the answer is no, and the framing remains the same.

The honest signal lives in measured benchmarks

Where the path is actually being walked is in benchmark work, not announcements. A recent IEEE Access study I worked on benchmarked 8-qubit ZZ feature-map quantum kernels on IBM’s 156-qubit ibm_fez processor against classical SVMs on industrial control datasets, reporting a statistically significant AUC improvement with p = 0.003 across cross-validated folds. The point is not that quantum kernels won. The point is that the win was small, measurable, reproducible, and tied to a real workload someone actually cares about. That is what a step on the path looks like in 2026. Modest, falsifiable, paid for in compute time on a public-access machine.

The Digital Journal roundup is full of language about “advantage” without specifying advantage over what, or under which assumed baseline. If a quantum demonstration cannot tell you the classical method it beat, the dataset it beat that method on, and the confidence interval, it is not a development on the path to true quantum computing. It is a development on the path to a press cycle.

ABB had a worse week than IBM had a good one

Look at what landed on CISA in the same window. ICSA-26–146–02 reports that AC500 V2 PLCs at firmware 2.5.2 and 2.5.3 expose fragments of earlier Modbus telegrams to an attacker who probes the right path. Modbus is the lingua franca of factory floors and substations. A device that leaks its prior session state leaks operational intent.

ICSA-26–146–01 covers Terra AC wallboxes, the EV charging product line. The advisory describes a heap pollution path that can take remote control of the unit and write to flash to alter firmware behavior. That is a route from a connected charger into persistent compromise of a grid-edge device. ICSA-26–146–05 reveals that Ability Camera Connect was shipped with VLC 2.2.4, a media player release from 2016, with the inherited vulnerabilities still in it. ICSA-26–146–03 lets an attacker trigger an unauthenticated OS reboot of the Zenon Remote Transport service. ICSA-26–146–06 sends LVS MConfig sensitive application data to anyone reachable on the local network.

None of those CVEs care about Shor’s algorithm. They are classical, present-tense, and exploit the same kinds of memory-handling and authentication failures that the ICS field has been writing post-mortems about for fifteen years. The grid-edge attack surface that needs to be migrated to post-quantum cryptography is the same surface that still ships VLC 2.2.4 in 2026.

This is what I mean by watching the wrong race. The harvest-now-decrypt-later threat assumes that adversaries are recording today’s encrypted traffic to break it later. The bigger problem is that today’s encrypted traffic is often not the most useful thing to record, because the same devices are bleeding plaintext through bugs that have nothing to do with cryptography. The PQ migration matters, and the IETF LAKE PQ-EDHOC work going on now is the right kind of plumbing, but it sits on top of devices that need to stop leaking state before they need to stop using ECDH.

A picture of the gap

The lower path produces material for the same adversary, sooner, with less ceremony. The upper path is the one we keep counting qubits about. A serious quantum-IoT security program plans for both, but it does not pretend the upper path is the only one going somewhere.

The numbers, side by side

Here is the comparison I keep on a sticky note next to the monitor.

Two halves of the same table. The top half is the path the headlines watch. The bottom half is the path the adversary already walks.

The math nobody wants to put on a slide

The reason qubit counts do not predict the cryptographically relevant horizon is that the surface code overhead grows fast in the code distance d, which itself grows with the target logical error rate p_L. A useful rough form is:

with p the physical two-qubit error rate, p_{\text{th}} the surface-code threshold near 10^{-2}, and N_{\text{log}} the count of logical qubits Shor needs. Plug in p = 3 \times 10^{-3}, p_{\text{th}} = 10^{-2}, N_{\text{log}} \approx 6000, p_L \approx 10^{-15}, and you land near the 20 million physical qubit figure. Pushing p down by a factor of three roughly halves d and quarters N_{\text{phys}}. Pushing qubit count up without pushing p down does almost nothing useful for an attacker holding ciphertext.

This is why the development that would actually move the cryptographic horizon is a two-qubit gate error rate sustained at 5 \times 10^{-4} across a connected lattice of thousands of qubits, not a press release about ten thousand physical qubits at 10^{-3}. The roundup almost never frames a milestone this way, because the audience is not asked to.

What I would put on the path instead

If I were writing a roundup of five developments for May 2026, three of the five would be about gate error rates published in peer-reviewed venues, one would be about logical error suppression scaling experiments on a code distance you can verify, and the fifth would be about the lifecycle of a PQ-EDHOC implementation running on a constrained controller in a substation. None of those make a headline. All of them shift the date when this stops being a thought experiment.

For the ICS side, the development I want listed every month is the count of devices in the field whose key-establishment stacks have moved to ML-KEM and whose firmware update paths are signed with ML-DSA or SLH-DSA. That is the metric that closes the harvest-now window for a substation. The PQ migration is going to happen one device family at a time, by people who have to keep the lights on while they do it. Counting qubits at Quantinuum does not move that number.

Back to the two browser tabs

So I sat there with the quantum advantage roundup on one side and the ABB advisory page on the other. Both tabs were dated within the same calendar week. One was telling me that we are walking faster on the path to true quantum computing. The other was telling me that the floors we are walking on still have holes in them. The honest read of May 2026 is that the quantum hardware story moved a little, the quantum software benchmarking story moved a little more, and the industrial control story moved sideways. The race the headlines describe is real. The race that decides whether the grid still works in 2032 is being run on a different track entirely, and the runners on that track are not the ones getting the photo.

The five-developments framing is fine as long as you remember to keep the second tab open.

A few days ago I was reading the immixGroup piece in Washington Technology on how IT vendors should approach the federal post-quantum cryptography market, and I kept circling back to one number that the authors mostly use as scenery. The 2035 deadline. It does almost all of the rhetorical work in articles like this, and it does almost none of the procurement work. The decisions that shape who wins federal PQC dollars are being made in fiscal 2026 and fiscal 2027, not in the year of the deadline itself. A vendor reading the calendar by the end-state is going to miss the window that actually matters.

So this article is a forecast. I want to put down, in writing, what I think the federal PQC market looks like eighteen months from now, when we are sitting in late 2027 and reading back over what happened. Some of these calls will age well. Some will not. That is the point of writing it down.

Where the next eighteen months of federal spend actually go

The OMB M-23–02 cryptographic inventory cycle is still the gating event. Agencies were told to keep their HVA inventories current and prioritize systems by exposure. In practice what has happened, and what I expect to continue happening through fiscal 2027, is that the inventory work is becoming the actual product. The phrase “discovery tooling” is doing a lot of heavy lifting in vendor pitch decks right now, and the federal customer increasingly buys that before they buy any hybrid TLS termination box or PQ-capable HSM.

My first forecast is unglamorous. The biggest line item in federal PQC by Q4 2027 is going to be cryptographic bill of materials tooling, far ahead of crypto libraries. CBOM as a category did not exist as a budget code three years ago. It will be a budget code at most civilian CFO Act agencies by the next reauthorization, and the winners will be the vendors who can produce a defensible inventory that survives an IG audit. The vendors with the prettiest lattice math will not move that needle by themselves.

The second forecast is about NSA’s CNSA 2.0. The compliance dates land hard in 2027, and software signing in particular is supposed to be ML-DSA or LMS or XMSS by the end of that year for new acquisitions. I expect at least one major prime to miss that gate publicly, and I expect that miss to become the reference incident that drags every other prime forward. Vendors who quietly shipped ML-DSA signing in 2026 will look prescient. Vendors who waited for “broad ecosystem readiness” will spend 2028 doing emergency patch programs.

The DARPA signal

The DARPA Quantum Benchmarking Initiative, the one immixGroup flagged at the 282 million dollar figure, is more interesting as a market signal than as a research program. DARPA is essentially renting a wide-aperture viewing port on the hardware roadmap. What that buys the rest of the federal cyber establishment is calibration. By late 2027 the benchmarking outputs will be the closest thing to a defensible answer when someone in an oversight hearing asks how close a cryptographically relevant quantum computer actually is.

The downstream effect on vendors is sharper than it looks. Once the benchmarking outputs are public, the “hedge your bets and buy hybrid everything” pitch loses some of its leverage. Procurement officers can point at concrete capability curves and ask whether the hybrid scheme is buying a defensible margin or just paying for a second key schedule. I expect the first wave of pushback against unjustified hybrid configurations to start in mid-2027, and the procurement language to start excluding hybrids where the classical half is not load-bearing.

That timing matters for vendors who built their roadmap around indefinite hybrid coexistence. The window for selling “we do both, you choose later” is closing faster than the public marketing suggests.

The constrained endpoint is where the forecast bends

The migration question is not uniform across the federal estate. Servers and gateways will move first because they have the silicon headroom and the existing PKI scaffolding. The hard part is the long tail of constrained devices that already populate federal facilities. Building automation controllers. Tactical radios. Smart meters at federally owned utility sites. Door access systems like the Johnson Controls CEM AC2000 that just shipped a privilege escalation advisory, and B&R Automation Studio with its ANSL over TLS masquerade flaw. These are the kinds of systems that already struggle with classical TLS, and they are the systems that have to absorb a multi-kilobyte key blob next.

In related work I implemented FIPS 203 and FIPS 204 on an ATmega328P with 2 KB of SRAM, and measured ML-DSA signing at 136 milliseconds. That number is a useful anchor. The 8-bit AVR is the worst case for federal procurement, but the broader pattern holds. As you drop down the embedded ladder, the constants shift from microseconds to tens or hundreds of milliseconds, the memory footprint becomes the binding constraint long before the CPU does, and the firmware update path becomes the actual risk rather than the algorithm.

The forecast that follows from this is concrete. Eighteen months from now, the federal market will have effectively split into two PQC segments. A high-assurance datacenter segment where ML-KEM and ML-DSA are routine, and a constrained-device segment where vendors are still arguing about which subset of LMS to ship and how to handle the stateful-signature operational footgun. The agencies that handle a lot of OT, think Energy, parts of Defense, and the civilian agencies running building automation at scale, will start asking pointed questions about that second segment in fiscal 2027.

DOD’s R&D posture creates a quiet bifurcation

The immixGroup piece quotes the DOD position that quantum computing and quantum sensing are R&D plays, with no procurement of commercial quantum offerings near term. That sentence is doing more work than it looks. It is splitting the DOD PQC market cleanly into two procurement tracks that vendors should price separately.

The first track is the PQ-classical migration, fully on the procurement clock and aimed at the 2031 internal target. ML-KEM and ML-DSA, HSMs that support them, CNSA 2.0 compliant signing, PKI replatforming. That track is open for commercial business and is moving aggressively.

The second track is anything that says “quantum” on the actual hardware. The closed bucket covers QKD chassis, quantum sensors, and quantum networking gear. That track is closed to direct procurement and will stay closed at least through fiscal 2028 based on the current DOD posture. Vendors who built their go-to-market on selling QKD chassis to the Pentagon are going to spend the next eighteen months pivoting their pitch to research programs and OTAs, or to allied governments where the procurement door is open.

What the predictions look like as a table

Forecasts read better when they are committed to numbers, so here is what I would put on the record. Each row is a specific call for November 2027.

The high-confidence calls are anchored on procurement language that is already drafted. The medium calls are anchored on industry capacity. The QKD-procurement row is at the top of the confidence column because the DOD has been explicit about the posture.

A map of how the procurement flow actually moves

The dependency chain matters because vendors keep selling into the wrong part of it. Inventory comes first, then crypto-agility, then algorithm migration, then assurance. Selling the third step before the first has been done is how procurement decks die in committee.

Vendors who can credibly sell two adjacent nodes of that chain will outperform vendors who try to sell the whole thing, and they will outperform vendors who only sell the glamour middle of it.

The math behind why the urgency is real

The forecast also has to engage with the underlying threat model, because the 2035 deadline rests on a particular assumption about how long an adversary will sit on captured ciphertext before they can decrypt it. If we model the probability that traffic captured today is still cryptographically valuable at the moment a cryptographically relevant quantum computer arrives, and we let T_{1/2} be the operational half-life of that secret and T_q be the number of years until quantum capability is available, the survival probability is

For diplomatic cables, intelligence reporting, and SCADA configuration data with T_{1/2} around 25 years, and a T_q around 10 years out, the survival probability sits near 0.76. Roughly three quarters of what an adversary captures today is still operationally valuable when they can decrypt it. That is the harvest-now decrypt-later argument in one line, and it explains why CISA, NSA, and OMB stopped writing PQC into ten-year roadmaps and started writing it into three-year ones.

The vendor implication is that buyer urgency is genuine. It is also unevenly distributed across data types. Vendors who can articulate which mission data sits in the steep part of that exposure curve will close deals faster than vendors selling generic PQ readiness.

What I expect to be wrong about

A forecast is more useful when the author admits the failure modes. The most likely place this forecast goes wrong is the CBOM call. CBOM tooling could turn out to look like SBOM tooling, widely produced and narrowly used, in which case the 18-of-24 prediction collapses to 10. The second most likely failure is the stateful hash signature call. LMS and XMSS at OT scale require operational discipline that the federal OT supply chain has not historically shown, and the named programs I expect to see might quietly slip to fiscal 2028.

The one I am most confident about is the QKD-procurement row. The DOD has been clear, NSA has been clear, and nothing in the next eighteen months moves that needle.

Reading this back in a year

When I read this back in November 2027, the test is not whether every cell in the table is right. The test is whether the structural calls hold. CBOM as a budget line rather than a slide. Constrained-device migration as the binding problem rather than the algorithm choice. DARPA benchmarking as a procurement input rather than a research curiosity. A bifurcated DOD market that splits PQ-classical migration from quantum-on-hardware procurement. If those four hold, the rest of the numbers will land within a reasonable band.

The 2035 deadline will still be there, of course. It will keep doing rhetorical work for another decade. The interesting question for vendors is which of the next six fiscal quarters they treat as the decisive ones, and the honest answer is all of them.

Yesterday a paper landed on arXiv that I want to read like a cryptography paper, even though strictly it isn’t one. The title is “Experimental high-dimensional multi-qubit Bell non-locality on a superconducting quantum processor,” and the headline result is that two parties, holding six qubits each, observed Bell-violating correlations between their joint d=64 dimensional subsystems. The number itself is not what hooked me. What hooked me was the line that the violation was genuinely collective, with all twelve qubits participating, while most pairwise correlations across the cut remained Bell-local.

I have spent enough time around device-independent protocols to know that this is the kind of experimental claim that quietly reshapes what is possible at the protocol layer, even if the authors are careful to frame it as foundational physics. So I want to walk through what the paper actually shows, and why a Quantum-IoT engineer should be paying attention to it the same week that CISA publishes a fresh batch of ICS advisories.

What the paper actually shows

Bell non-locality, in the everyday sense most working engineers carry around, is the CHSH inequality. Two parties, two settings each, two outcomes each, and a single number that bounds any local hidden-variable theory at 2 and any quantum theory at 2√2. That bound, written cleanly, is

The Tsirelson bound on the right is the strongest violation any pair of qubits can ever produce, regardless of how cleverly you prepare the state or align the measurements. The new paper steps outside that frame. The authors encode each side of the bipartition in six superconducting qubits, treat each side as a single d=64 dimensional system, and run a Bell test designed for high-dimensional pairs. By d=32 they already exceed the 2√2 ceiling. By d=64 they report a high-confidence violation that no qubit-pair experiment can match, even in principle.

There is a second result that I find more interesting than the dimensional record. The authors check whether the violation is carried by a few dominant pairs of qubits across the cut, or whether it is genuinely a property of the full twelve-qubit state. The pairwise correlations, taken individually across the bipartition, mostly satisfy local bounds. The collective correlation does not. That is the difference between a parlor trick that scales with hardware count and a non-local resource that only exists because the whole register is entangled the right way.

For a hardware operator, that is a practical fact rather than a philosophical one. Bell violation strength is one of the few diagnostics that does not rely on trusting the device. If your benchmark requires that all twelve qubits cooperate, you are detecting a class of errors that a state tomography on individual pairs would miss.

Why dimension matters at the protocol layer

Device-independent quantum key distribution and device-independent randomness expansion both treat Bell violation as a budget. The amount you violate sets the floor on how much extractable randomness, or how many secret-key bits per round, you can certify against an adversary who built your hardware. With qubit pairs, that budget is bounded by the Tsirelson constant, and practical implementations sit well below it once you account for detection loopholes and finite-statistics overhead. The yield per round is small.

High-dimensional Bell tests change the arithmetic. A d-dimensional violation lets you certify more output randomness per measurement, because the dimension of the Hilbert space sets the entropy ceiling. If the violation is strong enough, the certified entropy per round grows, and the rate at which you can extract device-independent secret keys grows with it. For a Quantum-IoT context, where the device sitting at a substation might run a Bell-style certification round only occasionally between heavier work, getting more entropy out of each round is the thing that decides whether the protocol is feasible at all.

The Brunner survey of Bell non-locality remains the cleanest reference for the upper bounds in higher dimensions, and the gap between the d=2 Tsirelson bound and what is achievable for d=32 or d=64 is large. What this experimental paper provides is the first credible signal that present-day superconducting hardware can land near those higher bounds, with a confidence that survives the experimental loopholes one can close in a single-lab setting.

The diagram above is the path I keep sketching in my notebook when I read papers like this. The upstream work is the experiment. The downstream consumer is whatever protocol is going to use the certified randomness, and in my own work that protocol is usually the post-quantum variant of EDHOC on a sensor or a smart-meter front end. The bridge between the two is not in the abstract of the paper. It is in whether the violation survives once you stop trusting the device and start treating it as a black box.

The collective signature, and why it matters for benchmarking

Return to the second result for a moment. The authors show that pairwise correlations across the bipartition are mostly Bell-local, while the joint correlation violates. That is what the paper means by genuinely collective non-locality. It is also a clean diagnostic for entangling-gate quality at the system level.

Most processor benchmarks today look at small substructures. Randomized benchmarking on two qubits, cross-entropy benchmarking across a tiled pattern, cycle benchmarking on small subsets. Each of these is local in the sense that it certifies a property of a sub-register and then assumes the rest of the device behaves similarly. A genuinely collective Bell violation works the other way around. The signal is only present when the whole register is entangled correctly, and it goes away under exactly the failure modes you most want to catch, which are correlated errors and crosstalk that pairwise tests would miss.

What I take away from this, in operational terms, is that high-dimensional Bell tests are a candidate for an end-to-end functional check on a multi-qubit device, the way a self-test is for a classical chip. You design the test such that the device cannot pass it without producing the entanglement structure your downstream protocol requires. Then you run it periodically, in production, as part of the same operational telemetry you would already be collecting from a device handling cryptographic material.

That is the kind of feedback loop the post-quantum community has been quietly hoping for. The PQC algorithms shipping in the IETF tracks today are classical, in the sense that they run on classical silicon and rely on lattice or hash assumptions. The longer-term picture for high-assurance systems involves device-independent components for randomness and key agreement, sitting alongside the classical PQC primitives. The benchmarking story is the part that makes those components deployable.

The week the experiment landed

The experiment landed in the same week as five new CISA ICS advisories. None of them involve quantum hardware. They involve a GRASSMARLIN information-disclosure issue, an Intrado 911 Emergency Gateway file-handling flaw, a cluster of Milesight camera vulnerabilities including remote code execution, a Carlson Software GNSS receiver authentication problem, and a SpiceJet booking-system disclosure. Routine, in the sense that nothing on this list is exotic.

I keep both windows open at the same time on purpose. One window is the arXiv paper, with a result that opens a new regime for device-independent cryptography. The other window is a 911 emergency gateway with a CVE that lets an attacker read or delete files. The distance between those two timelines is the working environment of anyone trying to design forward-looking security for critical infrastructure.

Quantum hardware is not going to fix the Intrado bug, and nobody is suggesting it should. What changes is the set of building blocks available for the protocols we are designing today. The post-quantum EDHOC variants under discussion in the IETF LAKE group will eventually need to interoperate with a generation of devices whose entropy, key-agreement, and self-test stories are quantum-anchored. The experimental result this week is one of the early signs that the underlying physics is not the bottleneck. The bottleneck is integration and benchmarking.

What I am taking from it

A few specific things change for me after reading this paper. The first is that the d=2 Tsirelson budget should stop being the reference point for back-of-envelope calculations on device-independent randomness yield. For superconducting platforms with twelve or more high-fidelity qubits, the high-dimensional bound is the relevant ceiling. The second is that genuinely collective Bell violations are a benchmarking primitive worth standardising. There is an obvious place for this conversation, somewhere between the ISA99 working groups thinking about OT trust models and the IRTF efforts on post-quantum protocols. Neither side is currently writing it down.

The third reading is more cautious. A high-confidence violation in a single experimental run is not the same as a violation that survives adversarial assumptions about the device. The loopholes that matter for foundational physics are not always the loopholes that matter for cryptographic security. Detection efficiency, memory effects in repeated rounds, side channels in the control electronics, all of these sit in the gap between what the paper demonstrates and what a deployable protocol would need. None are stoppers. They are work items.

When I started writing this, I said I wanted to read the paper as a cryptography paper. The reason is that the result quietly closes one of the open questions in that lane, which is whether superconducting platforms are even capable, in principle, of operating in a regime where high-dimensional Bell certification can run. The answer, as of this week, is yes. The work that follows is in protocol engineering, in benchmarking standards, and in the unglamorous task of making sure the next 911 gateway in the next ICS advisory still gets patched while the long-horizon stack matures around it.

A few weeks ago I was reading a fresh arxiv preprint over a long flight back from Chicago to Boston, and a small detail in the abstract pulled me out of my seat. The paper, posted on April 23, 2026 by a group studying peaked quantum circuits, argues that a recent heuristic quantum advantage claim on Quantinuum’s 56-qubit H2 trapped-ion processor can be efficiently simulated on a classical machine. Not someday. Today, with a careful tensor network contraction.

That kind of result does not always make headlines. It should, because every time a quantum advantage claim deflates, the people I work with in critical infrastructure security need to recalibrate. We do that quietly, in committee meetings and in CRQC timeline spreadsheets that nobody outside the field will ever see. I want to walk through what the peaked circuit construction was, why this new simulation method breaks it, and what the broader signal looks like when you sit at the intersection of post-quantum cryptography and operational technology.

What the peaked circuit construction actually was

The original Gharibyan et al. work, posted in late 2025, took a clever angle on the quantum advantage problem. Standard random circuit sampling, which had powered earlier advantage claims, has a verification problem. If a quantum machine returns samples from a distribution you cannot compute classically, you cannot easily verify the samples were drawn from the right distribution. Cross-entropy benchmarking helps, and it does not eliminate the underlying issue.

Peaked circuits sidestep this by construction. Imagine a circuit whose output distribution, instead of being spread across all 2^n bitstrings, concentrates almost all of its weight on a single hidden bitstring b^. If the quantum machine is honest and the hardware noise is low enough, the most frequent sample is b^. You verify by checking that the machine returned the expected peak. The peak is the answer.

To make these circuits hard, the authors trained a shallow, classically simulable circuit variationally so that its output peaked on a chosen b^*. They then composed this shallow circuit with a depth-amplifying obfuscated permutation. The obfuscation increased the effective circuit depth to a level where a naive tensor network contraction blew up. They estimated that the largest instances would take years on the best classical machines.

The peakedness condition is what gives the construction its verifiability. Roughly, the success probability of recovering b^* can be written as

and the construction tunes parameters so that P(b^*) is close to one. The hidden bitstring is a fixed point of the composed unitary up to a small noise budget.

The trick that quietly breaks it

The new paper points out that the peakedness assumption is not free. To guarantee that the output concentrates on b^*, the obfuscated permutation cannot scramble the shallow circuit too aggressively. There is a structural tension between depth amplification and peak preservation. The construction resolves this by giving the obfuscation a mirrored structure, where one half of the deep block effectively undoes the other, with a permutation in the middle that hides the cancellation from a casual classical adversary.

Mirrored structure is a gift to tensor network contraction. If you build the contraction graph carefully and pick an order that exploits the mirror, large portions of the network telescope. Bond dimensions stay bounded. The contraction that looked exponential in depth collapses to something polynomial in qubit count for the regimes of interest. Near-exact sampling becomes feasible on a workstation. Extracting b^* directly becomes feasible too, because you can contract the network conditioned on candidate bits one at a time.

This is the kind of result that does not require a faster computer. It requires a sharper eye.

Why this matters when you plan post-quantum migration

I work on post-quantum cryptography for constrained devices and on the protocols that move PQ key material into industrial control networks. Most of that work is timing work. We do not yet know when the first cryptographically relevant quantum computer arrives, and the answer has direct consequences for what gets migrated when and what stays on legacy curves until documented sunset dates.

Quantum advantage claims feed into those timing models. They are not the only signal, and they are an important one. When a 56-qubit trapped-ion machine appears to clear a verifiable advantage threshold, it shifts where reasonable people place their priors on the CRQC arrival window. When a careful classical simulation paper deflates the same claim two quarters later, the priors have to shift back. Operationally, this looks like a slow oscillation in the planning conversation. A vendor pushes for accelerated rollout of ML-KEM in firmware. A program manager pulls in the other direction because the latest classical simulation paper suggests the hardware is not as far along as the press release implied.

Both responses are correct in isolation. They cannot be correct simultaneously, which is why the people setting policy for ISA/IEC 62443 and the IETF LAKE PQ-EDHOC working group spend a lot of time reading papers that look like the one I just described, rather than reading the press releases that summarize them.

The PQC algorithm parameters themselves do not move when an advantage claim deflates. The migration work is the same, and the urgency profile changes. Below are the sizes that field engineers actually have to fit into constrained transports, drawn from the NIST FIPS 203, 204, and 205 standards. These numbers are public and they are the ones that matter when you are budgeting bytes for a CoAP exchange over a lossy radio link.

The point of staring at this table is that almost none of the rows fit comfortably inside a single 6LoWPAN fragment. ML-DSA-65, the workhorse signature for many of the ICS profiles I look at, costs more than five kilobytes per round trip in public key plus signature, before you add the certificate chain. Whether the CRQC arrives in 2030 or 2035 or 2040, those bytes still have to travel over the same constrained links. The peaked circuit story does not change the cost. It changes the discount rate you use when you decide which devices get the upgrade in which fiscal year.

What this looks like from the OT side

The same week I was reading the peaked circuit paper, CISA pushed an advisory on the Intrado 911 Emergency Gateway, covering versions 5.x through 7.x with CVE-2026–6074. The vulnerability allows an attacker to read, modify, or delete files on a device that sits inside the dispatch chain for emergency calls. The same advisory wave covered a Carlson Software VASCO-B GNSS receiver under CVE-2026–3893 and a set of Milesight cameras with a half dozen CVEs that range from device crashes to remote code execution.

I bring these up because the operational threat surface in critical infrastructure is not driven by quantum risk yet. It is driven by 911 gateways and GNSS receivers and IP cameras with broken authentication. The PQC migration work has to happen in the same firmware update channels that are also fixing CVE-2026–6074. The two budgets compete for the same engineering hours. When a peaked circuit claim deflates, the program manager who is balancing those budgets gets a small amount of room to push the harder, slower PQC firmware work back by a quarter so that the GNSS authentication patch can ship now.

This is the boring middle of the field, where most of the work actually happens. The peaked circuit paper, on its own, is a beautiful piece of physics-inflected algorithm design. Its second-order effect is a quiet adjustment in maintenance schedules at substations and dispatch centers nobody outside the industry has heard of.

The signal underneath the headlines

If you read enough of these papers, a pattern emerges. Quantum advantage claims tend to land first as bold experimental announcements, and they tend to get whittled down over the following six to eighteen months by classical simulation work that is sharper than what the original authors had assumed. This is healthy. It is how the field tells the difference between a hardware milestone and a marketing artifact.

The peaked circuit paper is unusual because it offered verifiable advantage by construction. That makes the deflation more striking. The authors of the original construction did the right thing scientifically by giving the world a verifiable target. The simulation paper did the right thing by hitting it. The CRQC timeline tightens or loosens by some small fraction of a year as a result, and the people whose job it is to migrate the world’s cryptography to lattice-based primitives keep moving.

For my own work, the lesson is that the threshold of advantage is a moving target whose location depends as much on the cleverness of classical algorithms as on the qubit count of the hardware. Anyone who claims to know the CRQC date to within a year is either selling something or has stopped reading.

Coming back to that long flight

I closed the preprint somewhere over Lake Erie and stared out the window for a while. There was nothing particularly profound in the moment. Just a quiet recalibration. The 56-qubit advantage claim that had nudged my internal clock forward by a few months in late 2025 had been gently nudged back. The CISA advisories from the same week kept their place at the top of the priority queue. ML-KEM-768 was still going to need to fit into a CoAP fragment somewhere in a substation in the upper Midwest by the end of the decade.

A small detail in an arxiv abstract changed almost nothing for the broader public, and it changed the slope of a planning curve I care about. That is most of what the work feels like, and on most days it is enough.