up:: Migration Architecture MOC

The Three-Pile Sort

The three-pile sort is a per-device triage for cryptographic hardware you can’t upgrade, which asks two questions of every legacy device and sorts it into one of three piles: wrap it behind a post-quantum gateway, move its point-to-point links onto a pre-shared symmetric key, or replace it on its normal refresh cycle. It exists because an estate full of frozen firmware looks hopeless until you stop asking “can this device run the new algorithms” and start asking “does this device need the vulnerable math at all, and can I put protection in front of it.” The output is three schedules you can plan against instead of one exposure you can only dread.

The reason it works is that only public-key cryptography is in danger, and a surprising amount of industrial and legacy hardware either barely uses it or does its vulnerable work on connections you can reach from the network. Once you sort by that, the pile that genuinely has to wait for a forklift, the replace pile, is usually the smallest of the three.

The short version:

1. The sort runs on the hardware you can’t upgrade, and it starts with two questions to your controls engineers: does this device depend on public-key cryptography to establish trust, and can you place something on the network in front of it.
2. Wrap pile: a post-quantum gateway sits in front of the device, running the quantum-safe handshake on the outside and the device’s old protocol on the inside, so the device itself never changes.
3. Pre-shared symmetric pile: bounded point-to-point links drop onto a shared symmetric key, RFC 8784 style, which is quantum-resistant with no public-key math on the endpoint at all.
4. Replace pile: devices whose trust anchor is sealed inside them, out of a gateway’s reach, wait for scheduled physical replacement, and this is the only pile that actually waits, usually the smallest of the three.
5. Two guards ride along: only the replace pile sets its own clock, and “it’s symmetric” is a green light only when the primitive underneath is a strong modern one.

Picture an old building full of locks you can’t re-key, because the mechanisms were cast into the doors decades ago. You still have to make the building secure, so you walk it door by door and ask two things at each one. For most doors you bolt a modern card reader onto the frame in front of the old lock, and the door behind it never changes. A few interior doors run between two rooms you already control, so both sides just carry one shared key you handed out yourself, and no reader is needed. A small number have the cylinder welded inside a vault door you can only swap when the vault itself gets renovated. Those last ones set their own timeline, and once you’ve walked the building, they’re the shortest list.

What is the three-pile sort?

The three-pile sort is the fix-selection step of a post-quantum migration for hardware that can’t be updated in place. Earlier steps find your cryptography and rank it: The Four Questions map what runs where and who controls it, and The Two-Lane Split sorts the whole estate by which quantum clock each item races. The three-pile sort picks up the subset those steps flag as un-upgradable and answers the next question, which is what you actually do about each device.

It applies wherever you hold hardware with cryptography frozen at manufacture and no path to change it: industrial controllers, protective relays, smart meters, medical devices, payment terminals, and the long tail of embedded gear that runs for 10 to 20 years. It does not apply to software estates where a library upgrade and a config change do the work, and it stops being a sort on any device you can simply reconfigure, because that device was never un-upgradable in the first place.

The three buckets line up with the architectural options catalogued in Bertino et al.’s 2026 systematization of quantum-safe approaches for legacy and industrial systems (symmetric-only, gateway or proxy wrapping, and scheduled hardware replacement). The two-question triage that produces the buckets is LaMarr Labs’ own; the research below carries the architecture, and the sort is how you drive it device by device.

Source: Bertino et al., systematization of knowledge on quantum-safe migration for legacy and industrial systems, 2026, arXiv:2605.04129.

What two questions produce the three piles?

Two questions, asked of your controls engineers rather than your security team, because the engineers know what actually crosses the wire and who the device talks to. In these words:

1. “Does this device depend on public-key cryptography to establish trust?” This separates the devices whose exposure is a key exchange or a signature check from the ones whose real work is symmetric. Only public-key math is broken by Shor’s algorithm; symmetric cryptography survives the transition on its own.
2. “Can I place something on the network in front of it?” This separates the devices you can protect where they stand from the ones whose vulnerable trust decision happens somewhere a box in front can’t reach.

The two answers sort every un-upgradable device into exactly one pile. The table is the whole framework on one page.

