How to Protect Systems That Can’t Be Upgraded to Post-Quantum Cryptography

Which systems can’t be upgraded to post-quantum cryptography?

The systems that can’t be upgraded to post-quantum cryptography have cryptography fixed in firmware or hardware, processors too limited for the new algorithms, a vendor that has ended support, or software that cannot change without revalidation. NIST describes the hardest case: in secure boot, “the public key and the program for verifying the signatures are included in the boot code and cannot be updated” (NIST CSWP 39-upd1, updated June 29, 2026).

• Operational technology (OT) controllers and programmable logic controllers (PLCs): firmware changes need a vendor release, testing and a production window. CISA wrote in October 2024 that OT may be “some of the last remaining platforms to achieve post-quantum cryptographic standards.”
• Medical devices on manufacturer validation cycles: the manufacturer controls the software and its validation and regulatory process.
• Building systems: HVAC and access control controllers are vendor-managed and often stay in service far longer than IT equipment.
• Embedded IoT: cameras, sensors and badge readers have small processors and often no update channel.
• Legacy servers and applications with hardcoded cryptography: NIST notes such systems “often have cryptographic functions tightly embedded within their components.”
• Hardware security modules (HSMs) without a PQC firmware path (validated, where FIPS 140-3 applies): the fix is a new module.

How do you find systems that can’t migrate?

Find systems that can’t migrate to PQC through a cryptographic inventory confirmed in writing by each vendor. Network scans miss cryptography compiled into applications, firmware keys and supplier components, so ask each manufacturer which version supports the NIST PQC algorithms, or when support ends. The inventory step in the 2027 budget guide lists the fields to record.

What do NIST, CISA, NCSC and Canada say about systems that can’t migrate?

CISA, Canada’s Cyber Centre and NIST describe containment for systems that can’t migrate. The UK NCSC lists retiring, running to end of life or tolerating the risk. US federal mandates expect replacement and do not mention segmentation.

The sources split on one point. OMB M-26-15 and CNSA 2.0 expect replacement, decommissioning or a waiver. Canada’s roadmap counts systems that are isolated or tunnelled toward its milestones: completing them “implies that quantum-vulnerable algorithms are disabled, isolated or tunnelled.” CISA prioritizes segmentation for legacy OT, and NIST describes crypto gateways and compensating controls. Tolerating the risk (NCSC) works only as an owned, dated decision.

How do you protect a system that can’t be upgraded to post-quantum cryptography?

Protect a system that can’t be upgraded to post-quantum cryptography with five options, usually two or three together: replace or retire it, put a PQC-capable gateway or tunnel in front of it, segment it, reduce the data it handles, or accept the risk until a fixed date.

For cryptographic containment through a gateway or tunnel, Gartner advises CISOs to “plan containment or accelerate the retirement of systems that cannot migrate,” using “encapsulation, cryptographic shims or PQC-protected channels only as governed interim measures” (Gartner research (Elisity reprint), September 17, 2026).

How do you protect devices that cannot be upgraded to post-quantum algorithms?

For devices that cannot be upgraded to post-quantum algorithms, the first option depends on the asset type.

How does network segmentation reduce quantum risk for systems that can’t migrate?

Network segmentation reduces quantum risk for systems that can’t migrate by cutting the paths an adversary can use to reach the system, capture its traffic inside the network, or pivot through it. CISA wrote in October 2024 that “strong OT network segmentation can be particularly effective in mitigating vulnerabilities associated with post-quantum cryptographic compromises by denying attackers access to OT systems.”

1. Map required flows: the hosts, protocols and directions the system needs.
2. Simulate first: see what the policy would block before enforcing it.
3. Enforce default deny at the first managed point where the device connects: a switch port, a wireless controller, a host firewall if the device supports one, or a dedicated gateway. Allow only approved flows, including between peers on the same subnet. Devices sharing an unmanaged switch below that point can still reach each other, so find those first. Keep firewalls for traffic between zones and at the perimeter; enforcement at the connection point covers device-to-device traffic inside a zone, which never reaches the firewall.
4. Keep OT policies static: change them through change control rather than automatically.
5. Record the policy ID in the exception register.

