What should teams do first when legacy devices cannot support post-quantum crypto?

What should teams change first when old devices cannot run post-quantum crypto?

The first move is to remove unsupported public-key use from the exposed path, not to leave the legacy endpoint negotiating on its own. In practice, that usually means terminating traffic on a modern gateway or proxy that can handle post-quantum or hybrid key exchange, then constraining the legacy device behind it. If that is impossible, teams should shrink the device’s exposure and plan replacement.

For teams managing device and certificate lifecycles, the practical boundary is often the same one described in the Machine Identity, PKI and Certificate Lifecycle Guide, where cryptographic agility depends on being able to move trust handling away from brittle endpoints.

Why the gateway or proxy pattern is the safest first step

A legacy device that cannot support post-quantum or hybrid exchange should not remain the place where modern trust decisions are made. A terminating gateway lets you upgrade the cryptographic posture at the boundary while preserving the device’s business function. That keeps the weakest component from directly handling the most future-sensitive part of the handshake.

This pattern is especially relevant for edge and medical-style devices that cannot be patched quickly, which is why the Medical Device Security Guide is a useful analogue: when a device cannot be made modern in place, teams reduce exposure through architecture, isolation, and compensating controls rather than waiting for an impossible firmware fix.

Where the device still must talk to other systems, the modern gateway also becomes the place to enforce protocol policy, logging, and session limits. That is more reliable than hoping the endpoint will somehow become safe through configuration alone, because the cryptographic weakness is in the device’s capability set, not just in its settings.

What to do when replacement must wait

If the gateway option is not available, the next best move is to reduce the device’s blast radius. Put it on a tightly segmented network, restrict the data it processes, and use short-lived tunnels or equivalent compensating controls so any exposure window is smaller. The goal is to stop unsupported cryptography from persisting on an externally reachable path.

That is the same operational logic used in the Edge Device End of Life Replacement Playbook: reduce exposure first, then replace the device on a controlled schedule. A legacy device may remain in service temporarily, but it should do so with limited reach, limited data, and a clear exception path.

Teams should also treat any compensating control as temporary, not as a substitute for modern cryptography. Segmentation and tunnels lower risk, but they do not make an unupgradable device cryptographically current. If the device handles sensitive traffic, the replacement plan should move from backlog item to active remediation.

Risk and Threat Considerations

The main risk is not just that the legacy device lacks post-quantum support, it is that exposed links can preserve vulnerable public-key use for far longer than teams expect. That creates a future compromise window if traffic is recorded now and decrypted later, or if the endpoint becomes the easiest place to weaken trust in the chain.

Failure mechanism: The device continues to participate in exposed key exchange or certificate-based trust even after the rest of the environment has moved on, leaving a weak boundary that attackers, interceptors, or future cryptanalytic advances can target.

Impact: Confidentiality and trust can fail at the boundary, and the longer the legacy path stays open, the more likely teams are to inherit a hard-to-unwind exposure that affects multiple connected systems.

Practitioner Guidance

What to prioritise: Put the highest-risk boundary first, meaning the link that is most exposed, most sensitive, or most likely to carry long-lived traffic. If you can terminate that path on a modern proxy or gateway, do that before spending time on lower-value compensations.

Decision rule: If the device cannot be upgraded but the surrounding architecture can be changed, prefer boundary termination plus segmentation. If neither is possible, treat continued use as a temporary exception and constrain the device to the smallest possible data set and trust zone.

What to verify: Confirm that the legacy device is no longer directly negotiating unsupported public-key exchange on any reachable interface. Also verify that any tunnel, proxy, or gateway is actually enforcing the stronger mode end to end, not merely advertising it upstream.

Practitioner takeaway: The right first step is architectural containment of the weak crypto path, not attempting to make the legacy device do what it cannot do.

Related resources from NHI Mgmt Group

• How should healthcare security teams reduce identity risk on legacy medical devices that cannot support MFA?
• What should security teams do first if their vendors have not published a roadmap for post-quantum support?
• What should critical infrastructure teams do first when legacy internet-facing devices cannot be fully secured?
• What should organisations do first when legacy applications cannot support automatic rotation?