IEC 62443 conduit encryption post-quantum: what’s required?

Post-quantum conduit encryption under IEC 62443 means protecting the communication path between two OT security zones with a cryptographic tunnel whose key exchange can resist a future quantum computer. You do this inside the zone and conduit model, so the protection follows the target security level set for that conduit and isn’t a stand-alone IT add-on.

This article covers what the standard actually requires, which system requirements apply, how a quantum-safe tunnel fits the model and how to build an audit trail for it. The ISA99 Committee describes IEC 62443-3-3 as a standard that “provides guidance in determining and protecting high risk communication conduits and security zones”. That is the right lens for everything below.

Does IEC 62443 require encryption on conduits between OT zones?

Not unconditionally. IEC 62443 makes conduit encryption a requirement once the risk assessment sets a target security level, or identifies a network path, that triggers the confidentiality and integrity requirement enhancements.

The decision begins in IEC 62443-3-2. There you split the system under consideration into zones and conduits, run a detailed risk assessment and give each one a target security level (SL-T). IEC 62443-3-3 then provides detailed technical control system requirements (SRs) associated with the seven foundational requirements (FRs) described in IEC 62443-1-1, including the capability levels a system must reach.

In practice, encryption becomes hard to avoid when a conduit leaves the plant. Examples are links between substations over carrier networks, connections from a site to a cloud historian, and remote engineering access over the internet. The standard leaves “untrusted network” undefined: a specific definition of untrusted networks in this context is not given within the IEC 62443. Your risk assessment has to state explicitly which networks you treat as untrusted.

Which IEC 62443-3-3 system requirements cover communication confidentiality and integrity?

Three system requirements carry most of the weight: IEC 62443-3-3 SR 4.1 (information confidentiality), IEC 62443-3-3 SR 3.1 (communication integrity) and SR 4.3 (use of cryptography). SR 5.2 (zone boundary protection) sits alongside them.

SR 4.1 escalates in steps. One analysis of the standard notes that the first RE adds the mandatory protection of confidentiality in cases where information is transferred via or stored in untrusted networks, and that the last RE restricts this further by expanding the required confidentiality on the whole network including all zones and information leaving the network boundaries. Check the exact mapping of requirement enhancements to security levels against your licensed copy of the edition you are audited on.

Which security level (SL 1-4) calls for protection against advanced nation-state attackers who could harvest traffic?

SL 4 is the level for well-resourced, highly motivated adversaries, a profile that matches nation-state actors. SL 3 covers capable attackers with fewer resources.

The ISA/IEC 62443 Security Levels describe attacker capability, not product grades. The standard defines four security levels (SL1, SL2, SL3, SL4), and these are qualitative measures of confidence that the IACS can withstand attacks from different classes of threat actors.

Harvesting matters most at SL 4. An adversary with extended resources can record encrypted conduit traffic today and keep it until it can be decrypted. CISA, NSA and NIST warned critical infrastructure operators that “cyber threat actors could be targeting data today that would still require protection in the future”. For OT, that long-lived data includes network topology, controller configurations, safety system parameters and engineering credentials sent during remote sessions.

Why do quantum timelines matter for OT conduits now?

OT assets stay in service for decades, so conduits you design today will still carry traffic when current public-key algorithms are disallowed. The timelines below come from primary sources.

• 3 standards: On August 13, 2024, NIST approved three PQC standards (FIPS 203, FIPS 204, and FIPS 205) (CISA, 2024).
• 8 years: the standards are the result of an eight-year effort managed by NIST (NIST, August 2024).
• 2030 and 2035: the NIST IR 8547 draft lists quantum-vulnerable algorithms at 112 bits of security strength as deprecated after 2030 and disallowed after 2035 (NIST, November 2024).
• 55 functions: there are potential risks from quantum computing to each of the 55 NCFs, according to CISA’s analysis of National Critical Functions (CISA, 2022).

