Post-quantum questions to ask your vendors (OT and VPN)

Post-quantum questions to ask your vendors are a structured set of procurement and assurance questions that test whether a supplier’s products, firmware and services can move from quantum-vulnerable public-key cryptography, such as RSA and elliptic-curve Diffie-Hellman, to standardised post-quantum algorithms such as ML-KEM, and on what verifiable timeline.

For organisations running operational technology (OT) and critical infrastructure, these questions carry more weight than in a typical IT estate. Site-to-site VPNs, remote maintenance access and edge-to-cloud links often depend on equipment that stays in service for well over a decade. On November 5, 2026, CISA, the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) and the National Security Agency (NSA) released joint guidance and an accompanying quick-reference list to help organizations assess vendor readiness for transitioning to post-quantum cryptography (PQC). The guidance notes that cryptography is also embedded in systems and devices that are difficult to update, tied to long asset lifecycles, and require vendor support or replacement, such as industrial control systems and Internet of Things (IoT) devices.

What post-quantum questions should I ask my OT and VPN vendors?

Ask questions that force specific, checkable answers: which algorithms are used where, which product versions will support ML-KEM and when, and what happens to equipment that cannot be upgraded. The joint CISA, ASD’s ACSC and NSA guidance frames this as testing risk awareness, transparency and support for the transition.

According to the three agencies, “effective PQC transition depends on vendor readiness”, and organisations can use the guidance to determine whether a vendor understands quantum-related risks, maintains transparency over its cryptographic implementations, and supports a secure, cost-effective and timely transition to PQC. For OT and VPN suppliers, translate that into four groups of questions.

Transparency about current cryptography

• Which public-key algorithms does the product use for key exchange, authentication, firmware signing and management access (web interface, SSH, SNMPv3, vendor cloud portals)?
• Can you supply a cryptographic bill of materials (CBOM) per firmware version, including the cryptographic library and its version?
• Which of those functions are implemented in hardware acceleration and which in software?

This matters because discovery tools may not be able to identify embedded cryptography used internally within products, hindering discoverability or documentation. For embedded OT controllers and protocol gateways, the vendor is often the only party that knows.

Algorithms, protocols and modes

• Will key establishment use ML-KEM (FIPS 203), and in a hybrid construction with a classical algorithm or standalone?
• Which ML-KEM parameter sets will be supported, and can the operator choose? For reference, NSA has selected two: ML-DSA-87 for signing and ML-KEM-1024 for key establishment under CNSA 2.0.
• For IPsec, which IKEv2 extension carries the post-quantum exchange (for example RFC 9370 multiple key exchanges), and does it interoperate with other implementations?
• Does PQC cover the data plane only, or also the management plane and the remote access client?

Agility and update path

• Can algorithms be changed through configuration or a software update, or are they fixed in hardware?
• Are firmware and update packages signed with algorithms that will themselves be migrated?
• Can updates be applied without a production outage, and how are offline or air-gapped sites served?

Commercial terms

• Is PQC delivered in the existing support contract, or does it require a new licence tier or hardware refresh?
• Will dates be committed in writing, with end-of-support dates for models that will never receive PQC?

How do I know if my existing firewall or VPN gateway will get ML-KEM support?

You only know when the vendor names a specific firmware release for your specific hardware model; a general statement that the product line is “quantum-ready” is not enough. Check hardware headroom, the firmware branch your model is on, and its end-of-support date.

CISA’s federal product list shows that network gear is not yet in the mature group:

Even where products are listed as capable, CISA cautions that most of these categories have implemented PQC for key encapsulation and key agreement but have not yet widely implemented PQC for digital signatures and authentication. Expect the same split in VPN gateways: hybrid ML-KEM key exchange first, post-quantum certificates later.

The following signals help predict whether an installed gateway will be upgraded or replaced:

If your gateway also serves remote users, ask the same question about the client software on Windows and macOS. A gateway that supports ML-KEM gives no protection to sessions whose clients still negotiate classical-only key exchange.

What should a vendor’s post-quantum roadmap include for devices with long lifecycles?