What quantum risks does segmentation leave open?

Network segmentation leaves two quantum risks in place, each with a different fix: recorded traffic and forged signatures. Segmentation limits reachability; it does not repair weak cryptography.

• Confidentiality (harvest now, decrypt later): traffic on permitted paths, including links that leave your network, can be recorded today and decrypted once a cryptographically relevant quantum computer exists. The fixes are a PQC-capable gateway or tunnel, less data and replacement.
• Authenticity (forged signatures): a device that verifies firmware, code or commands with a quantum-vulnerable signature scheme will accept a forgery from an attacker who can break that scheme, whether it arrives over a permitted path, a vendor channel or removable media. Segmentation narrows the network paths, and the device’s verification check stays as weak as before. PQC-signed firmware or replacement is the fix.

In US federal and national security frameworks, segmentation does not satisfy a PQC mandate on its own.

How do these options apply in OT and hospitals?

How does quantum risk affect operational technology (OT) and industrial networks?

In OT, the bigger quantum concern is usually integrity: forged firmware, code or commands. CISA says confidentiality attacks “are not as impactful for OT (vs. IT) communications.” The exception is OT traffic carrying long-lived intellectual property, such as recipes and process data, which is still a confidentiality concern and belongs in a PQC-protected tunnel when it leaves the plant. For equipment that cannot change, CISA prioritizes segmentation (see IT/OT segmentation for manufacturing).

What should a hospital do to prepare for quantum risk to patient data?

A hospital should prepare for quantum risk to patient data by treating it as a long-lived confidentiality problem: records stay sensitive for years, so quantum-vulnerable traffic recorded today can be decrypted later.

1. Inventory every networked medical device.
2. Get a dated PQC roadmap in writing from each manufacturer.
3. Rank devices by the confidentiality lifetime of the patient data they handle.
4. Log each device without a roadmap as an exception with an owner and a replace-by date.
5. Segment each device to the clinical systems it must reach.
6. Tunnel patient-data flows that leave the device segment through a PQC-capable gateway.

Forged firmware or commands on a medical device are a patient-safety risk as well as a privacy one. The medical device security guide covers the groundwork.

What should an exception register for quantum-vulnerable systems record?

An exception register for quantum-vulnerable systems should record each system’s owner, cryptography and use, data lifetime, reason it can’t migrate, containment and replacement date.

Illustrative example; not a real device or customer.

A tunnel can address key exchange; only new firmware or hardware addresses signatures. An entry without a replace-or-retire-by date is a permanent exception.

Which post-quantum migration deadlines apply?

Post-quantum migration deadlines depend on jurisdiction and sector, and every roadmap below runs to 2035.

Data that must stay confidential longer than the time left before a quantum computer can break it is already exposed, because traffic recorded now can be decrypted later.

How much should you budget for systems that can’t be upgraded?

For the whole PQC program, including systems that can’t be upgraded, Gartner says that “currently Gartner’s best estimate is that this is a multiyear effort between now and 2030, with an expected budget impact between 1% and 5% of the total IT budget” (Gartner research (Elisity reprint), September 17, 2026). Give each remedy its own budget line.

Replacement often sits in another department’s capital plan; pull those dates forward. The post-quantum section of the 2027 budget guide covers the full program.

Where does Elisity fit?