Pile	What lands there	The fix	The clock it runs on
Wrap	Devices with a reachable network front, whose vulnerable public-key work happens on the connections coming into them	A post-quantum gateway in front, terminating the quantum-safe handshake and speaking the device’s old protocol behind it	Your own project schedule, because you control when the gateway goes in
Pre-shared symmetric	Bounded, point-to-point links between a known set of peers	Drop the link onto a pre-shared symmetric key, RFC 8784 style, so no public-key math runs on the endpoint	Available today, paced by your own key-management work
Replace	Devices whose trust anchor is sealed inside them, where the vulnerable check happens on silicon a gateway can’t touch	Scheduled physical replacement with quantum-safe hardware	The device’s refresh cycle, the one pile that genuinely has to wait

The unit of the sort is the device, and a device that does two jobs gets split into two rows. A controller that both accepts network connections (a wrap candidate) and verifies its own firmware against a burned-in signing key (a replace item) is honestly both, and writing it as one row hides the harder half.

How does the wrap pile work?

The wrap pile is the workhorse, because it converts a problem you can’t solve, upgrading an unchangeable endpoint, into one you can, adding a modern box to the network in front of it. A post-quantum gateway is a small current-generation appliance that sits between the legacy device and the wider network. It runs the quantum-safe or hybrid handshake on the network side and the device’s original, untouched protocol on the device side. Every connection reaching the device from the network is now protected by post-quantum cryptography, and the device behind it runs exactly as it did the day it was installed.

The gateway is the piece that gets upgraded, which is the entire point, because a gateway is a normal modern system with a normal update path. When the standards move again, you patch the gateway rather than the fleet behind it. Concretely, a gateway terminating an IPsec tunnel can run RFC 9370’s hybrid key exchange, folding an ML-KEM exchange in alongside the classical one, so the tunnel into the plant is quantum-safe while the controller inside speaks the same fieldbus it always did.

Source: Tjhai et al., “Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 9370, May 2023, rfc-editor.org/rfc/rfc9370.

The boundary of the wrap pile is that a gateway protects the connection into a device and nothing that happens inside it. It secures the link, so it does nothing for a trust decision the device makes on its own silicon, and it does nothing if the endpoint itself is already compromised. That boundary is exactly what pushes a device out of the wrap pile and into replace, and naming it is the difference between a real plan and a comfortable one.

How does the pre-shared symmetric pile work?

The pre-shared symmetric pile holds links that never need the math a quantum computer breaks, because their security rests on a secret both ends already hold. A connection keyed by a shared symmetric secret, agreed in advance and loaded onto both endpoints, does no public-key negotiation, so there is nothing for Shor’s algorithm to unwind later. Grover’s algorithm only halves symmetric strength, which a long enough key answers, so a strong pre-shared key is quantum-resistant on hardware that could never run lattice cryptography.

The standardized worked example is RFC 8784, which mixes a static post-quantum pre-shared key into IKEv2 so an IPsec tunnel gains quantum resistance without the endpoints running post-quantum key exchange. The pre-shared key is distributed out of band, then stirred into the key material, so an adversary who later breaks the classical Diffie-Hellman half with a quantum computer still can’t derive the session keys without the symmetric secret they never saw.

Source: Fluhrer, Kampanakis, McGrew, Smyslov, “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,” RFC 8784, June 2020, rfc-editor.org/rfc/rfc8784.

What makes this pile fit legacy operational networks specifically is their shape. The usual objection to pre-shared keys is that you can’t hand them out to millions of strangers on the open internet, and for a bounded control network with a fixed set of members, that objection simply disappears. The cost is real and you budget for it up front: distributing, storing, and rotating those symmetric keys is genuine operational work, and it doesn’t scale the way public-key infrastructure does. For a manageable set of long-lived point-to-point links, though, it buys quantum resistance today with no change to the device.

What lands in the replace pile, and when does it move?

The replace pile holds every device whose vulnerable trust decision happens inside it, where neither a gateway in front nor a shared key can reach. The clean example is a controller that checks its own firmware against a signing key burned into its silicon. If that key is one a quantum computer can forge, no box on the network changes what the device accepts, because the vulnerable check runs where you have no access. A device like that has to be replaced with quantum-safe hardware, and the replacement lands on the device’s own refresh cycle, which for industrial gear is measured in budget cycles and years.

Two facts make the replace pile easier to carry than it first looks:

