How Long Does PQC Migration Take, and How Can Enterprises Protect Data in Transit in the Meantime?
A full enterprise PQC migration takes 5 to 7 years for small organizations, and 12 to 15 or more years for large ones, according to a peer-reviewed study. Government deadlines run from 2030 for federal high-value assets to 2035 for full migration in the United States and the United Kingdom. Adding to the complexity, migrations are patchy, and from one remote endpoint to another, data is often passing through sections that are not upgraded to quantum-secure encryption links. In 2025, Cloudflare measured that more than 50 percent of connections from PC’s to Cloudflare already used the quantum-safe handshake. But only 3.7 percent of company servers behind Cloudflare supported it, lagging behind due to companies failing to upgrade their own servers. Traffic recorded during a migration stays exposed after the upgrade. Carmel protects data in transit at the physical optical layer while the migration runs.
A full PQC migration takes 5 to 15 or more years depending on enterprise size, and traffic crossing enterprise networks during those years needs protection before the migration finishes. Robert Campbell's peer-reviewed study puts small enterprises at 5 to 7 years, medium enterprises at 8 to 12, and large enterprises at 12 to 15 or more. A large organization that starts in 2026 and needs 12 years finishes in 2038 - three years after NIST's proposed 2035 disallowance date. Below, we set out the published timelines, the deadlines they collide with, and the links that stay uncovered in between.
Published estimates by enterprise size
Capgemini's global post-quantum lead Adrian Neal calls three-to-five-year plans best-case and about eight years realistic at enterprise scale. The UK NCSC expects large organizations to need 2 to 3 years for discovery and planning and another 2 to 3 years for early migration, with full migration by 2035. Added together, those two phases take the first half of a large program to roughly four to six years, before the more complex work begins.
Large technology firms have set shorter dates. Google announced a 2029 completion deadline in March 2026 and Microsoft targets 2033. Campbell's baseline for even the smallest enterprise class, 5 to 7 years, runs longer than the three years that remain before Google's date arrives.
We walk through a full roadmap, from inventory to rollout, in - What Is the Step-by-Step Quantum Readiness Roadmap for Enterprises Preparing for Q-Day?
Deadlines that cap the migration window
Three sets of deadlines apply. NIST proposes deprecating today's most common public-key algorithms after 2030 and disallowing them after 2035. Executive Order 14412 requires federal agencies to move their most important systems to post-quantum key establishment by December 31, 2030, and to post-quantum digital signatures by December 31, 2031. The NSA requires post-quantum algorithms in networking equipment by 2030 and in web, cloud, and operating systems by 2033. New national security system purchases must comply from January 1, 2027. Every one of these dates falls within the 12- to 15-year estimate for a large enterprise migration.
What the migration leaves uncovered in the meantime
Protection for web users is moving faster than protection for the servers behind them. Cloudflare reported in October 2025 that over 50 percent of human-initiated traffic to its network used post-quantum key agreement. By September 2026, only about 12 percent of customer origin servers supported it (Cloudflare). The significance of this means that while quantum-safe protection covers the connection from the user to Cloudflare, for most companies, it does not cover the connection from Cloudflare to the company's own server. Therefore, an attacker who copies data from that server’s connection now, will be able to read it once quantum computers can break today's encryption.
The exposure during a migration sits on the fiber cables that connect sites, not only on the servers at either end. A fiber link can be tapped to copy the signal passing through it, and the person making the copy does not need access to any endpoint. While a migration is still running, any link whose endpoints have not been upgraded carries traffic protected by today’s key exchange, and a copy of that traffic can be stored and decrypted later. The longer the migration takes, the longer traffic is vulnerable as it crosses fiber in this state.
Timing widens the gap. A Springer Cybersecurity framework paper models a representative enterprise and finds that moving the migration start from 2026 to 2030 raises the expected exposed fraction of the confidentiality window from 0.37 to 0.54 under a midline quantum timeline. The NCSC adds that certificate-based PKI and IoT and industrial control protocols follow more slowly than confidentiality services. The concern is that sessions protected after an upgrade do not protect captures taken before it.
We cover how recorded traffic stays exposed after an upgrade in What Is Harvest Now, Decrypt Later, and How Can Organizations Protect Against It?
Protection options for data in transit during migration
Four options protect data in transit during the migration, and each works at a different layer. Hybrid post-quantum key agreement in TLS is the fastest where both endpoints support it. Symmetric and Asymmetric encryption algorithms are used to protect the payload and the key exchange respectively. Quantum key distribution suits point-to-point spans. Unlike these other solutions that are blocking the decryption of the algorithms, our Carmel platform, ensures that neither the payload, nor the encryption keys, can be harvested in the first place.
Carmel does not change which algorithm an organization migrates to and does not replace certificate or signature migration. It protects the optical links where it is installed, so there is a layer of pre-emptive defense, to protect against data leakage during the migration.
Choosing which links get protected first
A full migration takes 5 to 15 or more years, and many large organizations will still be migrating when the 2030 to 2035 regulatory deadlines arrive. Until the migration finishes, a large share of connections is only partly protected. Data copied from those connections today can be read later, once technology advances can break current encryption. Even still, upgrading the endpoint’s encryption changes what a copy contains, but it does not ensure continued encryption in the face of advanced quantum and AI capabilities.
Yet, in either case, all exposures are heightened in the time the migration is running. Carmel gives a guaranteed layer of protection on the optical links where it is installed. Neither the payload nor the encryption keys can be harvested from those links, whatever stage the migration has reached. We recommend installing Carmel first on the links that carry the data that must stay confidential for the longest time, and running the migration alongside it.
Have data that must stay confidential past 2035? Talk to us at CyberRidge about which links warrant physical-layer protection during your migration.
FAQs
Q: Does Carmel shorten a PQC migration?
A: No. Carmel provides a security layer during your PQC migration. The migration continues on its own timeline. Carmel covers the optical links it is installed on while that timeline runs.
Q: How quickly can Carmel be deployed compared with a full migration?
A: Carmel deploys in weeks, installing as a transmission line card substitute without changes to existing systems. Campbell's study puts a full enterprise migration at 5 to 15 or more years depending on size.
Q: Does Carmel change which PQC algorithm an organization adopts?
A: No. Carmel operates at the physical layer beneath whichever key establishment or signature algorithm a migration program selects. It does not influence or replace that decision.
Q: Which links should get Carmel while the migration runs?
A: We put links that carry the longest-lived data and fail the Mosca test first. Cloudflare's measurements show coverage varies by connection type, with only about 10 to 12 percent of origins supporting post-quantum key agreement in 2026, so links outside the browser path are the likelier gaps.
Q: Does Carmel protect traffic that was recorded before it was installed?
A: No. Carmel protects traffic from the point it is deployed on a link, and earlier captures stay exposed. The Springer framework paper shows why the start date matters, with the exposed fraction rising from 0.37 to 0.54 when a migration start moves from 2026 to 2030. The necessity to act as early on as possible is imperative!
Q: Does Carmel satisfy EO 14412 or CNSA 2.0 requirements?
A: No. Those requirements set deadlines for algorithms and systems, such as the December 31, 2030 date for PQC key establishment under Executive Order 14412. Carmel does not change those obligations, and the PQC migration should be designed to meet them.