Can Quantum-Safe Cryptography Migration Run in Production?

AdvancedUNO
8 Aug, 2026
Can Quantum-Safe Cryptography Migration Run in Production?

6 min read

The Reality of the Quantum Handshake

  • The Catalyzing Shift: Publication of FIPS standards and NIST IR 8547 drafts has forced organizations to move from theoretical planning to concrete product roadmaps.
  • The Production Friction: While updating OpenSSL to version 3.5 takes under two hours, the resulting key sizes cause severe packet fragmentation across legacy network hardware.
  • The Immediate Threat: Well-resourced adversaries are actively capturing and storing encrypted enterprise traffic today under "harvest now, decrypt later" strategies.
  • The Operational Vulnerability: Legacy load balancers, firewalls, and embedded devices fail to handle the larger overhead of hybrid ML-KEM handshakes, stalling deployments.

The Great Mathematical Plumbing Remodel

We have spent the last thirty years living in a state of magnificent digital complacency, operating on the assumption that our encrypted data is as safe as houses. Every time you buy a book, check your bank balance, or send an email, a silent, invisible piece of mathematical wizardry occurs in the background, factoring giant numbers to keep prying eyes at bay. It is the digital equivalent of indoor plumbing: we only notice it when it stops working.

That complacency is quietly eroding. The National Cyber Security Centre (NCSC) and Vodafone recently convened a landmark workshop of government, industry, and academic leaders to address a deeply unsettling reality. While a cryptographically relevant quantum computer does not exist yet, the threat to our digital infrastructure is already here. Adversaries are actively capturing encrypted enterprise traffic today, storing it in vast server farms with the sole intention of decrypting it the moment quantum hardware catch up. Security teams call this "harvest now, decrypt later," and it has transformed quantum-safe cryptography migration from an academic talking point into an immediate operational headache.

The migration is not a sudden, clean break from the past. It is an uneven, messy, and half-finished transition. On paper, the path is clear: NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (Sphincs+) in August 2024, and OpenSSL delivered native support in its 3.5 long-term-support release in April 2025. You can theoretically upgrade an Nginx server to support hybrid post-quantum key exchange in about 75 minutes. But in production, where legacy mainframe databases, industrial IoT devices, and ancient firewalls rule the roost, the transition is hitting a wall of physical constraints.

The Physical Reality of Giant Keys

To understand why this migration is stalling in the wild, we have to look at the sheer physical size of the new mathematical algorithms. For decades, we have enjoyed highly compact cryptographic keys. An elliptic curve key (ECDH) is a svelte 32 bytes, while an RSA-2048 public key is 256 bytes. They slip through the internet's standard packet structures like a hot knife through butter.

The new quantum-safe algorithms are, by comparison, absolutely gargantuan. ML-KEM-768 requires a public key of 1,184 bytes and a ciphertext of 1,088 bytes. If you attempt to use ML-DSA-65 for signatures, you are looking at a 1,952-byte public key and a massive 4,032-byte signature. In network terms, this is the equivalent of trying to squeeze a fully inflated bouncy castle through a standard residential cat flap.

Public Key Size Comparison (Bytes)
ECDSA P-25664 BytesRSA-2048256 BytesML-KEM-7681184 BytesML-DSA-651952 Bytes

Figures compiled from the sources cited below.

The Collision of Mathematics and Middleboxes

In a representative secondary-market financial services portfolio, an engineering team attempted to enable hybrid ML-KEM-768 key exchange on their edge load balancers. While local tests on modern Linux loopback adapters showed sub-millisecond overhead, real-world traffic running through older, hardware-accelerated middleboxes suffered a p99 latency spike from 45ms to 1,200ms.

The culprit was not the CPU overhead of the new math, but packet fragmentation. The standard Maximum Transmission Unit (MTU) of an Ethernet frame is 1,500 bytes. When a TLS Client Hello and its corresponding Server Hello exceed this limit due to the massive ML-KEM keys, the TCP packets must be fragmented. The network's older firewalls and load balancers, unprepared for fragmented TLS handshakes, dropped the packets entirely, forcing endless TCP retransmissions. The migration stalled not because the software was ready, but because the underlying hardware simply could not handle the physical bulk of quantum safety.

The Regulatory Squeeze and Legacy Stagnation

