Quantum-safe VPNs: what to ask vendors

Short answer: A VPN's bulk encryption is not the main quantum risk. The weak point is the key exchange that sets up the tunnel, which usually relies on RSA or elliptic-curve cryptography that Shor's algorithm would break on a large enough quantum computer. When buying or renewing a VPN, ask vendors where public-key cryptography sits in the product, whether they support hybrid key exchange with ML-KEM (FIPS 203), and what their migration timeline and rollback plan are.

Understanding the Cryptographic Dependencies

The foundation of a secure VPN lies in its ability to establish a shared secret between endpoints. Historically, this has been achieved through public-key algorithms such as RSA or Elliptic Curve Diffie-Hellman. However, these methods are susceptible to quantum computing attacks, specifically Shor’s algorithm, which can efficiently solve the mathematical problems underlying their security. The recent finalization of NIST standards has provided a clear path forward, identifying specific algorithms that are resistant to such threats. Among these, FIPS 203, known as ML-KEM or Kyber, is particularly critical for VPN architectures. It is designed to agree on a shared secret at the start of a connection, effectively securing the handshake phase of the tunnel establishment.

Organizations must ask vendors to identify exactly where public-key cryptography is embedded in their products. It is not sufficient to know that a product uses "modern encryption"; one must understand the specific role of asymmetric cryptography in the key exchange process. Vendors should be able to articulate which components of their stack rely on algorithms that are now considered insecure in a post-quantum world. Furthermore, they should explain how their products handle the transition from legacy algorithms to new ones. This includes understanding whether the vendor supports hybrid modes, which combine classical and post-quantum algorithms to provide security during the migration period. By mapping these dependencies, organizations can identify the specific points of vulnerability in their supply chain and prioritize remediation efforts accordingly.

Assessing Transition Planning and Risk

A vendor’s readiness for the post-quantum transition is best judged by the clarity and rigor of their migration strategy. Organizations should inquire about the vendor’s risk assessment processes, specifically how they evaluate the impact of algorithm changes on performance, interoperability, and security. Transition planning should not be an afterthought but a core component of the product roadmap. Vendors should be able to describe their timeline for implementing post-quantum features, including any phased rollouts that allow for gradual adoption.

Risk assessment in this context involves more than just swapping one algorithm for another. It includes evaluating the computational overhead of post-quantum operations. Some published measurements suggest that the performance overhead of post-quantum key exchange can be manageable in practice. Overhead still depends on the implementation and hardware, so vendors should provide data specific to their own products. Organizations should ask for benchmarks that demonstrate the impact of post-quantum key exchange on connection setup times and throughput. Additionally, vendors should outline their approach to managing risks during the transition, such as the potential for interoperability failures if peers have not yet upgraded. A robust transition plan will include rollback procedures and clear communication protocols to ensure that all parties in the network can coordinate the migration safely.

Implementation Approaches and Hybrid Modes

The implementation of post-quantum cryptography in VPNs often involves hybrid key exchange, where both a classical algorithm and a post-quantum algorithm are used simultaneously to establish a shared secret. This approach provides a layer of security during the transition period, ensuring that the connection remains secure even if one of the algorithms is compromised. ML-KEM, standardized as FIPS 203, is the primary post-quantum algorithm used in these hybrid deployments. It is based on the hardness of the Module Learning With Errors problem, a mathematical challenge believed to be difficult for both classical and quantum computers.

Vendors should be asked to detail their implementation of hybrid key exchange. This includes understanding how they combine the outputs of the classical and post-quantum algorithms to derive the final shared secret. They should also explain how they handle key encapsulation, where the client generates a keypair and the server responds with a ciphertext that allows the client to derive the shared secret. Furthermore, organizations should inquire about the vendor’s support for other post-quantum standards, such as FIPS 204 (ML-DSA) for digital signatures and FIPS 205 (SLH-DSA) as a backup signature method. While ML-KEM is most relevant for the key exchange in VPNs, the ability to sign software and prove identity using post-quantum signatures is also a critical component of a fully quantum-safe ecosystem. Vendors should demonstrate that their products can operate in hybrid modes and provide clear guidance on when and how to enable these features.

Communication and Supply Chain Coordination

The transition to post-quantum cryptography is not a unilateral action; it requires coordination across the entire supply chain. Organizations must ensure that their vendors are prepared to communicate effectively throughout the transition process. This includes providing clear documentation on the post-quantum capabilities of their products, as well as guidance on how to configure and test these features. Vendors should be willing to engage in dialogue with their customers to understand specific requirements and constraints, such as legacy system compatibility or performance targets.

Moreover, vendors should be transparent about their own supply chain dependencies. If a vendor’s product relies on third-party libraries or components for cryptographic operations, they should be able to identify those dependencies and confirm that they are also transitioning to post-quantum algorithms. This holistic view of the supply chain is essential for ensuring that no weak links remain in the security posture. Organizations should ask vendors about their communication plans, including how they will notify customers of updates, deprecations, and security advisories related to the post-quantum transition. Effective communication ensures that organizations can make informed decisions about their own migration timelines and can coordinate with their vendors to minimize disruption. By fostering open and transparent communication, organizations can build confidence in their vendors’ ability to deliver quantum-safe solutions that meet their specific needs.

FAQ

Is VPN traffic encryption itself at risk from quantum computers?

The bulk encryption of data in transit uses symmetric algorithms, which remain secure under current assumptions. The exposure is in the public-key key exchange used to establish the tunnel.

What is hybrid key exchange in a VPN?

It combines a classical algorithm and a post-quantum algorithm, such as ML-KEM (FIPS 203), to derive the shared secret. The connection stays secure as long as at least one of the two algorithms holds.

What should I ask a VPN vendor about post-quantum support?

Ask where public-key cryptography is used in the product, whether hybrid key exchange is supported, which post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) are on the roadmap, and what the timeline and rollback procedure are.

Does post-quantum key exchange slow VPNs down?

Some published measurements suggest the overhead can be manageable, but it depends on the implementation and hardware. Ask the vendor for benchmarks of connection setup time and throughput for their own product.

Why does the vendor's supply chain matter?

If a product relies on third-party cryptographic libraries, those libraries also need to move to post-quantum algorithms. Ask the vendor to identify those dependencies and how they will communicate updates and advisories.