Most conversations about quantum computers and cybersecurity start with the wrong question:
“When will a quantum computer actually break our encryption?”
It is a fair thing to ask. It is also a poor anchor for enterprise planning.
Neither NIST, nor national security agencies, nor the researchers can give a definitive date for Q-Day (defined below). What we can say with far more confidence is that migrating cryptography across a large enterprise takes years. In many environments, it may take close to a decade. In some sectors, it may take longer.
Once that reality sinks in, the question changes. It is no longer: “When does the threat arrive?”
It becomes: “Do we have enough time left to be ready when it does?”
This post opens our series on post-quantum readiness. Before we discuss inventories, migration governance, PQC algorithms or crypto-agility, we need to challenge the idea that waiting for Q-Day is a valid strategy.
Sirris [1] frames the issue in a similar way: cryptographically relevant quantum computers (CRQCs) do not need to exist today for preparation to matter. The real challenge is preparing for a transition that may take years.
This is no longer only a specialist cryptography concern. The G7 Cybersecurity Working Group [2] has also called for the quantum threat to be reframed from a distant future problem into a near-term issue requiring action across sectors, not only in critical infrastructure.
What “Q-Day” Actually Means
Q-Day is the point when a fault-tolerant quantum computer reaches sufficient scale to run algorithms such as Shor’s algorithm against real-world cryptographic key sizes.
The public-key mechanisms most exposed are the ones that hold much of today’s digital infrastructure together:
- RSA
- Diffie-Hellman
- Elliptic-curve key exchange
- Elliptic-curve signatures
Qubit counts in headlines can be misleading. A chip with more physical qubits is not automatically a machine that can break cryptography. Reliable logical qubits, error correction and large-scale engineering matter far more than raw qubit numbers.
So how close are we?
- NIST NCCoE [3] notes that many experts anticipate a CRQC within 15 to 20 years, while others think 30 years or more, especially given the difficulty of achieving fault tolerance. NIST also stresses that significant progress in scaling and error correction is still needed.
- Germany’s BSI [4] takes a similarly cautious position, estimating roughly 15 years at the conservative end, while noting that the real timeline could be shorter.
- Bart Preneel [5] has pointed out that estimates for the physical qubits required to break RSA-2048 have dropped significantly in recent years, mainly because of improvements in error correction and algorithmic efficiency rather than raw hardware scaling alone.
Even the conservative timeline can move. Uncertainty is real, but uncertainty is not a strategy. If an organization waits until a CRQC exists before starting migration, the migration will already be late.
Harvest-Now, Decrypt-Later: The Risk Is Live Today
Adversaries cannot yet break today’s deployed public-key cryptography with quantum computers. But real-time decryption is not the immediate concern.
The immediate concern is Harvest-Now, Decrypt-Later (HNDL). The logic is simple:
- Today: An adversary intercepts and stores encrypted traffic.
- Future: A CRQC is used to break the quantum-vulnerable key exchange and recover session secrets.
- Retroactive breach: Historical traffic may become readable.
The G7 call to action frames the risk in the same way: the attack matters wherever confidentiality must be protected for longer than the time required to develop a CRQC. If you hold data that must stay confidential for longer than that (health records, intellectual property, financial archives, identity data, government information, long-lived business secrets), the risk may begin the moment the encrypted data is captured, not when Q-Day arrives.
Digital signatures carry a related but different risk. This is not retroactive decryption. Once a signing algorithm is broken, malicious actors may be able to forge firmware updates, spoof trusted identities or compromise software supply chains going forward. The G7 document highlights the same authentication risk: future CRQC capability could allow attackers to impersonate trusted entities, compromise equipment and forge trusted data.
Why Public-Key Cryptography Specifically?
Not all cryptography is affected in the same way [6]. Precision matters here, because it prevents both underreaction and overreaction.
- Public-key cryptography (RSA, Diffie-Hellman and ECC): These systems rely on integer factorization and discrete logarithm problems. Shor’s algorithm breaks those assumptions outright. Systems relying on these mechanisms need a migration path to post-quantum alternatives.
- Symmetric encryption (AES, for example): Affected mainly through Grover’s algorithm, which gives a quadratic speed-up for key search. For many use cases, larger keys such as AES-256 restore the intended security margin without replacing the primitive.
- Hash functions (SHA-256, for example): Face related but more nuanced quantum search considerations. The impact is not comparable to Shor’s complete break of RSA, Diffie-Hellman and elliptic-curve cryptography.
The practical message is this:
Public-key cryptography needs migration. Symmetric cryptography and hash functions mostly need review and appropriate parameter choices.
Two Clocks, One Planning Problem: Mosca’s Inequality
Dr. Michele Mosca framed the problem through a simple decision rule:
X + Y > Z, where:
- X is the number of years your data must remain confidential.
- Y is the number of years required to migrate your infrastructure.
- Z is the estimated number of years before a CRQC exists.
If X + Y > Z, you are already late, and the moment to start is now.
Take conservative numbers. Suppose your sensitive data requires 10 years of confidentiality, and a realistic enterprise migration takes 5 years. That means you need a 15-year runway.
Against BSI’s own 15-year estimate for Z, that leaves exactly zero margin.
Y is the number people underestimate.
Migration is not just changing a configuration line. It includes discovery, cryptographic inventory, vendor coordination, testing, certification and rollout across production systems. Cryptographic migration is slow even without quantum pressure: SSL/TLS and payment-infrastructure transitions each took a decade or more across the broader ecosystem.
We will unpack why in Part 2.
The 4-Layer Readiness Framework
Post-quantum readiness is not a single patch update. It is an architectural and governance process.
A practical readiness model has four layers:
- Awareness: Understanding which systems are at risk and why public-key cryptography is the main focus. (This post.)
- Visibility: Building a cryptographic inventory: keys, certificates, algorithms, HSMs, protocols and supplier dependencies. (Coming up.)
- Prioritization: Ranking assets by data lifetime, business criticality and migration friction.
- Migration governance: Planning how to test, deploy, monitor and maintain the transition, and deciding who owns the execution.
The standards are no longer the missing piece. NIST [7] finalized FIPS 203, FIPS 204 and FIPS 205 in August 2024, covering ML-KEM, ML-DSA and SLH-DSA. The UK’s NCSC [8] has also set a concrete migration timeline:
- 2028: complete discovery and initial migration planning.
- 2031: complete highest-priority migrations.
- 2035: complete broader transition.
But a standard on paper is not the same as code running in production.
That gap is where Layer 4 lives. Ownership is spread across security engineering, enterprise architecture, infrastructure, product teams, procurement and risk management. PQC therefore needs explicit executive sponsorship.
It is also hard to fund, because a migrated product may look exactly the same to the customer: the website still loads, the VPN still connects, the payment still works.
The G7 paper frames this clearly: quantum risk is an economic and business risk, not merely a cryptographic one. Organizations that delay may lose competitive advantage or be excluded from contracting opportunities, including public procurement.
Questions to Push into Architecture Reviews Now
You do not need to rewrite your whole stack overnight. But you do need to start putting the right questions into architecture reviews, vendor assessments and risk discussions [9]:
- Where do we rely on RSA, Diffie-Hellman or ECC across our network and applications?
- Which systems handle data that must remain confidential beyond 2035?
- Which suppliers control cryptographic decisions on our behalf?
- Do our cloud, PKI, identity and HSM vendors have credible PQC roadmaps?
- Where do we have hard-coded cryptographic primitives in legacy software or embedded firmware?
- Do we have a cryptographic inventory at all?
The goal is not to migrate everything tomorrow.
The goal is to avoid discovering too late that the hardest systems to change are also the most critical ones.
The Threat Is Future. The Migration Is Present.
The threat timeline is uncertain.
The migration timeline is already something you can start managing today.
In Part 2, we will look at why that migration is so much harder than it sounds: public-key cryptography worked so well for decades that it became invisible, deeply embedded in almost everything we build.
That success is exactly what makes replacing it so slow.
Sources & Further Reading
- Sirris, “Post-quantum security starts with migration, not quantum computers”
- G7 Cybersecurity Working Group, chaired by ANSSI, Preparing for the Post-Quantum Era: A Call to Action, September 2026
- NIST NCCoE, Migration to Post-Quantum Cryptography FAQ
- BSI, guidance on quantum-safe cryptography and cryptographic mechanisms
- Bart Preneel, COSIC, KU Leuven: talks on the quantum threat and post-quantum migration
- Alfred Menezes, Post-Quantum Cryptography Explained
- NIST, FIPS 203, FIPS 204 and FIPS 205
- UK NCSC, Timelines for migration to post-quantum cryptography
- CISA, NSA and NIST, Quantum-Readiness: Migration to Post-Quantum Cryptography