PQC Migration Handbook AIVD TNO CWI: how do I apply it?

The PQC Migration Handbook is Dutch government guidance, written by the AIVD, TNO and CWI, that helps organisations move from quantum-vulnerable public-key cryptography to quantum-safe (post-quantum) cryptography. It sets out a risk-based diagnosis, an inventory and planning phase, and an execution phase. Its main use is deciding which systems need to move first.

For organisations that run operational technology (OT) and critical infrastructure, the hardest questions are practical ones: which inter-site VPNs, cloud uplinks and remote-access paths to tackle first, and how to justify that order to a board and a regulator. This article applies the handbook to exactly those connections.

What is the Dutch PQC Migration Handbook and who published it?

It is a joint publication by the AIVD (General Intelligence and Security Service of the Netherlands), the research organisation TNO and CWI (Centrum Wiskunde & Informatica). The current version is the revised and extended second edition from December 2024.

The first edition appeared in 2023. The government published the Dutch edition, Het PQC-migratiehandboek, as a report dated 2 December 2024. In January 2025 Minister Uitermark (BZK) sent the renewed handbook to the Tweede Kamer with a covering letter. Within the AIVD, the expertise comes from the Netherlands National Communications Security Agency (NLNCSA, Dutch NBV). TNO and CWI bring applied research and cryptographic science.

The handbook is aimed at the Dutch government, businesses, vital sectors and knowledge institutions that handle sensitive encrypted information. The AIVD and the Nationaal Cyber Security Centrum (NCSC) also published a shorter companion guide, Make your organisation quantum secure, which works out the first steps in more detail for CIOs, CTOs and CISOs.

How does the PQC Migration Handbook decide which systems should migrate first?

It does not use a fixed sector list. Instead, a diagnosis estimates how urgently each organisation and system must migrate, based on the type of information processed, the systems in use and dependencies on other organisations.

The method has three phases. First, a PQC diagnosis assesses data handling and risk exposure. Second, an inventory records the cryptographic assets in use, the data they protect and who manages them. Third, a migration plan is executed, with explicit care not to introduce new risks along the way. Researchers who analysed the framework note that the handbook expects the transition to be time- and resource-intensive.

The AIVD and NCSC sum up the logic in their companion guide: “The urgency and required speed of migration depends on an organisation’s risk profile and its risk appetite.”

For connections, three questions from the diagnosis carry most of the weight:

• Confidentiality lifetime: traffic captured today could be decrypted once a cryptographically relevant quantum computer exists. Network diagrams, engineering files, protection settings and asset data often stay sensitive for many years.
• System lifetime: a gateway or remote terminal unit that stays in service for a long time will still be running when the quantum threat becomes real, so it has to be migrated or isolated in time.
• Dependencies: if a link relies on a supplier’s firmware, a cloud provider’s endpoint or an integrator’s remote-access path, your timeline depends on theirs.

How do you apply the handbook’s migration personas to VPN gateways and OT links?

The handbook offers tools for different personas. At one end are early or urgent adopters, who must act before quantum-safe cryptography is fully standardised and widely available. At the other end are regular adopters, who can wait until it is. Place each connection under a persona, then plan accordingly.

The NCSC’s TLS Security Guidelines (version 2025-05) put the same split into operational terms. If your risk analysis shows no urgent risk, you can wait until quantum-safe algorithms are part of standard protocols and libraries. If you are already at significant risk, build up expertise and deploy hybrid key exchange now.

Why the tunnel is often the first place to act in OT

In OT, the equipment behind a link is often the hardest thing to change. Programmable controllers, protection relays and legacy HMIs frequently cannot run new cryptographic libraries, and changing them can mean recertification or downtime. Protecting the connection at the network layer, at both ends of the path, separates the migration of the link from the lifecycle of the devices.

That is the design principle behind Layer 3 gateways such as Quantum Network’s QPN. A gateway sits at each end of the connection and installs no software on the equipment behind it. It sits alongside existing firewalls and routers, and a few routes are added or adapted to bring it in. Note what such a gateway does not do: it protects data in transit, not the devices behind it. It also does not replace firewall inspection, filtering or denial-of-service defences.

Mapping the inventory to the personas

For each link in the inventory, record four facts: the current key exchange (for example, classical Diffie-Hellman or RSA), the owner, whether the algorithm can be replaced without new hardware, and whether the path crosses networks you do not control. Links that use classical key exchange over third-party networks and protect long-lived OT data are urgent-adopter material.

What does the PQC Migration Handbook recommend about hybrid key exchange and crypto-agility?

