Post-quantum requirements procurement OT: what to ask?

Post-quantum requirements in OT procurement are the contract and specification clauses that make a supplier deliver, and keep delivering, encryption that resists future quantum attacks. They cover algorithms, crypto-agility, support periods and update duties. For equipment that will run for decades, they decide whether connections between sites, cloud and remote users stay protected after classical public-key cryptography is phased out.

The timing problem is simple. A switch, RTU gateway or encryption appliance you buy in 2026 could still be in service in 2045. In that time, regulators and standards bodies expect classical key exchange to be retired. Your tender has to deal with that gap today, because once the purchase order is signed you have far less leverage.

What quantum-safe encryption requirements should be in an OT equipment tender?

A good tender asks for hybrid key establishment using ML-KEM, strong authenticated symmetric encryption, a defined way to fail safely, and proof that the cryptography can be replaced without replacing the device. Each requirement should be testable at acceptance, not just stated in a brochure.

Key establishment

Require hybrid key agreement, where a classical algorithm and a post-quantum algorithm are combined into one session key. This follows EU policy. Commission Recommendation (EU) 2024/1101 calls for deploying post-quantum cryptography in existing public administration systems and critical infrastructures via hybrid schemes that may combine it with existing cryptographic approaches. Name ML-KEM and the parameter set explicitly. Don’t settle for a vague phrase like “quantum-resistant”.

Data in transit

Specify authenticated encryption for the payload, with integrity checking on every packet, and set a maximum key lifetime or rekey interval. Ask suppliers to say at which network layer they encrypt. Layer 3 encryption covers all traffic above it, including industrial protocols that have no security of their own.

Failure behaviour and OT constraints

OT links break: radio backhaul drops, and leased lines fail. The tender should require that a connection never falls back to unencrypted traffic, and that it recovers automatically without someone having to go on site. Also ask for operation without cloud dependency or outbound telemetry where your sites are segmented or air-gapped, and set limits on latency overhead for control traffic.

Which standards should a procurement specification point to for post-quantum algorithms?

Point to FIPS 203 for the algorithm, to NIST IR 8547 and the EU roadmap for timelines, and to IEC 62443-4-1 and IEC 62443-2-4 for how suppliers develop, patch and maintain the product. Together they define what to build, by when, and under which process.

FIPS 203 is the anchor. NIST published it on 13 August 2024, and it specifies three parameter sets for ML-KEM: in order of increasing security strength and decreasing performance, ML-KEM-512, ML-KEM-768 and ML-KEM-1024.

The timelines are now specific enough to put into a contract:

• NIST IR 8547 (November 2024 draft): 112-bit security strength algorithms are deprecated after 2030 and disallowed after 2035.
• European Commission (June 2025): the protection of critical infrastructures should be transitioned to PQC as soon as possible, no later than by the end of 2030.
• EU roadmap milestones: national PQC roadmaps by 31/12/2026, and by 31/12/2035 all of the migrations should be completed.

How do you require crypto-agility from suppliers of devices with a 20-year lifespan?

Define crypto-agility as a capability you can test: algorithms and parameter sets that can be replaced through a signed update or configuration change, without new hardware and without changing the network design. Then require the supplier to show it before you award the contract.

EU policy already expects this. The NIS Cooperation Group roadmap, according to the European Commission’s Joint Research Centre, also recommends hybrid and crypto-agile approaches. The same roadmap foresees that, by 2030, quantum-safe software and firmware upgrades are enabled by default.

For long-lived OT assets, turn agility into four concrete tender requirements:

• Algorithm replacement demonstration: during evaluation, the supplier switches the post-quantum algorithm or parameter set on a test unit and shows that the connection comes back up.
• Hardware headroom: a statement of CPU, memory and storage reserve for larger keys and future algorithms. ML-KEM keys and ciphertexts are much larger than elliptic-curve equivalents.
• Cryptographic inventory: a list of every algorithm, library and protocol in the product, kept up to date for the life of the contract.
• Update signing that is itself upgradable: if firmware signatures use classical algorithms only, the update channel becomes the weak point once those algorithms are retired.

