Skip to content
Get in touch

Quantum-safe network encryption explained: protecting data in transit at scale

A cryptographically relevant quantum computer that is capable of breaking the public-key cryptography and that secures most network traffic today doesn't exist yet. Nobody is certain when it will. But the risk to your organization’s data doesn't depend on that timeline. It depends on how long your data needs to stay confidential.

Adversaries don't need a quantum computer to start an attack, only to finish one. Encrypted traffic intercepted today can be recorded cheaply and decrypted years later, once the technology matures.

Security teams call this harvest-now-decrypt-later, and for any data with a confidentiality lifetime longer than a few years, the exposure isn't a future event. It began the moment the data crossed the network.  So mission-critical data on a data center interconnect, a site-to-site link, or a backbone connection that link garrisons, bank branch offices, police stations, government offices, production sites, satellite ground stations, or third parties collaborating with such entities are in jeopardy right now.

After all, financial transactions, military secrets, government correspondence, classified material, intellectual property, and OT telemetry all have a lifetime of decades.

That's why quantum-safe network encryption has become its own discipline, distinct from quantum-safe cryptography in general. Understanding the algorithms is necessary but not sufficient. Protecting data in transit at the scale a modern enterprise or operator actually runs at is a different engineering problem, with its own architecture, performance, and deployment considerations.

This page covers that problem: what quantum-safe network encryption means, why it has to start with data in transit, what "at scale" actually demands, and how to evaluate a solution against your own network.

Check out the two minute video below to get an overview on the topic:

What "quantum-safe" means for data in transit

Most network encryption in use today, like TLS, IPsec, SSH, relies on public-key cryptography for key exchange and authentication. That cryptography is secure against classical computers but is precisely what a sufficiently capable quantum computer, running Shor's algorithm, would break.

Quantum-safe (or post-quantum, PQC) cryptography replaces the vulnerable key-exchange math with problems believed to resist quantum attack (such as lattice-based schemes) while leaving the underlying symmetric encryption (AES) largely intact.

