Post-quantum cryptography for operational technology (OT) and industrial control systems (ICS) describes the application of quantum-resistant algorithms, principally the NIST-standardised ML-KEM (FIPS 203) and ML-DSA (FIPS 204), to protect the authentication, key exchange, and integrity functions embedded in industrial networks such as power grids, water treatment plants, and manufacturing facilities. Unlike enterprise IT, these environments were engineered for deterministic performance over decades, not for cryptographic agility, which makes the migration fundamentally different in kind and urgency.
Why OT Is Not Just Slow IT
The post-quantum challenge in ICS environments is distinct from IT migration because the constraints are physical and contractual, not merely technical.
Enterprise servers can be patched, containerised, or replaced on a two-to-five-year cycle. A substation remote terminal unit (RTU) or a distributed control system (DCS) managing a chemical process may carry a guaranteed operational lifetime of 15 to 25 years. The firmware on that device was compiled against cryptographic libraries that assumed RSA-2048 or ECC-256 would remain computationally infeasible to break for its entire operational life. That assumption no longer holds at the planning horizon relevant to the device’s retirement date.
Three structural constraints separate OT from IT when it comes to post-quantum migration:
- Latency budgets: Protocols such as IEC 61850 GOOSE messages operate on sub-4-millisecond timing windows for protective relay coordination. ML-KEM key encapsulation adds handshake overhead that must be engineered around, not simply accepted.
- Resource ceilings: Many PLCs and RTUs operate on microcontrollers with kilobytes of RAM. ML-KEM-768 requires approximately 1,088 bytes for a public key alone, which exceeds the available working memory on some deployed devices.
- Air-gap assumptions: Many OT environments were designed assuming network isolation would substitute for cryptographic strength. Increasing IT/OT convergence and remote access requirements have invalidated that assumption, often without a corresponding cryptographic upgrade.
Which Cryptographic Functions Are Most Exposed
Not all cryptographic operations in an OT estate carry equal quantum risk; three functions warrant immediate prioritisation.
Device authentication
IEC 62443, the industrial cybersecurity standard that defines security levels for industrial automation and control systems, requires authenticated device identity as a baseline control. In current-generation OT, this authentication typically relies on X.509 certificates backed by RSA or ECDSA keys. Both are broken by Shor’s algorithm on a sufficiently powerful quantum computer. A compromised device identity in a SCADA network is not an abstract risk: it enables an attacker to impersonate a sensor or controller and inject false data or commands.
Firmware signing
Firmware updates to PLCs and RTUs are verified using digital signatures, again typically ECDSA or RSA. If the signing key is broken, an adversary can distribute malicious firmware that passes the device’s integrity check. Given that firmware update cycles in OT may occur only once every several years during scheduled maintenance windows, there is minimal opportunity to revoke and reissue compromised keys quickly.
Session key establishment
Protocols that carry operational commands over encrypted channels, including TLS-wrapped Modbus or DNP3 Secure Authentication Version 5, use asymmetric key exchange to establish session keys. This is the direct target of a harvest-now-decrypt-later attack. ML-KEM (FIPS 203) is the designated replacement for this function and must be deployed at the boundary where encrypted sessions terminate.
Applying NIST ML-KEM and ML-DSA to OT Protocols
Direct integration of FIPS 203 and FIPS 204 into legacy OT protocols is constrained but not impossible, provided operators accept a layered rather than in-place approach.
| Protocol | Current cryptographic function | Feasible PQC path | Device replacement required? |
|---|---|---|---|
| DNP3 Secure Authentication v5 | HMAC with shared secret; asymmetric key update via RSA | Replace RSA key update mechanism with ML-KEM at crypto gateway; retain HMAC for message authentication | No, if gateway offloads key exchange |
| IEC 61850 (MMS/TLS) | TLS 1.2 with ECDSA certificates | Upgrade TLS to 1.3 with hybrid ML-KEM + ECDH; ML-DSA for certificate signing at CA level | No for gateway-terminated TLS; yes for end-device TLS |
| Modbus TCP (encrypted tunnel) | IPsec or TLS tunnel with RSA/ECDH | Replace tunnel endpoints with PQC-capable VPN concentrators running ML-KEM | No |
| IEC 62351 (power system security) | RSA and ECDSA for key management and signatures | Revise key management infrastructure to ML-KEM; migrate certificate authority to ML-DSA | Partial: CA and key server must be updated |
The practical conclusion is that crypto gateways, placed between the OT network and any external connection, offer the highest near-term impact without requiring device replacement. These gateways terminate and re-encrypt traffic, absorbing the computational cost of ML-KEM on hardware sized for that purpose.
The EU PQC Transition Roadmap and NIS-2 Obligations
The EU PQC Transition Roadmap 2026–2030 establishes a phased migration schedule for public-sector and critical-infrastructure operators across member states. For NIS-2 essential entities, which include operators of energy, water, transport, and digital infrastructure under Article 21 of the NIS-2 Directive, this roadmap creates a compliance obligation, not merely a recommendation.
ENISA’s implementation guidance translates the roadmap into sector-specific expectations. Energy and water operators are expected to complete cryptographic asset inventories by 2026 and to have migration plans approved by their competent national authority. By 2028, newly procured OT equipment must support post-quantum algorithms. Full migration of existing estate is targeted for 2030, though ENISA acknowledges that some legacy installations with fixed operational lifetimes may require derogations documented through risk acceptance procedures.
CISA’s 2024 guidance document, Post-Quantum Considerations for Operational Technology, reinforces this timeline from a threat intelligence perspective, noting that the convergence of IT and OT increases the attack surface available to state-level adversaries who are already investing in quantum computing capability.
“Operational technology environments were not designed with cryptographic agility in mind. Migrating them to post-quantum algorithms is not a software update; it is an engineering programme that must start years before quantum computers become a practical threat.” (CISA, Post-Quantum Considerations for Operational Technology, 2024)
A key practical implication: essential entities that cannot demonstrate progress toward PQC migration during a NIS-2 supervisory review face enforcement action under Article 32, including fines of up to 10 million euros or 2 percent of global turnover for essential entities.
Conducting a Cryptographic Inventory of an OT Estate
A cryptographic inventory in OT is considerably harder than in IT because algorithms are often embedded in proprietary firmware with no published specification.
The first step is passive network analysis. Tools capable of parsing OT protocol traffic, including protocol-aware deep packet inspection platforms, can identify TLS handshake parameters, certificate subject fields, and key exchange mechanisms visible on the wire. This reveals the cryptographic posture of any device that communicates over a network, even if the device firmware itself is opaque.
The second step is vendor engagement. Operators should formally request a cryptographic bill of materials from every OT vendor, specifying which algorithms are used for firmware signing, device authentication, and session establishment in each firmware version currently deployed. IEC 62443 compliance clauses in procurement contracts provide a contractual basis for this request. Vendors who cannot or will not provide a CBOM should be treated as a material supply-chain risk under NIS-2 Article 21’s supply-chain security provisions.
The third step is risk classification. Algorithms should be mapped to one of three categories: quantum-safe (ML-KEM, ML-DSA, symmetric AES-256), hybrid-acceptable during transition (ECDH combined with ML-KEM), and quantum-vulnerable requiring urgent remediation (standalone RSA, standalone ECDSA, Diffie-Hellman below 3072-bit equivalent).
“Essential entities must implement state-of-the-art cryptographic controls. Where algorithms are known to be vulnerable to quantum computing, competent authorities may require migration plans to be submitted as part of incident reporting obligations.” (ENISA, NIS-2 Implementation Guidance for Critical Infrastructure Operators)
HSMs and Secure Enclaves in the Transition Period
Hardware security modules serve a critical bridging function during the period between now and full ML-KEM deployment across an OT estate.
An HSM placed at a network demarcation point can hold private keys for the operator’s PKI, perform ML-KEM key encapsulation on behalf of legacy devices, and sign firmware using ML-DSA without requiring the end device to execute either algorithm. This architecture separates key material from the device lifecycle, meaning that a PLC with a 20-year operational lifetime does not need to run post-quantum software; it only needs to trust a credential issued by an HSM that does.
For sovereign operators who must keep key material outside US jurisdiction, the choice of HSM vendor is not neutral. Devices manufactured by US-headquartered vendors may be subject to export controls, National Security Letters, or FISA 702 orders directed at the vendor’s support and maintenance operations. European alternatives include Utimaco (Germany), whose SecurityServer line supports PKCS#11 and CNG interfaces usable in OT contexts, and Securosys (Switzerland), whose Primus HSM series is available in configurations that meet industrial operating temperature requirements and is manufactured outside US jurisdiction.
Secure enclaves, specifically Trusted Execution Environments (TEEs) available in ARM TrustZone-capable industrial SoCs, offer a complementary approach for newer OT hardware. TEEs can isolate key material and cryptographic operations from the main application processor, reducing the attack surface even if the main firmware is compromised.
IBM’s Cost of a Data Breach Report 2023 found an average of 287 days to identify and contain a breach across all sectors, with critical infrastructure incidents trending longer due to system complexity. This figure underlines that HSM-based key isolation is not merely a cryptographic choice but a breach containment measure: an attacker who cannot extract key material from an HSM cannot pivot from one compromised OT device to the entire network’s encrypted communications.
According to the Claroty State of XIoT Security Report for H1 2022, more than 50 percent of ICS vulnerabilities disclosed in that period could be exploited remotely. ENISA’s Threat Landscape 2023 noted that a significant majority of critical infrastructure operators lack a complete inventory of cryptographic assets across their OT environments, confirming that the baseline for most organisations is further from compliance than their risk registers acknowledge.
FAQ
Can NIST ML-KEM (FIPS 203) run on a legacy PLC or RTU without replacing the hardware?
Not directly in most cases. ML-KEM requires more computational resources and memory than RSA or ECC, which makes in-place deployment on resource-constrained PLCs and RTUs impractical. The feasible path is to offload cryptographic operations to a crypto gateway or HSM placed at the network boundary, so the legacy device itself does not need to execute the post-quantum algorithm.
What does NIS-2 Article 21 specifically require of an energy or water utility running SCADA systems?
Article 21 requires essential entities to implement technical and organisational measures covering encryption and access control proportionate to the risk. ENISA guidance interprets this as requiring a documented cryptographic asset inventory, a transition plan for deprecated algorithms, and evidence of controls presentable during supervisory review. Quantum-vulnerable algorithms in active use constitute a foreseeable risk that must be addressed in that plan.
How does “harvest now, decrypt later” apply specifically to OT data such as DNP3 traffic?
DNP3 traffic carries SCADA commands, sensor readings, and operational state data. An adversary recording encrypted DNP3 sessions today can store that traffic and decrypt it once a sufficiently powerful quantum computer becomes available, potentially revealing network topology, device identifiers, and command patterns useful for future sabotage. Long-lived operational data in energy, water, and transport networks is exactly the target profile this attack model exploits.
Which sovereign HSM vendors offer form factors suitable for OT environments?
Utimaco (Germany) offers HSMs with PKCS#11 interfaces usable in OT contexts, and Securosys (Switzerland) produces the Primus HSM series in rack and cloud-agnostic configurations. Both support post-quantum algorithm suites. When evaluating vendors, operators should verify industrial-enclosure availability, operating temperature ratings, and whether the vendor’s supply chain is free of components subject to US export-control jurisdiction.
What contractual levers exist if an OT vendor’s firmware embeds quantum-vulnerable cryptography and the vendor has no migration roadmap?
Operators can invoke IEC 62443 compliance clauses, which are increasingly referenced in EU public procurement frameworks. NIS-2 Article 21 supply-chain security requirements mean an operator can formally require vendors to provide a cryptographic bill of materials and a PQC migration timeline as a condition of contract renewal. Failure to provide these can constitute a material breach where the original contract referenced current-state cybersecurity standards.