In our recent exploration of future networking trends, we touched on the looming quantum threat. But what does preparing for “Q-Day”—the moment quantum computers can crack today’s encryption—actually look like? The answer involves two acronyms you’ll be hearing a lot more: ML-KEM and ML-DSA. These aren’t just academic curiosities. They’re the new NIST-standardized algorithms that will eventually replace RSA and elliptic curve cryptography across your entire infrastructure.

Let’s break down what’s changing, why it matters, and what you need to do about it.

The Quantum Threat: More Than Hype

Here’s the uncomfortable reality: the encryption protecting your VPNs, TLS connections, and digital signatures relies on mathematical problems that quantum computers will eventually solve trivially. Specifically, Shor’s algorithm running on a cryptanalytically relevant quantum computer (CRQC) can crack both integer factorization (RSA) and discrete logarithm problems (ECC) in polynomial time.

We’re not there yet. But the “Harvest Now, Decrypt Later” (HNDL) threat is real today. Adversaries—particularly nation-states—are already collecting encrypted traffic with the expectation of decrypting it once quantum capability arrives. If your data needs to remain confidential for 10+ years, you’re already behind.

NIST recognized this urgency and finalized the first post-quantum cryptography standards in 2024:

• FIPS 203 (ML-KEM): Module-Lattice-Based Key-Encapsulation Mechanism
• FIPS 204 (ML-DSA): Module-Lattice-Based Digital Signature Algorithm

These aren’t drop-in replacements. They’re fundamentally different cryptographic constructions that require real infrastructure changes.

Understanding Lattice-Based Cryptography

Both ML-KEM and ML-DSA are built on lattice problems—specifically the Module Learning with Errors (MLWE) and Module Short Integer Solution (MSIS) problems. Unlike RSA’s reliance on factoring large primes, lattice cryptography asks adversaries to find short vectors in high-dimensional mathematical spaces. No known quantum algorithm solves these efficiently.

The “module” construction is important. Pure lattice schemes are secure but produce enormous keys. Ideal lattices are efficient but may have exploitable structural symmetries. Module lattices split the difference—using polynomial rings that enable fast computation via the Number Theoretic Transform (NTT) while maintaining strong security margins.

This mathematical shift has tangible consequences for your infrastructure.

ML-KEM: The New Key Exchange

ML-KEM replaces the key agreement portion of your TLS handshakes and VPN tunnels. Where X25519 or ECDH currently establish shared secrets, ML-KEM will take over. It works through three operations: key generation, encapsulation, and decapsulation.

The security levels map to familiar AES equivalents:

Parameter Set	Security Level	Public Key	Ciphertext
ML-KEM-512	AES-128	800 bytes	768 bytes
ML-KEM-768	AES-192	1,184 bytes	1,088 bytes
ML-KEM-1024	AES-256	1,568 bytes	1,568 bytes

Compare ML-KEM-768’s 1.2KB public key to X25519’s 32 bytes. That’s a 37x increase. The good news? ML-KEM is actually quite fast—often matching or exceeding X25519 in raw computation speed. The bad news? All those extra bytes create protocol-level headaches.

ML-DSA: Signatures Get Heavier

Digital signatures face an even steeper size increase. ML-DSA (formerly CRYSTALS-Dilithium) uses the “Fiat-Shamir with Aborts” construction, which involves rejection sampling to prevent private key leakage through statistical analysis.

Parameter Set	Security Level	Public Key	Signature Size
ML-DSA-44	AES-128	1,312 bytes	2,420 bytes
ML-DSA-65	AES-192	1,952 bytes	3,309 bytes
ML-DSA-87	AES-256	2,592 bytes	4,627 bytes

An ML-DSA-65 signature is approximately 3.3KB compared to Ed25519’s 64 bytes—a 50x increase. This directly impacts certificate chain sizes, API authentication overhead, and anywhere else you’re signing data.

The TLS Handshake Problem

Here’s where theory meets painful reality. A TLS 1.3 handshake using post-quantum algorithms grows substantially:

Message	Classical Size	PQC Size
ClientHello	< 500 bytes	1.5-2.0 KB
Certificate Chain	2-5 KB	10-20 KB
CertificateVerify	64 bytes	2.4-4.6 KB

On high-bandwidth, low-latency connections, the impact is minimal—often under 5% Time-To-Last-Byte increase. But on constrained links with high latency or packet loss, you’re looking at 20-30% performance degradation.

The culprit is TCP’s initial congestion window (initcwnd), typically around 14-15KB. A post-quantum handshake exceeding this window incurs an extra round trip before data can flow. That additional RTT hurts, especially on mobile or satellite links.

Hybrid Key Exchange: The Transition Bridge

The industry has settled on hybrid approaches that combine classical and post-quantum algorithms. The connection remains secure as long as either algorithm holds. You’ll see identifiers like X25519MLKEM768 in your TLS configurations—X25519 combined with ML-KEM-768.

This provides defense-in-depth: protection against HNDL attacks today while maintaining compatibility if any unexpected weaknesses emerge in the new algorithms.

IPsec and VPN Challenges

IPsec VPNs face unique challenges. IKEv2 messages traditionally fit in single UDP packets, but ML-KEM keys will force IP fragmentation. Many firewalls and NAT devices drop fragmented UDP as a security measure—potentially preventing VPN tunnels from establishing entirely.

The fix requires implementing IKEv2 fragmentation (RFC 7383) or IKE_INTERMEDIATE exchanges. If you’re running site-to-site VPNs or remote access infrastructure, this is a firmware and configuration update you’ll need to plan for.

