Post-Quantum Cryptography for Secure Tunnels: Fighting “Harvest Now, Decrypt Later”

The Data You Encrypt Today Is Being Recorded for Tomorrow’s Decryption

Welcome to 2026. If you’re still relying solely on RSA-2048 or standard Elliptic Curve Cryptography (ECC) for your production tunnels, you aren’t just behind the curve—you’re effectively leaving a time-capsule of your company’s secrets for future adversaries.

The “Quantum Y2K” (or Q-Day) is no longer a distant academic curiosity. With NIST’s release of the first three post-quantum cryptography standards in August 2024, the industry has reached a critical tipping point. The threat is no longer about a “future attack”—it’s about the Harvest Now, Decrypt Later (HNDL) campaign currently being executed by well-funded state actors.

The HNDL Crisis: Why “Later” is Actually “Now”

The Harvest Now, Decrypt Later strategy relies on acquiring and storing encrypted data today, betting that quantum computing breakthroughs will render it readable in the future. Adversaries intercept and store massive amounts of encrypted traffic today. They can’t read it yet, but they don’t need to. They’re betting that by the early 2030s, a Cryptographically Relevant Quantum Computer (CRQC) using Shor’s Algorithm will be able to break current encryption in minutes.

NIST has stated that encrypted data remains at risk because adversaries collect it now with the goal of decrypting it once quantum technology matures, and since sensitive data often retains its value for many years, starting the transition to post-quantum cryptography now is critical to preventing these future breaches.

If your 2026 traffic is secured with legacy protocols, its “shelf life” expires the moment that quantum computer turns on. For intellectual property, medical records, or government secrets, a four-year protection window is a catastrophic failure.

Who’s at Risk?

Organizations that store long-life sensitive data are prime targets: government agencies, defense contractors, financial institutions, healthcare providers, and critical infrastructure operators, but increasingly private-sector enterprises with valuable intellectual property or customer data are equally attractive.

Critical infrastructure operators maintain architectural diagrams, operational technology configurations, and control system communications that, if decrypted later, could enable sabotage or disruption.

The Vulnerability Table: Legacy vs. Quantum

Algorithm	Type	Classical Security	Quantum Security	Status in 2026
RSA-3072	Factorization	Strong	Broken (Shor’s)	Legacy / Risky
ECDHE (P-256)	Discrete Log	Strong	Broken (Shor’s)	Legacy / Risky
ML-KEM (Kyber)	Lattice-based	Strong	Strong	NIST Standard
ML-DSA (Dilithium)	Lattice-based	Strong	Strong	NIST Standard

The New Gold Standard: NIST’s Post-Quantum Standards

In August 2024, NIST released its principal PQC standards as Federal Information Processing Standards (FIPS), specifying key establishment and digital signature schemes. These include:

1. ML-KEM (Formerly CRYSTALS-Kyber) - FIPS 203

ML-KEM is a Key Encapsulation Mechanism used to establish a shared secret key between two parties communicating over a public channel, with security related to the computational difficulty of the Module Learning with Errors problem.

The Math: It relies on the “Module Learning with Errors” (MLWE) problem, a subset of lattice-based cryptography. Unlike RSA, which is a one-dimensional problem of factoring, lattice problems involve finding the shortest vector in a multi-dimensional grid—a task that remains “hard” even for quantum computers.

FIPS 203 specifies three parameter sets for ML-KEM: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, in order of increasing security strength and decreasing performance.

2026 Use Case: Used in the TLS 1.3 handshake to replace or augment ECDHE.

2. ML-DSA (Formerly CRYSTALS-Dilithium) - FIPS 204

FIPS 204 specifies the Module-Lattice-Based Digital Signature Standard, which is used to detect unauthorized modifications to data and authenticate the identity of the signatory.

The Math: Also lattice-based, specifically using the Module-Lattice-based Digital Signature Algorithm.

2026 Use Case: Used in identity providers and certificate authorities (CAs) to sign the certificates that authenticate your tunnel endpoints.

