Why Post-Quantum Migration Is More Than an Algorithm Upgrade

Key Takeaways

• NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on August 13, 2024. FIPS 206 (FN-DSA, based on FALCON) remains in draft as of 2026.
• Post-quantum keys and signatures are dramatically larger than RSA or ECC, which changes protocol behavior, hardware requirements, and infrastructure capacity, not just the algorithm in use.
• A cryptographic inventory has to exist before phases, budgets, or vendor conversations can be planned with any accuracy.
• A practical migration runs through discovery, prioritization, pilot testing, staged rollout, and validation, not a single cutover event.
• Vendor coordination, staff training, and executive-level governance determine whether a migration stays on schedule as much as the algorithms chosen do.
• Interoperability and performance testing evidence, not a successful lab benchmark alone, is what proves a migration is ready for production.

Published: April 2026. Updated: August 2026. Reviewed by Encryption Consulting’s PQC Advisory team.

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 ECC in mind. Post-quantum algorithms challenge many of those assumptions, exposing dependencies that rarely appeared during previous cryptographic transitions, and doing so at the same time that organizations still have to run the inventory, vendor, and governance work a migration of this scale requires.

What Does “Algorithm Upgrade” Actually Cover, and What’s Missing?

An algorithm upgrade covers selecting and implementing a NIST-standardized post-quantum algorithm, such as ML-KEM for key establishment or ML-DSA for signing, in place of RSA or ECC. That is a real and necessary decision, but it is one decision inside a much larger program.

What algorithm selection does not cover: the protocol overhead those larger keys and signatures introduce, the hardware and infrastructure that has to support them, the cryptographic inventory needed to know where RSA and ECC are actually used, the vendor coordination required when a dependency is outside your direct control, the testing evidence needed to prove a rollout is safe, and the governance, budget, and staffing decisions that keep the effort on schedule. This article covers each of those in turn: current standards and deadlines, why an inventory has to come first, the protocol and hardware caveats that show up in deployment, a phased process for running the migration, the testing evidence worth collecting, and an implementation checklist covering the organizational side of the work.

What Are the Current PQC Standards and Deadlines?

NIST has finalized three post-quantum algorithm standards, and a fourth is still in draft. Government and industry timelines built on top of those standards add further deadlines that a migration plan has to account for.

On August 13, 2024, NIST published its first three finalized post-quantum cryptography standards: FIPS 203, which defines ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) as the primary general-purpose key establishment standard; FIPS 204, which defines ML-DSA (Module-Lattice-Based Digital Signature Algorithm) as the primary general-purpose signature standard; and FIPS 205, which defines SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), a structurally different, hash-based signature scheme intended as a backup if weaknesses are found in lattice-based constructions. A fourth standard, FIPS 206 (FN-DSA, based on FALCON), remains in draft and should not be built into a production timeline until NIST finalizes it.

Two further timelines shape when this work has to be done. NIST IR 8547 points toward deprecating RSA and ECC around 2030 and disallowing them around 2035 for systems requiring 112 bits of security strength or more, a timeline worth confirming directly with NIST before it becomes an internal deadline, since transition guidance of this kind is periodically revised. National security systems fall under a separate, generally stricter set of obligations defined by CNSA 2.0. Separately, the CA/Browser Forum is shortening public TLS certificate validity on a fixed schedule, which forces certificate automation but does not by itself address non-certificate cryptography; see our breakdown of preparing for 47-day TLS certificates for that schedule in detail. If your primary investment so far has been certificate lifecycle management, our companion guide on why CLM alone is not enough for post-quantum readiness covers the certificate-specific side of that gap; this article focuses on the broader organizational work a migration needs regardless of which tooling is already in place.

Why Is a Cryptographic Inventory a Prerequisite for Migration?

A cryptographic inventory is a prerequisite because none of the later decisions, prioritization, budget, vendor outreach, or testing scope, can be made accurately without knowing what cryptography exists and where. Teams that skip this step tend to plan a migration around the certificates and algorithms they already know about, then discover the rest during the pilot.