While network engineers wrestle with MTU limits, compliance deadlines are creeping closer. The transition framework published in the draft of NIST IR 8547 calls for RSA-2048 and ECC-256 to be deprecated by 2030 and completely disallowed after 2035. This applies directly to federal agencies and their contractors, but the ripple effects are hitting global enterprises.

This timeline has created a deep division within corporate infrastructure. Modern web applications and cloud-native services are migrating rapidly, but core transactional systems are dragging their feet. Hardware Security Modules (HSMs) purchased less than a decade ago often lack the physical memory or firmware upgradeability to run FIPS 203 or FIPS 204 algorithms in hardware. Replacing these units is an incredibly expensive capital expenditure that many CFOs are reluctant to authorize until the quantum threat is on their doorstep.

Algorithm Standard Public Key Size (Bytes) Signature/Ciphertext (Bytes) Production Readiness
ECDH P-256 FIPS 186-5 64 64 Legacy Standard (Deprecated by 2030)
RSA-2048 FIPS 186-5 256 256 Legacy Standard (Disallowed after 2035)
ML-KEM-768 FIPS 203 1,184 1,088 Supported in OpenSSL 3.5; network issues in wild
ML-DSA-65 FIPS 204 1,952 4,032 High storage overhead; limited hardware support

Where Legacy Infrastructure Actually Holds Up

Despite the push toward modern post-quantum standards, there are specific environments where rushing to migrate actually introduces more risk than it resolves. In highly isolated, air-gapped industrial control networks running SCADA protocols, the "harvest now, decrypt later" threat model is practically non-existent. Because these systems do not expose their traffic to the public internet, there is no adversary sitting on the wire capturing packets for future decryption.

In these specialized enclaves, forcing a rapid upgrade to ML-KEM or ML-DSA can be disastrous. The microcontrollers running PLC devices often operate with mere kilobytes of RAM and clock speeds measured in megahertz. Forcing these tiny processors to compute lattice-based cryptography would cause severe buffer overflows or complete system lockups. For these legacy environments, maintaining classical, lightweight cryptography is the only sensible operational choice until the physical hardware reaches the end of its natural lifecycle.

Leading Indicators to Track

  • HSM Vendor Firmware Roadmaps: Monitor whether your hardware security module vendors (such as Thales or Entrust) provide native, hardware-accelerated support for FIPS 203/204, rather than slow software emulation.
  • Middlebox MTU Handling: Track the error rates of fragmented TLS Client Hellos on your edge firewalls and load balancers to identify which network segments will choke on larger key sizes.
  • OpenSSL 3.5+ Adoption in Base Images: Watch the upgrade cycles of your enterprise container base images (such as Alpine or Red Hat Universal Base Image) to determine when native post-quantum libraries become the default.

Frequently Asked Questions

What happens to our compliance audit trail when a legacy HSM cannot support FIPS 203/204 without a hardware replacement?

If your HSM cannot be upgraded via firmware, you will fail to meet the NIST IR 8547 deprecation guidelines for RSA-2048 by 2030. To maintain compliance without a multi-million-dollar hardware replacement, you must implement a hybrid architecture. This involves offloading the TLS handshake to a modern, software-defined proxy layer running OpenSSL 3.5+, while reserving the legacy HSM solely for internal, low-risk signing operations that do not traverse the public internet.

How do we handle packet fragmentation when our corporate VPNs and SD-WAN tunnels enforce a strict 1400-byte MTU limit?

When MTU limits are strictly enforced, the larger public keys of ML-KEM-768 will trigger packet drops. You must configure TCP Maximum Segment Size (MSS) clamping on your routers to force clients to negotiate smaller segment sizes, or implement hybrid key exchange configurations that prioritize algorithms with smaller packet footprints. If fragmentation persists, you may need to temporarily fall back to classical ECDH for VPN tunnels while utilizing post-quantum cryptography exclusively for application-layer traffic.

The Architect's Verdict: Do not let vendor marketing convince you that quantum-safe migration is a simple software update. While the cryptographic libraries are ready, your underlying network hardware and legacy HSMs are almost certainly not. Begin audit-mapping your network's MTU limits and hardware lifecycles today, or prepare for severe production outages when the regulatory deadlines arrive.

Related from this blog

Sources

Next Post Previous Post
No Comment
Add Comment
comment url