Post-Quantum Cryptography Migration: Why 2030 Is Closer Than It Looks

Most security teams treat quantum computing as a distant threat. Something to monitor, plan for eventually, and respond to when the warning signs become impossible to ignore. That posture made sense five years ago. In 2026, it is a liability.

Post-quantum cryptography (PQC) refers to a new generation of cryptographic algorithms built to hold their ground against both today’s classical computers and the quantum processors being developed for tomorrow. Where RSA and elliptic-curve cryptography (ECC) draw their strength from mathematical problems that quantum hardware can break efficiently, PQC algorithms are founded on entirely different mathematical structures, ones that large-scale quantum computers are not expected to crack.

The timeline is shorter than most planning assumptions reflect. The systems being designed and commissioned today will still be in production when quantum capability crosses the threshold needed to break RSA and ECC. And the data being encrypted right now is already being collected by adversaries who do not need a quantum computer today. They only need one eventually. This blog breaks down why 2026 is the convergence point, what the regulatory environment actually requires, and what a credible migration posture looks like in practice.

The Timeline Problem Is Algorithmic

Most planning timelines treat quantum risk as a hardware problem. That framing misses a critical variable: algorithmic progress. Gidney and Ekerå’s 2021 paper in the journal Quantum estimated roughly 20 million noisy physical qubits to factor RSA-2048 in eight hours. Gidney’s May 2025 preprint (arXiv:2505.15917) reduced that estimate to under one million qubits under the same hardware assumptions, through a series of algorithmic and error-correction improvements.

The February 2026 Pinnacle Architecture preprint (arXiv:2602.11457) reduced the estimate further, to under 100,000 physical qubits, using quantum LDPC codes under stated hardware assumptions.

Each reduction arrived faster than the last, with no change in assumed hardware. Hardware timelines are forecastable. Algorithmic breakthroughs are not, and the direction of travel is one way.

Because adversaries can already pursue a harvest-now, decrypt-later (HNDL) strategy, collecting encrypted data today for future decryption, systems protecting data with multi-year confidentiality requirements should be treated as inside the threat window now. That is not a theoretical concern.

Understanding why that threat window is already open requires looking at what adversaries are doing right now, before any quantum computer capable of breaking encryption exists.

What Is Already Being Collected

The asymmetric timeline creates a threat that does not require a quantum computer to begin. HNDL describes the strategy where adversaries intercept and store encrypted data today, then decrypt it once a capable quantum computer exists. Collection at scale is already underway.

Which data is most at risk?

• Long-lived government and diplomatic communications
• Attorney-client communications and sealed litigation strategy
• Medical records with lifetime confidentiality requirements
• Intellectual property with durable commercial value
• Financial instruments, merger and acquisition strategies, and sovereign debt data
• Authentication credentials embedded in protocols that will remain in production for decades

The operational implication is important: reactive approaches that attempt to fix systems after quantum capability arrives will be nearly impossible to execute fast enough to matter. By the time the threat is visible, the collection will have already been running for years. HNDL means the exposure begins at the moment of encryption, not the moment of decryption.

Knowing that the collection is already underway makes the regulatory response easier to understand. The standards and deadlines exist precisely because governments and regulators recognize that the window to act is open now, not in 2030.

What the Standards and Regulations Require

NIST finalized three post-quantum cryptography standards on August 13, 2024, following an eight-year global evaluation process. A fourth standard, FIPS 206, is also in development. When published, it will specify FN-DSA, short for FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm, based on FALCON.

FALCON was selected alongside the three finalized algorithms and will serve as an additional digital signature option, offering smaller signature sizes suited to constrained environments. FIPS 206 had not been finalized as of mid-2026.

Standard	Algorithm	Primary Function
FIPS 203	ML-KEM	Key encapsulation, replacing RSA and ECDH key exchange
FIPS 204	ML-DSA	Digital signatures, replacing ECDSA and RSA-PSS
FIPS 205	SLH-DSA	Hash-based backup signature scheme

