What ISA/IEC 62443 actually is
ISA/IEC 62443 is a series of standards developed by the ISA99 Committee at the International Society of Automation, harmonised with IEC. It defines a security lifecycle for IACS, broken into four parts:
- 1.x, General, terminology, concepts, security lifecycle.
- 2.x, Policies and procedures, asset owners and service providers.
- 3.x, System, security technologies, system security requirements, security levels (SL 1 to 4).
- 4.x, Component, secure development lifecycle for product suppliers, component-level requirements.
The vocabulary that everyone needs to know is zone (a logical grouping of assets with shared security requirements) and conduit (a logical grouping of communication channels between zones). Get those two right and most of the rest follows.
The Purdue model and why it matters
The Purdue Model (PERA) is the reference architecture 62443 implicitly assumes. It segments the plant into hierarchical levels: physical process (Level 0), basic control (Level 1), supervisory control / SCADA (Level 2), site operations (Level 3), business systems (Level 4), and enterprise (Level 5). 62443 zone-and-conduit design typically maps zones to Purdue levels.
The challenge for PQC migration is that Levels 0 to 2 contain devices with 15 to 25-year lifecycles, no remote firmware update, and vendors who may no longer exist. The migration plan that works for Levels 4 to 5 (TLS upgrade) does not work for Levels 0 to 2.
Where post-quantum cryptography fits
The 62443 series does not yet specify PQC algorithms (work is in progress). Current best practice for asset owners:
- At Level 4 to 5, deploy hybrid TLS (classical + Kyber) on enterprise-to-DMZ links today. This is the easy win.
- At Level 3 (site operations), plan HSM replacement, not firmware upgrade. RSA-sized HSMs do not fit Dilithium-2 in working memory.
- At Level 2 (SCADA), target the next major refresh cycle. Specify Kyber + Dilithium support in next RFP.
- At Levels 0 to 1, expect 15+ year migration. Inventory long-lived secrets, treat them as already harvested.
For the constrained-device end of this stack, see my work on IoT PQ-EDHOC and the FIPS 203 / 204 implementation on Arduino-class targets.
Validating defenses on real testbeds
SWaT (Secure Water Treatment, Singapore University of Technology and Design) and HAI (HIL-based Augmented ICS, South Korea's National Security Research Institute) are the two most-used labelled ICS testbeds. They expose the gap between lab-clean and process-realistic anomaly detection.
My IEEE Access 2026 paper validated 8-qubit ZZFeatureMap quantum kernels on both. Results: SWaT was the easier dataset (already AUC near 0.99 for classical), HAI was the harder one (where the quantum kernel showed a statistically significant +10.8 percent AUC gain over RBF SVMs, p = 0.003). See the quantum kernels topic and the research deep-dive for detail.
The deadlines that now apply to OT
Three sets of dates shape every utility and manufacturer conversation in 2026:
- NSA CNSA 2.0, for National Security Systems: new acquisitions must be CNSA 2.0 compliant from 1 January 2027. Software and firmware signing, and traditional networking equipment, move to quantum-resistant algorithms exclusively by 2030. Operating systems, niche equipment and custom or legacy systems follow by 2033, and all National Security Systems by 2035 (NSA CNSA 2.0 FAQ).
- US federal mandates, the June 2026 executive orders set end-2030 for post-quantum key establishment and end-2031 for signatures on high-value federal systems, and push the same dates to contractors (Mayer Brown summary).
- EU and UK roadmaps, the EU coordinated roadmap targets high-risk use cases, including critical infrastructure, by 2030. The UK NCSC asks organisations to finish discovery by 2028, high-priority migration by 2031 and full migration by 2035 (NCSC timelines).
None of these are forecasts of when a quantum computer arrives. They are policy decisions about how long migration takes, which is the y term in Mosca's inequality. For OT, y is longer than anywhere else in IT.
Can PLCs and RTUs run post-quantum cryptography?
Some can, most installed ones cannot. ML-KEM (FIPS 203) is fast and its keys are small enough for modern 32-bit controllers. ML-DSA (FIPS 204) signatures run to roughly 2.4 to 4.6 KB, which strains fieldbus frame sizes and the RAM on older 8-bit and 16-bit devices. My own work ported ML-KEM and ML-DSA to an ATmega328P with 2 KB of SRAM at 136 ms per signature, which shows it is possible, and also shows how little headroom is left. In practice the answer for Levels 0 and 1 is a post-quantum gateway or bump-in-the-wire on the conduit, not a firmware update on every PLC.
For firmware and update signing, CNSA 2.0 prefers the stateful hash-based schemes LMS and XMSS. They are conservative and well understood, but they demand careful state management in the signing infrastructure, which is an operations problem more than a cryptography problem.
A five-step PQC migration plan for OT
- Inventory cryptography by zone and conduit. Reuse the 62443 zone and conduit model. For every conduit record the protocol, key exchange, signature scheme, certificate lifetime and who owns the keys.
- Rank by secrecy lifetime. Score each data flow by how long it must stay confidential (the x in Mosca's inequality). Process designs, grid topology and long-lived keys rank first. Telemetry that is stale in an hour ranks last.
- Fix the conduits before the devices. Put hybrid key exchange (classical plus ML-KEM) on enterprise-to-DMZ and DMZ-to-control conduits first. This blunts harvest now, decrypt later without touching a single controller.
- Move signing to post-quantum. Firmware, update packages and engineering-workstation code signing move to LMS, XMSS or ML-DSA. Forged firmware is the attack that turns Q-Day into a physical incident.
- Write it into procurement. Every RFP for controllers, HSMs and gateways should require FIPS 203 and 204 support, crypto-agility and a vendor statement on firmware-signing migration. Assets bought in 2027 will still be running in 2045.
What I am writing about next
The migration sequencing problem is the next long-form blog post. The summary version is in the why ICS PQC migration is 10x harder than TLS migration piece. The forthcoming post extends that into a 62443-zone-by-zone migration playbook.