Quantum-Safe VPN Remote Access and Zero Trust for European Organisations

A quantum-safe VPN with zero-trust network access (ZTNA) is a remote-access architecture that replaces classical Diffie-Hellman and RSA key exchanges with post-quantum key encapsulation mechanisms, enforces continuous identity and device-posture verification, and routes all traffic exclusively through infrastructure under the organisation’s jurisdictional control. For European public-sector and regulated organisations, this combination addresses two converging threats: the immediate risk of credential-based intrusion and the longer-horizon risk of retroactive decryption of captured traffic.

Why Classical VPNs Are Already Compromised in Transit

Conventional IPsec and TLS VPNs rely on key exchanges that Shor’s algorithm can break on a sufficiently powerful quantum computer. Sessions encrypted today are already collectable by well-resourced adversaries.

The attack model is known as “harvest now, decrypt later.” A state-level or well-funded adversary captures encrypted VPN sessions in bulk, stores them at low cost, and decrypts them retrospectively once quantum hardware matures. This is not speculative: the NSA’s PRISM programme and bulk-collection authorities under FISA 702 demonstrate that large-scale interception of in-transit data is an established practice, not a theoretical one. For data with a sensitivity lifetime of five to fifteen years, such as patient records, legal files or classified procurement data, the window of exposure begins the moment the first packet leaves the gateway.

Classical IKEv2 and TLS 1.3 use ephemeral Elliptic Curve Diffie-Hellman (ECDH) for forward secrecy within a session, but the session keys themselves are protected only by classical asymmetric cryptography. Once ECDH is breakable, forward secrecy provides no retroactive protection against a recorded session.

What Makes a Quantum-Safe Gateway Architecturally Different

A quantum-safe gateway replaces or augments the classical key exchange with a post-quantum key encapsulation mechanism (KEM), so that even a future quantum computer cannot reconstruct the session key from recorded traffic.

NIST finalised FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) in August 2024, making it the first standardised post-quantum KEM. ML-KEM-768 is the recommended security level for most government and enterprise use cases, offering roughly 180-bit quantum security. NTRU is an older lattice-based alternative with a longer academic history, though NIST did not select it as a primary standard; it remains available in some implementations as a fallback option.

Both BSI and ANSSI explicitly recommend hybrid key exchange during the transition period: pairing a classical ECDH group (Curve25519 or NIST P-256) with ML-KEM in the same IKEv2 negotiation. This ensures that if the PQC implementation contains an as-yet-undiscovered flaw, the classical component still provides baseline security. BSI Technical Guideline TR-02102-3 specifies approved algorithm combinations for IPsec and IKEv2, and its current edition includes hybrid PQC recommendations aligned with FIPS 203.

As ANSSI states in its post-quantum position paper: “The use of hybrid mechanisms, combining classical and post-quantum algorithms, is recommended as a transitional measure to ensure security against both classical and quantum adversaries.”

Production-Ready Implementations

StrongSwan, the open-source IKEv2/IPsec stack widely used in European public-sector deployments, supports ML-KEM hybrid key exchange from version 5.9.x onwards through its liboqs integration. This makes it one of the most mature production options for organisations that cannot wait for commercial appliance vendors to ship PQC support. WireGuard, which uses a fixed modern cryptographic handshake (Curve25519, ChaCha20-Poly1305), does not natively support PQC, but a research extension called “WireGuard with PQC” (sometimes called PQWG) grafts a Kyber/ML-KEM layer onto the handshake. This extension is not yet in mainline WireGuard and should be evaluated carefully before production deployment; it is better suited to organisations willing to run a monitored pilot than to those requiring a stable, audited baseline today.

Designing ZTNA for Travelling and High-Risk-Jurisdiction Staff

Zero-trust network access enforces the principle that no device or user is trusted by virtue of network location, which is particularly relevant for staff operating from airports, hotels or foreign offices where the local network may be surveilled or manipulated.

The architectural requirements for a sovereign ZTNA deployment are:

• The gateway and identity provider must reside on infrastructure outside the reach of the US CLOUD Act, UK Investigatory Powers Act and similar foreign-jurisdiction compelled-disclosure laws. Swiss hosting under the revised Federal Act on Data Protection (revFADP) or on-premises deployment within EU member states with no US parent company in the supply chain both satisfy this requirement.
• DNS resolution for internal resources must not leak to public resolvers. An encrypted DNS-over-TLS or DNS-over-HTTPS resolver operated on the same sovereign infrastructure closes this side channel.
• Split tunnelling should be disabled for classified or sensitive workloads, forcing all traffic through the verified gateway rather than routing internet-bound traffic directly from the endpoint.
• Session re-authentication must be triggered by risk signals, including geolocation anomalies, device-posture degradation and time thresholds, rather than relying on persistent session cookies.

Endpoint Hardening: Closing the Weakest Link

A quantum-safe gateway is irrelevant if the endpoint it serves is compromised. Endpoint hardening requirements must be enforced as technical prerequisites, not policy statements.

Device certificates should be bound to the Trusted Platform Module (TPM) so that they cannot be exported from the device. This prevents credential theft from compromised endpoints from being used to authenticate from a different machine.

