How Long Does Post-Quantum Cryptography Migration Take, and What Protects Data in Transit While It's Underway?
Executive Order 14412 gives federal agencies until December 31, 2030 to move high-value assets to post-quantum key establishment, and until December 31, 2031 for digital signatures. The UK's National Cyber Security Centre lays out a parallel three-phase migration running from now through 2035. Traffic crossing a network during that multi-year runway is only encrypted with algorithms scheduled for retirement, and a copy of that traffic taken today won’t hold up against the decryption capabilities of quantum computers. Historical protocol migrations of a similar scope have taken roughly a decade to fully complete across large organizations. Carmel is built to close that specific exposure window, protecting today's transmitted data on a timeline measured in weeks rather than years.
Post-quantum cryptography migration takes years rather than months for any organization with a real estate of systems to move. The two binding US deadlines under Executive Order 14412 alone span from now through the end of 2031, and full replacement of vulnerable algorithms runs past that. What protects data in transit during that window has nothing to do with which PQC algorithm eventually replaces the current one. It has to do with whether the traffic can be copied off the wire at all while the migration is still in progress.
The actual migration timeline, not a single cutover date
Executive Order 14412, signed June 22, 2026, sets two separate federal deadlines rather than one cutover date. Agencies must move high-value assets and high-impact systems to post-quantum key establishment by December 31, 2030, and to post-quantum digital signatures by December 31, 2031. The order also directs the FAR Council to require covered federal contractors to comply by that same December 2030 date. Its practical reach therefore extends well beyond the agencies it names.
The UK's National Cyber Security Centre runs a parallel structure on its own clock. Its roadmap sets a discovery and planning phase through 2028, high-priority upgrades from 2028 to 2031, and full migration for all systems by 2035. Two governments arrived independently at the same point, which is multiple years, phased, and ending well into the next decade.
Why migrations like this take years, not months
Migration programs run long because most organizations do not know the full scope of what needs to change before they start. NIST's NCCoE frames cryptographic discovery, meaning the inventorying of where and how an organization actually uses cryptography, as the opening workstream of migration for exactly that reason. That discovery phase alone consumes significant time, before a single algorithm is even replaced.
The last comparable transition offers the closest available benchmark. Industry trade coverage of the retirement of TLS 1.0 and 1.1 describes organizations as still nearly a decade into that process after the protocols were formally deprecated. A migration touching hardware, software, key management, and third-party vendors at that scale does not compress into a single fiscal year regardless of how firm the deadline is.
What happens between discovery and rollout
Discovery is only the first stage of a migration. Once an organization knows where it uses cryptography, the next stage is prioritizing data by how long that data must stay confidential. Data that is useful only for a short time, such as single-use credentials, carries little risk if it is exposed. Intellectual property, long-term government contracts, and medical records carry much more risk. The sensitivity of this data is long-term, and therefore the exposure risk severity is greater when quantum computers are able to decrypt stored traffic.
The stage after that is determining which links are most vulnerable. We assess this using four factors, which we explain in more detail in our whitepaper, How to Mitigate the Risk of HNDL Attacks.
The final stage is phasing the rollout. Executive Order 14412 sets December 2030 for high-value assets and high-impact systems and December 2031 for digital signatures, and the NCSC roadmap places high-priority upgrades between 2028 and 2031 and full migration of all systems by 2035. The ranked list of data and links determines what enters each phase. Systems that carry long-lived, sensitive data should be addressed in the earliest phases.
What that multi-year window actually leaves exposed
None of the discovery, prioritization, or phased rollout work protects a single byte of traffic that crosses the network before it is finished. A fiber link carrying sensitive data that gets harvested today produces a shadow copy that exists independent of whatever migration deadline eventually gets met. Completing the migration by 2030 or 2031 does not retroactively protect traffic that was already leaked. Exposure during migration is therefore separate from the migration itself and needs its own solution instead of waiting on the same multi-year timeline.
Do you know what harvest-now-decrypt-later attacks actually are? Discover how a harvested copy stays a liability long after the moment it was taken.
Where Carmel fits inside a multi-year migration
Photonic Layer Security (PLS) doesn't touch which algorithm an organization eventually standardizes on, and it isn't a substitute for finishing the migration. Carmel operates underneath that entire process, at the physical layer, making the transmitted signal itself unrecordable while discovery, prioritization, and rollout continue on their own schedule. It covers the specific links carrying the longest-lived, most sensitive data during the years a full migration takes. The urgency to eventually reach those links is no longer as critical.
The table below sets out what Carmel covers at the physical layer and what it leaves to the migration program.
| Feature | Detail | Why it matters |
|---|---|---|
| Scope | Protects data in transit at Layer 1, independent of the key algorithm | Protects data that would otherwise have insufficient protection during the years the migration takes |
| Deployment | Plug-and-play; Carmel brings links to post-quantum readiness in weeks with no changes to existing systems | Covers the highest-priority links well inside a multi-year migration window |
| Regulatory fit | Doesn't change an organization's EO 14412 or NCSC migration obligations | Migration still proceeds on its own required timeline |
| Distance | Up to 100 km unamplified, extending with EDFA or Raman amplification | Fits long-haul carrier and metro spans without a workaround |
| Exposure addressed | No traffic harvested during or after migration | Closes the specific gaps that discovery and rollout phases can't reach fast enough |
Which links can't wait for 2030 or 2031
Links are not equally vulnerable. Traffic can be copied digitally, by re-routing it to a rogue server, by exploiting a router, or deploying a switch to exfiltrate the data to external storage. It can also be copied physically, at street cabinets, communication tunnels, and manholes, by bending the fiber or inserting an optical splitter. Bending a fiber past a specific radius lets light leak out of the core, and a clip-on device can capture that light without breaking the connection. Links that run through public or shared infrastructure need to be ranked, and links that carry long-lived data, need to be prioritised for protection.
A migration program should run on the timeline the regulation sets, and adding physical-layer protection alongside it changes none of that. What changes is whether the highest-sensitivity links sit exposed for the years that the program takes to complete. Those are the links carrying data that have to stay confidential well past the migration's own end date.
FAQs
Q: How long does a full post-quantum cryptography migration actually take?
A: Multiple years for any organization with a real inventory of systems. Executive Order 14412 gives US federal agencies until December 31, 2030 for key establishment and December 31, 2031 for digital signatures, and the UK's National Cyber Security Centre runs a parallel roadmap through 2035.
Q: Is Carmel a replacement for a PQC migration program?
A: No. Carmel is complementary to a migration, not a substitute for it. The migration still has to happen on its regulatory timeline; Carmel protects the highest-priority links while that timeline runs.
Q: How fast can Carmel be deployed compared to a full cryptographic migration?
A: Carmel can be deployed in weeks, without changes to existing systems, compared to the multi-year timeline a full migration takes.
Q: Which links should be protected first while a migration is underway?
A: The links carrying the most sensitive, longest-lived data, meaning traffic that has to stay confidential well past an organization's own migration completion date, get the most benefit from closing the exposure window first.
Q: Does EO 14412 apply to every organization?
A: Directly, it applies to US federal agencies' high value assets and high impact systems. It also directs the FAR Council to require covered federal contractors to comply by that same December 2030 date, so its practical reach extends well beyond agencies themselves.
Q: Does Carmel change what algorithm an organization eventually standardizes on?
A: No. Carmel operates at the physical layer, beneath whatever key-establishment or signature algorithm a migration program eventually adopts, so it doesn't influence or replace that decision.
Q: How do organizations decide which data to protect first during a PQC migration?
A: We start with how long the data must stay confidential and what it would cost if it were decrypted later. Data that must stay secret for five years or more, such as intellectual property, long-term contracts, and medical records, rank highest. Those priorities then determine which links carrying that data need protection first.
Q: What makes a fiber link vulnerable to harvesting?
A: Exposure comes from digital methods, such as re-routing traffic or compromising network hardware, and from physical access to the fiber at cabinets, tunnels, and junction points. Links on third-party carrier backbones or through public infrastructure are harder to control and require close collaboration with the network carrier.