A credible roadmap ties each product model to a dated PQC release, an end-of-support date and a cost, and states how devices already in the field will be handled. It should line up with the deprecation dates in NIST IR 8547.

The dates to anchor on come from NIST’s final transition report:

• NIST IR 8547 (October 2026): NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.
• OMB M-26-15, cited in NIST IR 8547 (October 2026): federal agencies must meet a requirement for high value assets, high impact systems, and other systems with highly sensitive data to transition to quantum-resistant key establishment by December 31, 2030.

NIST explains that “The 2030-2035 deprecation window accommodates lower-risk systems and applications with legacy constraints while full migration concludes.” For OT, that window is short. CISA’s OT guidance warns that safety compliance, auditing, or other validation requirements may also create situations where OT platforms are subject to significantly extended lifetimes when compared to IT.

Ask that each roadmap covers, at minimum:

• Per-model status: PQC-capable now, PQC planned (with release and quarter), or never.
• Which functions migrate in which order: key establishment, authentication certificates, firmware signing, management interfaces.
• Interoperability testing against other vendors’ implementations, since site-to-site tunnels often cross vendor boundaries.
• Requalification impact: whether the update changes safety or validation status and what testing the operator must repeat.
• Cost, in line with the CISA, NSA and NIST advice that an organization’s quantum-readiness roadmap should include details of when and how each COTS vendor plans to deliver updates or upgrades to enable the use of PQC, as well as the expected cost associated with migration to PQC.

For new purchases, CISA is explicit: “OT owners and operators should request crypto-agile features in ICS equipment acquisitions”. Write that into tender requirements so the next device generation does not repeat the problem.

What if an OT vendor has no plans to support post-quantum cryptography?

Treat the device as a fixed risk and protect the paths around it: keep it off untrusted networks, wrap its traffic in a quantum-safe tunnel at the network layer, and schedule its replacement. Record the decision rather than leaving it as an open question.

CISA’s OT guidance recommends minimizing OT exposure to quantum threats via strong OT network segmentation, using quantum-resistant algorithms where appropriate, ensuring crypto-agility in applications and protocols, and applying quantum mitigation considerations to platform update schedules and upgrade lifecycles. In practice that means three parallel tracks.

Contain the device

Many PLCs, RTUs and historians communicate with no encryption, or with classical TLS that cannot be upgraded. The quantum exposure is mainly where that traffic leaves the site: links to control centres, cloud historians and vendor remote access. Keep the device’s own protocols local and limit what crosses site boundaries.

Protect the transport around it

A separate encryption gateway at each end of an inter-site link can add post-quantum key establishment without touching the device. Quantum Network’s QPN gateway is one example of this approach: it encrypts at Layer 3 with a hybrid key agreement that combines a classical part and ML-KEM (FIPS 203) into one session key, requires no software on the equipment behind it, and sits alongside the existing firewall. This protects data in transit only; it does not make the OT device itself quantum-resistant, and the device’s local authentication and firmware signing remain the vendor’s responsibility.

Use contract and lifecycle levers

Ask the vendor for a written statement that no PQC support is planned and for the end-of-support date. Use that statement to justify accelerating replacement budgets, and add PQC capability as a mandatory requirement in the replacement tender.

How do I document vendor PQC readiness for my migration plan?

Keep a vendor PQC readiness register that links each asset in your cryptographic inventory to the vendor’s written answers, the evidence behind them and a decision. Update it at every contract renewal, as the joint guidance recommends.

The NIST NCCoE describes a CBOM as a list of all the cryptographic algorithms, libraries, and protocols used in a system or application. Request one from each vendor and attach it to the register. A workable register has these fields:

Prioritise using the factors CISA lists for OT, including does the system support a critical infrastructure sector? and how long does the data need to be protected? Map each decision date to the 2030 and 2035 milestones in NIST IR 8547.

Finally, use the register to shape purchasing. On the release of CISA’s product categories list, Acting Director Madhu Gottumukkala said: “To stay ahead of these emerging risks, organizations must prioritize the procurement of PQC-capable technologies.” A register that shows which vendors gave dated, verifiable answers turns that principle into concrete supplier choices.