Integrating with an On-Premises Identity Provider

Dependence on Microsoft Entra ID (formerly Azure AD) or Okta introduces a foreign-jurisdiction SaaS layer into the authentication chain, which undermines the sovereign architecture of the gateway itself.

Keycloak, an open-source identity and access management platform maintained under the Cloud Native Computing Foundation ecosystem, provides a mature alternative. Keycloak supports OpenID Connect, SAML 2.0 and LDAP federation, making it compatible with StrongSwan’s EAP-TLS and certificate-based IKEv2 authentication without modification. It can federate against an on-premises FreeIPA or Active Directory instance to reuse existing user directories, and it supports hardware token (TOTP/FIDO2) as a second factor for gateway authentication.

FreeIPA, the integrated identity management solution combining Kerberos, LDAP, DNS and certificate management, is well suited as the authoritative directory backend for Linux-heavy environments. Together, Keycloak and FreeIPA form a complete on-premises identity stack that issues the certificates consumed by the VPN gateway, manages group-based access policies, and provides the audit log required for NIS-2 and DORA compliance evidence.

The BSI states in its migration guidance: “Organisations that handle sensitive data must start the migration to quantum-resistant algorithms now. The threat of ‘harvest now, decrypt later’ is real and the window for action is narrowing.”

Regulatory Guidance and Procurement Requirements

Three national cybersecurity agencies publish specific guidance that procurement officers and CISOs should reference directly.

BSI Technical Guideline TR-02102-3 is the most operationally specific: it names permitted IKEv2 cipher suites, specifies hybrid PQC combinations, and sets minimum key lengths. It is updated regularly and should be cited as a compliance requirement in tender documents for VPN gateway procurement. Any vendor unable to demonstrate TR-02102-3 compliance should be disqualified.

ANSSI’s “Guide de la sécurité des réseaux” addresses network architecture and VPN deployment, and ANSSI’s separate post-quantum cryptography position paper specifies the hybrid approach. French public-sector organisations should require ANSSI-qualified (CSPN-certified) products where these exist, and should reference the position paper when specifying algorithm requirements.

The UK NCSC publishes a “Preparing for quantum-safe cryptography” white paper that, while less prescriptive than BSI TR-02102-3, confirms that organisations handling data classified OFFICIAL-SENSITIVE or above should begin PQC migration planning immediately and prioritises key exchange over signature algorithms as the first migration target. This aligns with the hybrid approach recommended by BSI and ANSSI.

Procurement language should include, at minimum: support for ML-KEM-768 (FIPS 203) in hybrid IKEv2 key exchange; a documented PQC roadmap from the vendor with committed delivery dates; compatibility with on-premises OIDC/SAML identity providers; and audit-log export in a format consumable by a SIEM without vendor lock-in. Requiring open-source or source-available implementations allows independent cryptographic audit, which several national agencies now treat as a differentiator in public procurement.

FAQ

What is a harvest-now-decrypt-later attack and why does it affect VPN traffic today?

An adversary records encrypted VPN sessions now and stores them for decryption once a sufficiently powerful quantum computer becomes available. Because classical Diffie-Hellman and RSA key exchanges can be broken by Shor’s algorithm, any session key negotiated with those algorithms is already at long-term risk, regardless of when the quantum hardware arrives.

Is ML-KEM the same as CRYSTALS-Kyber, and is it ready for production use?

Yes. NIST FIPS 203, finalised in August 2024, standardises ML-KEM, derived directly from the CRYSTALS-Kyber submission. It is supported in production builds of StrongSwan (5.9.x and later via liboqs) and is a stable baseline for organisations ready to deploy hybrid PQC in IKEv2 today.

Can Keycloak replace Azure AD as the identity provider for a quantum-safe VPN?

Yes. Keycloak supports SAML 2.0 and OpenID Connect, integrates with on-premises LDAP and Active Directory via federation, and can issue tokens or work with certificates consumed by StrongSwan’s EAP-TLS or IKEv2 certificate authentication. Running Keycloak on-premises or on Swiss-hosted infrastructure eliminates the dependency on Microsoft and keeps authentication data under domestic jurisdiction.

What do BSI TR-02102-3 and ANSSI actually require for VPN cryptography right now?

BSI TR-02102-3 recommends hybrid key exchange combining a classical ECDH group (P-256 or Curve25519) with ML-KEM-768 in IKEv2. ANSSI’s post-quantum position paper similarly recommends hybrid mechanisms, warning against dropping classical algorithms before PQC implementations are sufficiently mature and widely audited. Both frameworks treat pure-PQC migration as a second phase, not an immediate requirement.

What endpoint checks are mandatory before granting access through a zero-trust gateway?

At minimum: a verified device certificate issued by an internal CA and bound to the device TPM; full-disk encryption confirmed active (BitLocker or LUKS); OS patch level within a 30-day window; and an EDR agent in active reporting state. These checks must be enforced as technical pre-conditions for tunnel establishment, re-evaluated at every session start rather than only at initial device enrolment.