3. SLH-DSA (Formerly SPHINCS+) - FIPS 205

The Stateless Hash-Based Digital Signature Standard provides an alternative digital signature mechanism, offering a different mathematical foundation as a backup to ML-DSA.

4. Additional Algorithms Under Development

On March 11, 2025, NIST released Hamming Quasi-Cyclic (HQC) as the fifth algorithm for post-quantum asymmetric encryption, serving as a backup for ML-KEM using different math to mitigate possible weaknesses in lattice-based approaches.

NIST plans to publish FALCON’s standard as FIPS 206 (to be named FN-DSA, for FFT NTRU-based Digital Signature Algorithm) as an alternative lattice-based signature scheme that provides even smaller signature sizes.

The Hybrid Approach: The “Safety Envelope” Strategy

One of the most common questions in 2026 is: “If PQC is so good, why are we still using ECC?”

The answer is Crypto-Agility. While lattice-based math is theoretically sound against quantum attacks, it is relatively new in terms of real-world “battle-testing” compared to RSA or ECC. There is always a non-zero chance that a clever classical mathematician finds a flaw.

To mitigate this, the industry has adopted hybrid cryptography as a bridge, combining classical and post-quantum algorithms to reduce risk and preserve interoperability.

How a Hybrid PQC Tunnel Works

Instead of replacing X25519 (ECC) with Kyber-768 (PQC), we use both:

Dual Key Exchange: The tunnel initiator sends two public keys: one classical (X25519) and one post-quantum (ML-KEM-768).
Shared Secret Derivation: The receiver responds with two “ciphertexts.” Both parties then use a Key Derivation Function (KDF) to “mix” the classical shared secret and the PQC shared secret into a single master key.
The Result: To break the tunnel, an attacker must break both the classical math and the quantum-resistant math. This ensures that 2026 traffic is safe from today’s hackers and tomorrow’s quantum computers.

Real-World Implementation: Industry Leaders

Cloudflare’s Deployment

Cloudflare deployed a preliminary version of the ML-KEM key agreement algorithm in 2022, and as of mid-August 2024, over 16% of human-generated requests to Cloudflare’s servers are already protected with post-quantum key agreement using a hybrid approach with X25519.

IBM’s Contribution

Two IBM-developed algorithms, ML-KEM (originally known as CRYSTALS-Kyber) and ML-DSA (originally CRYSTALS-Dilithium), were developed by IBM researchers in collaboration with industry and academic partners and were officially published among the first three post-quantum cryptography standards.

Microsoft’s Integration

Microsoft announced that with NIST’s standards in place, they are incorporating the PQC algorithms into Windows and Azure crypto libraries, with Microsoft’s core crypto API (SymCrypt) supporting Kyber (ML-KEM), Dilithium (ML-DSA), and Sphincs+ (SLH-DSA).

PQC in OpenSSH: Leading the Way

OpenSSH has been at the forefront of post-quantum adoption:

OpenSSH has offered post-quantum key agreement by default since release 9.0 in April 2022, initially via the sntrup761x25519-sha512 algorithm.

In OpenSSH 9.9, a second post-quantum key agreement mlkem768x25519-sha256 was added, and it was made the new default scheme in OpenSSH 10.0 released in April 2025.

OpenSSH 10.1 warns users when a non post-quantum key agreement scheme is selected, though this warning can be disabled via the WarnWeakCrypto option.

Current Adoption Statistics

Between October 2024 and March 2025, adoption grew 554% for SSH key exchange with ML-KEM and 21% for SSH key exchange with SNTRUP.

However, three quarters of OpenSSH versions on the internet still run versions released between 2015 and 2022 that do not support quantum-safe encryption, and less than 20% of TLS servers use TLSv1.3, which is the only version that supports PQC.

PQC vs. TLS 1.3 Tunnels: The Integration Deep Dive

The transition to PQC in tunneling is primarily happening at the TLS 1.3 layer. Standard tunneling agents (like those used for localhost exposure or site-to-site VPNs) are swapping their underlying transport security.

