Where Does Purdue Model Post-Quantum Encryption Belong?

Purdue model post-quantum encryption means protecting the network conduits between levels of the Purdue Enterprise Reference Architecture, and between sites, cloud environments and remote users, with key exchange that resists future quantum computers. In practice this means hybrid classical plus ML-KEM tunnels on the conduits that leave a trusted zone, not encryption on every controller.

The Purdue Enterprise Reference Architecture (PERA) came out of Purdue University in the 1990s. ISA-95 later adopted its level hierarchy for integrating enterprise and control systems. Most OT security teams still use the levels as shorthand: Level 0 is the physical process, Level 1 basic control, Level 2 supervisory control, Level 3 site operations, Level 3.5 the industrial DMZ (IDMZ), and Levels 4 and 5 the enterprise. For decisions about encryption, the levels work best when combined with the zones and conduits risk assessment in IEC 62443-3-2. Quantum risk lives on conduits, because conduits are where traffic can be recorded.

Timing matters because of “store now, decrypt later”. Traffic recorded today could be decrypted once a cryptanalytically relevant quantum computer exists. OT data often stays sensitive for a long time: grid topology, process recipes, safety system logic and engineering project files can be valuable for years. CISA addressed this directly in its 2024 paper Post-Quantum Considerations for Operational Technology.

At which Purdue levels should quantum-safe encryption be applied?

Apply it to conduits, not to levels: start with the links that leave a physically controlled boundary, meaning site-to-site WAN links, IDMZ links to enterprise and cloud, and remote access. Traffic that stays inside one fenced Level 0 to 2 cell is usually the lowest priority.

A practical way to rank conduits is to take the conduit list from your IEC 62443-3-2 assessment and score each entry on two questions. Does the traffic cross a network you do not own or physically control? And how long would the data remain useful to someone who recorded it? Conduits that score high on both go first.

Should post-quantum tunnels terminate in the industrial DMZ (Level 3.5)?

Yes, for every tunnel that starts in IT, in a cloud environment or on a remote user’s device. OT-to-OT tunnels between sites are a separate conduit and can terminate at the OT boundary of each site instead.

The IDMZ exists so that no session crosses directly from Level 4 to Level 3. If an encrypted tunnel ran from a cloud tenant straight to a Level 2 network, it would create exactly the direct path the IDMZ is meant to stop. The tunnel would also be invisible to the firewalls built to inspect that boundary. Terminating in Level 3.5 means decrypted traffic arrives where brokering services, replicated historians and inspection already sit.

Where the gateway sits relative to the IDMZ firewall matters. If the firewall needs to inspect the traffic, the gateway goes on the outer side so the firewall sees plaintext. Only on paths where inspection is not needed can the gateway sit behind the firewall.

Do Level 0 to Level 2 control networks need quantum-safe encryption?

Inside a physically protected cell, usually not. Once Level 0 to 2 traffic leaves that protection, for example over cellular, radio backhaul, leased lines or the public internet to a remote field site, it does.

There are four reasons for restraint inside the cell. First, NIST SP 800-82r3 notes that control loops run with cycle times from milliseconds to minutes, so anything added to the path must be tested against those timings. Second, many Level 1 devices cannot run modern cryptography at all, and replacing them for this reason alone is rarely justified. Third, for most control traffic integrity and availability matter more than confidentiality. Fourth, much I/O data has a short useful life. CISA also notes that breaking symmetric cryptography would likely require even greater quantum capability than breaking public-key algorithms. The urgent quantum exposure is the key exchange on long-lived links.

Distributed infrastructure is different. A water utility polling dozens of unmanned pump stations, or a grid operator reaching substations over a carrier network, sends Level 1 and 2 traffic across infrastructure it does not control. The usual pattern is a bump-in-the-wire gateway at the edge of the field site, so the PLCs and RTUs behind it need no changes.

How does quantum-safe encryption change traffic flows between OT and IT across the Purdue model?

It should not change which flows are allowed. It changes where traffic is visible, how routing is built, and how link failures behave.

The biggest operational surprise is usually monitoring. OT teams that rely on passive network monitoring at the WAN aggregation point will see their visibility drop once tunnels go live, unless they move sensors to the inside interfaces first. Plan that move before cutover, not after.

Failure behavior is a design decision with safety consequences. A well-designed tunnel fails closed: it never falls back to plaintext. That means each site must be able to keep running in islanded mode while the link is down, which SCADA designs often already assume. Verify that assumption explicitly for every conduit you encrypt.

Can a quantum-safe encryption gateway replace a jump server or data diode in the IDMZ?

No. A gateway protects the confidentiality and integrity of data in transit. A jump server and a data diode control who and what can cross the boundary, which is a different function.

Product scope reflects this split. Quantum Network describes its Quantum Gateway as protecting data in transit, not the devices behind it. It does no web filtering, no email malware scanning and no anti-virus, it is not a defence against denial of service, and it does not replace a central firewall. It works alongside existing firewalls and routers.

The patterns that work layer these functions. A remote engineer’s post-quantum tunnel terminates in the IDMZ, and the engineer then reaches Level 3 only through the jump host with its authentication and recording. In diode-protected plants the diode stays where it is. Encryption protects the data after it reaches the IT side, for example when replicated historian data travels on to a cloud analytics environment.

How do you plan a Purdue-aligned post-quantum rollout?

Start from the cryptographic inventory and conduit list, protect the long-lived WAN conduits first, and plan for algorithm changes from day one.

The joint CISA, NSA and NIST factsheet Quantum-Readiness: Migration to Post-Quantum Cryptography recommends a quantum-readiness roadmap built on a cryptographic inventory. In OT, the conduit table from IEC 62443-3-2 is a natural place to record that inventory. As then CISA Director Jen Easterly put it, “It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography.”

A workable order for most operators:

• Site-to-site and field-site WAN links, because they carry long-lived OT data over networks you do not control.
• Remote access into the IDMZ, terminating before the jump host.
• IDMZ to enterprise and cloud, aligned with where historian and analytics data actually go.
• Selective Level 2 links only where traffic leaves physical protection.

Use hybrid key agreement, where a classical and a post-quantum exchange are combined into one session key, during the transition. Choose equipment whose algorithms can be updated, because standards will keep moving. NIST’s Dustin Moody has urged organizations to “begin their transition to these standards immediately”. NIST is also revising its OT guidance: an initial public draft of SP 800-82 Revision 4 is open for public comment until 30 November 2026. Architecture teams should read it alongside their encryption plans.