Prepare for Q-Day with Hybrid Mode Key Exchange

“Store Now, Decrypt Later," or SNDL, attacks are a unique brand of attack that you need to keep top-of-mind in the coming years. Our new publication, A Practitioner’s Guide to Post-Quantum Cryptography, lays out why SNDL is so different. Exploitation may start today and only completes when Cryptographically Relevant Quantum Computers (CRQCs) arrive. That time factor means an adversary could harvest data in motion right now and decrypt it later, once they gain access to stronger compute.

Does your organization move sensitive data over HTTPS, SSH, or VPNs? (Spoiler: it does.) Then encryption in transit and the hybrid mode key exchange path for TLS is what you can do now. Reduce SNDL exposure while the post-quantum cryptography (PQC) ecosystem continues to mature.

 

Why focus on “encryption in transit”?

Data in transit uses symmetric session keys. However, you establish those keys by key exchange procedures using public-key algorithms like RSA and Diffie-Hellman. Those are exactly the families broken by Shor’s algorithm once CRQCs are viable.

The practical risk isn’t that AES fails tomorrow. Rather, adversaries could record today’s TLS handshakes and later decrypt them when "Q-Day" arrives.

The following table maps real systems to the crypto you depend on. For the web stack, TLS (HTTPS) lists:

• X.509 certificates for authentication
• RSA, Diffie-Hellman, and elliptic curve for key exchange
• SHA-256 for integrity

For SSH and IPsec/IKE, the same pattern applies: public-key algorithms sit in the key exchange path, creating a quantum-era weak link. That’s why SNDL matters so much for traffic crossing your networks every second.

 

Security Functions	Applications	Security Components in Focus	Cryptographic Components
Encryption in transit	Web browsers and servers, most cloud applications	TLS (HTTPS)	Authentication X.509 certificate Key exchange  RSA Diffie-Hellman Elliptic curve Integrity validation SHA256
Encryption in transit	Access remote computers and transfer files	SSH	Authentication Certificate Public key Password Key exchange algorithm  RSA Diffie-Hellman Elliptic curve Integrity validation SHA256
Encryption in transit	Virtual private network (VPN) key exchange	IKE	Authentication X.509 certificate Shared secret Key exchange algorithm  RSA Diffie-Hellman Elliptic curve Integrity validation SHA256
Encryption at rest	Data storage	Key management system (KMS)	Key encryption RSA Diffie-Hellman Elliptic curve
Non- repudiation	Contract signing		Authentication X.509 certificate Integrity validation SHA256

 

The bridge to PQC you can deploy first: Hybrid mode key exchange

Until fully PQC-native stacks are ubiquitous, we recommend an interim solution. Use a hybrid mode key exchange, such as TLS 1.3 hybrid key exchange combining X25519 with Kyber ML-KEM.

In a hybrid, you still run a familiar classical key exchange like X25519 and add a post-quantum KEM in parallel. The handshake binds both results. If either remains secure, the derived session key remains confidential. This means that a CRQC in the future doesn’t automatically crack what an adversary captured today.

The standards underpinning that approach are now real:

• FIPS 203 (ML-KEM), NIST’s standardized key encapsulation mechanism (Kyber) for establishing shared secrets
• FIPS 204 (ML-DSA), a module-lattice digital signature standard (Dilithium) for authentication and non-repudiation
• FIPS 205 (SLH-DSA), a stateless hash-based signature standard offering an additional PQC signature option

NIST’s migration playbook (SP 1800-38) also provides practical guidance on discovery and planning for PQC transition.

Most PQC modules and components are in the experimental stage and have not made it into mainstream products. Even for interim solutions enabled by FIPS-204 or hybrid mode, out-of-the-box support is limited. Teams may need to replace cryptographic libraries or even compile and build with PQC modules. That has cost and complexity implications you must weigh during risk assessment.

 

A pragmatic, SNDL-aware rollout plan for hybrid TLS

Here’s a concrete plan that aligns with a risk-first posture and the PQC standards outlined above:

1. Inventory data-in-transit paths that matter. Focus on user-facing and machine-to-machine TLS endpoints that carry data with long-term value.
2. Prioritize systems that can accept hybrid today. For test beds, use stacks where OpenSSL + liboqs or vendor PQC builds are available. These will let you validate X25519 + ML-KEM handshakes, measure handshake sizes/latency, and test fallbacks. (See NIST FIPS-203 for KEM context and current security footing.)
3. Adopt a “crypto discovery” habit. Run discovery tooling regularly to map TLS, SSH, and IKE usages and surface classical algorithms still in key exchange. NIST SP 1800-38 Volume B outlines discovery and measurement patterns to baseline and track progress.
4. Plan for authentication, not just key exchange. Hybrid TLS addresses confidentiality in transit. However, you’ll also need a path to ML-DSA or SLH-DSA for non-repudiation and code-signing over time. Start by segmenting where long-lived signatures actually matter.
5. Communicate the “why” in business terms. Time dominates SNDL risk, so if the data will still matter when Q-Day comes, protect it now. Use that framing to justify limited pilots where benefits are clear and the operational blast radius is small.

 

Gotchas you’ll actually hit

• Handshake size & performance: Hybrid TLS increases handshake bytes and compute. Pilot with real clients and real CDNs/load balancers to quantify the cost. (IETF guidance and emerging drafts around ML-KEM usage discuss operational considerations.)
• Interoperability gaps: Not every browser, proxy, or agent will speak the same hybrid ciphersuite yet. Keep classical-only fallbacks (while tracking and limiting their use).
• Toolchain churn: Having to compile, build, and maintain these technology components raises cost. Budget for CI/CD updates, FIPS-validated builds as they appear, and security reviews for new crypto dependencies.

 

Why now?

If you’ve been following PQC developments for a while, it’s tempting to think that you'll act when quantum computers are closer. However, the timeline for quantum threats doesn't align with the timeline for crypto migration. SNDL attacks are already happening today. But the data adversaries are stealing may remain sensitive for years or even decades.

This is the paradox of quantum risk. You may not know the moment Q-Day arrives, but your vulnerability window has already opened.

Until recently, the PQC landscape included experimental algorithms and academic proofs of concept. NIST finalized its first set of post-quantum standards in August 2024. Now, we have approved cryptographic primitives ready for use in FIPS-validated modules and commercial systems.

Government guidance has followed quickly. In 2025, CISA, NIST, and NSA jointly released the “Quantum-Readiness: Migration to PQC” factsheet. In it, they urge agencies and critical infrastructure operators to begin cryptographic inventorying, prioritization, and transition planning now. This marks a policy-level acknowledgment that the migration phase could take years and must begin immediately.

Any organization transmitting long-lived or compliance-sensitive data should assume attackers have already collected it for future exploitation. Since you can't detect these attacks at the time of collection, preventive action is the only mitigation.

 

The bottom line

The cryptographic world has reached an inflection point. The standards exist, the guidance is clear, and the threat actors are already harvesting data. You can’t predict Q-Day, but you can prepare for it. Treating PQC readiness as a strategic, phased transformation shows that you take the long view of security seriously.

In other words: the right time to start was yesterday. The second-best time is now.

Your next steps:

• Read A Practitioner’s Guide to Post-Quantum Cryptography. Get the full context on risk assessment, encryption in transit protocols, and technology components for mitigation.
• Explore the underlying NIST standards and migration guidance: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), and SP 1800-38.

SNDL turns today’s TLS traffic into tomorrow’s breach. Hybrid mode key exchange gives you a defensible, standards-aligned first step on the road to PQC. You can pilot this step now, measure, and scale as the ecosystem catches up.