OT & Industrial Control Systems PQC
PQC for operational technology across energy, water, rail, manufacturing and building automation: why forged commands and firmware matter more than harvested data, IEC 62443 zones and conduits, the native security of OT protocols, safety-critical timing, PLC firmware and project signing, and the regulations that apply.
Why this matters: In OT a quantum computer’s worst trick is not reading old traffic but forging what controllers trust — firmware, project downloads, certificates and commands — on assets that stay in service for decades and cannot change crypto without a safety review.
Start here: Open the Zone & Conduit Planner and see why controllers rank high once forged firmware — not just harvested traffic — is scored.
For your role
- Security Architect
- Map IEC 62443 zones and conduits to where PQC lands first, plan an IEC 61850 substation migration within the GOOSE trip-time classes, and lay out sector roadmaps for energy, water, rail, manufacturing and building automation.
- Researcher / Academic
- Compare the native security of IEC 61850/62351, DNP3 Secure Authentication, OPC UA, CIP Security, PROFINET and BACnet/SC, and score how safety and timing constraints limit which PQC algorithms can be used where.
- IT Ops / DevOps
- Plan the substation migration around outage windows, sign PLC firmware and project files with ML-DSA, with the LMS verifier checked against the RFC 8554 test vectors, and track the NERC CIP, NIS2 and TSA milestones per sector.
Operational technology (OT) runs physical processes: grids, pipelines, water plants, railways, factories and buildings. IT security usually ranks confidentiality first. OT turns the order around: safety, then availability, then integrity, then confidentiality. A control system that leaks data is a problem; one that accepts a forged command can hurt people.
That changes what the quantum threat means here. In IT the headline risk is . In OT the bigger risk is authenticity: a cryptographically relevant quantum computer could forge the RSA or ECDSA signatures that controllers use to accept firmware, project downloads, certificates and commands. Forgery needs no harvesting — it starts the day such a machine exists — and the devices that trust the old keys stay in service for decades.
Forged commands and firmware
Signing roots (vendor firmware keys, engineering-tool keys, device CAs) are the first thing to migrate. Step 2 of the workshop scores this as its own axis.
Harvested traffic
Still real at the boundary: remote-access sessions, inter-site links and vendor VPNs carry credentials, topology and settings worth recording now.
20–50-year assets
A relay or PLC installed today may still run in the 2040s; substation primary plant lasts longer still (see the table below).
Recertification cost
Changing crypto in a safety-related device can mean re-testing a protection scheme, re-running a SIL assessment or re-opening a rail safety case — far more than a software update.
| Asset | Typical life (years) | Why it matters |
|---|---|---|
| Substation primary plant (transformers, switchgear) | 30–50 | No crypto itself, but outlives several generations of the IEDs that control it. |
| Protection relay / IED | 15–25 | Safety-related; a firmware change can mean re-testing the protection scheme. |
| PLC / DCS controller | 15–25 | Firmware and project signing roots live as long as the controller does. |
| RTU / outstation | 15–20 | Often on serial links; firmware updates may need a site visit. |
| Safety instrumented system | 15–25 | Changes go through the IEC 61511 management-of-change process. |
| Rail signalling / interlocking | 25–40 | Every crypto change touches a safety case. |
| SCADA / HMI servers | 7–15 | Shortest lifecycle; easiest place to start TLS migration. |
Smart meters, AMI head-ends and RF-mesh networks are covered in IoT & Embedded Device PQC, which deals with fleets of constrained devices.
Try it on your own plant
Six steps: tag protocol layers, rank zones by forgery and HNDL, plan a substation, score consequences, build a sector roadmap and size a firmware-signing scheme.
Related Resources
Products shown here are a representative selection — not an exhaustive list. For the full vendor landscape with PQC readiness status, visit the Tools & Products tab in this module or browse the Migrate catalog →
Check off all sections and mark this reading done.
Related modules
- IoT & Embedded Device PQCSame track · Applications · Same migration phase · Shares LMS/XMSS, ML-DSA, ML-KEM
- Code SigningSame track · Applications · Same migration phase · Shares ML-DSA, LMS/XMSS, FIPS 204
- Aerospace PQCSame migration phase · Shares ML-DSA, ML-KEM, FIPS 203
- Healthcare PQCSame migration phase · Shares ML-DSA, ML-KEM, FIPS 203
In the Industry Landscape
- Critical Infrastructure / EnergySCADA & substation automation (IEC 61850/62351) · Nuclear I&C and safeguards data · Pipeline & OT remote-access VPNs
- Internet of Things (IoT)Industrial IoT (OPC UA / IEC 62443)
- Rail / TransitTrain control key management (ETCS) · Railway mobile communications (GSM-R → FRMCS) · Positive Train Control PKI
- Water / WastewaterTreatment plant SCADA & remote ops · Dam & hydropower remote access
Check your understanding
23 questions on OT & Industrial Control Systems PQC, each with its answer and the reason.
Take the quizNext step
Produce the artifact: MTI NegotiatorThis module belongs to phase 5 (Pilots & Migration); MTI Negotiator produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.