A useful inventory covers certificates, but it does not stop there. It has to reach SSH keys, symmetric encryption keys, algorithms embedded directly in application source code, cryptography used inside HSMs and TPMs, and the cryptographic choices made by cloud services, container platforms, and CI/CD pipelines. Each of those categories carries its own owner, its own upgrade path, and often its own vendor dependency, and each has to show up in the plan before that plan can be considered complete.

Discovery also has to be continuous rather than a one-time project. New applications, services, and dependencies appear constantly, and a cryptographic inventory that goes stale six months after it is built stops being useful for prioritization. A continuously maintained inventory, often expressed as a Cryptographic Bill of Materials (CBOM), lets an organization rank remediation by business impact rather than by raw certificate count, and it removes the need to repeat a large discovery exercise every time an algorithm or deadline changes. For a closer look at where inventory efforts most often miss cryptography, see our guide on the endpoint blind spot in PQC migration.

What Protocol and Interoperability Caveats Should You Plan For?

Plan for larger message sizes, protocol support gaps outside TLS, and a transition period where hybrid deployment is the norm rather than the exception, because post-quantum algorithms change what protocols and middleboxes have to handle on the wire.

An RSA-2048 public key is 256 bytes, while an ECDSA P-256 signature is approximately 64 bytes. By comparison, ML-DSA-65 uses a 1,952-byte public key and produces a 3,309-byte signature, and ML-KEM-768 uses a 1,184-byte public key and a 1,088-byte ciphertext. These larger cryptographic objects 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, roughly 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 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, and confirm each one before it sits in a production path.

During the transition, most organizations will run hybrid or composite deployments that combine a classical algorithm with a post-quantum algorithm, so a client that cannot yet validate the post-quantum component still has a classical fallback. Confirm which of your certificate authorities, TLS libraries, and clients actually support the specific hybrid formats you plan to issue before rolling them out broadly; support is uneven across vendors and changes frequently enough that it needs to be reconfirmed rather than assumed.

How Do 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. Understanding where these changes occur lets teams plan capacity upgrades and infrastructure changes before deployment rather than after production issues appear.

Why Weren’t Hardware Constraints 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. Organizations that want to avoid owning that hardware refresh cycle directly can evaluate a hosted alternative such as Encryption Consulting’s HSM-as-a-Service, which shifts firmware and certification currency to the provider. These constraints are not weaknesses in post-quantum algorithms themselves, but a reflection of how tightly cryptographic capability is coupled to hardware lifecycles, which is exactly the kind of dependency a cryptographic inventory needs to surface early rather than during a pilot.

Why Is Crypto-Agility 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. FIPS 205’s SLH-DSA exists precisely because it is structurally different from the lattice-based approach used in ML-DSA, giving the ecosystem an alternative if weaknesses are identified in lattice-based constructions. For a deeper, PKI-specific breakdown of building this into certificate authority architecture, see our guide on PKIaaS and crypto-agility strategy.

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, which is the core reason algorithm selection alone was never going to be the hard part.

What Are the Phased Migration Steps?

A practical PQC migration runs through five phases, treated as a repeatable program rather than a one-time project.

1. Discover. Build a cryptographic inventory covering certificates, keys, applications, libraries, HSMs, cloud services, and code repositories, rather than starting from a certificate-only list.
2. Prioritize by business impact. Rank remediation by what an asset protects and how exposed it is, factoring in vendor readiness and hardware refresh timelines, not by raw certificate or key count.
3. Pilot in a controlled environment. Deploy hybrid or post-quantum algorithms on a limited set of systems, coordinate with the vendors and internal teams that own the surrounding infrastructure, and measure performance and interoperability before touching production traffic.
4. Roll out in stages. Expand from the pilot in waves sized to what your testing evidence supports, keeping a documented rollback path for each wave and pairing certificate-side changes with a certificate lifecycle platform such as CertSecure Manager where automation is needed.
5. Validate and govern. Confirm each wave against the testing evidence defined below, then feed the results back into the inventory and priority list on a fixed cadence, since new applications and dependencies appear continuously.