1. It’s usually the smallest of the three once you’ve actually done the sort, because most un-upgradable hardware turns out to be wrappable or to sit on a link you can move onto a pre-shared key.
2. A refresh cycle is a schedule, so the replace pile converts into a dated replacement plan rather than an open-ended exposure. You know roughly when each device retires, so you sequence the highest-consequence sealed devices first and require quantum-safe cryptography in the procurement that replaces them.

The one hard rule the replace pile carries is the deadline math. If a sealed device has a 15-year service life and the credible window to a capable quantum computer is shorter than that, the last safe replacement cycle has already started, so the device is a start-now item even though its failure mode arrives later. That is the same arithmetic Mosca’s theorem runs on any long-lead item.

Does un-upgradable hardware always set its own clock?

Only for the replace pile, and this is the caveat that keeps the framework honest. It’s a common and dangerous shorthand to say that un-upgradable hardware sets its own clock, meaning it waits for physical replacement no matter what. That’s true for a device whose trust anchor is sealed inside it, because there genuinely is no faster path than swapping the box. It is false for the other two piles.

1. A wrap-pile device does not wait. You put a gateway in front of it on your own project schedule, which can be this year, so the device’s own replacement date is irrelevant to when it becomes protected.
2. A pre-shared-symmetric-pile device does not wait either. You move its link onto a shared key today, again on your schedule, with no change to the device at all.

So the sort is precisely what qualifies the “sets its own clock” claim: it’s true for the pile that earns it and misleading for the two that don’t. Applying the replace-pile timeline to a whole estate is how organizations talk themselves into believing they’re stuck for a decade when most of the estate could be protected this year.

Is a symmetric-only device automatically quantum-safe?

No, and this is the trap hidden inside the good news. Hearing that symmetric cryptography survives the quantum transition, it’s tempting to conclude that any device running only symmetric crypto is automatically safe. Symmetric survives when the primitive underneath is a strong modern one such as AES-256, where Grover’s algorithm only trims the margin. It is a green light for the right primitive, and not a blanket pass for whatever a legacy controller happens to run.

The reason is that some older symmetric constructions fall to a dedicated quantum attack of their own, separate from Grover. In April 2026 a team including BSI researchers demonstrated a proof-of-concept hardware run of Simon’s algorithm against the Even-Mansour construction, a minimal cipher design, on a real quantum machine at a toy 3-to-4-bit scale. Even-Mansour is roughly a 1-round version of a block cipher, so the result is a design lesson about a narrow family of constructions and says nothing about the security of AES, which is built on entirely different foundations. The correct framing is that a symmetric construction was broken on quantum hardware at laboratory scale, never that AES was broken.

Source: Köhler et al., “Breaking the Even-Mansour Cipher on Quantum Hardware,” April 2026, arXiv:2604.25509.

The practical consequence for the sort is that a device which hardcoded a fragile symmetric scheme years ago can’t be swapped any more easily than one that hardcoded RSA, so it belongs in the replace pile regardless of the word “symmetric.” When an engineer tells you a device is symmetric, the follow-up is which primitive, and whether it’s a strong modern one, before you rest the device’s safety on it.

What does the three-pile sort look like on a real plant?

Take a generic multi-site utility with a control center, a handful of substations, a fleet of field devices, and a corporate network the operational data flows into. Run the two questions across a representative sample of its un-upgradable hardware. The device types are universal; the sort is the point.

Device	Depends on public-key trust?	Can you get in front of it?	Pile	Why
SCADA / HMI servers on a routable network	Yes, for their remote-access and telemetry connections	Yes	Wrap	A gateway terminates the quantum-safe handshake on the network side and the servers keep their native protocol
RTU-to-control-center telemetry over a fixed link	The trust can rest on a shared secret between two known ends	Point-to-point between a known pair	Pre-shared symmetric	A bounded link with a fixed peer set, the exact case RFC 8784 fits
Substation-to-control-center site link	Yes, key exchange over the WAN	Yes, at the tunnel endpoints	Wrap	A gateway pair runs hybrid ML-KEM key exchange across the boundary
Smart meters reporting to a concentrator	Mostly symmetric to the concentrator	Yes, wrap the concentrator	Wrap	Protection moves to the concentrator the fleet already reports through
Protective relay verifying firmware against a burned-in key	Yes, and the check is sealed in silicon	No, the check is internal	Replace	No box in front changes what the relay accepts; it moves on its refresh cycle
Safety controller with a sealed secure-boot anchor	Yes, internal signature verification	No	Replace	Trust anchor out of reach; sequenced by service life