Key Differences in PQC Tunnels

1. Payload Size: PQC keys are significantly larger than ECC keys. An X25519 public key is 32 bytes; a Kyber-768 public key is 1,184 bytes. This “bloat” can lead to IP fragmentation if not handled correctly by the tunneling agent.

2. Processing Overhead: While PQC is generally fast, the initial handshake requires more CPU cycles. For high-frequency “short-lived” tunnels, this can introduce a slight latency penalty.

3. Localhost Tunnels: Developers using tunnels to expose localhost (via tools like Cloudflare Tunnel or Tailscale) are now seeing “PQC-Enabled” flags in their CLI. This ensures that even the “temporary” development traffic—which often contains sensitive API keys or .env data—is shielded from harvesting.

Performance Comparison: PQC vs. Legacy (2026 Benchmarks)

Protocol Metric	ECC (X25519)	Hybrid (X25519 + Kyber768)	PQC Only (Kyber768)
Handshake Latency	~0.5ms	~0.8ms	~0.6ms
Public Key Size	32 B	~1.2 KB	1.18 KB
Quantum Resistance	No	Yes	Yes
Classical Confidence	100%	100%	95% (Newer)

Note: The performance hit of hybrid tunnels is negligible for most applications. In 2026, the risk of not using PQC far outweighs the 0.3ms latency trade-off.

Implementing PQC Tunnels: A 2026 Checklist

If you’re managing infrastructure, your “Quantum Readiness” roadmap should prioritize tunneling agents. These are the “pipes” through which your most sensitive data flows.

1. Audit Your Tunneling Agents

Check if your providers (Zscaler, Cloudflare, Twingate, or OpenSSH) support hybrid PQC key exchange. As of 2026, the industry-standard hybrid groups are:

For OpenSSH: - mlkem768x25519-sha256 (ML-KEM-768 + X25519) - Default in OpenSSH 10.0+ - sntrup761x25519-sha512 (NTRU Prime + X25519) - Available since OpenSSH 9.0

To check your OpenSSH configuration:

ssh -Q kex

To force PQC key exchange:

ssh -o KexAlgorithms=mlkem768x25519-sha256 user@host

For TLS 1.3: Ensure your server-side library (OpenSSL 3.5+, BoringSSL) has the PQC groups enabled in the preference list. OpenSSL 3.5, released in April 2025, added full support for the three NIST standards ML-KEM, ML-DSA and SLH-DSA.

2. Update Your “Localhost” Workflows

Don’t let your dev environment be the weak link. When using a tunneling agent for local development:

Use agents that support Post-Quantum Key Exchange (PQ-KEX)
Verify the handshake in your browser’s security tab (look for “X25519 + Kyber768”)
Enable PQC flags in your development tunnel CLI tools

3. Shift to ML-DSA for Internal PKI

While public CAs are still transitioning, your internal Root CA (used for mTLS between services) should start issuing hybrid certificates using ML-DSA. This prevents an attacker from impersonating a service inside your network once they have a quantum computer.

4. Implement Crypto-Agility

Crypto-agility is the ability to swap out cryptographic algorithms quickly as standards change, and will be a defining capability in the quantum era, as organizations that hard-code encryption deep into legacy systems will struggle to adapt when those algorithms become obsolete.

Regulatory and Compliance Timeline

Under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier.

Recognizing the challenge of migrating to post-quantum cryptography, agencies across the world have begun publishing multi-year roadmaps with timelines that move the quantum threat to the immediate, setting regulatory expectations for preparedness today, with consensus that planning, discovery, and inventory must be completed within the next two to four years.

Key Deadlines

2030: U.S. federal agencies must complete migration to PQC
2035: NIST will phase out RSA, Diffie-Hellman, and elliptic curve cryptography (ECDH and ECDSA) as specified in CNSA 2.0
2027: Expected finalization of HQC standard as ML-KEM backup

The Quantum Timeline: When Will Q-Day Arrive?