On March 11, 2025, NIST selected Hamming Quasi-Cyclic (HQC) as a fifth post-quantum algorithm. It is a key encapsulation mechanism (KEM) that will serve as a backup for ML-KEM, the main algorithm for general encryption. HQC is based on different math than ML-KEM, which NIST describes as important in case a weakness is discovered in ML-KEM.

Unlike ML-KEM, HQC is a code-based algorithm, specifically a KEM based on QC-MDPC (quasi-cyclic moderate-density parity-check) codes, providing a second line of defense rooted in different mathematical assumptions. NIST plans to issue a draft standard incorporating HQC in about a year from its March 2025 selection, with a finalized standard expected in 2027. Organizations should continue migrating to the standards finalized in 2024; HQC is a backup, not a replacement for ML-KEM.

NIST IR 8547, published as an Initial Public Draft on November 12, 2024, with a comment period that closed January 10, 2025, and still in draft status as of mid-2026, proposes NIST’s expected transition schedule. Per the IR 8547 IPD transition tables, quantum-vulnerable algorithms are assigned one of two statuses by security strength:

• Algorithms at 112-bit security strength, including RSA-2048 and lower-strength ECC parameter sets, are “deprecated after 2030, disallowed after 2035.”
• Algorithms at ≥128-bit security strength, including RSA-3072 and ECDSA/ECDH with P-384, are “disallowed after 2035” with no intermediate 2030 deprecation step.

Note: In NIST’s terminology, “deprecated” means the algorithm and key length may be used, but the user must accept some security risk. “Disallowed” means the algorithm may no longer be used for the stated purpose in any system governed by NIST standards. All quantum-vulnerable public-key algorithms (at every key size) are therefore disallowed after 2035, because Shor’s algorithm renders RSA and ECC insecure regardless of key length in the presence of a cryptographically relevant fault-tolerant quantum computer.

Key Regulatory Deadlines To Know

CNSA 2.0 FAQ v2.1 (December 2024, the current authoritative NSA guidance document): This mandates ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures across all National Security Systems (NSS). For software and firmware signing, where signature roots of trust must remain valid for years or decades, CNSA 2.0 specifies the stateful hash-based schemes LMS and XMSS from NIST SP 800-208.

ML-DSA-87 is additionally approved for all signing use cases and may be reasonable for some software and firmware signing scenarios, particularly where a signing strategy requires more signatures than can be managed with a single LMS or XMSS key, or in distributed signing environments. SLH-DSA is not included in CNSA 2.0.

The January 2027 procurement gate: Starting January 1, 2027, any new NSS acquisition must be CNSA 2.0 compliant. This is a hard deadline. A system delivered after that date without ML-KEM and ML-DSA support is non-compliant on arrival. With defense acquisition cycles running 18 to 36 months, programs being scoped today are already working against that clock. For organizations in those supply chains, the cascade is real: prime contractors flow CNSA 2.0 requirements down to sub-tier suppliers.

An earlier deadline applies before that. On September 21, 2026, all FIPS 140-2 validated module certificates will move to the NIST Historical List. Once on the Historical List, federal agencies cannot rely on a FIPS 140-2 certificate to justify new procurement decisions. For any organization selling into or procuring for the US federal, financial services, or defense sectors, FIPS 140-3 validated modules are now the requirement for new deployments. That deadline is less than three months away.

These are not recommendations. They are binding requirements for covered organizations and practical planning constraints for anyone in their supply chain.

While the regulatory picture makes the obligation clear, the most compelling evidence that migration is achievable comes from what has already been deployed at scale across the public internet.

What Has Already Been Deployed at Scale

Post-quantum infrastructure is already in production at a significant scale, and it carries a clear message for organizations still in planning mode.

Key Exchange Across the Web

