Quantum Security for OT and SCADA Systems: A Practitioner's Assessment Framework

The PQC migration problem in operational technology environments is structurally harder than in IT. Not because the cryptographic threat is different, Shor's algorithm breaks RSA and ECDH regardless of whether they run in a data centre or a substation control network, but because the constraints are different. Hardware refresh cycles of ten to twenty years. PLCs and RTUs deployed in safety-critical contexts with compute resources that predate lattice-based cryptography. Operational availability requirements that make active scanning inappropriate. Q-Day is assessed at 2033 to 2035 (Mosca, IEEE Security and Privacy, 2018). That sits well within the operational lifetime of OT equipment being commissioned today.

This article provides a four-stage assessment framework for OT security practitioners starting a quantum security evaluation of their industrial environment. It assumes familiarity with OT architecture concepts (Purdue model, IEC 62443 zones and conduits, SCADA protocols) and does not re-explain quantum computing basics. The framework is designed to be completed without active scanning of live OT systems.

Why OT and SCADA Systems Face a Harder PQC Migration Problem

Three factors compound the difficulty in OT environments simultaneously. First, hardware lifecycle. IT infrastructure refreshes every three to five years; enterprise TLS stacks can be updated across a server fleet in weeks. OT hardware refreshes every ten to twenty years. A PLC commissioned in 2018 for a fifteen-year operational life was designed years before ML-KEM existed. Its firmware update path may be non-existent, vendor-constrained, or require a full-process shutdown to execute.

Second, compute constraints. Lattice-based cryptography (ML-KEM, ML-DSA) requires more computational resources than legacy asymmetric schemes. Many deployed OT endpoints cannot run ML-KEM in hardware at all. This is not a configuration problem. It is an architectural one that requires gateway-mediated or isolation-based approaches rather than device-level migration.

Third, HNDL exposure on operational data. SCADA communication streams carrying control commands, sensor readings, grid state, and pipeline pressure are encrypted with RSA or ECDH today. A state-level adversary capturing and retaining those streams now can decrypt them retrospectively when a CRQC arrives. For critical national infrastructure operators, operational data from 2026 may retain strategic intelligence value in 2033 to 2035. The HNDL threat in OT environments is not about confidential communications in the corporate email sense. It is about adversaries understanding infrastructure behaviour, operational patterns, and system-state data that could inform future disruption campaigns.

NIST SP 800-82r3 (Guide to Operational Technology Security, September 2023) is the primary US federal guidance for OT security management. Revision 3 added explicit quantum security context, referencing the PQC standardisation effort and advising OT operators to assess their cryptographic exposures. It does not mandate specific migration timelines but provides the risk management framework that the four-stage assessment below builds on.

The Regulatory Landscape: CNSA 2.0, NIST SP 800-82r3, and IEC 62443

For OT operators in the defence supply chain, CNSA 2.0 sets the most prescriptive requirements. NSA's Commercial National Security Algorithm Suite 2.0 (September 2022) mandates ML-KEM-1024 (FIPS 203) for key establishment and ML-DSA-87 (FIPS 204) for digital signatures in national security systems. SLH-DSA (FIPS 205) provides a hash-based signature alternative. The CNSA 2.0 transition timeline requires new national security systems to use these algorithms from 2025, with legacy system migration complete by 2033.

OT and SCADA systems in defence-adjacent critical infrastructure, weapons manufacturing, naval logistics, energy supply for defence installations, telecommunications under defence contracts, may fall within CNSA 2.0 scope depending on NSS determination under 44 USC section 3552(b)(6). The first assessment question for any OT operator in the defence supply chain is whether their OT systems qualify as national security systems under that definition. If they do, CNSA 2.0 applies directly, and the 2033 deadline is not advisory. For a detailed treatment of CNSA 2.0 compliance requirements and how they differ from CNSA 1.0, see /insights/cnsa-2-vs-1-defence-suppliers/.

IEC 62443 provides the architectural framework within which PQC migration in OT environments should be planned. IEC 62443-3-3 defines Security Levels (SL 1 through SL 4) for industrial automation and control systems. Cryptographic requirements scale with security level: SL2 and above require authenticated encryption; SL3 and above require resistance to sophisticated attacks. The zone-and-conduit model in IEC 62443 provides the segmentation architecture within which migration sequencing decisions are made. As of 2025, IEC 62443 had not published explicit PQC migration guidance, but the zone-and-conduit model is the structural framework that makes PQC sequencing tractable in complex OT environments. [ASSUMED, verify whether IEC 62443 has published PQC-specific guidance before publication.]

The Industrial Protocol Problem: Modbus, DNP3, IEC 61850, and OPC UA

Industrial communication protocols do not have uniform cryptographic exposure. The attack surface is in different places for each protocol, and generalising "all OT protocols need PQC migration" produces a migration plan that misses the actual risk.