In the 2024 Quantum Threat Timeline Report, a survey of experts generally agreed that a quantum computer could achieve 100 logical qubits in the next 10 years, and one in three cybersecurity experts forecast that Q-Day will happen before 2032.

Estimates for when a cryptographically-relevant quantum computer will arrive, based on the rate of progress in the field, range from 5-20 years, with many observers expecting them to arrive in the mid-2030s.

However, the most alarming aspect of HNDL attacks is that they can happen without any visible signs of intrusion, as the attacker’s goal is to quietly collect and store data for future decryption, meaning breaches may have already occurred but remain undisclosed or even unknown.

Taking Action: The 90-Day Quantum Readiness Plan

Leaders can take meaningful action in the next 90 days by focusing on four concrete steps:

Week 1-2: Map Your Crown Jewels

Identify the data that must remain confidential long-term and understand where it lives, how it’s accessed, and who can reach it.

Week 3-4: Audit Network Configurations

Review your tunneling infrastructure, VPN endpoints, and TLS configurations. Identify all systems using legacy-only encryption.

Week 5-8: Cryptographic Inventory

This involves two key actions: a cryptographic inventory and a data-centric risk assessment, directly aligning with mandates from the U.S. Department of Homeland Security to take an inventory of the most sensitive and critical datasets and of all cryptographic systems.

The critical question: Which data assets would cause significant harm if decrypted in 10 years’ time?

Week 9-12: Begin Hybrid Migration

Deploy hybrid PQC for your most sensitive tunnels
Update OpenSSH to version 10.0 or later
Enable ML-KEM support in TLS 1.3 endpoints
Test hybrid configurations in staging environments
Document your PQC transition roadmap

The Linux Enterprise Perspective

Red Hat Enterprise Linux 10.0 provides ML-KEM key exchange algorithm to protect TLS connections established by OpenSSL, GnuTLS and NSS, and SSH connections with OpenSSH against harvest now, decrypt later attacks.

To enable PQC system-wide on RHEL 10.0:

# Install required packages
dnf install crypto-policies-pq-preview crypto-policies-scripts

# Switch to TEST-PQ policy
update-crypto-policies --set DEFAULT:TEST-PQ

The Verdict: Don’t Wait for the “Quantum Y2K”

The “Quantum Y2K” isn’t a single date on a calendar; it’s a sliding window. Every day you continue to use legacy-only tunnels, you add another day of data to the “Harvest” archives of global adversaries.

Research shows that high-retention sectors such as satellite and health networks face exposure windows extending decades under delayed PQC adoption, while hybrid and forward-secure approaches reduce this risk horizon by over two-thirds.

By integrating ML-KEM and ML-DSA via the Hybrid Approach, you aren’t just following a NIST mandate—you are ensuring that your intellectual property remains private well into the 2030s and beyond.

Summary of Actions

Identify all legacy RSA/ECC tunnels in your infrastructure
Enable Hybrid PQC (ML-KEM) in your TLS 1.3 stacks
Upgrade OpenSSH to version 10.0 or later
Verify that localhost tunneling agents are utilizing NIST-approved algorithms
Conduct a cryptographic inventory of all sensitive data and systems
Implement crypto-agility to prepare for future algorithm transitions
Establish a PQC migration timeline aligned with regulatory requirements
Monitor adoption progress and adjust as standards evolve

Additional Resources

NIST PQC Standards: https://csrc.nist.gov/projects/post-quantum-cryptography
NIST IR 8547: Transition to Post-Quantum Cryptography Standards
OpenSSH PQC Guide: https://www.openssh.org/pq.html
Cloudflare PQC Blog: Industry implementation examples and performance data
IETF RFC 9794: Standards for hybrid key exchange in TLS

The quantum threat is not tomorrow’s problem—it’s today’s strategic imperative. Organizations that act now will protect their data for decades to come. Those that wait may find their secrets exposed the moment quantum computing becomes reality.

Start your PQC transition today. Your future self will thank you.

2026 Post-Quantum Tunnels: Fighting Harvest Now, Decrypt Later