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.

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 on quantum-safe cybersecurity pulled federal timelines in further, binding government contractors through FIPS compliance. 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:

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?
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.
Is the cryptographic engine software-upgradable, so algorithm changes don't require a hardware refresh cycle?
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?
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?
Who controls the keys — is key generation, rotation, and storage sovereign to your organization, with keys that are non-exportable by design?
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:

Inventory cryptography in use and the data whose confidentiality must outlast the harvest-now-decrypt-later horizon.
Map exposure — which sensitive traffic crosses which links, and for how long it must stay confidential.
Prioritize data in transit — it's where the risk bites first, and where protection can be added without touching the systems generating the traffic.
Require crypto-agility in anything procured, so today's algorithm choice never forces tomorrow's forklift upgrade.
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.