OPC UA is the highest-priority PQC migration target in most OT environments. OPC UA Security Mode "SignAndEncrypt" uses asymmetric key exchange, currently RSA-2048 or ECC, for key establishment between clients and servers. This is direct Shor's algorithm exposure. The OPC Foundation has published security guidance and is developing quantum security profiles; operators should monitor OPC Foundation publication status for formal PQC security profiles as they are finalised. [ASSUMED, verify current OPC Foundation PQC specification status before publication.] The migration path for OPC UA is to configure hybrid key exchange (X25519+ML-KEM) in security policies as client and server implementations add support.

DNP3 Secure Authentication v6 uses HMAC-SHA-256 for message authentication and does not use asymmetric encryption in the protocol itself. It is not directly vulnerable to Shor's algorithm. The attack surface is in the key distribution mechanism: initial key establishment for DNP3 SA commonly uses RSA-based key wrapping or TLS. Operators assessing DNP3 SA should audit the key distribution mechanism, not the DNP3 SA authentication protocol. The relevant specification is IEEE 1815-2012 (verify whether a newer edition has been published). [ASSUMED, verify IEEE 1815 revision status before publication.]

IEC 61850 has a split exposure profile. GOOSE (Generic Object-Oriented Substation Event) and Sampled Values messaging typically operate without encryption, as multicast time-critical communications. MMS (Manufacturing Message Specification) over TLS is the asymmetric exposure surface. Certificate management for IEC 61850 TLS certificates is the migration target. IEC TC57 Working Group 15 is developing security guidance for IEC 61850 that is expected to address PQC. [ASSUMED, verify WG15 PQC guidance publication status before publication.]

Modbus/TCP has no native security features at all. Modbus communications rely entirely on transport-layer wrappers: IPsec or TLS at the network/transport layer. The migration target is the transport-layer wrapper, IPsec IKEv2 with ML-KEM (IETF RFC 9242 specifies PQC support for IKEv2 intermediate key exchange), or TLS 1.3 with NIST PQC cipher suites. Modbus endpoint devices cannot implement PQC themselves. Gateway-mediated migration, where a PQC-capable security gateway handles the asymmetric key exchange on behalf of constrained Modbus endpoints, is the only viable path for most deployed Modbus infrastructure.

Protocol Cryptographic exposure type Attack surface location Near-term migration path Priority
OPC UA Asymmetric key exchange (RSA/ECC) SignAndEncrypt security mode X25519+ML-KEM in security profiles High
DNP3 SA v6 Key distribution (not protocol auth) RSA/TLS in key establishment Migrate key distribution mechanism Medium
IEC 61850 MMS TLS certificate chain MMS-over-TLS connections ML-DSA certificate migration Medium
Modbus/TCP Transport-layer wrapper IPsec/TLS gateway Gateway-mediated ML-KEM migration Low (gateway-mediated)

A Four-Stage Assessment Framework for OT Environments

The framework below is designed for passive assessment. Active scanning of live OT systems risks disrupting safety-critical processes. Every stage can be completed through passive traffic analysis, vendor documentation review, and network architecture audit.

Stage 1: Cryptographic Asset Discovery

Standard IT cryptographic discovery methods do not transfer to OT environments without modification. Active port scanning is inappropriate in safety-critical OT networks. Discovery in OT requires three parallel workstreams.

Passive network traffic analysis on OT network segments: capture TLS handshakes, certificate exchanges, and key negotiation traffic using span port or network tap. This identifies which OT network segments carry asymmetric cryptography and what algorithms are in use without generating any active traffic. NIST SP 800-82r3 addresses the passive-first principle for OT security assessment (section reference: verify against current document at time of use). [ASSUMED, verify section number at time of writing.]

Vendor documentation review: for each PLC, RTU, HMI, historian, and engineering workstation in the environment, review the manufacturer's security documentation for embedded cryptographic capabilities. This identifies which devices support TLS, which protocol security modes are available, and what firmware versions are in deployment. Compile firmware version against cryptographic library version where vendor documentation permits.

Network architecture audit: review network diagrams, firewall rules, VPN configurations, and remote access infrastructure. This identifies cryptographic endpoints at IT/OT boundaries, historian replication paths, and engineering workstation TLS configurations, the external-facing assets that carry the highest asymmetric exposure and are typically the most feasible to migrate first.

Stage 2: Protocol-Level Cryptographic Gap Analysis

For each OT network zone, map the current cryptographic posture against the migration target. The gap analysis produces: current algorithm (e.g. RSA-2048 key exchange in OPC UA, ECDH in TLS at historian boundary) mapped against the Shor's algorithm vulnerability; the CNSA 2.0 or NIST IR 8547-compliant replacement (ML-KEM-1024 for CNSA 2.0 scope, ML-KEM-768 for NIST IR 8547 general compliance); and feasibility given device compute constraints and protocol support.

The output of this stage is a protocol-level heat map: which OT zones have migration-blocking constraints (protocol does not support PQC, device firmware cannot be updated) versus which can be migrated through standard approaches (update security gateway, configure hybrid TLS on historian). The heat map drives Stage 3 classification.

