Every enterprise conversation about quantum risk stalls on the same question, and it is the wrong one.
The question is when. When will a quantum computer capable of breaking RSA actually exist? Estimates vary by a decade or more depending on who is asked, and the variance is used (reasonably enough) as grounds for waiting.
The problem with that reasoning is that it treats Q Day as the moment risk begins. For encrypted data already in transit, risk began the day an adversary started recording it.
Table of contents
- What Q Day means
- Why the date is genuinely uncertain
- Why the uncertainty does not buy time
- The deadline that is already fixed
- Working out your own exposure
- What to do before Q Day arrives
- Frequently asked questions
Key takeaways
- Q Day is the point at which a quantum computer can break the public-key cryptography protecting most enterprise data today.
- The date is uncertain, but it is not the date that matters, because adversaries are recording encrypted traffic now to decrypt after it arrives.
- CNSA 2.0 makes post-quantum compliance mandatory from 2027, giving enterprises a fixed deadline regardless of when Q Day lands.
- Exposure is determined by how long your data must stay confidential, not by the quantum timeline.
- The second attacker (autonomous AI) is already operating at machine speed on the same infrastructure, which is why both need answering at one control point.
What Q Day means
Q Day is shorthand for the moment a cryptographically relevant quantum computer exists: one capable of running Shor's algorithm at sufficient scale to break the public-key cryptography that secures essentially all enterprise communication.
RSA and elliptic-curve cryptography protect TLS sessions, VPNs, code signing, digital certificates, secure messaging and the key exchanges underneath almost every system an enterprise runs. Their security rests on mathematical problems that are hard for conventional computers and tractable for a sufficiently large quantum one.
Symmetric encryption such as AES is affected differently and less severely; larger key sizes remain a reasonable answer there. It is the public-key half of the stack that breaks, and it is the half everything else depends on for establishing trust.
When Q Day arrives, data protected by those algorithms becomes readable. Not gradually. Not selectively. Any of it that someone kept.
Why the date is genuinely uncertain
The honest position is that nobody knows, and enterprises should be skeptical of anyone claiming precision.
Breaking RSA-2048 requires a fault-tolerant machine with error correction operating at a scale well beyond current systems. Progress depends on qubit counts, error rates and error-correction overhead improving together, and those variables do not advance on a predictable curve. Credible estimates span from the early 2030s to considerably later.
Uncertainty in both directions is real. Breakthroughs compress timelines. Engineering walls extend them. Anyone offering a specific year is selling something.
But the uncertainty argument only works if the risk starts at Q Day. It does not.
Why the uncertainty does not buy time
Here is the mechanism that makes the timeline debate largely beside the point.
Nation-state actors are capturing encrypted enterprise traffic today. They are not attempting to decrypt it now. They are storing it (cheaply, patiently, at scale) against the day the capability arrives. Harvest now. Decrypt later. Exploit forever.
This means the relevant question is not "when is Q Day" but "how long does my data need to stay secret". If the answer is longer than the time remaining until Q Day, the data is already compromised. It simply has not been read yet.
Consider what carries a long confidentiality life: patient records, legal privilege, merger discussions, defence contracts, intellectual property, source code, personnel files, diplomatic communication, long-term financial positions. Much of it was transmitted years ago. Some of it is being transmitted this afternoon.
Q Day is not when the risk starts. It is when the recording gets played back.
The deadline that is already fixed
While the Q Day date remains contested, a different date is not.
CNSA 2.0 mandates post-quantum compliance from 2027. Canada, the EU, the UK and the UAE are moving on comparable timelines. For any organisation in a regulated sector or a government supply chain, that is not a forecast. It is a procurement deadline with contractual consequences.
The replacement algorithms already exist. FIPS 203 standardises ML-KEM for key encapsulation and FIPS 204 standardises ML-DSA for digital signatures, both published through the NIST post-quantum cryptography project. The standards question is settled.
What is not settled, inside most enterprises, is where cryptography is actually used. The UK's National Cyber Security Centre has set out post-quantum migration timelines describing discovery, planning and execution phases measured in years. Discovery alone routinely surprises organisations that assumed they had an inventory.
That is the real constraint. Not the algorithm. The archaeology.
Working out your own exposure
A practical way to convert Q Day from an abstract threat into a planning input is to compare three durations.
How long your data must remain confidential. Ten years for medical records. Twenty-five for some defence material. A quarter for a press release.
How long your migration will take. Discovery, testing, replacement and validation across every system that establishes a secure connection. For a large enterprise this is measured in years, not months.
How long until Q Day. Uncertain, but bounded by credible estimates.
If the first two added together exceed the third, exposure already exists. For most enterprises holding anything with a decade-long confidentiality requirement, that inequality resolves uncomfortably, which is the entire argument for starting now rather than waiting for certainty that will not arrive in time to be useful.
For a fuller treatment, see our guides to the cryptographically relevant quantum computer, how Shor's algorithm breaks RSA and the Mosca inequality.
What to do before Q Day arrives
The work divides into things that must happen regardless of when Q Day lands.
Inventory the cryptography. You cannot migrate what you cannot find. Certificates, embedded libraries, hardware modules, third-party integrations, legacy systems nobody owns.
Prioritise by confidentiality life. Long-lived secrets crossing untrusted networks first. Ephemeral session data last.
Build for agility, not for one algorithm. Today's standards are current, not final. Systems that hard-code a primitive will need this exercise again.
Apply quantum-safe encryption to traffic in transit now. Every day of unprotected transmission is another day added to someone's archive.
Do not treat this as the only threat. The second attacker is already inside the timeline. Autonomous AI attacks complete in seconds against tooling built to alert a human hours later. An organisation that spends 2026 on post-quantum migration alone has protected its ten-year secrets while leaving tonight undefended.
This is why Conux is built as a cybersecurity gateway rather than a migration project. Every connection passes through one control point. At that point, quantum-safe encryption is applied to everything in transit, autonomous attacks are blocked in seconds rather than escalated, machine identities are governed, and the audit evidence CNSA 2.0 will demand is generated continuously rather than assembled before each assessment.
No rip-and-replace. Existing cloud, identity, applications and models stay where they are. One deployment, not two migrations arriving at the same deadline.
The bottom line
The Q Day debate has become a way of postponing a decision that the harvesting has already made for you.
The date will be argued over until it happens. Meanwhile the archive grows, the 2027 mandate does not move, and a second adversary is operating at machine speed on the same infrastructure.
Two attackers. One gateway.


