Every few months a CISO forwards me an article about quantum computing and asks the same thing. Is this real, and when? I understand the question. If you are going to spend money, you want a date.
I have stopped answering it, because the date does not change what you should do this year.
The attack is already running
Harvest now, decrypt later is simple. Someone with patience and storage records your encrypted traffic today. They cannot read it. They keep it anyway, because one day the key exchange that protected it will be cheap to break, and whatever was inside will still be there.
That means the attack is not waiting for a quantum computer. The interesting half of it, the collection, is happening now. CISA, the NSA and NIST described exactly this in their 2023 quantum‑readiness factsheet. Nobody needs to guess at the motive; long‑lived secrets are worth storing.
So the physics question, when will a machine exist that can run Shor's algorithm at scale, is a question about the second half of the attack. You have no control over that half. You have a great deal of control over the first.
Three numbers, one inequality
Michele Mosca put it plainly years ago, and it still holds. Take three numbers.
- How many years does this data need to stay secret? Call it X.
- How many years will it take you to migrate the systems that protect it? Call it Y.
- How many years until a machine can break the cryptography? Call it Z.
If X plus Y is bigger than Z, you are already late for that data. Notice which of the three you can change. X is a property of the data. Z is a property of the universe and a few well‑funded labs. Y is yours. Y is a plan and a budget.
In my experience Y is also the number nobody has measured. When I ask a security team how long it would take to replace every use of RSA and elliptic‑curve key exchange across their estate, the honest answer is usually "we don't know what we have." That is not a criticism. Cryptography is buried in libraries, certificates, hardware modules, vendor products, firmware and SaaS contracts, and almost none of it was written down as a list.
What this looks like as a budget
Once you frame it as Y, the work becomes ordinary. Unglamorous, but ordinary.
First, an inventory. Where does cryptography live, what algorithms, what key sizes, who owns it, and what data does it protect. This is the largest single cost and the one most organisations try to skip. It cannot be skipped. Every regulator roadmap I have read, from the EU's NIS Cooperation Group to Canada's federal directive, starts with an inventory for a reason.
Second, a classification by data lifetime. A session token that expires in an hour has an X of roughly zero. A citizen's medical record, a design file for a product that ships in five years, or a government archive has an X measured in decades. Sort by X and the migration order writes itself. Long‑lived secrets and externally exposed key exchange go first.
Third, a sequence that respects your vendors. You will not migrate faster than your slowest critical supplier. The finalised NIST standards for ML‑KEM, ML‑DSA and SLH‑DSA gave vendors something concrete to build to in August 2024, and hybrid key exchange has already shipped in the major browsers and OpenSSL. Ask each vendor for their date. Write it in the contract renewal.
Fourth, agility. The point is to make the next swap boring. If the migration leaves you with configuration instead of code, you have done it right.
Why the deadlines help
Regulators have started giving you dates, and I think that is a gift. The United States now treats federal migration as an obligation with a 2030 line for agencies and their contractors. Australia's ISM expects traditional public‑key cryptography retired by the end of the decade. Most other jurisdictions cluster around 2030 for high‑risk systems and 2035 for everything else.
Those dates are a forcing function for Y, whatever the physics does. Use them that way. A board that will not fund "quantum risk" will often fund "compliance by 2030", and the work is identical.
What I would do this quarter
If you have nothing in place, start with three things. Commission the inventory, even a rough one, and put a name against each finding. Turn on hybrid key exchange at your edge, because it is cheap and it stops the collection half of the attack for traffic you control. And send every critical vendor one written question: when will your product support ML‑KEM and ML‑DSA, and what will it cost me.
None of that requires you to have an opinion about the physics. It requires a spreadsheet, a few meetings and a line in next year's budget. That is a much easier conversation to have than the one about qubits, and it is the one that protects the data.
