A post-quantum IPsec VPN to a cloud virtual network is a site-to-cloud tunnel whose key exchange can withstand a future quantum computer. Usually that means hybrid IKEv2, where ML-KEM (FIPS 203) is combined with classical Diffie-Hellman, or a post-quantum preshared key mixed into the session keys. The traffic recorded today stays confidential later.
OT and critical infrastructure operators feel this most. Historian data, engineering files and control-network telemetry going to cloud analytics often stay sensitive for many years. The tunnel carrying that data is negotiated today, so anyone recording it can try to decrypt it later. The sections below go through the practical questions: what managed cloud gateways can do, what to do when they can’t, and how to prove which key exchange is actually in use.
Do cloud virtual network VPN gateways support hybrid ML-KEM in IKEv2?
Short answer: not reliably yet. The IETF standard for ML-KEM in IKEv2 is almost final, but you can’t assume managed cloud VPN gateways negotiate it. Check your provider’s current list of supported IKEv2 key exchange transforms, and keep checking it.
Where the standards stand
The base framework is RFC 9370, which lets IKEv2 run up to seven extra key exchanges on top of the initial one. ML-KEM is then plugged into that framework. ML-KEM key exchanges can be negotiated in IKE_INTERMEDIATE, CREATE_CHILD_SA, or IKE_FOLLOWUP_KE messages as defined in the Multiple Key Exchanges in IKEv2 specification [RFC9370].
The ML-KEM profile is draft-ietf-ipsecme-ikev2-mlkem. The latest version, -09, has been submitted to IESG for publication as Proposed Standard and sits in the RFC Editor queue. Early versions covered only hybrid use. Version 09 specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. It also asks IANA for three identifiers, “ml-kem-512”, “ml-kem-768”, and “ml-kem-1024” in the IKEv2 “Transform Type 4 - Key Exchange Method Transform IDs”.
The draft’s author, Panos Kampanakis, sums up why it matters: “By integrating ML-KEM into IKEv2, IKEv2/IPsec tunnels become resistant to harvest-now-decrypt-later attacks.”
What this means for managed gateways
Managed cloud VPN gateways are shared, provider-operated services. They usually add new IKEv2 features only after the RFC is published and interoperability has been tested. An academic study of protocol readiness found that IPsec adoption of PQC remains largely confined to research prototypes and testbeds, with no major commercial VPN product shipping post-quantum IKEv2 by default. Treat any claim of “post-quantum support” from a provider as something to check. Look specifically for RFC 9370 additional key exchange transforms and the ML-KEM transform IDs, not just general marketing language.
How can I make a site-to-cloud IPsec tunnel quantum safe if the cloud gateway does not support ML-KEM?
If the managed gateway can’t do ML-KEM, you have three ways to add a post-quantum layer. You can mix in a post-quantum preshared key, if the gateway supports RFC 8784. You can end the tunnel on a gateway you run yourself inside the virtual network. Or you can run a post-quantum encrypted layer inside the existing classical tunnel.
| Option | What changes | Main trade-off |
|---|---|---|
| Managed gateway with hybrid ML-KEM | Only configuration, once the provider supports RFC 9370 and the ML-KEM transforms | You depend on the provider’s timeline and on matching support at your site |
| Managed gateway with RFC 8784 PPK | You add a high-entropy shared secret on both ends | You have to distribute and rotate keys by hand; the initial IKE SA is not covered |
| Self-managed gateway in the virtual network | A virtual appliance ends the tunnel; route tables send traffic through it | You take over sizing, availability and patching |
| Post-quantum layer inside the classical tunnel | Gateways at both ends encrypt before the traffic enters the existing VPN | Double encapsulation lowers the usable MTU; you run two tunnel stacks |
For most OT operators the choice depends on two things: who controls the cloud end, and how many sites connect to it. One substation sending data to one analytics network is easy to handle with a PPK. Fifty sites going to several virtual networks usually justify a dedicated gateway layer.
Can post-quantum preshared keys protect site-to-cloud tunnels in the meantime?
Yes, if both peers implement RFC 8784 and the key really is random. A post-quantum preshared key (PPK) is mixed into IKEv2 key derivation. The IPsec traffic keys then hold up even if the Diffie-Hellman exchange is broken later.
RFC 8784 was published in June 2020 for exactly this gap. Its authors explain it describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. Key quality is what matters:
- Statistic (IETF RFC 8784, June 2020): any post-quantum preshared key [should contain] at least 256 bits of entropy; this will provide 128 bits of post-quantum security.
The RFC is blunt about shortcuts: “Deriving a post-quantum preshared key from a password, name, or other low-entropy source is not secure”. Generate PPKs with a proper random source, give each tunnel its own key, and move them through a channel separate from the tunnel itself.
Know where the coverage stops. RFC 8784 protects the Child SA keys, but this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. The newer draft-ietf-ipsecme-ikev2-qr-alt protects the initial IKEv2 SA too. RFC 8784 also lets a peer continue without the PPK when the PPK isn’t configured as mandatory. Always set it to mandatory on both ends.
Should I run my own encryption gateway inside my cloud virtual network?
Run your own gateway when you need post-quantum key exchange now, want the same cryptography across many sites, or don’t want to wait for the provider’s timeline. Stay with the managed gateway if your data has a short confidentiality lifetime and the provider will support ML-KEM soon.
A self-managed gateway is a virtual machine that ends the encrypted tunnel inside your virtual network. The cloud work is mostly routing:
- Enable IP forwarding (or switch off source/destination checks) on the gateway’s network interface.
- Add user-defined routes so traffic for on-premises prefixes goes through the gateway, not straight out through the provider’s edge.
- Decide whether cloud-side inspection happens before or after decryption. Then place the gateway and any virtual firewall in that order.
- Plan for availability: two instances in separate zones, with a health-checked route or a load-balancer frontend.
- Size the instance for encrypted throughput, not just for the number of tunnels.
Ownership is the main cost. Your team now handles patching, algorithm updates and monitoring. In return you get crypto agility on your own schedule. One example of this model is Quantum Network’s QPN. For edge-to-cloud links it runs a virtual gateway on a supported Linux platform in the organisation’s own cloud or data centre. Key agreement is hybrid: a classical part and ML-KEM are combined into one session key, and both handshakes renew every two minutes. The software stack on a virtual gateway handles up to 10 Gbit/s.
How do I verify which key exchange a site-to-cloud IPsec tunnel actually uses?
Check the IKE SA that was actually negotiated, not the configuration. Look in the gateway logs or status output for the agreed key exchange transforms. Then confirm the post-quantum exchange happened on the wire with a packet capture.
On gateways you control
- Negotiated transforms: the IKE SA status should list an additional key exchange (RFC 9370 Transform Types 6 to 12, ADDKE1 to ADDKE7) with an ML-KEM method, not only an ECDH or MODP group.
- PPK use: for RFC 8784, check that the USE_PPK notification was exchanged and the log says the PPK was applied. “Configured” is not enough.
- Rekeys: check that the CREATE_CHILD_SA rekeys repeat the post-quantum exchange, or the later key material may be classical only.
On the wire
In a capture of UDP 500/4500, a hybrid ML-KEM negotiation shows IKE_INTERMEDIATE exchanges between IKE_SA_INIT and IKE_AUTH. ML-KEM key shares are much larger than elliptic-curve ones. The draft notes that IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts may be IKEv2 fragmented as per the IKEv2 Message Fragmentation specification [RFC7383]. If the capture shows only IKE_SA_INIT followed by IKE_AUTH, no additional key exchange took place.
On a managed gateway where you can’t see the cloud side, use your on-premises peer as the reference point. Whatever your site-side device logs as negotiated is what the cloud side agreed to.
Which post-quantum deadlines apply to site-to-cloud VPNs?
The main reference dates come from NIST and US federal policy. Quantum-vulnerable key exchange gets deprecated after 2030 and disallowed after 2035. High-value US federal systems face an earlier date. These dates are widely used as planning anchors outside government too.
- Statistic (NIST IR 8547, final, October 2026): NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.
- Statistic (NIST IR 8547, citing OMB M-26-15, October 2026): high value assets and similar systems must transition to quantum-resistant key establishment by December 31, 2030.
- Statistic (draft-ietf-ipsecme-ikev2-mlkem-09, July 2026): The 32-byte ML-KEM shared secret output, ss, is used without padding like the traditional shared g^ir value, so it fits into existing IKEv2 key derivation.
These dates trace back to National Security Memorandum 10, whose stated goal is “mitigating as much of the quantum risk as is feasible by 2035”, as quoted by NIST’s Dustin Moody. For national security systems, CNSA 2.0 sets a stricter bar: NSA has included two in CNSA 2.0: ML-DSA-87 [FIPS204] for signing, and ML-KEM-1024 [FIPS203] for key establishment. A separate draft, draft-guthrie-cnsa2-ipsec-profile, applies this to IPsec. Even if your organisation is outside that scope, it’s a useful benchmark when choosing a parameter set for long-lived OT data.
In practice the deadlines matter less than how long your data stays sensitive. Telemetry that is worthless after a week is low priority. Process recipes, grid topology and engineering projects sent to the cloud today are not, and those tunnels should get a post-quantum layer first.
Where Quantum Network fits
Quantum Network is a quantum-safe encryption gateway that protects the connections between your own locations, without replacing the network equipment you already run.