Hardware Acceleration: The NTT Imperative

Your security appliances—firewalls, load balancers, VPN concentrators—rely on hardware acceleration to handle cryptographic operations at line rate. Current accelerators are optimized for RSA modular exponentiation and ECC point multiplication. Lattice cryptography needs something different: the Number Theoretic Transform (NTT).

NTT is essentially the Fast Fourier Transform over finite fields. For lattice dimensions of n, it reduces polynomial multiplication complexity from O(n²) to O(n log n). Hardware implementations require:

• Unified NTT/iNTT engines supporting different moduli (12-bit for ML-KEM, 23-bit for ML-DSA)
• Dedicated Keccak/SHA-3 accelerators for the hashing operations both algorithms depend on
• Expanded memory for the larger keys and intermediate values

Vendors like Fortinet are addressing this with ASICs designed for PQC workloads. When evaluating security appliances over the next few years, NTT acceleration capability should be on your checklist.

HSM and Root of Trust Evolution

Hardware Security Modules require deeper changes than simple API additions:

• Quantum-safe secure boot: Firmware must be signed and verified using PQC algorithms
• Expanded key storage: ML-KEM and ML-DSA private keys are orders of magnitude larger than current ECC keys
• Constant-time implementations: Side-channel resistance requires uniform memory access patterns and branch-free code paths

If your security architecture depends on HSMs for key management or code signing, start conversations with your vendors about their PQC roadmaps.

Middlebox and Firewall Implications

The larger handshakes create operational challenges for network middleboxes:

Packet fragmentation: When ClientHello or certificate chains exceed MTU, they fragment across multiple packets. Your next-gen firewalls must buffer and reassemble these fragments to inspect the handshake and apply security policies—increasing memory and compute load.

Protocol fragility: Some appliances may drop connections simply because they don’t recognize new PQC cipher suite identifiers or can’t handle oversized ClientHello messages. Early hybrid PQC browser deployments actually had to be rolled back due to this “protocol ossification” breaking connectivity.

Deep packet inspection: DPI tools examining TLS metadata will need updates to parse new extension types and understand hybrid key exchange patterns.

5G and Edge Computing

The 5G Service-Based Architecture uses mutual TLS extensively for inter-component communication. The “double impact” of mTLS—both client and server presenting certificates—means substantial signaling traffic increases.

The more immediate application is subscriber identity protection. Pilot projects have demonstrated ML-KEM encryption of subscriber identifiers (SUPI) on 5G SIM cards, preventing quantum-capable IMSI catchers from tracking users. This requires SIM secure elements capable of handling lattice-based encapsulation.

For Ultra-Reliable Low-Latency Communication (uRLLC) use cases, ML-KEM’s computational efficiency actually makes it viable—the raw speed is there, it’s the bytes-on-wire that need management.

Migration Timeline and Strategy

NIST and CISA have established clear milestones:

Phase	Timeline	Goal
Standard publication & pilots	2024-2025	Libraries like OpenSSL 3.5+ support ML-KEM/ML-DSA
Hardware readiness	2026-2028	HSMs and firewalls with native NTT acceleration available
Critical infrastructure migration	2029-2032	5G, financial, and government networks transition
Legacy retirement	2035+	RSA and ECC disallowed for federal use

NIST plans to deprecate 112-bit security strengths (RSA-2048) by 2030, with full disallowance by 2035.

Your Migration Checklist

1. Cryptographic inventory: Identify every application, service, and appliance using RSA or ECC. Tools exist to automate this discovery.

2. HNDL prioritization: Systems handling long-term confidential data—healthcare records, financial data, legal documents—need ML-KEM migration first.

3. Interdependence mapping: Upgrading clients without servers (or vice versa) breaks connectivity. Map your communication flows for coordinated rollout.

4. Hybrid deployment: Enable hybrid modes now where supported. Chrome and Firefox already negotiate X25519MLKEM768 with supporting servers.

5. Vendor engagement: Ask your HSM, firewall, and load balancer vendors about PQC roadmaps. Cryptographic agility—the ability to swap algorithms without forklift upgrades—should be a procurement criterion.

Implementation Security Considerations

Lattice algorithms are more complex than classical cryptography, creating a larger attack surface for side-channel analysis:

Constant-time implementation: Code must avoid branches based on secret values and ensure uniform memory access patterns. This is particularly challenging during ML-DSA’s rejection sampling phase.

Randomness quality: Both algorithms depend on high-quality randomness during key generation and signing. FIPS 203 and 204 require DRBG strength of at least 128 bits, with 256 bits recommended for higher security levels.

When evaluating PQC implementations, look for libraries with FIPS 140-3 validation (AWS-LC already has hybrid module certification) and established security audit history.

Conclusion

Post-quantum cryptography isn’t a distant concern—it’s an active infrastructure planning requirement. The HNDL threat makes waiting until quantum computers arrive too late for data that needs long-term confidentiality.

The good news: the standards are finalized, libraries are maturing, and hybrid deployment provides a graceful transition path. The work ahead involves hardware refresh cycles, protocol updates, and careful migration planning—but it’s tractable work with clear milestones.

Start with your cryptographic inventory. Identify your HNDL-sensitive data. Enable hybrid modes where available. And ensure your next generation of security hardware supports the NTT acceleration that ML-KEM and ML-DSA require.

The quantum future is coming. Your infrastructure can be ready.