Post-quantum cryptography vs the reality of legacy code

AdvancedUNO
23 Jun, 2026
Post-quantum cryptography vs the reality of legacy code

8 min read

The federal mandate for post-quantum cryptography migration by 2030 reveals a massive gap between clean policy paper and dirty production code.

Jim sat in the fluorescent hum of a subterranean federal data center, staring at a terminal screen that had not changed its basic layout since the mid-1980s. On his desk lay a freshly printed copy of Executive Order 14409, signed into law on June 23, 2026. The document, titled "Securing the Nation Against Advanced Cryptographic Attacks," set a hard, unforgiving deadline: federal agencies and their contractors must complete the migration of all high-value assets to post-quantum cryptography (PQC) for key establishment by December 31, 2030. Jim, tasked with running the agency's systems, was looking at a legacy benefits-processing system that still relied on hardcoded RSA-2048 keys buried deep within compiled COBOL binaries.

To the politicians in Washington and the venture-backed security vendors in Silicon Valley, migrating to PQC is sold as a simple upgrade—a routine patch, like moving from TLS 1.2 to TLS 1.3. They talk about the "harvest now, decrypt later" threat as if it can be solved with a software license. But to the engineers who actually have to keep the packets moving, this mandate represents the most disruptive cryptographic overhaul in the history of computing. It is a forced march into unchartered mathematical territory, and the map they have been given does not match the terrain of the modern enterprise.

The Paper Mandate Meets the Bare Metal

The urgency behind the transition is real, even if the deployment timelines are optimistic. Under EO 14409, the federal government is attempting to outrun a quiet threat. Adversaries are actively exfiltrating petabytes of encrypted government, military, and corporate data today, storing it in massive data centers, and waiting for the arrival of a cryptanalytically useful quantum computer to decrypt it. To counter this, the executive orders lay out a dual-track strategy. While EO 14411 pushes the Department of Energy to build a large-scale quantum computer and orders the Department of Defense to field quantum sensors by September 30, 2028, EO 14409 acts as the defensive shield, forcing agencies to inventory their cryptographic assets and name a dedicated PQC migration lead within 30 days.

Federal PQC Migration Deadlines (EO 14409)
Dec 31, 2027
PQC Pilot Launch
Dec 31, 2030
Key Establishment Migration
Dec 31, 2031
Digital Signatures Migration

Figures compiled from the sources cited below.

The problem is that our entire digital economy is built on asymmetric encryption algorithms—primarily RSA and Elliptic Curve Cryptography (ECC)—that rely on the mathematical difficulty of factoring large integers or finding discrete logarithms. A sufficiently powerful quantum computer running Shor's algorithm can solve these problems in minutes. The National Institute of Standards and Technology (NIST) spent years evaluating replacements, eventually standardizing on lattice-based cryptographic algorithms, including ML-KEM (for key encapsulation) and ML-DSA (for digital signatures).

But swapping these algorithms out is not like swapping a flat tire. Lattice-based cryptography uses entirely different mathematical structures. The keys are significantly larger, the ciphertexts are bulkier, and the computational overhead behaves in ways that legacy hardware security modules (HSMs) and network appliances simply cannot handle without choking.

The Battle of the Handshakes: Hybrid Wrappers vs. Native Clean Cuts

When you sit down to plan this migration, you are immediately forced to choose between two fundamentally different architectural paths. Each has its own operational friction, its own hidden costs, and its own points of failure.

The first path is the Dual-Mode Hybrid Implementation. This approach wraps a classical algorithm (like ECDH) and a post-quantum algorithm (like ML-KEM) together in a single cryptographic handshake. The theory is elegant: if the post-quantum algorithm is later found to have a mathematical vulnerability—a very real concern given how recently these standards were finalized—the classical encryption layer still protects the data. Security suites from vendors like SandboxAQ, Keyfactor, and DigiCert heavily promote this hybrid approach because it allows organizations to meet compliance targets without completely abandoning their existing, battle-tested security controls.

The second path is the Native Pure-Play PQC Migration. This is the clean cut. You rip out the legacy RSA and ECC algorithms entirely and replace them with pure ML-KEM and ML-DSA implementations. It is the approach favored by greenfield cloud-native environments and modern software-as-a-service providers who can update their entire infrastructure stack with a single CI/CD pipeline run. There are no redundant handshakes, no double-encryption overhead, and no complex negotiation protocols to debug.

But when these two approaches collide with the physical limits of network routing, the theoretical elegance of both starts to fray.

The Broken Pipes of the Network Layer

To understand where the migration breaks down in production, you have to look at the size of the keys. An ECDH public key is a crisp 32 bytes. An ML-KEM-768 public key, by contrast, is 1,184 bytes. When you combine them in a hybrid handshake, the payload explodes.

Rule of Thumb: If your network infrastructure cannot handle IP packet fragmentation over standard WAN links, do not attempt a pure-play ML-DSA migration; the larger key sizes will trigger packet drops before the TLS handshake ever completes.

