PQC for Operational Technology and Industrial Control Systems

Quick answer: CISA’s own guidance is direct about this: operational technology could become the last remaining platform category to achieve post-quantum readiness, because of long software patching cycles, hardware replacement times measured in decades, and strict change-control procedures that IT environments do not carry. Some OT platforms still run on unsupported operating systems entirely, and safety-critical systems often require extensive re-testing after any software change, cryptographic or not, before that change can go live. The practical path forward that CISA recommends is not a rip-and-replace migration; it is requesting crypto-agile features in new procurement, using gateways to handle PQC on behalf of legacy devices that cannot change, and treating compensating controls as a legitimate interim strategy rather than a stopgap to apologize for.

OT and ICS migration planning cannot borrow the enterprise IT playbook wholesale, and pretending otherwise is how OT programs stall. The constraints are structurally different: equipment that runs for twenty years or more, vendors who may no longer exist, and safety certifications that treat any software change as a potential re-certification event. This guide covers what CISA and NSA guidance actually recommends for this environment specifically.

Key Takeaways

• CISA’s guidance explicitly states OT could be the last platform category to reach post-quantum readiness, due to long patching and replacement cycles and strict change governance.
• A significant share of OT endpoints run outdated or unsupported operating systems, some tied to specialized software that has no path to a newer platform at all.
• Safety certification requirements mean some OT systems need extensive re-testing after any software update, cryptographic or otherwise, due to complex process interdependencies in physical environments.
• CISA specifically recommends requesting crypto-agile features in future ICS procurement, using gateways or proxies to handle PQC negotiation on behalf of devices that cannot be upgraded directly.
• Compensating controls, network segmentation, monitoring, and remote-access hardening are a legitimate part of an OT PQC strategy where direct device upgrade is not feasible on any reasonable timeline.

Why OT Migration Is Structurally Different From IT

CISA’s “Post-Quantum Considerations for Operational Technology” guidance is blunt about this: OT systems may end up among the last platforms in critical infrastructure to achieve post-quantum cryptographic standards, specifically because of long software patching cycles, extended hardware replacement timelines, and the strict procedures and governance that OT environments operate under. A meaningful share of OT endpoints run outdated operating systems, including some considered fully end-of-life and no longer supported by their original vendor at all. In some deployments, the specialized software required to perform a specific industrial task is only compatible with an unsupported platform, such as an old Windows or UNIX release, which means there is no upgrade path for the underlying operating system, let alone its cryptography, without replacing the entire application stack.

Safety Certification: Why a Software Change Isn’t Just a Software Change

This is the constraint that most distinguishes OT from IT migration planning. Some OT platforms, particularly those automating heavy equipment or controlling hazardous or combustible processes, require extensive safety testing after any software update because of complex process interdependencies, testing that has nothing to do with the cryptographic change itself and everything to do with the physical process the system controls. A cryptographic update that would be a routine patch cycle in IT can trigger a full safety re-certification event in OT, which is a legitimate reason migration timelines here run on a different clock than enterprise IT, not an excuse to defer indefinitely.

Remote Access and Firmware Trust

Remote access into OT environments, whether for vendor support, maintenance, or monitoring, typically relies on the same VPN and TLS mechanisms covered in our post-quantum VPN migration guide, with the added constraint that the OT side of that connection may be running on hardware that cannot be upgraded on any near-term timeline. Firmware trust for PLCs, RTUs, and other field controllers carries the same long-lived-signature risk covered in our PQC code signing guide, amplified by OT’s typically longer device service life and, frequently, no straightforward field-update mechanism for firmware at all.

Gateways and Crypto-Agility: The Practical Path Forward

CISA’s guidance points toward a specific, practical strategy for equipment that cannot itself be upgraded: place a quantum-safe gateway or proxy in front of the legacy device, so communications leaving that segment are upconverted to post-quantum protection by the gateway, even though the legacy sensor or controller behind it continues running unchanged. This encapsulation approach, “design for swap-out” at the cryptographic layer rather than replacing every endpoint, is the realistic strategy for the portion of an OT fleet that has no viable direct upgrade path within any relevant planning horizon.