Be realistic about embedded devices. In a comment on NIST guidance about long-lived SCADA and ICS assets, the U.S. Department of Energy warned that “upgrading embedded devices with PQC after installation may not be feasible.” Where a field device cannot meet the agility requirement, specify quantum-safe gateways at each end of the links it depends on. That way the connection is protected even if the endpoint is not.

How do the Cyber Resilience Act’s essential requirements affect what you can ask from network equipment suppliers?

The Cyber Resilience Act (Regulation (EU) 2024/2847) turns support periods, vulnerability handling and security updates into legal duties for manufacturers. That gives buyers a legal floor to build on. The Act does not prescribe post-quantum algorithms, so you still have to specify those yourself.

When the Act entered into force, Commission Executive Vice-President Henna Virkkunen called it “a major step forward in ensuring digital products in the EU do not pose cyber risks”. For procurement, the relevant provisions are in Article 13 and Cyber Resilience Act Annex I:

• Support period: the support period shall be at least five years, and its end date (including month and year) must be clearly specified at the time of purchase.
• Update availability: each security update must remain available for a minimum of 10 years or for the remainder of the support period, whichever is longer.
• Longer lifetimes: the recitals note that products intended for industrial settings, such as industrial control systems, are often in use for significantly longer periods of time.
• Timing: the CRA will be fully applicable as of 11 December 2027, with reporting obligations under Article 14 applying from 11 September 2026.

In practice, this means you can ask for the support period end date in the bid and score it. You can also ask how the supplier’s risk assessment deals with the quantum threat over that period, since Article 13 requires the assessment to consider how long the product is expected to be in use. One caveat: products placed on the market before 11 December 2027 are subject to the CRA only if they later undergo a substantial modification. For stock already on the market, your contract has to carry the full load.

How do you make suppliers responsible for future post-quantum firmware updates in the contract?

Write post-quantum migration in as a deliverable with a date, an acceptance test and a remedy if it is missed. Then decide upfront how it is paid for, so that the update cannot be held back later as a separate purchase.

Clauses worth including

• Migration obligation: the supplier delivers firmware that removes or disables classical-only key establishment before a fixed date in line with the 2030 EU milestone, at no extra cost within the support period.
• Standards tracking: if NIST or EU guidance deprecates an algorithm the product uses, the supplier provides a replacement within an agreed number of months.
• Process evidence: the supplier’s development and update management follow IEC 62443-4-1. System integrators and maintainers meet IEC 62443-2-4, with audit rights for the buyer.
• Remedies: service credits, a right to terminate, or a right to have the update delivered by a third party (including a code escrow trigger) if a migration milestone is missed.
• Subscription transparency: if updates depend on a paid subscription, the bid must say what happens to security and algorithm updates when the subscription ends.

That last point matters, because update models differ. Quantum Network’s Quantum Gateway, for example, ties automatic updates of algorithms and software to an active subscription. Physical gateways are leased together with the subscription and returned at the end of the contract. Knowing this at tender stage lets you budget subscription terms for the full asset lifetime.

Linking it to NIS2

For essential and important entities, NIS2 Directive Article 21(2)(d) requires supply chain security measures, including attention to the security practices of direct suppliers. Contract clauses on post-quantum updates are a concrete way to put that duty into practice for network equipment. ENISA, which supports the NIS Cooperation Group’s PQC work, is a useful reference for guidance as national roadmaps take shape.

Above all, keep in mind that updates are where most of the work lies. As NIST puts it, “Cybersecurity products, services, and protocols will need updates”, and organisations must find where vulnerable algorithms are used and plan to replace them. A tender that only buys post-quantum capability today, without contractual update duties, leaves you to solve the next migration on your own.