A security team spends eight months selecting ML-KEM-768 for key establishment and ML-DSA-65 for signing under NIST‘s post-quantum cryptography (PQC) standards, gets sign-off from the architecture board, and considers the hardest part of the migration complete. Then the pilot deployment begins.
A load balancer that has quietly assumed for years that a TLS handshake fits within a small number of network packets suddenly has to process significantly larger cryptographic messages. Handshake latency increases, packet fragmentation becomes more common, and performance testing exposes assumptions that had never mattered with RSA or elliptic curve cryptography (ECC). The algorithm selection wasn’t the problem. The assumption that selecting an algorithm was the difficult part was.
Modern enterprise infrastructure was built around decades of assumptions about how public-key cryptography behaves. Protocols, applications, security appliances, and certificate management workflows were designed with the size and performance characteristics of RSA and elliptic curve cryptography (ECC) in mind. Post-quantum algorithms challenge many of those assumptions, exposing dependencies that rarely appeared during previous cryptographic transitions.
This article examines four areas where those assumptions begin to break down: larger cryptographic objects and protocol overhead, performance impacts across systems, infrastructure and hardware readiness, and the need for crypto-agility so future algorithm transitions become routine rather than another large-scale migration project.
The Hidden Cost of Larger Cryptographic Objects
An RSA-2048 public key is 256 bytes, while an ECDSA P-256 signature is approximately 64 bytes. By comparison, ML-DSA-65, NIST’s primary general-purpose post-quantum digital signature algorithm standardized in FIPS 204, uses a 1,952-byte public key and produces a 3,309-byte signature. ML-KEM-768, standardized in FIPS 203 for key establishment, uses a 1,184-byte public key and a 1,088-byte ciphertext. These significantly larger cryptographic objects fundamentally change the amount of data protocols must exchange during authentication and key establishment.
Those larger numbers matter the moment they hit the wire. Researchers studying TLS 1.3 handshakes found that replacing a single leaf certificate’s issuer signature with ML-DSA-65 grows that signature alone from 64 bytes to 3,309 bytes, and a two-certificate chain carrying embedded Certificate Transparency timestamps can push total on-wire certificate overhead past 17,000 bytes, about 32 times what a classical Ed25519 chain costs.
Separate studies of post-quantum deployment across TLS, SSH, and IPsec show that this is not a TLS-specific issue. Post-quantum public keys, ciphertexts, and signatures routinely exceed typical network MTU sizes, triggering packet fragmentation, additional round trips, and increased processing overhead. These effects become even more pronounced on bandwidth-constrained embedded and IoT devices. Organizations must therefore evaluate load balancers, firewalls, proxies, VPN gateways, and other middleboxes that were designed around the message sizes produced by RSA and ECC.
Performance Changes Extend Beyond the Handshake
Post-quantum migration affects more than protocol message sizes. The computational characteristics of post-quantum algorithms differ from RSA and ECC, changing how applications, servers, and security infrastructure consume CPU, memory, and network resources. Some operations, such as ML-KEM key generation, are actually faster than their classical equivalents, while others require significantly more processing or data movement, making performance evaluation an essential part of migration planning.
These gains can be offset by the larger public keys, signatures, and ciphertexts that must be generated, transmitted, stored, and processed at scale. Systems that terminate thousands of TLS connections per second, issue large numbers of certificates, or perform frequent cryptographic operations may experience different bottlenecks than they do today, even where the underlying algorithm is computationally efficient in isolation.
Performance testing therefore cannot focus solely on cryptographic benchmarks. Organizations should evaluate end-to-end behavior under realistic workloads, including TLS handshake latency, certificate issuance rates, memory consumption, network utilization, and the impact on constrained devices. Systems that terminate thousands of TLS connections per second, issue large numbers of certificates, or perform frequent cryptographic operations may encounter bottlenecks that were not present with RSA or ECC. Understanding where these changes occur allows teams to plan capacity upgrades and infrastructure changes before deployment rather than after production issues appear.
Hardware Constraints Were Not Designed for Post-Quantum Scale
Hardware security modules (HSMs) and trusted platform modules (TPMs) that protect signing keys today were originally designed and optimized for RSA and ECC key sizes and workloads. In comparison, ML-DSA private keys are significantly larger, ranging from roughly 2.5 KB at lower parameter sets to about 4.8 KB at higher ones. This increase affects not only storage, but also key loading, backup, and operational handling inside constrained hardware environments.
Many production HSM deployments follow hardware refresh cycles measured in a decade or more, which does not always align with the pace required for cryptographic transitions. TPMs introduce additional constraints because they are typically integrated directly into system motherboards rather than being modular components, which ties secure boot and platform attestation capabilities to vendor firmware support.
Even when HSM vendors introduce support for ML-KEM and ML-DSA through firmware updates, those capabilities often depend on completion of certification processes such as FIPS 140-3 validation before they can be used in regulated environments. This creates a gap between functional availability and production approval. These constraints are not weaknesses in post-quantum algorithms themselves, but a reflection of how tightly cryptographic capability is coupled to hardware lifecycles.
Crypto-Agility Is the Missing Architectural Layer
Many migration programs treat post-quantum adoption as a finite engineering task: identify RSA and ECC usage, replace it with ML-KEM and ML-DSA, and complete the rollout. This approach addresses the immediate transition but does not account for subsequent algorithm changes or future cryptographic requirements.
Crypto-agility refers to designing systems so that cryptographic primitives are abstracted from application logic. Instead of embedding specific algorithms into services, systems rely on interchangeable cryptographic interfaces, allowing algorithms such as ML-KEM-768 to be replaced in the future without requiring large-scale application rewrites.
NIST IR 8547 reflects this reality by framing post-quantum adoption as an ongoing transition process rather than a fixed set of replacements. It acknowledges that parameter sets and algorithm recommendations may continue to change as implementations mature. Similarly, FIPS 205 standardizes SLH-DSA, a stateless hash-based signature scheme that is structurally different from lattice-based approaches used in ML-DSA. It serves as an alternative option in case weaknesses are identified in lattice-based constructions.
Systems designed with crypto-agility can adapt to such shifts through configuration or controlled upgrades. Systems that treat migration as a one-time algorithm swap typically require deeper redesign when cryptographic assumptions change again.
How Encryption Consulting Can Help
Organizations that begin a PQC migration quickly discover that the challenge extends beyond algorithm selection. Success depends on understanding where cryptography exists, assessing the impact of quantum-vulnerable systems, coordinating with vendors, modernizing PKI infrastructure, and building the operational capabilities required to support future cryptographic transitions.
PQC Advisory Service
Encryption Consulting supports organizations throughout this journey with end-to-end PQC migration services covering discovery, assessment, planning, validation, and deployment.
Our PQC Advisory Services help organizations identify certificates, keys, algorithms, protocols, and cryptographic dependencies across cloud environments, applications, infrastructure, HSMs, source code repositories, containers, APIs, and CI/CD pipelines. Using this visibility, we assess exposure to quantum-vulnerable cryptography, identify high-priority remediation areas, and develop risk-based migration roadmaps aligned with NIST standards, regulatory requirements, and business objectives.
Beyond planning, Encryption Consulting assists with vendor readiness assessments, proof-of-concept validation, interoperability testing, hybrid cryptography deployments, crypto-agile PKI architecture design, and enterprise-scale implementation programs. This structured approach enables organizations to move from fragmented cryptographic visibility to a governed, measurable, and sustainable PQC migration program.
CBOM Secure
A successful post-quantum transition begins with visibility. Encryption Consulting’s CBOM Secure provides continuous discovery and inventory of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services.
Unlike a point-in-time inventory, CBOM Secure continuously generates and consumes Cryptographic Bills of Materials (CBOMs) while tracking certificates, keys, algorithms, and cryptographic dependencies across the environment. It provides visibility into what is deployed, where it is running, and how those dependencies evolve over time.
The platform supports policy-driven governance by validating cryptographic configurations against organizational standards, identifying deviations, and highlighting security, operational, and compliance risks. For organizations preparing for PQC migration, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms, prioritize remediation efforts, and establish the continuous cryptographic governance required to achieve long-term crypto-agility.
Whether your organization is starting from scratch with no formal inventory in place or is looking to operationalize an existing discovery effort into a continuous governance program, Encryption Consulting brings both the advisory depth and the platform capability to move you forward. To learn more about our PQC Advisory Services or CBOM Secure, visit encryptionconsulting.com or reach out to our team directly.
Conclusion
Post-quantum migration is not a direct replacement of one algorithm family with another. It changes the scale and behavior of cryptographic operations in ways that expose long-standing assumptions in protocols, hardware, and operational design. Issues such as message size growth, performance impacts, hardware constraints, and crypto-agile architecture show that the challenge extends well beyond selecting ML-KEM or ML-DSA.
The organizations that navigate this transition successfully are not the ones that simply complete an algorithm swap, but the ones that validate how cryptography behaves across the entire stack, from network devices to hardware security modules and certificate systems. Each layer introduces constraints that must be tested, measured, and adapted in context rather than assumed to be compatible by default.
Ultimately, post-quantum readiness is less about a single migration milestone and more about building systems that can absorb change. Crypto-agility, careful infrastructure validation, and awareness of real-world deployment constraints determine whether this transition remains manageable or becomes a repeated cycle of large-scale redesign.