Read what the sort did. Of six representative device classes, four are protected where they stand, on the utility’s own schedule, and only two wait for a forklift. The replace pile is the smallest, it carries a schedule (each device’s known refresh cycle) rather than an open exposure, and the estate the operator walked in fearing was mostly savable. The two sealed devices then get the deadline math from Mosca’s theorem, and if their service life outruns the runway to a capable machine, their replacement starts now.

Common misconceptions

1. “Our OT is air-gapped, so quantum doesn’t touch it.” True air gaps are rarer than believed, because most industrial networks carry some connectivity for monitoring, vendor maintenance, or data flowing to business systems. And even a real gap doesn’t stop harvest-now-decrypt-later on any data that crosses a boundary to a historian or corporate network over a classical channel.
2. “We’ll just upgrade the firmware when the new algorithms ship.” On a large share of industrial devices the cryptography is compiled into firmware with no update path, so waiting for a firmware update the device was never built to accept is how a decade disappears. If there’s no path to change it, it’s a wrap, a pre-shared-key link, or a replace item, and never a config change.
3. “It’s symmetric, so it’s automatically quantum-safe.” Symmetric survives only when the primitive is a strong modern one such as AES-256. A device that hardcoded a fragile symmetric construction can fall to a quantum attack of its own, so “it’s symmetric” is a green light for the right primitive rather than for whatever ships in a legacy controller.
4. “Firmware-upgradable means crypto-upgradable.” A device that accepts firmware updates can still lack the memory or the link bandwidth to hold a post-quantum artifact. An ML-DSA-65 signature is 3,309 bytes against roughly 64 for an ECDSA one, so a device with an update path but a small buffer or a hard signature-size ceiling is still a replace item. Constrained-Device PQC carries the fit problem.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, csrc.nist.gov/pubs/fips/204/final.

5. “The replace pile is basically the whole estate.” This is the assumption the sort exists to disprove. Once you’ve asked the two questions device by device, most un-upgradable hardware turns out to be wrappable or to sit on a link you can move onto a pre-shared key, and the genuinely sealed devices are the shortest list.
6. “A scanner will tell me which pile each device is in.” The answers live with the controls engineers who know the wire and the peer set, and with the vendor documentation on what’s sealed in silicon. A scanner’s clean report shows the tool’s reach, and the two questions get answered by people, not by a probe.

Pro tips

1. Ask the controls engineers, in their words. The two questions are for the people who run the plant, because they know what actually crosses the wire and which devices talk only to a fixed set of peers. The security team will answer with policy; the engineers answer with reality.
2. Budget the key-management work before you commit to the pre-shared pile. Distributing, storing, and rotating symmetric keys is the real cost of that pile, and it’s genuine operational effort. A pre-shared-key plan with no rotation story is a plan that decays quietly.
3. When told “it’s air-gapped,” ask what leaves the segment. The useful follow-up is which data crosses to a historian or corporate network, and over what channel, because that boundary-crossing traffic is exposed to harvesting regardless of the gap.
4. When told “it’s symmetric,” ask which primitive. A strong modern cipher is a wrap-or-leave-it answer; a fragile legacy construction is a replace item. The word “symmetric” alone doesn’t finish the sort.
5. Confirm the gateway’s outside is actually post-quantum. A gateway that only speaks classical key exchange adds a box and no protection. Verify it negotiates a hybrid or post-quantum group, the way a hybrid handshake folds ML-KEM in alongside the classical exchange.
6. Turn the replace pile into dates immediately. Tag each sealed device with its known refresh cycle, so the pile reads as a replacement schedule the board can act on rather than a vague dread it can only absorb.

Where does the three-pile sort break?

Published limits, because a triage rule you can’t break is a triage rule you haven’t tested:

