IPsec vs TLS post-quantum edge to data centre: which fits?

Post-quantum encryption from the edge to the data centre means protecting traffic between remote sites and a private data centre with a key exchange that combines a classical algorithm and ML-KEM (FIPS 203). The goal is that recorded traffic cannot be decrypted later by a quantum computer. In practice, the choice is between a network-layer IKEv2/IPsec tunnel and application-layer TLS 1.3.

For organisations running operational technology (OT) and critical infrastructure, the choice is more than a matter of taste. Edge sites often hold PLCs, RTUs and HMIs that run for decades, use protocols with no built-in security, and cannot take new software. This article compares the two protocol families on standards maturity, PKI, legacy devices and layering.

Should edge sites use IPsec or TLS to connect to a private data centre in a post-quantum world?

For whole-site connectivity from OT edge locations, a network-layer tunnel is usually the better base layer, because it protects every protocol without touching the endpoints. TLS 1.3 is the better tool for individual applications that you control on both ends, such as a historian or an API.

What the quantum threat changes

The main near-term risk is “harvest now, decrypt later”. Traffic captured today can be stored and decrypted once a cryptographically relevant quantum computer exists. Both protocol families address this the same way: they add ML-KEM to the key exchange. What differs is the scope of protection. NIST describes IPsec as “a widely used network layer security control for protecting communications”, so it covers every protocol that runs over IP. TLS only protects the specific sessions an application opens.

NIST’s own transition planning has fixed the deadline:

• NIST IR 8547 (2026): NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.
• UK NCSC milestones (as summarised in 2026): completing discovery and initial planning by 2028, migrating the highest-priority services by 2031, and completing migration by 2035.

OT equipment bought now will still be running when those deadlines arrive. That is a strong reason to protect edge links at a layer that does not depend on each device being upgraded.

Which is more mature for hybrid ML-KEM today, IKEv2 or TLS 1.3?

TLS 1.3 is further along: its hybrid ML-KEM groups have been published as an RFC and are widely deployed. IKEv2 has had a standardised framework for multiple key exchanges since 2023, and its ML-KEM binding is in the final stage before RFC publication.

TLS 1.3 status

TLS 1.3 itself is defined in RFC 8446. The IETF draft draft-ietf-tls-ecdhe-mlkem defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, and the Datatracker records that it was ultimately published as RFC 10024. X25519MLKEM768 is marked Recommended=Y in the registry. For environments that need FIPS-approved components on both sides, the P-256 variant supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms.

• Handshake growth (2026): hybrid X25519MLKEM768 increases the client and server entries to 1216 and 1120 bytes.

IKEv2 status

RFC 9370, published in May 2023, extends IKEv2 so that the establishment of a shared secret by using multiple key exchanges: typically, one classical (EC)DH and the other one post-quantum algorithm becomes possible.

• RFC 9370 (2023): To negotiate additional key exchanges, seven new Transform Types are defined.
• draft-ietf-ipsecme-ikev2-mlkem (March 2026): registers three ML-KEM identifiers for IKEv2 (ml-kem-512, ml-kem-768 and ml-kem-1024, as values 35, 36 and 37).

The draft author, Panos Kampanakis, sums up its purpose: “By integrating ML-KEM into IKEv2, IKEv2/IPsec tunnels become resistant to harvest-now-decrypt-later attacks.” The Datatracker shows draft-ietf-ipsecme-ikev2-mlkem-09 Submitted to IESG for Publication : Proposed Standard and waiting in the RFC Editor queue.

The practical gap is message size. Academic reviewers point out that IKEv2 was designed around the assumption of compact key exchange payloads, and its fragmentation mechanisms are less mature than those in TLS 1.3. The IKEv2 drafts deal with this through IKE_INTERMEDIATE (RFC 9242), whose messages can be fragmented at the IKEv2 layer before causing IP fragmentation [RFC7383].

How do certificate and PKI requirements differ between post-quantum IPsec and TLS tunnels?

IPsec between gateways needs a small, private trust relationship, often a handful of certificates from an internal CA or preshared keys. TLS needs a certificate for every service and, for mutual TLS, a certificate for every client device, so the PQ signature migration reaches much further into the estate.

Key exchange first, signatures second

Harvest-now-decrypt-later targets the key exchange, not the authentication. A signature only has to be unforgeable at the moment the handshake happens. That lets organisations add hybrid ML-KEM now and move certificates to post-quantum signatures as a separate project. NIST IR 8547 applies the same 2030 and 2035 dates to quantum-vulnerable signatures such as RSA, ECDSA and EdDSA, so the second phase still has a deadline.