Vendor coordination and governance sit inside every phase above rather than after them. A pilot that succeeds technically but was never scoped with the vendors whose products sit in the same trust chain will stall at rollout, and a rollout that has no governance owner will drift between business units running inconsistent timelines. For a full breakdown of who should own each of these decisions, see our guide on PQC program governance roles and responsibilities.

What Testing Evidence Should You Collect Before Rollout?

Collect interoperability results, performance benchmarks, hardware validation records, and a tested rollback plan before any production cutover, and keep that evidence as part of the migration record rather than treating a passed test as the end of the exercise.

• Interoperability testing. Confirm that every client, load balancer, proxy, and downstream service in a given trust chain can actually validate the hybrid or post-quantum certificate before it reaches production. A certificate that renews successfully but fails validation at the client is a self-inflicted outage.
• Performance benchmarking. Measure the effect of larger ML-KEM and ML-DSA key and signature sizes on TLS handshake latency, connection setup time, and bandwidth-constrained or embedded environments, and compare it against an existing baseline rather than a vendor’s isolated benchmark.
• HSM and CA validation. Verify that the HSM firmware and CA software generating and signing post-quantum keys have been tested against the finalized FIPS 203, 204, and 205 specifications, not an earlier draft, and that FIPS 140-3 certification status is confirmed for regulated environments.
• Staged rollback plan. Keep a documented, tested path back to the previous classical or hybrid configuration for any system where post-quantum validation fails in production, so a failed rollout does not become an outage.

For a structured way to check that this evidence has actually been gathered before a rollout decision, our post-quantum readiness assessment walks through 75 questions across inventory, PKI, HSM, TLS, code signing, applications, vendors, and governance.

Algorithm Swap vs. Full Migration: What’s the Gap?

Activity	Covered by an Algorithm Swap	Requires Full Migration Scope
Selecting ML-KEM and ML-DSA for a given system	Yes	No, this is the swap itself
Confirming a library or CA can produce post-quantum keys	Yes	No
Finding every RSA and ECC dependency, certificate-based or not	No	Yes, needs a cryptographic inventory
Validating middlebox and MTU behavior under larger message sizes	No	Yes, needs interoperability and performance testing
Confirming HSM and TPM firmware and FIPS 140-3 readiness	No	Yes, needs hardware validation
Coordinating third-party vendors on the same trust chain	No	Yes, needs vendor coordination
Budgeting hardware refreshes and staff training	No	Yes, needs governance and budget planning
Building in crypto-agility for the next algorithm change	No	Yes, needs architectural design

What Are the Limitations of This Guidance?

This article describes the general shape of a PQC migration program and does not replace organization-specific planning. A few limits worth stating directly:

• FIPS 206 (FN-DSA) is still in draft. Any timeline built around it should be treated as provisional until NIST finalizes it.
• Regulatory and industry-specific deadlines vary. Financial services, government, and national security systems governed under CNSA 2.0 often face earlier or stricter deadlines than the general NIST IR 8547 timeline referenced here.
• Vendor support for hybrid and post-quantum algorithms is uneven and changes frequently. Confirm current support directly with each CA, HSM, cloud provider, and client vendor rather than relying on this article’s snapshot.
• Performance figures cited here come from published research on general TLS, SSH, and IPsec deployments. Actual impact depends on your own protocol mix, traffic volume, and hardware, and should be confirmed with your own benchmarking.
• This is not exhaustive migration guidance for every environment. Highly regulated, air-gapped, or safety-critical systems typically need additional validation steps beyond what is outlined here.

Implementation Checklist