Chrome 131, released in November 2024, shipped ML-KEM hybrid key exchange as the default, using codepoint 0x11EC. Firefox 132 and Edge 131 followed. By Chrome 138, users could no longer disable ML-KEM. The enterprise override policy PostQuantumKeyAgreementEnabled is deprecated as of Chrome 146 and removed in Chrome 147, making post-quantum key exchange a permanent part of the Chrome TLS stack.

Over 65% of human traffic to Cloudflare is now post-quantum encrypted, a figure that has since grown to over two-thirds of browser traffic as of June 2026. Key exchange is largely solved at the infrastructure layer, but authentication remains the frontier. Cloudflare has set a target of full post-quantum security, including post-quantum authentication, by 2029, a deadline it accelerated following recent quantum computing research breakthroughs. Although the first post-quantum certificates are expected in 2026, broad availability and trust across all browsers are unlikely before 2027.

Signatures Are the Harder Problem

The web has largely solved post-quantum key exchange for new TLS connections. The signature side, covering digital certificates, code signing, and authentication, involves more ecosystem dependencies and is progressing more slowly. Key exchange protects forward secrecy for session data. Signatures protect identity and integrity, and those roots of trust are embedded far more deeply in enterprise infrastructure than session key negotiation.

What This Means for Your Organization

The fact that Chrome, Firefox, Cloudflare, and Akamai have deployed ML-KEM hybrid key exchange at a global scale without breaking the internet removes the last credible technical objection to starting the migration. The tooling works. The interoperability is real. What remains is doing the internal work.

That internal work follows a consistent structure, and understanding what it looks like in practice is the difference between a migration that completes on schedule and one that stalls at the planning stage.

The Migration Is Not a Technology Purchase

Visibility is the most important first step. The problem is not a shortage of post-quantum algorithms. There is a shortage of organizational knowledge about where the current algorithms actually live.

Phase One: Build Visibility

Most organizations entering the migration do not struggle to choose between ML-KEM and ML-DSA. They struggle to answer the prior question: what cryptography does the organization currently run, where does it live, and who owns it? Four blockers consistently appear at this stage:

• Limited visibility into cryptographic usage across applications, infrastructure, and third-party dependencies
• No ability to assess business or regulatory impact without that visibility baseline
• Fragmented ownership of cryptography is scattered across security, infrastructure, application, and vendor teams
• Decision stalls caused by deadline uncertainty, even though the deadlines are now fixed

A Cryptographic Bill of Materials (CBOM), mapping every system using RSA, ECDSA, ECDH, DSA, or Diffie-Hellman, is the foundation for everything that follows. NIST NCCoE SP 1800-38B provides the reference methodology for building it.

Phase Two: Embed Migration Into Existing Work Cycles

Once the inventory exists, migration must be built into normal modernization cycles: application updates, infrastructure refreshes, cloud migrations, and vendor contract negotiations. Crypto-agility is the key architectural property here. A crypto-agile system isolates cryptographic operations so that algorithms can be swapped without rebuilding the surrounding infrastructure. That is what allows an organization to respond to algorithm updates and future deprecation notices without treating each one as a crisis.

Hybrid deployment, running a classical algorithm alongside a post-quantum one so that both must fail for a system to be compromised, is the standard approach during transition. It is exactly what Chrome has implemented for key exchange, and it is what the IETF composite signature specifications provide for the authentication layer.

With the structure clear, the next question is where to begin. The answer is consistent across every credible framework: start with a sequenced set of practical steps.

Where To Start

Organizations beginning migration now should follow a clear, practical sequence:

