Every few weeks, I hear the same message from peers and industry leaders: "PQC migration is just replacing RSA and ECC with ML-KEM and ML-DSA. It should be easier than a cloud migration."
In practice, it's rarely that simple.
Working in this space, I've found that the biggest challenges don't come from the algorithms, they come from deployment. In one project, a firmware update pipeline that had worked reliably for years began failing after introducing a PQC signature scheme. The implementation was correct, but the larger signatures exceeded assumptions built into an older network path. Days of troubleshooting led back to one unexpected cause: message size.
The algorithms are well understood. NIST has standardized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), with additional standards continuing to evolve. The real challenge is understanding everything PQC impacts once it reaches production.
This article focuses on those practical realities, from performance and interoperability to hybrid deployments, organizational complexity, and migration trade-offs.
The key takeaway: PQC is not an algorithm swap. It's a reassessment of the performance, size, latency, interoperability, and operational assumptions that have shaped cryptographic systems for the past two decades.
1. Security vs. performance
Every PQC algorithm buys quantum resistance by giving up compactness, and the size difference is not cosmetic:
Key takeaways from the comparison:
-
ML-DSA (Dilithium) is the primary replacement for RSA and ECDSA, offering strong performance but signatures that are roughly 50× larger, impacting bandwidth-sensitive and high-frequency signing workloads.
-
SLH-DSA (SPHINCS+) provides conservative, hash-based security, but its 7.8–50 KB signatures make it unsuitable for environments with limited bandwidth or storage.
-
ML-KEM (Kyber) delivers fast key exchange, but its public keys and ciphertexts are significantly larger than classical alternatives like X25519.
-
FN-DSA (Falcon) addresses signature size constraints but introduces greater implementation complexity due to its floating-point arithmetic requirements.
There is no universally "best" PQC algorithm.
Every choice is a trade-off between security, performance, signature size, bandwidth, latency, and implementation complexity. Selecting an algorithm simply because it is the default recommendation without evaluating your application's traffic patterns and operational constraints is a recipe for deployment problems.
2. Security vs. bandwidth (network efficiency)
Independent, real-world data backs this up: Cloudflare has reported that a hybrid X25519+ML-KEM-768 handshake adds roughly 2.3 KB and a median latency of 10-20 milliseconds compared to classical key exchange. That sounds trivial on a data-center backbone. It is not trivial once you leave one.
-
TLS handshakes grow enough to exceed single-packet size in some configurations, which introduces fragmentation and the retransmission overhead that comes with it.
-
Fragmentation shows up as latency that looks like a network problem, not a cryptography problem, which is exactly why it's hard to diagnose without knowing to look for it.
-
Bandwidth-constrained environments feel this first: satellite links, cellular backhaul in the field, industrial control networks, and legacy WAN links sized for classical handshake overhead.
-
Middleboxes matter too. Load balancers, proxies, and network appliances that inspect or terminate TLS were often built with assumptions about maximum certificate and handshake size that PQC quietly violates.
As of early 2026, Cloudflare reported that only around 1.8% of TLS 1.3 connections it observes use post-quantum key exchange, a useful reality check on how early we still are in real-world deployment, even with standards finalized for more than a year.
[RELATED: 2030 Clock Is Ticking: The Accelerated Post-Quantum Cryptography Mandate]
3. Performance vs. resource usage (embedded and constrained devices)
While PQC performs well on modern servers, embedded and IoT devices face challenges.
Trade-offs include:
-
Higher CPU utilization
-
More RAM and flash storage
-
Greater power consumption
-
Longer execution times on constrained hardware
Some devices may require hardware upgrades or cryptographic offloading.
4. Cost vs. future readiness
Migrating to PQC is an enterprise-wide investment, and the costs are broader than most initial scopes capture:
-
Cryptographic discovery and inventory across applications, infrastructure, and third-party dependencies, often a decade or more of accumulated systems.
-
Software updates across every affected application and service.
-
Hardware replacement for constrained devices that can't run PQC as-is.
-
Vendor coordination, since you almost certainly don't control every cryptographic dependency in your stack, your vendors do, and their timelines become your timeline.
-
Employee training, because PQC introduces failure modes and operational patterns most security and infrastructure staff haven't worked with before.
-
Testing and certification, particularly in regulated industries where cryptographic changes trigger re-certification.
5. Standardization vs. agility
Standards are still evolving, HQC's draft standard lands in early 2026 with finalization in 2027, and more signature schemes are in development. That's thorough, but it means the ground can shift under a multi-year plan. Crypto-agility is the fix: design systems so swapping an algorithm is a configuration change, not a re-architecture.
The least airtime, the most schedule slippage. A real migration touches security and PKI teams, infrastructure and DevOps, procurement and vendors, legal and compliance, and every business unit running cryptography someone first has to find. Regulatory pressure is accelerating this: Executive Order 14412, issued in June 2026, mandates an accelerated federal PQC migration timeline with compliance flowing down through contractors—a preview of what's likely coming to commercial sectors.
This is an optimization problem, not an upgrade. You're balancing security against performance, bandwidth against resistance, cost against risk, standardization against agility, technology against organizational capacity, and where you land depends on your systems and risk tolerance.
Start with the unglamorous work: a real cryptographic inventory, performance tests against actual use cases, and procurement, legal, and infrastructure in the room now.
The algorithms were the easy part. The trade-offs are the real project.
Next in this series (Part 3), I'll cover why hybrid cryptography was supposed to be the safe choice. It's often the harder one.
Read Part 1 of this series here.
This article appeared originally on LinkedIn here.
To help security teams and leaders transition from panic to a practical roadmap, SecureWorld is bringing together the brightest minds in the industry for the SecureWorld Quantum Cryptography virtual conference on September 23, 2026. See details and register to attend here.
