Your Traffic Is Post-Quantum. Your Keys Aren't Yet.

Somewhere, encrypted traffic is being collected and stored.

Not to be read now — classical public-key cryptography makes that impractical. The collection is for later, when a cryptographically relevant quantum computer (CRQC) exists and can break the key exchange that protected those sessions. The attack is called “harvest now, decrypt later,” and it’s been documented in joint guidance from CISA, NSA, and NIST as a current threat to critical infrastructure.¹ The Federal Reserve published a paper on the risk in September 2025.² The question isn’t whether the attack is plausible — it’s how much time remains before it becomes practical.

That question got significantly harder to answer this spring.

The timeline just moved¶

In late March and early April 2026, two independent research papers shifted the expert consensus on when CRQCs will arrive. Google published new quantum algorithms showing dramatically reduced resource requirements to break P-256 elliptic curve cryptography. Oratomic independently estimated that P-256 can be broken with approximately 10,000 physical qubits on a highly connected neutral atom architecture — an order of magnitude fewer than prior estimates.³

Cloudflare responded on April 7, 2026, by moving their internal target for full post-quantum security to 2029.⁴ Google independently made the same move. Filippo Valsorda, the Go programming language’s cryptography maintainer, wrote that the papers changed his position on urgency: “The risk that cryptographically-relevant quantum computers materialize within the next few years is now high enough to be dispositive.” He revised his own personal planning horizon from 2035 to 2029.⁵

NIST’s formal deprecation deadline for quantum-vulnerable algorithms is still 2030–2035, per the draft IR 8547 published November 2024.⁶ That deadline was set in a different landscape. The infrastructure community is now planning for 2029.

The good news: key exchange is largely solved¶

NIST finalized three post-quantum cryptographic standards on August 13, 2024:

• FIPS 203 (ML-KEM) — key encapsulation, based on CRYSTALS-Kyber. This is what protects key exchange.
• FIPS 204 (ML-DSA) — digital signatures, based on CRYSTALS-Dilithium.
• FIPS 205 (SLH-DSA) — hash-based digital signatures, a backup approach based on different mathematics.⁷

Since then, adoption of ML-KEM for key exchange has moved faster than most people realize.

In your browser: As of 2026, every major browser defaults to the post-quantum hybrid key exchange algorithm X25519MLKEM768 for TLS connections — Chrome (131+), Firefox (132+), Edge (131+), Safari (26+), Brave, Opera, and Tor Browser.⁸ The algorithm is a hybrid: X25519 (classical Curve25519) plus ML-KEM-768. A hybrid means the connection is as secure as the stronger component — if the ML-KEM piece were somehow broken, you’d fall back to classical X25519 security rather than getting worse than nothing.

By October 2025, Cloudflare reported that the majority of human-initiated traffic to their network was already using post-quantum key exchange. By April 2026, that number was 65%.⁴

In SSH: OpenSSH 10.0 (April 2025) changed the default key exchange to mlkem768x25519-sha256, the ML-KEM based hybrid.⁹ If you’re running a reasonably current SSH client and connecting to a reasonably current server, your session content is already protected against harvest-now-decrypt-later attacks.

OpenSSH 10.1 went further: it now emits a visible warning when you connect to a server that doesn’t support post-quantum key exchange:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

If your SSH server is older and you’re seeing this warning on connections from clients, it means the session content of those connections is being harvested in a format that a future quantum computer could decrypt. The fix is updating your server to OpenSSH 9+ and ensuring PQ key exchange is negotiated.

For the key exchange problem — the protection of session content against future decryption — the infrastructure is broadly deployed and the adoption curve is steep.

The bad news: authentication is still classical¶

Key exchange and authentication are different security problems.

Key exchange protects the confidentiality of session content. Even if an adversary records every packet, PQ hybrid key exchange means they can’t decrypt it later (assuming the PQ component holds).

Authentication protects identity. It’s what ensures you’re connecting to the real server and not an impersonator, and what ensures the server can verify you’re the legitimate user.

SSH authentication keys — your ed25519, ECDSA, or RSA host keys and user keys — are classically vulnerable. OpenSSH’s own documentation is explicit: “The only urgency for signature algorithms is ensuring that all classical signature keys are retired in advance of cryptographically-relevant computers becoming a reality. OpenSSH will add support for post-quantum signature algorithms in the future.”⁹ That future support doesn’t exist yet.

This means: when a CRQC exists, an attacker could forge SSH host keys (a quantum MitM), forge user authentication, or extract private keys from public keys collected today. The key exchange protection doesn’t help here.

TLS certificates have the same gap. No major certificate authority is currently issuing post-quantum certificates. The reason is partly practical — ML-DSA signatures are significantly larger than RSA or ECDSA signatures, adding overhead to TLS handshakes — and partly architectural. Google is exploring Merkle Tree Certificates as an alternative to traditional X.509 for the long-term PQ web PKI transition, but this is still in feasibility study.⁸ Let’s Encrypt, DigiCert, and other CAs have not announced PQ certificate timelines.

For now: the key exchange that protects your session content is post-quantum. The certificates that authenticate server identity are not.

The VPN gap¶

WireGuard uses Curve25519 for its handshake. This is classically secure but not post-quantum secure, and WireGuard intentionally has no protocol agility — you can’t simply swap in ML-KEM the way you can in TLS.¹⁰

The upgrade path is WireGuard’s optional pre-shared key (PSK) feature. Because PSKs are symmetric, mixing one into the WireGuard handshake provides post-quantum protection: a quantum attacker who breaks the Curve25519 key exchange still can’t recover a secret they don’t have. The challenge is secure PSK distribution — which itself needs to happen over a PQ-secure channel.

If you use Tailscale, their documentation is unambiguous: “Today, Tailscale’s WireGuard implementation is not post-quantum secure and does not use PSKs. There is also no way for Tailscale users to configure PSKs manually.” They intend to build automatic PSK provisioning eventually, but there is no announced ship date as of May 2026.¹⁰

This means Tailscale tunnels are fully unprotected against harvest-now-decrypt-later. If your infrastructure traffic runs over Tailscale, every session being collected today will be readable once a CRQC arrives.

Rosenpass is an open-source project that implements PQ-secure PSK negotiation for WireGuard, compatible with the standard protocol.¹¹ It requires manual setup and isn’t integrated into any major VPN platform by default. For operators running raw WireGuard rather than Tailscale, it’s a viable option.

Where this leaves you¶

The attack surface has split into two distinct problems with very different timelines.

The HNDL problem for session content — “collect now, decrypt the session contents later” — is being actively closed for web traffic and SSH. Browser adoption of PQ key exchange is broad. OpenSSH defaults to PQ hybrid key exchange and warns when servers don’t support it. If you’re running current software, your session content is largely protected.

The authentication problem — “a live quantum attacker forges identity or extracts keys in real-time” — is unsolved. SSH keys, TLS certificates, and VPN authentication are classically vulnerable. This attack requires a real-time CRQC, not just a future one used against stored data. It’s a different (and somewhat more distant) threat, but it’s the one the industry hasn’t solved yet.

Tailscale is neither problem solved. It’s unprotected on both counts: session content is harvestable now, and authentication will be classically vulnerable when CRQCs arrive.

NIST’s formal deadline for deprecating quantum-vulnerable algorithms is 2030, with complete removal from standards by 2035.⁶ Cloudflare and Google are now planning for 2029. The three-year gap between the regulatory deadline and where the infrastructure community is actually moving their target is the current best estimate of how much the April 2026 papers changed things.

For most of your traffic, post-quantum protection is already in place. For your keys, the clock is running.