A batch of your company's traffic left the building this morning. It was encrypted, so nobody logged it as an incident. And somewhere it may now be sitting on a disk in a facility you will never see, waiting. Not for a stolen password. For a machine that does not exist yet.
Attackers are storing encrypted traffic today to decrypt once quantum hardware matures. NIST has already set the clock: RSA and elliptic curve go deprecated after 2030 and disallowed after 2035. Data with a long confidentiality life is exposed now, not later. Start the inventory this quarter.
Why It Matters
The attack has a name that sounds almost polite. Harvest now, decrypt later. An adversary, usually state-sponsored, quietly copies encrypted traffic and archives it. No malware, no ransom note, no alert. They are not trying to read it this year. They are betting that a cryptographically relevant quantum computer arrives before the value of that data expires, and for a lot of records that bet is a comfortable one.
Here is where most security budgets get it wrong. Teams treat post-quantum work as a 2030 problem because that is the first date on the NIST calendar, and 2030 feels like somebody else's fiscal year. But the exposure window opened the day the traffic was captured, not the day it gets decrypted. If you handle records that must stay confidential for fifteen years, your deadline already passed. I would go further: for anything covered by long-retention regulation, the decision to defer migration is a decision to accept an eventual breach, just one you will not have to explain until after you have left the job. That is a governance failure dressed up as a scheduling call, and it belongs on the same risk register as the accountability gaps in enterprise AI agent deployments that boards spent the first half of this year arguing about.
The hardware side is no longer speculative either. Banks and pharmaceutical firms are already buying processing time on commercial systems, a shift covered in more detail in this breakdown of what quantum computing actually means for business leaders. Nobody serious claims a machine can break RSA-2048 today. The point is that the archive does not care about today.
Money makes the scale legible in a way that threat modelling never does. Look at what one government alone expects to spend just to swap its own algorithms.
Final Deadline
2035
Legacy algorithms fully disallowed
Federal Migration Cost
$7.1 billion
Civilian agencies only, excludes defence
Practitioners Surveyed
4,000+
IT and security roles worldwide
Actively Preparing
38%
Down from the prior year
The cost estimate comes from the congressionally mandated OMB and ONCD report to Congress, covering United States federal civilian systems in 2024 dollars (as of 2024). It deliberately leaves out national security systems and the entire commercial sector. Read it as a floor, not a ceiling. What it really measures is not licence fees but archaeology: the labour of finding every place a cryptographic primitive was hardcoded by someone who left in 2014. The preparation rate, drawn from the 2026 Entrust and Ponemon Institute global study, moved the wrong way against the prior year, which tells you budget pressure is beating deadline pressure right now.
One government put $7.1 billion against swapping its own algorithms, and that estimate covers civilian systems alone. Whatever your number is, you have not budgeted it yet.
The standards themselves are settled, so the usual excuse about waiting for the technology to mature no longer holds. Here is the state of play.
| Category | Detail | Insight |
|---|---|---|
| The standards | FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) | Finalised in 2024, ready to deploy |
| Deprecation date | RSA, ECDH, ECDSA, DSA and FFDH deprecated after 2030 | Continued use needs documented risk justification |
| Certificate visibility | 43% report full insight into their own certificates | Most teams cannot see what breaks |
| Operational pain | 68% call managing cryptographic assets extremely difficult | A tooling gap, not awareness gap |
| Highest-risk data | Regulated records, intellectual property, health data, identity records | Confidentiality outlives the encryption protecting it |
| The attack | Collection is passive and leaves no trace on your network | No breach alarm ever fires |
Read that table as a sequencing document. Rows three and four are the real project; rows one and two are the easy part everyone talks about instead. So why is the work stalling? The reasons people actually give are boring, and boring reasons are the ones that win.
Budget was cited by 39% of respondents and missing expertise by 38%, both up sharply on the prior year in the same Entrust and Ponemon study.
Friction Points
The migration itself is not the hard part. Swapping a TLS library is a Tuesday. Finding every system that quietly depends on a certificate nobody documented is a two-year archaeological dig, and that discovery work is what the money is really paying for. Every embedded device, every code-signing key, every hardware security module, every vendor integration where the crypto lives on their side of the contract and not yours.
There is one question nobody in this field can answer honestly, and it deserves saying plainly rather than hiding behind a confidence interval. Nobody knows when a cryptographically relevant quantum computer arrives. Estimates run from the early 2030s to never. That uncertainty is not a reason to wait, it is the reason the deadline exists at all: regulators picked 2035 precisely because the honest answer is a shrug, and a shrug is not something you can build a control around. Reasonable, well-informed people disagree about this, and they will keep disagreeing right up until somebody publishes a result.
Practical watch-outs before you scope the work:
- Vendor claims of being quantum-ready usually mean the product supports a hybrid mode, not that your deployment uses it. Ask which algorithm is negotiated in production.
- Certificate lifetimes are shrinking independently of quantum concerns. If your renewal process is manual, that breaks first, and it breaks loudly.
- Long-lived signing keys, especially firmware and code-signing, are worse than transport encryption. You cannot re-sign a device already in a customer's hands.
- Regulatory sequencing bites. Mandated technical standards land on their own timetable regardless of your roadmap, a pattern already visible in fights over mandating universal OBD access across car brands.
- Data you already sent is not covered by anything you do next. Migration protects future traffic only.
Key Takeaways
- Inventory before you migrate. You cannot replace an algorithm you have not located, and the discovery phase dominates the timeline.
- Rank by confidentiality lifetime, not by system importance. A dull archive of health records outranks a busy internal dashboard.
- Build crypto-agility, not a one-time swap. Whatever replaces today's choice will itself need replacing, and the second migration should cost a fraction of the first.
- Put the risk acceptance in writing now. After the deprecation date, that documentation stops being optional, and drafting it late is how audits go badly.
Pull your certificate inventory this quarter and sort it by how long each dataset has to stay secret, not by how busy the system is. That single sorted list is the whole project plan, and the teams that have one are already ahead of the clear majority who have not started.