NIST’s message to operators is direct: “NIST is encouraging computer system administrators to begin transitioning to the new standards as soon as possible.” NIST also notes that high-risk systems are expected to move well before the 2035 end date.

How does a quantum-safe tunnel between zones fit into a zone and conduit model?

The tunnel is a countermeasure assigned to a specific conduit. It doesn’t create a new zone, and it doesn’t replace the boundary controls of the zones at either end.

The tunnel as a conduit countermeasure

In IEC 62443-3-2, a conduit groups communication channels that share security requirements. An encrypted tunnel between two zone boundaries turns an exposed channel, such as the public internet, a leased line or a cloud provider network, into one that meets SR 4.1 and SR 3.1 for that conduit. The endpoints of the tunnel should sit at, or inside, the boundaries of the zones the conduit connects. Otherwise part of the path stays unprotected and has to be documented as a separate conduit.

Where NIST FIPS 203 fits

NIST FIPS 203 covers the key-exchange step, which is where harvested traffic is exposed. FIPS 203 standardizes ML-KEM, a lattice-based key encapsulation mechanism intended to serve as a PQ alternative to the key agreement functionality of classical Diffie-Hellman. Many conduit designs use a hybrid exchange, which combines a classical and a post-quantum algorithm. NIST’s transition draft describes such composite mechanisms as intended to be secure as long as at least one of the component algorithms is secure, and states that such hybrid approaches may be used in the initial transition to PQC.

Placement relative to firewalls and inspection

OT conduits often depend on deep packet inspection of industrial protocols at the zone boundary. Encrypting in front of the inspection point blinds it. So place the tunnel endpoint so that traffic is decrypted before it reaches the inspecting firewall, or document why that path doesn’t need inspection. As one example of the gateway approach, Quantum Network’s QPN puts a gateway at each end of a connection that encrypts at Layer 3. It goes in front of an existing firewall when that firewall must keep inspecting traffic, and behind it when inspection isn’t needed on that path.

OT-specific design checks

• Failure behaviour: state whether the tunnel can ever fall back to cleartext after a link failure. A fallback silently breaks SR 4.1 for that conduit.
• Latency budget: measure the tunnel’s overhead on real control traffic, such as polling cycles and time synchronization, rather than relying on datasheet figures.
• Key renewal: short re-keying intervals limit how much traffic any single session key exposes.
• Endpoint footprint: network-level tunnels avoid installing software on controllers and HMIs, which matters where vendor support contracts forbid changes.

How do you document post-quantum conduit encryption for an IEC 62443 audit?

Document it as a traceable chain: risk assessment, then conduit requirement, then countermeasure, then verification evidence. The cryptographic choice is justified under SR 4.3 with references to NIST publications.

1. Conduit record in the cybersecurity requirements specification (IEC 62443-3-2): give the conduit’s name, the zones it connects, its physical and logical path, the networks treated as untrusted and its SL-T vector.
2. Threat and data-lifetime statement: record which threat profile drove the SL-T and how long the transported data must stay confidential. This is your harvest-now-decrypt-later justification.
3. Requirement mapping: list SR 3.1, SR 4.1 and SR 4.3 with the applicable requirement enhancements, and name the control that meets each one. Show separately that SR 5.2 is covered by boundary devices.
4. Cryptographic specification: list the key-exchange components (classical and ML-KEM per NIST FIPS 203), payload cipher, integrity mechanism, re-keying interval and authentication method.
5. Verification evidence: include packet captures showing encrypted traffic on the conduit, link-failure tests proving there is no cleartext fallback, and latency measurements on production-like traffic.
6. Crypto-agility and maintenance procedure: explain how you will swap algorithms if NIST guidance changes, who approves the change and how updates reach air-gapped sites.

Write down known limits too. A tunnel protects data in transit only. It doesn’t harden the devices behind it, and it doesn’t address denial of service. Recording those gaps, and the controls that close them, shows the auditor that the conduit countermeasure was chosen on purpose rather than assumed to cover everything.