For organisations that cannot wait, the handbook points to hybrid solutions, which combine established classical cryptography with post-quantum algorithms. It also treats crypto-agility, the ability to replace algorithms quickly, as a core design requirement.

The companion guide advises that organisations with very high urgency should consider hybrid solutions today and refers to chapter 4.1 of the handbook. The reasoning: if a newer post-quantum algorithm turns out to have a weakness, the classical component still provides today’s level of security, and vice versa. European policy takes the same line. Commission Recommendation (EU) 2024/1101 foresees PQC entering critical infrastructures through hybrid schemes. The Joint Research Centre also observes that in Europe hybrid deployment is widely seen as the more conservative choice.

On crypto-agility, the NCSC is direct: “Make sure that your configuration and the cryptographic algorithms used are easy to replace (crypto-agility).” For connection infrastructure, this means three concrete checks during procurement and design:

• Can the post-quantum algorithm be swapped through a software update, without replacing hardware at remote sites?
• Who delivers those updates, under what contract, and what happens to the device if support ends?
• Does the design ever fall back to weaker or unencrypted operation when a link fails?

Here is how one implementation answers those questions. In QPN, a classical part and a post-quantum part (ML-KEM, standardised in FIPS 203) are combined into one session key, and both handshakes renew every two minutes. The post-quantum algorithm can be changed if needed. Without an active subscription, however, the gateway keeps running in its current state but receives no further security updates. Contract terms like these belong in the crypto-agility section of your migration plan.

How does the handbook relate to NIS2 obligations under the Dutch Cyberbeveiligingswet?

The Cyberbeveiligingswet (Cbw) implements the NIS2 Directive (EU) 2022/2555 in the Netherlands and took effect on 15 August 2026. It does not mention the handbook, but its duty of care requires a risk analysis and cryptography policies, and the handbook offers a structured way to fill in both for the quantum threat.

Key facts about the law:

• The Cbw applies to more than 8,000 organisations providing essential or important services (NCSC, 2026).
• It covers 18 sectors, including energy, drinking water, digital infrastructure, health care, government and transport (Rijksoverheid, 7 July 2026).
• The original transposition deadline was 17 October 2024. The Netherlands missed it, and the law entered into force on 15 August 2026 (NCSC FAQ, 2026).
• After a significant incident, a first notification is in most cases due within 24 hours (RVO, 2026).

The Cbw replaces the Wet beveiliging netwerk- en informatiesystemen (Wbni). Its obligations include registration with the NCSC, a duty of care, incident reporting, board accountability and supply-chain risk management. One of the listed duty-of-care measures covers policies and procedures on the use of cryptography and, where appropriate, encryption, which mirrors Article 21 of the NIS2 Directive. The Dutch Minister of Justice and Security, David van Weel, framed the law in terms of continuity: “Whether it concerns digital threats, sabotage, natural disasters or other disruptions: organisations must be prepared for risks that can affect the continuity of essential services” (translated from Dutch).

Where the EU timeline comes in

Separately from the Cbw, EU Member States adopted a Coordinated Implementation Roadmap for the transition to PQC in June 2025. According to the European Commission, Member States should start transitioning by the end of 2026. High-risk use cases should move to PQC as soon as possible, and no later than the end of 2030 (European Commission, 2025). The roadmap’s own examples of high-risk use cases include critical infrastructure such as water, energy and transport.

In practice, the handbook’s diagnosis gives a board the evidence it needs. It shows which links were judged urgent and why, what was inventoried, and how algorithm replacement is guaranteed. Under the Cbw, the board is accountable for cyber risk management, so a documented quantum risk analysis per connection is a reasonable thing to put in front of it. Be careful with claims, though: following the handbook does not in itself demonstrate Cbw compliance. Supervisors will look at the overall risk management, not at any single guidance document.

What should an OT operator do in the next planning cycle?

Run the diagnosis per connection and finish the inventory before buying anything. Then start with the links that score urgent on data lifetime, system lifetime and supplier dependency.

A workable sequence looks like this:

1. Map every connection between sites, cloud environments and remote users, including supplier access paths that bypass the corporate VPN.
2. Score each link with the handbook’s diagnosis and assign a persona.
3. For urgent links, specify hybrid key exchange and confirm that the algorithm can be replaced through updates.
4. For regular links, add crypto-agility requirements to the normal replacement cycle.
5. Record the decisions in the Cbw risk analysis and cryptography policy, and review them when the handbook or the EU roadmap is updated.

The order matters. An inventory built before procurement stops urgent links from being missed. It also stops regular links from soaking up budget that should go to the control-centre and field connections first.