Why this isn't a 2030 problem
A capable quantum computer that can break today's public-key cryptography doesn't exist yet, and estimates for when one will vary. The reason to act now anyway is "harvest now, decrypt later": encrypted data intercepted and stored today can be decrypted retroactively once that capability exists. For anything that needs to stay confidential for years — health data, trade secrets, long-lived credentials — the relevant deadline was effectively yesterday, not whenever the migration compliance date lands on a calendar.
Where the actual deadlines stand
| Jurisdiction / standard | Key dates |
|---|---|
| US National Security Systems (CNSA 2.0) | ML-KEM-1024 / ML-DSA-87 required starting 2025 |
| US federal civilian agencies & contractors (EO 14412) | 2030 (key establishment), 2031 (digital signatures) |
| UK (NCSC) | 2028 discovery plan, 2031 highest-priority migration, 2035 full migration |
| EU | End of 2026 national strategies published, 2030 critical infrastructure, 2035 complete migration |
| Germany (BSI) | 2030 critical infrastructure, 2031 classical-only key agreement sunset |
| Australia (ASD) | End of 2030, all classical asymmetric cryptography eliminated from government systems |
Canada, France, India, Japan, and South Korea have all published their own roadmaps in the same 2030–2035 window. The pattern across every one of them is the same: the compliance deadline is years out, but it assumes an organization that started preparing years before the deadline, not one that starts scrambling once it arrives.
Large enterprises are advised that a full cryptographic migration realistically takes 12-15 years once you count discovery, vendor coordination, testing, and staged rollout. Measured against 2030-2031 deadlines, an organization that hasn't started cryptographic discovery yet is already behind schedule — regardless of which specific regulatory deadline technically applies to it.
What "start now" actually means
- Cryptographic discovery. Most organizations don't have an accurate inventory of where cryptography is actually used — which certificates, which algorithms, embedded in which systems, including ones nobody's touched in years. You can't migrate what you haven't found.
- Figure out which deadlines actually bind you. Federal contractor status, sector-specific regulation, and jurisdiction all determine which of the dates above apply — and most organizations are subject to more than one, through customers or partners even if not directly.
- Build crypto-agility, not a one-time swap. Standards are still evolving. The architecturally sound move is designing systems that can swap cryptographic algorithms without a full re-architecture — because the algorithm you migrate to today may not be the final one you land on.
- Push the question to your vendors now. Ask every vendor and partner for their PQC migration plan before compliance pressure forces a reactive, worse-positioned conversation later — their timeline becomes a dependency in yours whether or not you've asked about it.
Where this fits in a normal engineering roadmap
This doesn't need to be a standalone crash project. Crypto-agility is an architecture property — much like observability or the ability to swap a database vendor — that's far cheaper to design in during normal build and modernization work than to retrofit under deadline pressure. It's a natural line item on any legacy modernization, cloud migration, or new-system build happening between now and the early 2030s, not a separate initiative competing for its own budget.
Not sure what your actual exposure looks like?
We help teams run cryptographic discovery and build crypto-agility into systems they're already modernizing.
Frequently asked questions
Do we need to do anything if our compliance deadline is 2031?
Discovery and planning, yes — now. A 2031 deadline assumes years of lead time for inventory, vendor coordination, and staged rollout; starting the actual migration work in 2030 for a 2031 deadline is where organizations get caught out.
What's the difference between PQC migration and normal certificate rotation?
Certificate rotation swaps keys using the same underlying algorithm. PQC migration changes the algorithm itself — which touches library support, protocol compatibility, and often hardware, not just a routine credential refresh.
Is 'harvest now, decrypt later' a real, active threat today?
The premise doesn't require a working quantum computer today — it only requires that encrypted traffic be interceptable and storable today, which is already true. The risk materializes retroactively whenever decryption capability arrives, on data that's already been captured.
Should a small company worry about this, or is it only for enterprises and governments?
The compliance deadlines above are mostly enterprise- and government-facing, but any company handling data that needs to stay confidential for a decade or more has the same underlying exposure — the deadlines just aren't the reason to care.