• Build a cryptographic inventory covering certificates, SSH keys, symmetric keys, embedded libraries, HSMs, cloud services, and code repositories.
• Confirm FIPS 203, 204, and 205 support with every HSM, CA, TLS library, and cloud provider in your environment, and clarify the FIPS 206 status with each vendor.
• Map every RSA and ECC dependency against the NIST IR 8547 deprecation timeline and any applicable CNSA 2.0 obligations.
• Pilot hybrid or composite deployments and test interoperability with every client and downstream service before production rollout.
• Benchmark handshake latency and message-size effects from larger post-quantum keys and signatures against your current baseline.
• Assign an executive-level governance owner for cryptographic decisions, exceptions, and testing sign-off, and set a budget that covers hardware refresh cycles, not just software changes.
• Schedule vendor readiness conversations early for every CA, HSM, cloud, and appliance vendor in a given trust chain, since their timelines will set the pace of your own.
• Train the operations and security staff who will run the pilot and rollout, not only the architects who selected the algorithms.
• Document a tested rollback path for any post-quantum deployment before it goes to production.

What Would Encryption Consulting Recommend?

Our recommendation is direct: budget and staff a PQC migration as a multi-phase organizational program, not as an algorithm-selection project handed to one architecture team. 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 Services

Encryption Consulting supports organizations throughout this journey with end-to-end PQC migration services covering discovery, assessment, planning, validation, and deployment through a structured, nine-phase roadmap.

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.

Both services are backed by Encryption Consulting’s ISO/IEC 27001:2022 and SOC 2 aligned delivery practices. 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.

Frequently Asked Questions

If we have already selected ML-KEM and ML-DSA, are we most of the way through our PQC migration? Not necessarily. Algorithm selection is one decision inside a larger program that also needs a cryptographic inventory, hardware and infrastructure validation, vendor coordination, testing evidence, and governance. Many organizations that select algorithms first still have the majority of the work ahead of them.

How long does a typical PQC migration take from start to finish? It depends heavily on inventory scope, vendor readiness, and hardware refresh cycles, but most enterprise programs run across multiple years rather than a single project cycle, particularly where HSM or TPM hardware refreshes are on the critical path.

Do we need new hardware to support post-quantum algorithms? Often, at least eventually. Many current HSMs and TPMs can support ML-KEM and ML-DSA through firmware updates, but production use in regulated environments typically waits on FIPS 140-3 certification of that firmware, and some older hardware will not receive updates at all.

Who should own a PQC migration program? Ownership works best as a named executive sponsor supported by a cross-functional team spanning security architecture, infrastructure, procurement, and the business units whose applications depend on the systems being migrated. Leaving ownership solely with the team that selected the algorithms tends to stall the program once vendor and budget questions appear.

Is this different from just deploying certificate lifecycle management or a cryptographic inventory tool? Yes. CLM automates certificate issuance and renewal, and an inventory tool provides visibility, but neither one on its own covers vendor coordination, hardware validation, phased rollout planning, or governance. Our guide on why CLM alone is not enough for post-quantum readiness covers the certificate-specific version of this gap in more depth.

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, and it adds organizational work, inventory, vendor coordination, testing, and governance, that has nothing to do with which algorithm was selected. Issues such as message size growth, performance impacts, hardware constraints, and crypto-agile architecture show that the technical challenge extends well beyond choosing ML-KEM or ML-DSA, and the phases, checklist, and testing evidence above show that the organizational challenge is just as real.

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, fund the hardware and staffing it requires, and run the whole effort as a governed program with a named owner. Each layer, technical and organizational, introduces constraints that must be tested, budgeted, and adapted in context rather than assumed to be settled once the algorithm is chosen.

Ultimately, post-quantum readiness is less about a single migration milestone and more about building systems and teams that can absorb change. Crypto-agility, careful infrastructure validation, vendor coordination, and clear governance determine whether this transition remains manageable or becomes a repeated cycle of large-scale redesign.

References

• NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 2024. nist.gov
• Federal Register, “Announcing Issuance of Federal Information Processing Standards (FIPS) FIPS 203, FIPS 204, and FIPS 205,” August 2024. federalregister.gov
• NIST IR 8547, “Transition to Post-Quantum Cryptography Standards” (algorithm deprecation and disallowal guidance).
• CA/Browser Forum, Ballot SC-081v3, TLS certificate validity and validation reuse reduction schedule.