The practical answer the industry has converged on is hybrid: combine a classical key-exchange algorithm with a quantum-safe one (for example, a classical Diffie-Hellman exchange alongside NIST's standardized ML-KEM, FIPS 203) so connections stay secure even if one method is later broken.

NIST finalized its first PQC standards in 2024, and national bodies have each published their own guidance and timelines on top, including the US NSA's CNSA 2.0, Germany's BSI, the UK's NCSC. (For a deeper walkthrough of the algorithms, quantum attack mechanics, and standards landscape, see Quantum-Safe Cryptography And the Quantum Threat.)

Regulation has turned this from a technical recommendation into a deadline. CNSA 2.0 requires new US national security systems to be quantum-safe from January 2027. The EU's NIS2 framework writes post-quantum cryptography into law for critical infrastructure, with transition expected by 2030.

DORA already requires EU financial entities to monitor quantum risk and plan for cryptographic updates as cryptanalysis evolves. A 2026 US executive order 14412 on quantum-safe cybersecurity pulled federal timelines in further, binding government contractors to PQC plans and migration Wherever your organization sits, one of these mandates likely already applies.

Why the shift has to start with the network

Not every system can become quantum-safe at the same pace. Browsers, email, and cloud services are gradually adopting hybrid PQC by default but that only protects modern, actively maintained software. It doesn't help:

  • Legacy IT — older VPN gateways, SSH servers, and proprietary protocols that can't be patched to support new cryptographic libraries
  • Operational technology — ICS/SCADA systems, energy grids, and manufacturing lines with decades-long lifecycles and hardcoded or vendor-locked cryptography
  • Embedded and field devices — sensors and appliances without the compute headroom for PQC, where a firmware update is risky or simply impossible
  • Third-party and vendor links — supply chain and partner connections that cross networks you don't control

The paradox is that these systems carry the longest-lived, highest-value data. Waiting for application-level PQC migration to reach them isn't a plan, since for many of them, the migration will never happen.

Network-layer encryption sidesteps the problem. Because it protects traffic as it crosses the wire, the protection is independent of the protocol, application, or device generating it.

What’s more, quantum-safe encryption applied at the network layer wraps existing communications transparently: no application rewrites, no protocol changes, no touching systems that can't be modified. That's what makes data in transit the practical first step in a PQC migration, rather than the last.

What "at scale" actually requires

Protecting a single link is straightforward. Where most approaches to quantum-safe encryption run into trouble is protecting all of an organization's high-value network traffic across data centers, sites, clouds, and countries. At scale, a solution has to deliver on several fronts simultaneously:

Throughput without compromise. Data center interconnects and backbone links routinely run at 10, 40, or 100 Gbps. Encryption that can't sustain wire speed forces a choice between security and network performance which is a trade-off mission-critical environments can't accept.

The good news is that the best network encryptors can deliver quantum-safe encryption at line rate, reaching up to 100 Gbps, sub-millisecond latency in well-engineered implementations today.

Layer 2 and Layer 3 coverage. Ethernet, data replication, storage synchronization are all examples of traffic that needs encryption below the IP layer.

Other traffic needs IP-layer encryption across routed networks. A network encryption platform built for scale handles both from a single product family, rather than forcing separate tools per layer.

Crypto-agility. Standards are still evolving, and no organization wants to bet its infrastructure on today's specific algorithm choice.

A well-designed and software-based crypto engine can run classical, post-quantum, and hybrid modes side by side, and adopt new algorithms through a software update rather than a hardware swap. This mitigates the fear of “choosing the wrong algorithm" to secure mission-critical data.

Support for classical and PQC algorithms in parallel. A capable network encryptor does not rely on a single hybrid handshake but can run classical and post-quantum algorithms concurrently across the network. One tunnel can stay on a proven classical algorithm while another runs full post-quantum key exchange and a third runs hybrid.

Yet they are all managed from the same platform at the same time. That turns migration into a rollout the organization controls rather than a single switch that has to work everywhere on day one.

This way, your organization can start with the highest-risk, longest-lived data flows, prove the post-quantum or hybrid mode in production, then extend coverage on their own timeline as confidence and standards mature.

Resilience and centralized control. At scale, encryption has to survive real network conditions, including failover, redundant topologies, and resistance to distributed denial-of-service (DDoS) attacks aimed at disrupting encrypted links. Once again, it helps to have a centrally managed solution covering potentially hundreds of nodes rather than handling the challenge one device at a time.

Key sovereignty. Non-exportable keys generated, controlled and held within the organization's own infrastructure matter increasingly to government, defense, finance, and critical-infrastructure organizations. They who can't accept third-party custody of key material.

Where quantum-safe network encryption fits in your architecture 

It's worth being precise about what this category of solution replaces and what it complements, because it's often confused with adjacent technologies:

  • Versus VPNs: Traditional site-to-site VPNs encapsulate traffic through always-on tunnels and struggle to scale to high-throughput, continuous data flows — tunnel sprawl and overlay inefficiency become the bottleneck. Purpose-built network encryption creates secure transport just-in-time and removes the overlay inefficiencies that limit VPN throughput.
  • Versus ZTNA: Zero Trust Network Access governs user-to-application access, focusing on who can reach what, session by session. Quantum-safe network encryption solves a different problem: bulk, continuous, network-to-network data transport. The two are complementary, not competing.
  • Versus "encrypted" transport services: Services like MPLS and DWDM are sometimes marketed as encrypted, but that framing can overstate what's actually protected end-to-end. A dedicated encryption layer on top ensures the cryptographic guarantee is real, not inherited from the transport.
  • Alongside firewalls: A firewall enforces traffic policy but it isn't designed to carry the cryptographic load of encrypting everything that passes through it. In fact, switching on encryption there can cut a firewall's effective throughput by as much as 30%. Keeping encryption and policy enforcement as separate, purpose-built layers preserves defense-in-depth, ensuring that a vulnerability or misconfiguration in one control doesn't compromise the other. This approach lets each be certified, upgraded, and operated independently, with its own key management and attack surface rather than a shared one.

In practice, quantum-safe network encryption shows up in a handful of recurring architectures: 

  • data center interconnects, where replication and backup traffic need line-rate encryption with minimal added latency
  • hybrid and multi-cloud backbones, protecting continuous flows between on-premises and cloud environments without VPN bottlenecks
  • critical infrastructure and OT networks, where encryption has to wrap control-system traffic without altering the protocols those systems depend on
  • and secure data mesh deployments, where many sites need consistent, centrally managed encrypted connectivity rather than a patchwork of point solutions.

Evaluating a quantum-safe network encryption solution

For teams building a shortlist, the criteria that separate a genuine at-scale solution from a checkbox PQC feature tend to cluster around six questions:

  1. Does it support hybrid key exchange today — classical plus NIST-standardized post-quantum algorithms (ML-KEM/FIPS 203, and increasingly alternates like FrodoKEM) — rather than a roadmap promise?
  2. Can it sustain PQC at wire speed and at your actual throughput and latency requirements, Carefully evaluate if the throughput numbers are reported with quantum-safe algorithms enabled or are they just a lab benchmark with classical encryption on.
  3. Is the cryptographic engine software-upgradable, so algorithm changes don't require a hardware refresh cycle?
  4. What independent certifications back it — national cryptographic approvals (such as NCSA certification for classified data), FIPS validation status, and evidence a compliance or audit team can actually use?
  5. How much does deployment disturb the existing network — does it require re-architecture, application changes, or router/switch replacement, or does it slot in transparently?
  6. Who controls the keys — is key generation, rotation, and storage sovereign to your organization, with keys that are non-exportable by design?
  7. Can it process Layer 2 and Layer 3 traffic in parallel — many network encryptors handle only one layer, and even those that support both often process them one at a time rather than concurrently. This becomes a bottleneck the moment mixed traffic needs protecting at wire speed.

These same questions map directly onto emerging regulatory expectations. DORA's technical standards, for instance, require encryption of data in transit, documented key-lifecycle management, and a plan for updating cryptographic technology as cryptanalysis evolves.

NIS2 and CNSA 2.0 impose comparable expectations on critical infrastructure and national security systems respectively. A solution that answers the seven questions above cleanly also tends to generate the evidence compliance teams need for these frameworks.

Who needs this now

The pressure is highest wherever data is both long-lived and carried over networks that can't easily be redesigned:

  • Government and defense — classified information with 25+ year confidentiality requirements, where harvest-now-decrypt-later is already a live concern and national certification (like NCSA) is a procurement requirement.
  • Energy, telecom, and utilities — critical infrastructure operators facing 2030 transition deadlines under NIS2, needing to protect OT/IT traffic without re-architecting operational networks.
  • Financial services — interbank, payment, and data center links carrying long-retention transaction data, under direct DORA obligations and an incoming ECB quantum mandate.
  • Data centers and managed service providers — operators for whom quantum-safe, wire-speed encryption is becoming a premium connectivity service to resell, not just an internal control.
  • Satelline ground station links – transmitting mission-critical satellite data from ground stations to further distribution.

A pragmatic first step

Quantum-safe network encryption at scale doesn't have to start as an all-at-once program. A workable five step program looks like as follows:

  1. Prioritize data in transit — it's where the risk bites first, and where protection can be added without touching the systems generating the traffic.
  2. Inventory cryptography in use and the data whose confidentiality must outlast the harvest-now-decrypt-later horizon.
  3. Map exposure — which sensitive traffic crosses which links, and for how long it must stay confidential.
  4. Require crypto-agility in anything procured, so today's algorithm choice never forces tomorrow's forklift upgrade.
  5. Align to the mandate that applies — CNSA 2.0, NIS2, DORA, or sector-specific guidance — and know what evidence it requires.

SSH's NQX is built around exactly this approach: quantum-safe, wire-speed encryption (up to 100 Gbps) at Layer 2 and Layer 3, deployed transparently to existing infrastructure, with crypto-agility and sovereign key management built in.

Explore NQX quantum-safe network encryption or go deeper on the underlying algorithms and standards in Quantum-Safe Cryptography And the Quantum Threat.

FAQ

What is quantum-safe network encryption? It protects data moving between sites, data centers and clouds with cryptography designed to withstand attacks from future quantum computers. Typically it combines post-quantum key exchange, such as ML-KEM (NIST FIPS 203), with classical algorithms in hybrid mode, and AES-256 for the data itself. It runs at the network layer, so applications and endpoints don't need to change.

Will quantum computers break AES encryption? Not in any practical sense. The quantum threat targets public-key algorithms such as RSA and elliptic-curve Diffie-Hellman, which protect key exchange. Grover's algorithm only weakens symmetric ciphers. AES-256 keeps a large security margin, so quantum-safe network encryption keeps AES-256 and replaces the vulnerable key exchange.

Does quantum-safe encryption slow down the network? It doesn't have to. Post-quantum key exchange happens when a tunnel is set up and when keys rotate. Bulk traffic is still encrypted with AES at line rate. Purpose-built encryptors reach up to 100 Gbps with quantum-safe modes enabled. When you compare vendors, ask for throughput measured with PQC switched on.

How is network encryption different from a VPN or ZTNA? ZTNA controls which users can reach which applications. Remote-access VPNs connect users to networks. Network encryption protects bulk site-to-site traffic, such as data center interconnects, backbones and OT links, at wire speed. Most organizations need both access control and transport encryption, so the two complement each other.

Do applications, servers or OT devices need to change? No. A network encryptor sits in the traffic path and encrypts everything that crosses it, whatever produced it. That makes it the fastest way to protect legacy systems, SCADA and embedded devices that may never support post-quantum cryptography themselves.

Where should an organization start? Find the links that carry data with the longest confidentiality lifetime, such as data center interconnects, inter-site backbones and OT or partner connections, and protect those first with hybrid post-quantum encryption. The harvest now, decrypt later page explains why lifetime matters. The EU roadmap covers deadlines.