Layer 2 vs. Layer 3 Quantum-Safe Encryption: Which Do You Need?
Once an organization accepts that data in transit needs quantum-safe encryption, the next question is architectural: where in the network stack should that encryption actually happen?
The two real answers are Layer 2 (Ethernet frame encryption, standardized as MACsec / IEEE 802.1AE) and Layer 3 (IP packet encryption, standardized as IPsec). Both can be quantum-safe. Picking the wrong one for a given link doesn’t make it less secure so much as it makes it not work.
This is worth being precise about upfront: the choice between Layer 2 and Layer 3 encryption is driven almost entirely by what your network looks like and not by which one is “more quantum-safe.” Getting the topology question right is what determines whether the security question even gets a chance to matter.
What Each Layer Actually Encrypts
Layer 2 encryption operates on the Ethernet frame, below IP. It encrypts everything inside that frame, including non-IP payloads, multicast and broadcast traffic, and the addressing information IP-layer encryption normally strips away.
It leaves the frame’s own addressing intact so switches can still forward it. Because it works at the frame level, it adds minimal overhead and is typically the lowest-latency option available, since there’s no IP header to parse, no routing decision to make, just a frame going from one point to another (or one point to several, in a point-to-multipoint design) exactly as it would unencrypted.
Layer 3 encryption operates on the IP packet, wrapping it (or its payload, depending on mode) for transport across a routed network. Because IP packets are what gets routed, Layer 3 encryption survives being forwarded across multiple hops, through networks you don’t control, and through equipment that has no idea the payload is encrypted.
That routability is the entire point but it comes with modest additional overhead per packet compared to frame-level encryption, which matters far less at modern link speeds than it used to.
Neither is a superset of the other. Layer 2 encryption generally cannot cross a routed IP hop, because it depends on the frame reaching its destination through switching, not routing. Layer 3 encryption generally cannot preserve non-IP protocols or true Ethernet-level multicast the way Layer 2 encryption can, because by the time it operates, that context has already been abstracted away into an IP packet.
Where Layer 2 Is the Right Answer
Layer 2 encryption fits links where you control the physical or logical path end to end and don’t need it routed:
- Dark fiber and DWDM circuits connecting two sites or two data centers directly, where the “network” is just a wire (or a wavelength) you own or lease outright.
- Data center interconnects within a campus or metro area, where storage replication, backup traffic, and other bulk flows need to move at the lowest possible latency and overhead.
- Point-to-multipoint and hub-and-spoke Ethernet topologies that stay within a switched fabric rather than crossing a router.
- Non-IP or mixed-protocol traffic — some industrial and operational technology environments, and some storage and replication protocols, that were never designed to be carried as IP packets and would need protocol conversion to reach a Layer 3 encryptor at all.
The common thread: the network between the two encryption endpoints is something you can draw as a straight line, not a route through infrastructure someone else operates.
Where Layer 3 Is the Right Answer
Layer 3 encryption fits links where the traffic has to survive being routed through infrastructure you don’t fully control:
- Wide-area networks and internet-routed links, including any connection that transits an ISP, a carrier, or multiple autonomous systems.
- Hybrid and multi-cloud connectivity, where traffic crosses from on-premises infrastructure into a cloud provider’s network and back.
- Cross-border and multi-site connectivity at scale, where a mesh or hub-and-spoke design spans locations with no direct fiber or DWDM path between them.
- Any transport where the physical medium is mixed or abstracted — MPLS, 4G/5G, xDSL, satellite backhaul — and the encryption has to work regardless of what’s carrying the packets underneath.
The common thread here is the mirror image of Layer 2’s: if the path between two points isn’t something you can guarantee stays within switched, unrouted infrastructure, Layer 3 is the layer that will actually survive the trip.
The Quantum-Safe Story Is Different at Each Layer
This is the part that doesn’t show up in a generic Layer 2 vs. Layer 3 comparison, but matters specifically for quantum-safe deployments: the two layers arrived at “quantum-safe” from different directions, because their native key-agreement mechanisms are built differently.
IPsec’s key exchange — IKEv2 — is built around negotiated, asymmetric key agreement, which is exactly the part of a connection that a future quantum computer threatens (via Shor’s algorithm against classical Diffie-Hellman and RSA).
That made it a natural fit for a standardized fix: RFC 9370, published by the IETF, defines how to combine a classical key exchange with one or more post-quantum key encapsulation mechanisms (such as ML-KEM) inside IKEv2’s existing negotiation — giving Layer 3 IPsec a direct, standards-based hybrid post-quantum upgrade path for the exact mechanism that needed one.
MACsec’s native key agreement — MKA — was built around simpler foundations: pre-shared keys or 802.1X/EAP-based authentication, not negotiated asymmetric key exchange.
Shor’s algorithm doesn’t threaten symmetric cryptography the way it threatens asymmetric key exchange, so the emerging path to “quantum-safe MACsec” looks different: strong, sufficiently long pre-shared keys and AES-256-GCM for the frame encryption itself, sized to stay ahead of Grover’s algorithm’s more modest quantum speedup against symmetric ciphers, rather than a lattice-based asymmetric handshake replacing the key exchange the way RFC 9370 does for IPsec.
That’s a legitimate route to quantum resistance, but it leans more heavily on pre-shared key management — distribution, rotation, and revocation across every encryption endpoint — than on a negotiated post-quantum handshake.
The practical takeaway: don’t assume a “quantum-safe” claim means the same thing at both layers on the same product. Ask specifically how the key exchange is being protected at the layer you actually need, because the operational burden of each differs, especially at the scale of dozens or hundreds of encrypted links.
| Layer 2 (MACsec / 802.1AE) | Layer 3 (IPsec) | |
| What's encrypted | The Ethernet frame, including non-IP and multicast/broadcast traffic | The IP packet (or its payload, depending on mode) |
| Survives routing? | No — needs a switched, unrouted path | Yes — designed to be routed across hops and networks |
| Overhead / latency | Minimal — no IP header parsing or routing decision | Modest additional overhead per packet; negligible at modern speeds |
| Native key exchange | MKA — pre-shared keys or 802.1X/EAP | IKEv2 — negotiated asymmetric key agreement |
| Standardized PQC path | Emerging — strengthened PSKs + AES-256-GCM | RFC 9370 — standardized hybrid PQC key exchange |
| Typical use | Dark fiber, DWDM, DCI, campus/metro Ethernet | WAN, internet, hybrid/multi-cloud, MPLS, cross-border links |
What a Fixed Choice Costs You Later
Purpose-built network encryption appliances have historically been built around one layer per model — a Layer 2 appliance or a Layer 3 appliance, chosen and locked in at procurement time. That’s a defensible design when a network’s topology never changes.
It becomes a real cost the moment it does: a dark-fiber link gets replaced by a routed WAN circuit during a data-center migration; a site that used to connect over a direct point-to-point link starts needing to reach a second, geographically separate site through a router; a new deployment turns out to need both a metro DCI link and a routed connection to a cloud region in the same rollout.
When that happens, a fixed-layer architecture doesn’t just require reconfiguration — it usually requires a different device family, a separate management console, and a separate key-management process, because the layer decision was made in hardware or firmware, not in software. Standardizing on a single vendor doesn’t help if that vendor’s own product line splits the same way the market does.
A Practical Way to Decide
- Map your links by transport type first, not by security requirement. For each one: is the path a dark fiber, DWDM circuit, or direct switched connection you control end to end — or does it cross a router, an ISP, a cloud boundary, or infrastructure you don't operate?
- Check for non-IP, multicast, or broadcast traffic on that link. If any of it exists — some storage replication, some OT and industrial protocols — that's a strong signal toward Layer 2, since Layer 3 encryption generally can't preserve it.
- Confirm whether the link has to survive routing. If it transits anything you don't control end to end, Layer 3 isn't optional — Layer 2 encryption typically won't survive the hop.
- Ask how quantum-safety is actually implemented at the layer you need, not just whether the product claims to be quantum-safe — a negotiated hybrid PQC key exchange and a strengthened pre-shared-key scheme carry different operational overhead, especially as the number of encrypted links grows.
- Plan for topology change, not just today's topology. If your network is likely to add routed links, cloud connectivity, or new sites over the next few years — which describes most growing networks — favor an architecture that can do both Layer 2 and Layer 3 from the same platform.
When You’re Ready to Stop Choosing
SSH’s NQX supports simultaneous Layer 2 and Layer 3 quantum-safe encryption from the same appliance family — so the topology decision doesn’t have to become a separate purchasing decision, management console, or key-management process when a network changes. The same software-defined crypto engine handles hybrid post-quantum key exchange (including ML-KEM and FrodoKEM) at whichever layer a given link actually needs.