1. IT estates. The pre-shared symmetric pile assumes bounded, point-to-point links between a known peer set, which is the shape of a control network and the opposite of a general IT estate. In many-party, dynamically peered IT, pile 2 rarely applies, so the sort degenerates into wrap-or-replace, and the interesting work moves to the agility of the software instead.
2. Devices that straddle two piles. A controller with a reachable network front and a sealed internal trust anchor is honestly both a wrap and a replace item, because the gateway protects the link while the internal firmware check stays exposed. Split it into two rows and carry each on its own clock.
3. Sealed devices with no refresh cycle. A device meant to run indefinitely with no planned replacement turns the replace pile into an end-of-life decision rather than a schedule, and that decision needs an owner and a budget line the sort itself doesn’t provide.
4. The sort produces piles, and a pile is still a pile. Turning three piles into a program takes owners, budget, sequencing, and the deadline math per device. The sort tells you which fix each device needs; it doesn’t run the project.

How do you use the three-pile sort in the boardroom?

The board value is that it converts “our plant floor is exposed forever, and we can’t rip it out” into three piles with three schedules, where the one that genuinely waits is the smallest. The deployable version fits in a few sentences. “Most of the hardware we can’t upgrade, we can protect where it stands, either by putting a modern gateway in front of it or by moving a link onto a shared key, both on our own schedule. A small remainder has its trust anchor sealed inside, so it waits for its normal replacement cycle, and we’ve turned that remainder into a dated schedule.”

It also arms you against the two pitches that recur when quantum reaches operational technology:

1. The rip-and-replace panic budget. When someone proposes replacing the whole un-upgradable estate, the sort is the two-sentence answer: most of it is wrappable or symmetric-only and protectable this year, and only the sealed devices justify a hardware line, so the replacement budget should be scoped to the smallest pile.
2. The “it’s isolated, we’re fine” complacency. When someone waves off the plant floor as air-gapped, the sort forces the question of what data leaves the segment and which devices actually depend on breakable trust, which is how the exposure hiding behind the gap surfaces.

One level up, a director who can ask “which pile, and what’s the replace schedule” has become an asset to the program rather than a source of either panic or complacency.

Questions people ask

Can I make operational technology quantum-safe without replacing it? Mostly yes. Once you sort the un-upgradable hardware with the two questions, most of it lands in the wrap pile (a gateway in front) or the pre-shared symmetric pile (a shared key on a bounded link), both of which protect the device with no change to it. Only the sealed-trust-anchor devices in the replace pile need new hardware.

Which pile is usually the smallest? The replace pile. The assumption walking in is that the whole estate has to be torn out, and the sort’s repeated finding is that the genuinely sealed devices are the shortest list, with a replacement schedule you can plan against.

What’s the simplest quantum-resistant option for a device that can’t run ML-KEM? A pre-shared symmetric key on a point-to-point link, which is quantum-resistant with no public-key math on the endpoint, exactly as RFC 8784 does for IPsec. Where the link isn’t point-to-point, a gateway in front is the next-simplest.

Does a gateway make the device itself quantum-safe? No. It protects the connection into the device, and it does nothing for a trust decision the device makes on its own silicon or for an endpoint that’s already compromised. That boundary is what moves a device from the wrap pile to the replace pile.

Does the whole estate have to wait for physical replacement? No, and that’s the misreading the sort corrects. Only the replace pile waits. Wrap-pile and pre-shared-key devices are protected on your own schedule, often this year, so “un-upgradable hardware sets its own clock” is true only for the sealed devices.

Who answers the two questions? Your controls engineers, because they know what crosses the wire, which devices talk only to a fixed set of peers, and what’s sealed in silicon. The security team can frame the exercise, and the answers come from the people who run the plant.

How is this different from the two-lane split and the four questions? The Four Questions map the estate (what runs where, who controls it), and The Two-Lane Split sorts everything by which quantum clock it races. The three-pile sort is the next step down for the subset those flag as un-upgradable: given that you can’t change this device, what do you actually do about it.

Is an air gap enough on its own? No. Genuine air gaps are rare, and even a real one doesn’t protect data that leaves the segment to a historian or corporate network over a classical channel, where it’s exposed to harvest-now-decrypt-later. The gap protects the isolated segment and nothing that leaves it.

---

Everything here is the map, given freely. The three-pile sort run across your own estate, device by device, with the gateways stood up, the pre-shared-key links keyed, and the replace pile turned into a dated schedule your board will accept, is the work I do. Request the workshop.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.