Elisity provides identity-based microsegmentation. IdentityGraph correlates device identity and context, and policies are enforced at the network edge through supported switches and wireless controllers. No Elisity software agent runs on the IoT, OT and medical devices it protects, which matters because those devices often cannot be upgraded. Elisity enforces allow-or-deny policy and does not decrypt or alter traffic. Validate infrastructure support, rollout effort and outcome scope in a proof of value. In October 2026, IonQ announced an agreement to acquire Elisity, with closing expected in the fourth quarter of 2026. Elisity said the next phase would extend IdentityGraph with cryptographic inventory and risk information. Elisity does not inventory cryptography today; that comes from crypto discovery tools and vendor attestations. Explore the Elisity platform or ask the Elisity Assistant for the solution brief that fits your environment.

Frequently asked questions

Does network segmentation stop harvest-now-decrypt-later attacks?

Network segmentation does not stop harvest-now-decrypt-later attacks on traffic it still permits. Any quantum-vulnerable session on an allowed path, including links leaving your network, can be recorded today and decrypted later. Pair segmentation with a PQC-capable gateway or tunnel, less data and a replacement date.

Can a PQC gateway protect a device that can’t run PQC?

A PQC gateway protects a device’s traffic from the gateway onward, which NIST CSWP 39-upd1 calls a “crypto gateway” or “bump-in-the-wire.” The link between device and gateway stays exposed, and firmware signatures the device verifies are unchanged. Place the gateway as close to the device as you can. OMB M-26-15 gives the same advice for the firewalls and VPN concentrators that terminate PQC connections.

Do OMB M-26-15 or CNSA 2.0 require segmentation?

Neither OMB M-26-15 nor CNSA 2.0 calls for segmenting systems that cannot migrate. OMB M-26-15 gives them priority for replacement or decommissioning; CNSA 2.0 phases out non-compliant national security equipment by December 31, 2030 unless noted or waived. CISA prioritizes segmentation for legacy OT, and Canada’s roadmap counts isolated or tunnelled Government of Canada systems toward its milestones.

Does a PQC gateway count as migration under OMB M-26-15?

OMB M-26-15 does not describe a PQC gateway in front of a legacy device as a completed migration. It requires firewalls, VPN concentrators, cloud gateways and API proxies that terminate connections to support PQC key exchange, ideally close to the endpoint, and says systems incapable of PQC must be given priority for replacement or decommissioning.

Who should own the exception register?

The CISO’s team should own the exception register for quantum-vulnerable systems. Each entry names a system owner, typically clinical engineering, OT engineering or facilities, who accepts the risk and holds the replacement date. The register should feed the capital plan so each replace-or-retire-by date becomes a budget line.

How long can a system stay on quantum-vulnerable cryptography?

A system should stay on quantum-vulnerable cryptography no longer than the earliest deadline that applies to it. NIST’s draft IR 8547 proposes disallowing quantum-vulnerable public-key algorithms after 2035; OMB M-26-15 sets 2028 to 2030 for key establishment in high-value federal systems; CNSA 2.0 phases out non-compliant national security equipment by December 31, 2030. Long-lived data shortens the window.

Sources

• Canadian Centre for Cyber Security, ITSM.40.001, Roadmap for the migration to post-quantum cryptography, June 23, 2025.
• CISA, Post-Quantum Considerations for Operational Technology, October 2024.
• NIST, CSWP 39-upd1, Considerations for Achieving Crypto Agility, December 19, 2025, updated June 29, 2026.
• UK NCSC, Timelines for migration to post-quantum cryptography, March 20, 2025.
• OMB, M-26-15, Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• NSA, CNSA 2.0 and Quantum Computing FAQ, version 2.1, December 2024.
• NSA, Announcing the Commercial National Security Algorithm Suite 2.0, September 2022.
• EU PQC Workstream, Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, v1.1, June 2025.
• NIST, IR 8547 (initial public draft), November 12, 2024.
• Gartner, CISO Agenda Priority: Transition to Postquantum Cryptography Before It’s Too Late (And Too Expensive), Mark Horvath, Sarah Almond, Thomas Lintemuth, September 17, 2026 (Elisity reprint).

Gartner does not endorse any vendor, product or service depicted in its research publications. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.