How Can Organizations Prepare for a Quantum Computer That Breaks Encryption Without Warning?
.png)
Quantum computing progress toward breaking today's public-key encryption has moved in sudden jumps rather than a predictable climb. Google Quantum AI researcher Craig Gidney cut the estimated qubit count needed to break RSA-2048 from roughly 20 million, a 2019 figure, to under 1 million in a 2025 analysis, a drop of about 95 percent. Harvest-now-decrypt-later attacks capture encrypted traffic today specifically so it can be decrypted once a capable enough quantum machine exists. Carmel protects the traffic still to be sent by converting the optical signal itself into a noise-like transmission that carries nothing worth storing.
Preparing for a quantum computer that breaks encryption without warning means handling two separate risks at the same time. The first is the migration itself: this process takes years, and each system is only protected once it has been upgraded. Network security specialists need to find which encryption algorithms are in use, rank systems by how sensitive their data is, and replace vulnerable algorithms with algorithms that meet NIST's new post-quantum standards. The second risk is the traffic sent while that migration is still running.
Traffic a system sends before it is upgraded is still protected by the old key exchange. If an adversary records that traffic off a fiber link, a future quantum computer can break the old key exchange and decrypt it. Upgrading the algorithm afterward does not protect what was already captured. Data an adversary has already recorded stays in their hands, and nothing an organization does now can pull it back. What an organization can still control is whether traffic sent from today onward can be recorded at all. Most post-quantum guidance focuses on stronger encryption: new algorithms, crypto-agility and migration planning. Far less of it addresses how easily the data itself can be harvested while a migration is rolled out.
Why quantum progress doesn't announce itself
Estimates for how many physical qubits a cryptographically relevant quantum computer needs have fallen sharply and repeatedly. In 2019, Gidney and Ekerå put RSA-2048 at roughly 20 million noisy qubits running for eight hours. Craig Gidney's 2025 paper for Google Quantum AI cut that to under one million qubits running for under a week, at a gate error rate of 0.1 percent. In February 2026, a preprint from Iceberg Quantum went further, estimating under 100,000 physical qubits using quantum LDPC codes, though it is not yet peer-reviewed and assumes non-local connectivity and about a month of runtime. Each revision has come from better algorithms and error-correction design rather than a hardware milestone anyone can watch approaching. A better algorithm arrives on no fixed schedule and can change the threat model in a single publication.
An organization planning to act once the breakthrough becomes visible is planning around a signal this history does not provide. The 2019 estimate held for six years before one paper cut it by roughly 95 percent. Nothing about that drop was observable in advance from outside the lab that produced it.
What a cryptographic inventory achieves
A cryptographic inventory establishes what an organization runs and where, which is the necessary opening step of any migration. NIST's National Cybersecurity Center of Excellence describes cryptographic discovery, meaning the inventorying of where and how an organization uses cryptography, as the starting point of post-quantum migration. That inventory tells a security team which systems run vulnerable algorithms and where to prioritize the move to NIST's post-quantum replacements. What it produces is the first step in a plan for future decisions to be made.
An inventory shapes which algorithms an organization will run in the future. It is only the first step in the journey towards stoping traffic on today's fiber links from being harvested while the migration is underway. As the rest of the migration process is being undertaken, data travelling across the fiber still requires protection.This vulnerability window is the reason to act now rather than later: traffic harvested before a link is protected stays vulnerable for good, with the full luxury of time to work on its decryption.
Do you know What Is Harvest Now, Decrypt Later, and How Can Organizations Protect Against It? It walks through how the attack pattern works.
Where the timeline is still genuinely uncertain
Gidney is explicit that his own analysis is not a forecast. He states that he does not expect a large enough quantum computer to exist by 2030, and frames the paper as a hedge rather than as a prediction. Public roadmaps disagree on when a machine at that scale arrives, with IBM targeting a few thousand logical qubits by the early 2030s while Microsoft and PsiQuantum point to million-qubit-scale systems as a longer-term goal. NIST's own guidance reflects the same uncertainty, deprecating RSA-2048 after 2030 and prohibiting it by 2035.
None of that uncertainty changes the harvest side of the equation. An adversary recording traffic today does not need to know when decryption becomes possible, since storage is cheap and a recording keeps indefinitely. The timeline is a reason not to panic about exactly when Q-Day arrives. It is not a reason to leave today's highest-sensitivity links recordable while the question stays open.
How Photonic Layer Security closes the recording gap
Photonic Layer Security (PLS) is a category of protection that changes what a tap on the fiber sees, rather than strengthening the key that protects the payload. We built Carmel around it, operating at the physical layer beneath any encryption running on the digital layer above. The transmitted signal is spread across a wide optical spectrum, its phase encoded by an optical key, and the signal buried under a negative noise ratio. A tap on a link in that state captures optical noise instead of a recoverable copy of the ciphertext, which leaves nothing in storage for a future quantum computer to work on.
The table sets out what Carmel does at that layer and where each property matters on a live network.
The part of this that isn't waiting on Q-Day
An organization does not need certainty about when a quantum computer arrives to act on the parts of the problem already settled. Cryptographic inventory should be underway regardless of that date. The highest-sensitivity links, the ones carrying data that has to stay confidential for years, are exposed to recording on every day the migration is still running. Closing that window of vulnerability is made simple and easy with CyberRidge shutting out the possibility of a harvest attack.
FAQs
Q: Does Carmel replace the need for a cryptographic inventory or a PQC migration plan?
A: No. Carmel is a layer that runs alongside cryptographic inventory and post-quantum migration, not a substitute for either. The inventory step still identifies which systems and algorithms need to change; Carmel addresses the separate question of whether traffic on a given fiber link can be recorded in the meantime.
Q: Does adding Carmel introduce latency or distance limits on a fiber link?
A: Carmel has no added latency and supports fiber spans up to 100 km unamplified, extending further with standard EDFA or Raman amplification. It operates at the physical layer without altering the higher-layer protocols or encryption already running on the link.
Q: How long does it take to get Carmel running on an existing network?
A: We built Carmel as a plug-and-play integration that reaches Post Quantum Ready status in weeks rather than the multi-year timelines associated with a full cryptographic migration
Q: What happens to traffic on a link once Carmel is active?
A: Carmel transforms the optical signal into a noise-like transmission by spreading it across a wide spectrum, encoding its phase, and running at a negative signal-to-noise ratio. An adversary tapping the link at that point captures a signal with nothing recoverable.
Q: Does Carmel work alongside encryption a network is already running?
A: Yes. Carmel operates at the physical layer, below the point where conventional encryption protocols and key-exchange schemes run, so it is complementary to existing higher-layer encryption rather than a replacement for it.
Q: Who is Carmel meant for?
A: Carmel is meant for organizations running long-haul or metro fiber links carrying data with a long confidentiality requirement: telecom operators, government and defense networks, financial institutions, and data center interconnects among others.