For new procurement, CISA is explicit that OT owners should request crypto-agile features directly in equipment acquisitions going forward: modular cryptographic libraries, firmware update mechanisms that can introduce new algorithms without a hardware refresh, and support for gateway-mediated post-quantum protection where native support is not feasible. Every piece of equipment purchased today without this requirement is a device the organization will need to work around, rather than with, during the eventual transition.

Compensating Controls as a Legitimate Strategy

For the portion of an OT fleet with genuinely no upgrade path, network segmentation, strict access control, and active monitoring are not a consolation prize; they are a legitimate, necessary part of an OT PQC strategy, buying time and reducing exposure for equipment that cannot itself become quantum-resistant on any relevant timeline. Documenting exactly which systems fall into this category, and why, is itself valuable: it turns an implicit gap into an explicit, tracked risk decision rather than an unmapped exposure discovered during an audit or incident.

What We’d Actually Recommend

Build a multi-year roadmap with explicit milestones, inventory complete, PQC-capable testbed established, hybrid certificate pilot, rather than a single migration date, since OT’s constraints genuinely do not support a fast, uniform timeline. Prioritize gateway-based protection for equipment with no direct upgrade path, and require crypto-agile features in every new procurement starting now, since equipment bought today without that requirement is a decade-plus liability. Document compensating controls explicitly for systems that cannot migrate on any reasonable timeline, and educate OT engineering staff on what the eventual changes mean operationally, since certificate management and performance characteristics under PQC will be unfamiliar territory for teams used to classical cryptography’s behavior.

How Encryption Consulting Can Help

Firmware trust for PLCs, RTUs, and other field controllers is where CodeSign Secure fits directly, bringing HSM-backed, policy-controlled signing, including hash-based LMS and XMSS schemes suited to long-lived firmware, into environments where a device may run the same firmware image for a decade or more without a straightforward field-update path.

Our PQC Advisory Services build the multi-year, milestone-based roadmap CISA’s guidance recommends, sequencing gateway deployment, procurement policy changes, and compensating controls around your specific safety certification and vendor constraints, rather than applying an enterprise IT timeline to an environment that cannot support one.

A Different Clock, Not a Different Destination

CISA’s own framing is worth taking seriously: OT may genuinely be the last critical infrastructure category to reach post-quantum readiness, and that is a structural reality of long hardware lifecycles and safety governance, not a sign of insufficient urgency. The practical answer is not forcing an IT-speed migration onto equipment that cannot support it; it is crypto-agile procurement going forward, gateway-based protection for equipment that cannot change directly, and explicit, documented compensating controls for the rest. Starting that work now, even on a multi-year timeline, is what separates organizations that are managing this risk deliberately from those that discover their exposure only when a deadline or an incident forces the question.

Frequently Asked Questions

Why does CISA say OT might be the last environment to reach post-quantum readiness?

Because of the combination of long software patching cycles, extended hardware replacement timelines, and strict change-control and safety governance that OT environments operate under, all of which slow migration compared to enterprise IT regardless of urgency.

What is a quantum-safe gateway and when is it the right approach?

A quantum-safe gateway or proxy sits in front of a legacy device that cannot itself be upgraded, handling post-quantum key exchange or signature verification on the device’s behalf. It is the right approach for equipment with no realistic direct upgrade path, letting the legacy device continue operating unchanged while the traffic leaving its network segment gains post-quantum protection.

Why does a cryptographic update sometimes require safety re-certification in OT?

Because some OT systems automate heavy equipment or hazardous processes with complex interdependencies, any software change, including a cryptographic one, can trigger the same extensive safety testing required for any other software update in that environment.

What should organizations require in new OT equipment procurement?

Crypto-agile features specifically: modular cryptographic libraries, firmware update mechanisms that can introduce new algorithms without a hardware refresh, and support for gateway-mediated post-quantum protection. Equipment purchased today without these requirements becomes a long-term liability given typical OT service lifespans.

Are compensating controls an acceptable substitute for direct PQC migration in OT?

For equipment with no realistic upgrade path within any relevant timeframe, yes, as a documented, deliberate interim strategy. Network segmentation, access control, and monitoring reduce exposure for systems that genuinely cannot migrate directly, provided the decision is explicit and tracked rather than an unmapped gap.