Post Quantum Migration of VPN and IPsec: How to protect your tunnels today?

What post quantum migration is?

Post quantum migration of VPN and IPsec is the process of making the encrypted tunnels that protect network traffic resistant to future quantum computers. The tunnels that link sites and remote users today are built on IPsec, set up by the IKEv2 protocol, which uses classical public key cryptography for its key exchange, exactly the kind of cryptography a powerful quantum computer could one day break.

The reassuring part is that tunnels can be protected today, without waiting for every algorithm to be replaced and without a large quantum computer needing to exist yet. Standardized techniques already let IKEv2 resist quantum attacks, and they are designed to be adopted gradually alongside the classical cryptography already in use.

Two methods do most of the work, and they can be combined. Post-quantum preshared keys, defined in RFC 8784, mix an extra shared secret into the key derivation. Hybrid key exchange, defined in RFC 9370, performs several key exchanges at once, combining a classical method with a post-quantum KEM such as ML-KEM. The rest of this page explains why this is urgent now, how the two standards differ, what they mean for performance and the installed base, and how to plan the migration.

Harvest now, decrypt later

The reason to act before quantum computers arrive is a threat known as harvest now, decrypt later. It changes the timeline of the risk, and it is what makes post quantum migration a present concern rather than a future one.

RFC 8784 and RFC 9370 compared

Two IETF standards let IKEv2, the protocol that establishes IPsec tunnels, resist quantum attacks. They work differently and can be combined for defense in depth. The table sets them side by side.

Performance and compatibility

Post quantum protection is real and available, but it is not free of practical trade-offs. Understanding them is what turns a good intention into a migration that works in production without surprises.

On performance, adding multiple or post-quantum key exchanges introduces overhead and can slow the IKEv2 negotiation, and post-quantum algorithms have larger key sizes and payloads, which can lead to fragmentation. None of this affects a tunnel’s steady state throughput as much as its setup, but on constrained devices or high volumes of tunnels it should be measured rather than assumed, so capacity is planned realistically.

On compatibility, both ends of a tunnel must support the same methods to use them, and not every device in an existing installed base can necessarily be upgraded to the new standards. IKEv2 offers backward compatibility, so a tunnel can fall back to classical cryptography if a peer cannot yet support the post-quantum features, which allows a gradual rollout. The practical consequence is that migration is planned around the installed base: identifying which devices can be upgraded, where preshared keys are the pragmatic first step, and where hybrid key exchange can be introduced.

Planning a phased migration

Post quantum migration is not a single switch but a planned, phased process. A clear sequence lets an organization gain protection where it matters most, while managing performance and compatibility along the way.

Quantum resistant VPN and Teldat

Post quantum migration is fundamentally about IPsec tunnels and IKEv2, which sit at the core of SD-WAN, so it is directly relevant to a network manufacturer. Teldat approaches it from a European base, with central management to make a phased migration workable.

FAQ’s about post quantum VPN migration

❯ What is post quantum migration of VPN and IPsec?

Post quantum migration of VPN and IPsec is the process of upgrading the encrypted tunnels that protect network traffic so they resist future quantum computers. Today, IPsec tunnels set up with IKEv2 rely on classical public key cryptography for their key exchange, and a sufficiently powerful quantum computer could break that cryptography, exposing the traffic. Migration means adding quantum resistant techniques to the key exchange so the tunnel stays secure even against a quantum adversary. It can be done today using standardized methods, without waiting for a full replacement of every algorithm: post-quantum preshared keys defined in RFC 8784, and hybrid key exchange with a post-quantum KEM defined in RFC 9370. The goal is to protect the confidentiality of tunnelled data both now and in the future.

❯ What is the harvest now, decrypt later threat?

Harvest now, decrypt later is the reason post quantum migration is urgent even though large quantum computers do not yet exist. The idea is simple: an attacker captures and stores encrypted traffic today, then waits, and once a cryptographically relevant quantum computer becomes available, decrypts the stored data. This means any information with a long confidentiality lifetime, records that must stay secret for years or decades, is effectively at risk right now, because it may be being harvested today for future decryption. It is why organizations are advised not to wait until quantum computers arrive but to begin protecting long lived data immediately. For VPN and IPsec, it means the tunnels carrying sensitive traffic should be made quantum resistant as soon as practical.

❯ What are RFC 8784 and RFC 9370?

RFC 8784 and RFC 9370 are two IETF standards that let IKEv2, the protocol that sets up IPsec tunnels, resist quantum attacks, and they can be used together. RFC 8784, from 2020, defines a way to mix a post-quantum preshared key, sometimes called a PPK, into the IKEv2 key derivation, adding entropy from a shared secret so the resulting keys are protected even if the classical key exchange is later broken. RFC 9370, from 2023, extends IKEv2 to perform multiple key exchanges at once, so a classical method such as ECDH can be combined with a post-quantum KEM like ML-KEM; the shared key is formed so that an attacker would have to break every exchange, meaning that as long as one component is quantum resistant, the tunnel is quantum safe. Preshared keys and hybrid key exchange can also be layered together for defense in depth.

❯ What is the impact of post quantum VPN on performance and compatibility?

Post quantum techniques bring real benefits but also practical considerations that shape how migration is planned. On performance, using multiple or post-quantum key exchanges adds overhead and can slow the IKEv2 negotiation, and the larger key sizes and payloads of post-quantum algorithms can cause fragmentation, so the impact on throughput and setup time should be tested. On compatibility, not every device in an installed base can necessarily be upgraded to support the new standards, and both ends of a tunnel must support the same methods to use them; IKEv2 provides backward compatibility so a tunnel can fall back if a peer cannot support the post-quantum features. This is why migration is usually phased: prioritizing the tunnels that protect the most sensitive, long lived data, testing performance, and using preshared keys where they fit while introducing hybrid key exchange as the installed base allows.

❯ How does Teldat approach post quantum VPN migration?

Teldat is a European manufacturer of networking and SD-WAN, where IPsec tunnels are central, so quantum resistant VPN is directly relevant to its portfolio. Teldat SD-WAN builds secure IPsec tunnels between sites, managed centrally through the CNM platform, which is the layer where post quantum protections for IKEv2, such as preshared keys under RFC 8784 and hybrid key exchange under RFC 9370, apply. Central management helps a phased migration, letting an organization prioritize the most sensitive tunnels, manage compatibility across the installed base and roll out changes in a controlled way. As a European manufacturer under European jurisdiction, Teldat also supports the digital sovereignty goals that matter for the long term confidentiality of sensitive data. Because post quantum standards and product support evolve quickly, the specific algorithms, RFC support and quantum resistant capabilities available should always be verified with Teldat for a given product and software version.