1. Complete a cryptographic inventory. Map every system, application, API, HSM, and third-party dependency that uses cryptographic primitives. Classify each by the confidentiality lifetime of the data it protects and by migration complexity.
2. Prioritize by HNDL exposure. Data that needs to remain confidential past 2030 is already inside the threat window. Healthcare records, government communications, legal files, and long-duration financial instruments are first-tier priorities regardless of when formal compliance deadlines apply.
3. Deploy hybrid key exchange on external services first. The IETF standard X25519MLKEM768 is the mechanism Chrome and major CDNs have already deployed at scale. Enable it on external services, test fallback behavior with classical-only clients, and measure throughput impact before rolling it out internally.
4. Plan hybrid signatures using composite specifications. Retaining a classical ECC layer alongside ML-DSA during the migration period protects against implementation bugs in new code, not just quantum attacks.
5. Assess vendor and supplier quantum readiness. Any product sold into NSS must be CNSA 2.0 compliant by January 1, 2027. For organizations in those supply chains, the question for every vendor is whether their product supports ML-KEM-1024 and ML-DSA-87 as validated implementations under FIPS 140-3.
6. Build crypto-agility into all new system designs. Any architecture designed in 2026 without the ability to replace cryptographic algorithms without re-platforming is accumulating technical debt from day one.

Each of these steps requires the right tooling, methodology, and expertise to execute well. Most organizations do not have all of that in-house, and the 2030 deadline does not allow time to build it from scratch. That is where Encryption Consulting can help.

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. We act as your trusted partner, guiding you through every step with clarity, confidence, and real-world expertise.

We start with a Cryptographic Discovery and Inventory, scanning your entire environment to locate certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This gives you the baseline visibility that any migration depends on.

From there, we run a PQC Assessment to measure your exposure to quantum threats, pinpoint RSA- and ECC-dependent systems, and produce a prioritized report of vulnerable assets ranked by risk severity.

With that picture in hand, we build a PQC Strategy and Roadmap: a phased migration plan shaped around your risk appetite, regulatory requirements, and long-term security goals, with cryptographic agility built in so your systems can adapt as standards continue to develop.

We then support Vendor Evaluation and Pilot Testing, helping you choose the right tools, run proof-of-concept tests, and confirm interoperability before any full-scale rollout begins.

Finally, we oversee Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and putting monitoring in place for long-term cryptographic health.

CertSecure Manager

On the execution side, CertSecure Manager delivers the certificate lifecycle automation that makes large-scale PQC migration operationally feasible. The platform continuously discovers RSA and ECDSA certificates across cloud services, servers, applications, and load balancers, consolidating them into a centralized inventory with a single view of status, ownership, and expiration risk. Automated renewal workflows reduce manual effort and the risk of outage-causing lapses, while proactive expiration alerts ensure teams are acting before certificates become service-impacting incidents.

CBOM Secure

Encryption Consulting’s CBOM Secure tool plays a central role in helping organizations prepare for this transition. Rather than working through spreadsheets, manual OpenSSL outputs, or scattered configuration files, teams get a consolidated view of cryptographic usage across their entire environment. The tool surfaces which algorithms are currently in use, identifies what needs to change to meet post-quantum security requirements, and shows whether systems are aligned with your security objectives.

For organizations preparing for board-level discussions, architecture decisions, or compliance planning, CBOM Secure delivers the clarity and speed that manual processes simply cannot match.

Beyond reporting, CBOM Secure accelerates the work itself. It automates cryptographic inventories, checks TLS configurations, validates algorithms against current and emerging standards, and aligns policies across teams, so organizations can move from discovery to action with confidence rather than guesswork.

Conclusion

The evidence is no longer theoretical. Algorithmic research has already reduced the hardware required to break RSA-2048 by a factor of twenty, with no change in physical assumptions. Regulatory frameworks have moved from guidance to binding deadlines. Adversaries are collecting encrypted data today, and they are not waiting for permission to decrypt it later.

The good news is that the path forward is clear. The standards are in place. The tooling is proven at scale. The organizations moving now are building migration programs they control, on timelines they set. That option remains available, but only for as long as the planning window holds.

The first step is knowing what you have. Organizations with a completed cryptographic inventory can plan and act with clarity. Organizations without one are guessing against a fixed deadline. Start with the inventory. The rest of the migration follows naturally.