IPsec specifics

• Gateway-to-gateway designs, as described in NIST SP 800-77 Rev. 1, work with a small number of identities. That makes rotating to new certificate algorithms manageable.
• RFC 8784 (2020) introduces this “Post-quantum Preshared Key” extension to augment IKEv2 with entropy from a pre-shared secret, which is an option for closed OT networks without a CA.
• PQ signature authentication for IKEv2 is defined in draft-ietf-ipsecme-ikev2-pqc-auth, which the Datatracker also lists in the RFC Editor queue.

TLS specifics

• Every data centre service endpoint needs a certificate chain the clients trust. Mutual TLS adds a client identity on each edge device.
• Embedded TLS clients on OT equipment often cannot load new trust anchors or verify new signature algorithms. That turns certificate migration into a firmware question.

Is a network-layer tunnel or application-layer TLS better for OT edge devices that cannot be upgraded?

A network-layer tunnel terminated on a gateway in front of the device is the only option that needs no change to the device. Application-layer TLS assumes the device can run a current, PQ-capable TLS stack, which most legacy controllers cannot.

Many OT protocols were never designed for TLS, and devices that do support it often have fixed cipher suites in firmware. A gateway that encrypts at Layer 3 moves the cryptography off the device and onto equipment you can update. NIST SP 800-77 Rev. 1 calls this the gateway-to-gateway architecture, which protects communications between two specific networks, such as an organization’s main office network and a branch office network.

Quantum Network’s QPN is one example of this model. It is a gateway, available as hardware or software, placed at each end of a connection. It encrypts at Layer 3 with a hybrid key agreement that combines a classical part with ML-KEM (FIPS 203), and it installs no software on the equipment behind it. For edge-to-cloud, a virtual gateway runs in the organisation’s own data centre or cloud on a supported Linux platform.

Be clear about what a gateway does not cover. It protects data in transit, not the devices behind it. The segment between the device and the gateway remains in plaintext, so place the gateway as close to the device as is practical, and secure that local segment physically.

Can you combine IPsec and TLS for defence in depth on edge-to-cloud links?

Yes. Running TLS 1.3 sessions inside a network-layer tunnel is a sound pattern, provided both layers use hybrid key exchange and the keys are managed independently.

The layers protect different things. The tunnel covers every protocol between the edge site and the data centre, including traffic from devices that cannot speak TLS. TLS adds end-to-end protection between a specific application and its server, so traffic stays protected even after the tunnel terminates inside the data centre network. If the two layers use separate implementations and separate credentials, one implementation flaw or one compromised key does not expose the payload.

Practical points for layering:

• Use hybrid groups in both layers. An inner TLS session that still uses X25519 alone adds no post-quantum assurance. Configure the hybrid groups from draft-ietf-tls-ecdhe-mlkem on servers you control.
• Plan where inspection happens. If a firewall has to inspect traffic, put the tunnel endpoint in front of it so that the firewall sees decrypted packets. QPN, for example, can sit in front of an existing firewall when inspection must continue, or behind it on paths that need no inspection.
• Keep forward secrecy at both layers. The SP 800-77 Rev. 1 authors are direct: using a fresh key exchange provides perfect forward secrecy (PFS). When resources allow, PFS should be used.
• Account for overhead. Two encapsulation layers reduce the effective MTU. Set MSS clamping or the tunnel MTU deliberately instead of relying on path MTU discovery across OT networks.

How should an OT operator sequence the migration?

Start with the links that carry long-lived sensitive data and the sites with equipment that cannot be upgraded. Protect those first with a hybrid tunnel, then move application TLS and certificates to post-quantum algorithms as vendors deliver support.

NIST frames the starting point plainly: “With the release of the first three final PQC standards, organizations should begin migrating their systems to quantum-resistant cryptography.” A workable order for edge-to-data-centre links:

1. Inventory every edge-to-data-centre and edge-to-cloud path, including the protocol, the endpoint’s ability to be upgraded and how long the data stays sensitive.
2. Put hybrid ML-KEM on the network-layer links that carry OT traffic from devices that cannot be changed.
3. Turn on hybrid TLS 1.3 groups on data centre services you control, keeping a classical fallback only where clients really cannot negotiate the hybrid groups.
4. Plan the move from RSA and ECDSA certificates to PQ signatures for gateways and TLS services before the 2030 deprecation point in NIST IR 8547.
5. Choose components that are crypto-agile, so that algorithms can be swapped as the IKEv2 drafts become RFCs and guidance changes.