Stage 3: Hardware Constraint Classification

Every OT device in the cryptographic asset inventory falls into one of four categories. The classification determines the migration path.

Firmware-upgradeable: devices where the manufacturer offers or will offer PQC-capable firmware updates within the migration window. These are the straightforward migration cases. Establish the vendor roadmap commitment and include in the standard migration schedule.

Gateway-mediated: devices too constrained for PQC in firmware, but protected by a PQC-capable security gateway or protocol translator that handles asymmetric key exchange on their behalf. Modbus/TCP infrastructure at an OT-DMZ boundary is the canonical example. The migration target is the gateway, not the constrained endpoint.

Network-isolated: devices for which neither firmware update nor gateway mediation is viable, but which can be isolated to reduce their external HNDL exposure. Isolation does not eliminate the long-term migration requirement but reduces the near-term risk surface. Flag these for scheduled hardware replacement.

Replace-before-Q-Day: devices whose operational lifetime extends beyond the 2033 to 2035 Q-Day window and which carry cryptographic exposure that cannot be mitigated by gateway or isolation measures. These are the assets that must be identified early in the planning cycle because hardware procurement and replacement for OT environments runs on three-to-five-year timescales. Finding a replace-before-Q-Day device in Stage 3 that was not budgeted in the current capital plan is a planning failure, not a procurement emergency, if found early enough.

Stage 4: Sequencing Within the IEC 62443 Zone-and-Conduit Architecture

PQC migration in OT environments should follow the IEC 62443 zone and security level structure. Priority sequencing from highest to lowest:

  1. SL3 and SL4 zones carrying the highest-consequence operational data (substation control, safety instrumented systems, critical infrastructure command). Any inter-zone conduits connecting these zones to lower-security zones are the highest-priority asymmetric exposure surfaces.
  2. External-facing interfaces: historian replication to cloud or corporate IT, remote access VPNs serving engineering workstations, and any OT-to-cloud API connections. These carry asymmetric key exchange and are generally the most technically accessible migration targets.
  3. IT/OT boundary gateways and protocol translators. These protect SL1 and SL2 zones from external exposure. Migrating the gateway upgrades the cryptographic posture for all devices behind it simultaneously.
  4. Internal OT-to-OT communications within SL2 zones where asymmetric cryptography is in use (OPC UA client/server, IEC 61850 MMS).
  5. SL1 monitoring-only devices with no external-facing connectivity. Lowest HNDL risk; lowest migration urgency.

Network Segmentation as the Primary Near-Term Mitigation

For OT environments where Stage 3 classification produces a large gateway-mediated or replace-before-Q-Day category, network segmentation is the primary near-term mitigation available before device-level or gateway-level migration is complete.

Physical and logical isolation of high-consequence OT zones reduces the HNDL attack surface directly: if traffic cannot be intercepted, it cannot be harvested. NIST SP 800-82r3 provides the segmentation guidance framework (section reference: verify against current document at time of use). [ASSUMED, verify section number at time of writing.] A dedicated OT-DMZ between the enterprise IT network and the OT network reduces the external-facing cryptographic exposure surface to a defined set of controlled interface points. VPN concentrators and protocol translators at the IT/OT boundary are then the highest-priority PQC migration targets in this architecture: they handle asymmetric key exchange for external connectivity and are generally firmware-upgradeable without touching embedded OT device firmware.

Segmentation reduces near-term HNDL risk. It does not eliminate the long-term migration requirement. It buys time for the migration programme to execute without leaving the most sensitive OT zones exposed during the transition period.

Where to Start: Four Diagnostic Questions

A practitioner beginning an OT quantum security assessment should start by answering four questions. The answers determine whether the organisation faces an urgent HNDL exposure, a manageable migration planning task, or a combination of both.

  1. Which OT zones carry data with a strategic sensitivity lifetime extending beyond 2033? Defence-adjacent CNI operators, energy companies, and advanced manufacturing are likely to find zones where the answer is yes. These zones are the immediate HNDL priority regardless of migration complexity.
  2. Which inter-zone conduits use asymmetric cryptography? Identify every point where asymmetric key exchange or digital signatures are used across zone boundaries. These are the harvest targets for a state-level adversary collecting traffic today.
  3. Which devices in those conduits are firmware-upgradeable for PQC? Vendor documentation review answers this. For devices that are not, identify the gateway-mediated alternative.
  4. Does the organisation fall within CNSA 2.0 scope? If any OT system supports a national security system as defined in 44 USC section 3552(b)(6), CNSA 2.0 applies with its specific algorithm requirements (ML-KEM-1024, ML-DSA-87) and deadlines (new systems 2025, legacy 2033). This changes the urgency of the migration programme.

These four questions can be answered without active scanning. Passive traffic analysis, vendor documentation review, and network architecture audit are sufficient to produce answers that define the scope and urgency of the OT quantum security programme.

Sources