In a typical corporate network, the Maximum Transmission Unit (MTU) is hard-coded to 1,500 bytes. A standard classical TLS 1.3 handshake fits comfortably inside a single TCP packet. A hybrid handshake, or a pure ML-DSA signature handshake, easily breaches this 1,500-byte limit. The network is forced to fragment the packets.

In the clean world of software development, packet fragmentation is handled automatically by the OS. In the gritty reality of enterprise security, edge firewalls, load balancers, and intrusion prevention systems frequently drop fragmented packets, viewing them as potential denial-of-service attacks. The moment you turn on hybrid encryption in a production environment, random branch offices will quietly lose connectivity as their edge routers reject the fragmented cryptographic handshakes.

The Hidden Bottleneck of Hardware Security Modules

The network layer is only the first hurdle. The deeper, more expensive crisis is taking place inside the secure enclaves of the enterprise: the Hardware Security Modules (HSMs).

These specialized appliances, manufactured by companies like Thales and Entrust, are designed to generate, store, and protect cryptographic keys. They are built on hardened, application-specific integrated circuits (ASICs) that are mathematically optimized to perform RSA and ECC calculations at lightning speed. They are not, however, designed to perform the complex polynomial arithmetic required by lattice-based algorithms like ML-KEM.

If you run a high-volume transactional system—such as a payment processing network or a federal benefits portal—your HSMs are likely running near peak capacity. If you attempt to update their firmware to support PQC via software emulation, the performance penalty is devastating. In a representative transactional environment, shifting from hardware-accelerated RSA-2048 to software-emulated ML-KEM on a legacy HSM can drop transaction throughput by up to 80% while spiking CPU utilization to its limits.

This means that for the vast majority of enterprises and federal agencies, "cryptographic agility" is a marketing myth. You cannot simply patch your way to compliance. You have to buy new, expensive, post-quantum-ready HSMs, physically install them in your racks, and rewrite the integration code that connects your applications to them.

Where the Direct Native Approach Actually Holds Up

Given the sheer friction of hybrid deployments, there are specific scenarios where skipping the hybrid phase and going straight to native ML-KEM is the only logical move.

This is true in high-throughput, low-latency microservice architectures that operate entirely within a controlled cloud environment, such as AWS or Google Cloud. When your services communicate over a private, high-speed virtual private cloud (VPC) where MTU limits can be adjusted to 9,000 bytes (jumbo frames), the packet fragmentation issue disappears.

Furthermore, because these environments do not rely on legacy physical HSMs and instead use cloud-native key management services that have already been upgraded by the cloud providers, the hardware bottleneck is abstracted away. In these isolated, modern environments, the overhead of maintaining a hybrid cryptographic stack is simply dead weight that introduces unnecessary latency and doubles your attack surface.

The Deciding Variable: Operational Visibility

Ultimately, the choice between a hybrid wrapper and a native cut depends on a single, sobering variable: your current level of cryptographic visibility.

If you do not have an automated, real-time inventory of every certificate, key, and cryptographic library active across your production environment, attempting a native migration is operational suicide. You will inevitably break critical, undocumented dependencies that you did not know existed. For these legacy-heavy environments, the hybrid approach acts as an essential insurance policy, keeping the business running while you spend the next five years untangling your code.

The road to 2030 is not a software upgrade. It is a structural rebuild of the digital foundation we took for granted.

Frequently Asked Questions

What happens to our TLS handshake performance when we switch to ML-KEM-768?

In production environments, switching to ML-KEM-768 increases the handshake size from under 500 bytes to over 1,500 bytes. This forces the handshake to span multiple TCP packets, causing packet fragmentation. If your network firewalls or load balancers are configured to drop fragmented packets to prevent DDoS attacks, your TLS handshakes will fail entirely, resulting in connection timeouts.

How do we handle legacy HSMs that do not support NIST-approved PQC algorithms?

Legacy HSMs that lack dedicated hardware acceleration for lattice-based mathematics cannot be patched effectively. Running ML-KEM or ML-DSA in software emulation mode on these devices typically results in an 80% drop in cryptographic throughput. To maintain production performance, you must budget for and deploy new, post-quantum-capable HSM hardware that natively supports these algorithms.

What is the immediate impact of EO 14409 on non-federal commercial contractors?

While the executive order directly targets federal agencies, it explicitly includes federal contractors within its scope. If your organization provides software, cloud services, or IT infrastructure to the US government, you will be required to demonstrate a clear PQC migration roadmap and meet the same 2030 key establishment deadlines to maintain your contracts.

How does packet fragmentation during PQC handshakes affect our edge firewalls?

Many enterprise edge firewalls and intrusion prevention systems (IPS) are configured with strict security policies that drop fragmented IP packets. Because post-quantum handshakes exceed the standard 1,500-byte MTU limit, they are split across packets. This triggers firewall drop rules, causing silent connection failures for remote users and branch offices trying to access your network.

The Final Verdict: Do not let vendors sell you on the illusion of an easy, automated post-quantum transition. Your immediate priority is not buying new encryption software, but deploying discovery tools to locate your hidden, hardcoded RSA keys. You cannot migrate what you do not know you have.

Related from this blog

Sources

Next Post Previous Post
No Comment
Add Comment
comment url