Most organizations planning a post-quantum migration arrive at the same instinct: find every RSA and ECC dependency, swap in ML-KEM and ML-DSA, and call it done. It is a logical instinct. It is also how you cause an outage, because treating this like a software patch is how migrations go wrong.
NIST, NSA, and every major cloud and browser vendor that has already shipped post-quantum cryptography (PQC) agree on a safer answer: hybrid cryptography. This means running classical and quantum-resistant algorithms side by side during the transition. This is not just extra caution, but a deliberate choice, based on how new cryptography tends to fail in the real world.
This blog explains why a complete PQC migration is riskier than it looks, what hybrid cryptography actually gives you, and how to build a migration plan that treats hybrid as the default, not an afterthought.
Why You Cannot Just Swap Algorithms for PQC
Past cryptographic upgrades, like moving from SHA-1 to SHA-256, or from 1024-bit to 2048-bit RSA, were small changes. They swapped a parameter or a hash function inside a familiar algorithm family. PQC is a bigger change. ML-KEM and ML-DSA are built on new math, mostly structured lattices and they behave differently from RSA and ECC, and that difference affects real systems.
NIST’s own guidance says the new cryptography will not be a “drop-in replacement.” Organizations should expect different performance, higher computing cost, and new operational complexity. Keys and signatures are larger. Error handling works differently. The steps involved are new territory for the libraries, hardware, and protocols built around RSA and ECC over the last three decades.
That is exactly why NIST expects hybrid setups, combining classical and PQC algorithms, to be necessary during the transition. Hybrid is not a cautious extra step layered on top of the “real” migration. It is the migration strategy that every serious standards body and large-scale deployer is actually using.
Three Risks of a Single-Step PQC Migration
A single-algorithm cutover puts three different kinds of risk into one irreversible step:
- Algorithm immaturity risk: Lattice-based PQC algorithms have had far less public testing than RSA or ECC. NIST is not betting on any single algorithm either.
- Protocol and ecosystem readiness risk: Key exchange and certificate standards are not maturing at the same speed. A single cutover hits gaps the ecosystem has not filled yet.
- Operational and performance risk: Larger PQC keys and signatures change packet size, memory use, and CPU load in ways that may not show up until after rollout.
Let’s understand about each one in detail below.
1. Algorithm Immaturity Risk
Lattice-based cryptography is much less tested than RSA and ECC. RSA and ECC have survived about 40 years of public attacks and review. ML-KEM and ML-DSA have had far less scrutiny, even after NIST’s multi-year evaluation. ML-KEM, standardized in FIPS 203, is currently the only standardized post-quantum key-encapsulation method, and it is lattice-based.
To guard against the chance that lattice-based schemes turn out weaker than expected, NIST selected HQC, a different kind of algorithm based on codes, not lattices, in March 2025 as a backup. A final standard for HQC is still in development. The fact that NIST is building a structurally different backup, just in case, says a lot about why a single-algorithm cutover is too early.
If you switch to PQC only today, and a weakness in lattice-based schemes shows up tomorrow, every system you touched is exposed again. Worse, it is now also exposed to the classical attacks you already removed protection against. Hybrid avoids that all-or-nothing bet. If one half of the pair is ever broken, classical or post-quantum, the other half still holds.
2. Protocol and Ecosystem Readiness Risk
Key exchange and digital signatures are not moving at the same pace. That gap creates risk if you try to force both at once. Most organizations actually face two separate post-quantum migrations: one for key agreement, and one for signatures and certificates. Key agreement is further along.
Certificates and signatures are a different story. As of mid-2026, the IETF is still working on how to combine classical and post-quantum signatures inside X.509 certificates. This covers two approaches: composite certificates (one certificate carrying both algorithms) and dual certificates (two separate certificates presented together). This work is still in Internet-Draft form, not yet published as finished RFCs.
If your migration plan relies on one big cutover, you’ll run into problems as soon as you start moving certificates. The standards work behind certificates, and the CA, browser, and validation systems built on top of it, are still being finished for pure PQC. Hybrid certificates and hybrid key exchange let you move at the speed each layer of your stack can actually support.
3. Operational and Performance Risk
Larger keys and signatures are not a small detail. They change packet size, memory use, and CPU load in ways that can affect production systems well after a rollout looks successful. NIST’s own FIPS 204 specification gives the exact figures: ML-DSA-65, the parameter set used at NIST security category 3, has a 1,952-byte public key and a 3,309-byte signature. RSA-2048 keys and signatures run around 256 bytes, and ECDSA P-256 keys and signatures run around 64 to 72 bytes.
That is roughly an order of magnitude larger for ML-DSA, with a real effect on TLS handshake size and certificate transmission, especially on slower networks. A pure-PQC cutover puts all of that risk directly into production, with no classical fallback if something breaks. A hybrid deployment keeps a tested, well-understood algorithm running alongside the new one. So a performance problem or a bug in the PQC half does not take down the connection on its own.
NIST and NSA Guidance on Hybrid Cryptography
The term “hybrid” is often misunderstood. However, NSA’s CNSA 2.0 guidance for national security systems (NSS) is more cautious about hybrid approaches than many people realize. NSA trusts CNSA 2.0 algorithms on their own and does not require hybrid setups for NSS security. Hybrid may still be used for compatibility or technical reasons. NSA is also clear that hybrid cryptography adds complexity to implementation and testing, which raises the risk of bugs and configuration mistakes. Also, hybrid setups can slow down standardization, since protocols need to agree on how to combine and manage multiple algorithms.
This distinction matters. For classified systems with strict validation rules, NSA prefers a direct move to CNSA 2.0 algorithms once they are validated. NSA treats hybrid as a temporary fix for specific protocol limits, not the end goal. For example, in IKEv2, a VPN protocol, NSA supports a hybrid approach because of size limits on public keys: a smaller key is used first, then a larger, encrypted one.
For the broader commercial internet, the picture is different. Hybrid deployments are expected to be the standard approach for the next several years. Until 2030, NSA itself recommends dual-algorithm or hybrid deployments, capable of running classical and post-quantum algorithms together, even while expecting full switchover by 2035. NIST’s own guidance from the National Cybersecurity Center of Excellence agrees: organizations should plan for compatibility problems and test hybrid approaches, like dual-use certificates that combine classical and PQC algorithms, to keep systems running through the transition.
So to summarize: hybrid is not required everywhere, but it is the practical, recommended path for almost everyone outside the most tightly controlled classified systems.
CNSA 2.0 and NIST Timelines for Post-Quantum Migration
Some teams treat post-quantum migration as a someday problem. The actual timelines say otherwise, and they are firmer than most people expect. The table below shows the staggered CNSA 2.0 deadlines NSA has set for NSS:
| System Category | Support and Prefer CNSA 2.0 By | Exclusive CNSA 2.0 Use By |
|---|---|---|
| Software and firmware signing | Immediate / 2025 | 2030 |
| Web browsers, servers, and cloud services | 2025 | 2033 |
| Networking equipment (VPNs, routers) | 2026 | 2030 |
| Operating systems | 2027 | 2033 |
| Niche equipment (constrained devices, large PKI) | 2030 | 2033 |
| Custom applications and legacy systems | — | 2033 (update or replace) |
On the federal policy side, National Security Memorandum 10 sets 2035 as the target for moving federal systems away from quantum-vulnerable algorithms. NIST’s draft transition guidance, currently published as an Initial Public Draft of NIST IR 8547, lays out a more detailed timeline that supports that target, including an earlier point for retiring lower-strength classical algorithms. However, this document is not finalized yet.
One thing is not in question: the threat driving all of this. It is called harvest now, decrypt later (HNDL). Adversaries store encrypted data today, planning to decrypt it once a powerful enough quantum computer exists. If your organization holds data that needs to stay confidential for a decade or more, that risk applies right now, no matter which year a given classical algorithm gets formally banned.
None of this means you need to finish migrating tomorrow. It means you need a working hybrid setup in place well before these dates. Testing, procurement, and validation take months, even after you choose your approach.
How to Build a Hybrid-First PQC Migration Plan
A practical migration plan usually moves through the same five stages, no matter the industry. The order and pace should be built around hybrid deployment, not a single cutover date.
Start with a cryptographic inventory: You cannot migrate what you cannot see. Find where public-key algorithms are used: applications, protocols like TLS and SSH, digital certificates, HSMs, and vendor services. Use scanning tools to detect quantum-vulnerable algorithms in your systems, software, and pipelines, and make these scans a normal part of CI/CD.
Prioritize by data lifetime and exposure: Build a risk-based plan that puts high-value or long-lived data first, especially anything that could be harvested now and decrypted later. Customer data, intellectual property, and anything needing multi-year confidentiality should be at the front of the queue.
Pilot hybrid key exchange first: This is the most mature layer, with broad library and browser support already in production. Use it as your lowest-risk testing ground for crypto-agility tools, before you touch certificates or signatures.
Talk to your vendors directly: Ask hardware, software, and cloud providers about their PQC plans, and factor their readiness into your procurement and risk decisions. A hybrid strategy is only as strong as the weakest link in your supply chain.
Build for crypto-agility: NIST is still finishing backup algorithms like HQC, and the IETF is still standardizing certificate formats. Today’s hybrid pairing is unlikely to be permanent. Systems that can switch algorithms without a major redesign will be much easier and cheaper to update as standards evolve.
How Encryption Consulting Can Help
If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you through our PQC Advisory Services. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.
We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.
From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.
With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.
We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.
Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.
CBOM Secure
Encryption Consulting’s CBOM Secure gives security teams a centralized, continuously updated view of every cryptographic algorithm, library version, and certificate across the organization. It identifies which systems carry quantum-vulnerable algorithms, tracks migration progress in real time, and surfaces misalignments before they become compliance gaps. For organizations trying to separate what genuinely needs migrating from what a vendor claims needs migrating, CBOM Secure provides the factual baseline to make that distinction clearly.
If your organization is ready to build a PQC migration program on evidence rather than noise, you can contact us. Encryption Consulting’s PQC Advisory Services and cryptographic discovery and inventory solutions are built around exactly this kind of phased, hybrid-first migration.
Conclusion
A pure post-quantum migration looks decisive, but it packs every kind of risk- algorithmic, ecosystem, and operational- into one irreversible step. And it does this right when the standards, tools, and ecosystem support for PQC are still maturing. Hybrid cryptography spreads that risk across two independently trusted algorithms. It buys you time while certificate formats and backup KEMs finish standardizing, and it matches what NIST, NSA, and the organizations already running PQC at scale are doing today.
The deadlines already on the calendar- 2027 for new CNSA 2.0 purchases, 2030 and 2033 for various equipment categories, 2035 for the federal target of full migration away from quantum-vulnerable algorithms- are not far enough away to ignore. They are also not close enough to justify a rushed, single-algorithm leap. Hybrid is how you use that time well.
If you are building your cryptographic inventory, or trying to figure out where hybrid deployment fits into your existing PKI and certificate lifecycle, that is exactly the kind of work a PQC readiness review is built for.
