- Key Takeaways
- Why The Deadline Moved Earlier
- The Risk That Does Not Wait: Harvest Now, Decrypt Later
- The Internet Is Migrating Unevenly, And The Gap Is The Warning
- Why Migration Takes Longer Than Leaders Expect
- Three Moves To Make Now
- Common mistakes that cost organizations time
- What The Deadlines Signal for Everyone
- How Encryption Consulting Helps
The post-quantum cryptography deadline is the point by which an organization must replace quantum-vulnerable algorithms like RSA and ECC with NIST-standardized post-quantum algorithms. That deadline is moving earlier because quantum capability and government mandates are both advancing faster than planners assumed.
The window for an orderly, planned migration to quantum-safe cryptography is narrowing. Two forces pull the date forward at once. Peer-reviewed research keeps lowering the resources a quantum computer would need to break today’s public-key cryptography, and the June 2026 White House executive order set firm federal deadlines of 2030 for key establishment and 2031 for digital signatures.
For any single organization, the real deadline is not a public date. It is the moment your most sensitive data stops being safe, and for long-life data that moment has already passed.
Key Takeaways
- The credible timeline to a code-breaking quantum computer is shifting earlier, not later.
- A 2025 Google Quantum AI paper cut the estimated qubits to break RSA-2048 from about 20 million to under 1 million, roughly a twentyfold reduction in six years.
- Executive Order 14412 (June 22, 2026) sets US federal deadlines of 2030 for key establishment and 2031 for digital signatures, and the EU expects member-state cryptographic inventories by the end of 2026.
- The internet is migrating unevenly: about half of measured domains now use hybrid post-quantum key exchange, but roughly 0% use post-quantum certificates, leaving authentication exposed.
- Harvest-now-decrypt-later means data with a long secrecy life is already exposed today. The first move is a cryptographic inventory; the durable goal is crypto-agility.
Why The Deadline Moved Earlier
For years, the working assumption held that breaking RSA or elliptic-curve cryptography would need a quantum computer with millions of physical qubits, and that such a machine sat decades away. The estimates have since collapsed.
In May 2025, Craig Gidney of Google Quantum AI published “How to factor 2048 bit RSA integers with less than a million noisy qubits.” The paper argues that a fault-tolerant machine with under one million noisy qubits could factor a 2048-bit RSA key in under a week.
That is roughly a twentyfold reduction from Gidney’s own 2019 estimate of about 20 million qubits, achieved by trading a longer runtime for far fewer qubits and by cutting the operation count sharply using newer error-correction and arithmetic techniques. Separate 2025 and 2026 work applied similar gains to elliptic-curve cryptography, which protects most modern key exchange and signatures.
The trajectory matters more than any single figure:
| Year | Estimated qubits to break RSA-2048 | Source |
|---|---|---|
| 2012 | ~1 billion physical qubits | Early academic estimates |
| 2019 | ~20 million noisy qubits (about 8 hours) | Gidney and Ekerå |
| 2025 | Under 1 million noisy qubits (under a week) | Gidney, Google Quantum AI |
The point is not a single breakthrough. Qubit counts, error correction, and algorithm efficiency are improving together, and the combination is what shortens the timeline. Expert views still differ on the destination.
The UK’s National Cyber Security Center and most academic surveys place a cryptographically relevant quantum computer in the 2030s or later, while Google and Cloudflare have signaled planning around 2029 to 2030. Treat the end of the decade as a planning floor rather than a forecast. The direction of travel is what should drive decisions: earlier, not later.
The Risk That Does Not Wait: Harvest Now, Decrypt Later
Some quantum risk does not wait for a future machine. An adversary can record encrypted traffic today and store it until a capable quantum computer can decrypt it. Security teams call this harvest now, decrypt later, and a joint advisory from NSA, CISA, and NIST has urged organizations to begin migration on that basis.
This reshapes the deadline math. The useful rule comes from cryptographer Michele Mosca: add the number of years your data must stay secret to the number of years your migration will take, and if that total runs past the arrival of a quantum threat, you are already exposed today. Consider how long different data classes must remain confidential:
- Government and defense secrets, often 25 years or more
- Health and genomic records, the lifetime of the patient
- Financial and trade data, 7 to 15 years under various regulations
- Intellectual property and source code, the commercial life of the product
- Identity and biometric data, effectively permanent
For any of these, a migration that takes three to five years and a quantum threat that may arrive at the end of the decade already overlap. The data being captured now is the data that needs protection first.
The Internet Is Migrating Unevenly, And The Gap Is The Warning
The clearest signal that the deadline is real is how the public internet has already started to move, and where it has not. A 2026 measurement study of 32,011 domains (arXiv:2606.16473) found that about 49% now support hybrid post-quantum key exchange, typically ML-KEM-768 paired with the classical X25519, while the rest still use classical key exchange only.
Cloudflare has reported that a majority of human-generated TLS traffic on its network already uses hybrid ML-KEM, and the X25519 plus ML-KEM-768 combination now ships by default in Chrome, Firefox, and Edge.
The alarming half of the finding is the authentication layer. The same study found that roughly 0% of those domains use post-quantum certificates. Key exchange protects confidentiality in transit, which directly counters harvest now, decrypt later, so it moved first. Digital signatures and certificates protect authenticity and are harder to migrate because they touch certificate authorities, chains of trust, and every device that validates them.
This is exactly why Executive Order 14412 sets two dates rather than one: key establishment by 2030 and digital signatures by 2031. The market has validated the easier half of the problem and left the harder half almost untouched, and a meaningful share of domains in banking and government still negotiate older TLS 1.2 connections. Authentication is where most of the remaining work, and the remaining risk, now sits.
Why Migration Takes Longer Than Leaders Expect
Public-key cryptography is not one system you patch in a maintenance window. It is embedded across the stack:
- TLS and HTTPS on every web application and API
- Digital certificates and the certificate authorities behind them
- Code signing and software update verification
- Identity, authentication, and access control
- VPNs and encrypted network traffic
- Cloud service authentication
- Connected devices and embedded systems
- Third-party and supply chain integrations
Replacing cryptography across that footprint requires discovery, prioritization, architecture changes, vendor coordination, testing, and staged rollout. As Palo Alto Networks framed it in 2026, post-quantum readiness is less an algorithm swap than an operating model for managing cryptographic change at scale. Several factors stretch the timeline in practice:
- Hidden and hard-coded cryptography: Algorithms are buried in third-party libraries, firmware, and legacy applications where no one can simply reconfigure them.
- Performance and size: Post-quantum keys and signatures are larger than RSA or ECC, which affects handshakes, certificate sizes, bandwidth, and constrained devices, so changes need testing rather than blind deployment.
- Supply chain dependencies: Much of an organization’s cryptography lives in products it does not control, so migration waits on vendors.
- Long-lifecycle systems: Operational technology, embedded devices, and industrial systems may run for a decade or more and cannot be patched on a normal cadence.
The standards themselves are ready. NIST published FIPS 203 (ML-KEM) for key encapsulation and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures in 2024, with FN-DSA (FALCON) expected to follow as FIPS 206. The gap is execution, and when the deadline shrinks while the work still takes years, that gap is the risk.
Three Moves To Make Now
You do not need perfect certainty to start. The work begins with visibility, moves to prioritization, then to a governed program built to adapt.
1. See Your Cryptographic Exposure
You cannot protect what you cannot see. Build a cryptographic inventory that records where RSA, ECC, and other algorithms run, which systems depend on them, what data they protect, and how hard each dependency is to replace.
Microsoft’s 2026 guidance frames this as the foundation of cryptographic posture management, an ongoing practice rather than a one-time audit, because certificates rotate, code ships daily, and cloud resources change constantly. A Cryptography Bill of Materials (CBOM), now part of the CycloneDX 1.6 standard, is the machine-readable way to express that inventory and govern it across the supply chain.
2. Prioritize What Matters Most
Not all exposure carries equal risk. Move first on systems protecting long-lived sensitive data, on core trust infrastructure such as certificate authorities and code signing, on systems that are slow or costly to change like embedded and operational technology, and on third-party links you do not directly control. The NCSC’s migration guidance recommends this kind of risk-based sequencing rather than a flat, system-by-system sweep. A simple scoring model makes the order defensible to a board and a regulator:
| Factor | Why It Matters | Higher-Risk Signal |
|---|---|---|
| Data secrecy lifetime | Long-life data is exposed to harvest now, decrypt later | Must stay secret 10+ years |
| Quantum vulnerability | Identifies what actually breaks | RSA, ECDSA, ECDH in use |
| Exposure | Interception likelihood | Internet-facing or cross-border |
| Migration complexity | Predicts effort and time | Hard-coded or vendor-controlled crypto |
| Business criticality | Sets the blast radius | Revenue, safety, or trust systems |
3. Build A Phased Program Around Crypto-Agility
Discovery and prioritization set the foundation. The next step is a governed migration with clear milestones and executive ownership that sequences the highest-risk systems first, usually running classical and post-quantum algorithms together in hybrid mode during the transition so a weakness in either one does not break security. Design for crypto-agility so future changes are cheap.
In practice, that means abstracting cryptographic functions behind a service layer or API so applications call a consistent interface while algorithms change through configuration rather than code rewrites. The benefit outlasts the quantum transition, because standards and threats will keep moving. Tightening certificate lifetimes, now on a path toward much shorter validity, makes that agility even more valuable.
Common mistakes that cost organizations time
- Treating the inventory as a one-time project: A point-in-time scan is stale within weeks. Discovery has to be continuous.
- Migrating key exchange and forgetting authentication: The internet’s 0% adoption of post-quantum certificates shows how easy it is to declare victory after the easy half.
- Confusing a TLS upgrade with full compliance: Public web traffic is one layer. Internal services, code signing, identity, and embedded systems all carry quantum-vulnerable cryptography.
- Auditing only your own code: Most cryptography lives in third-party and supply chain components, and a partner’s RSA dependency is still your exposure.
- Waiting for certainty: The arrival date is uncertain, but the migration time and the data lifetime are knowable now, and that is enough to start.
What The Deadlines Signal for Everyone
Executive Order 14412, signed June 22, 2026, directs federal agencies to move high-value and high-impact systems to post-quantum key establishment by the end of 2030 and to post-quantum digital signatures by the end of 2031, and it pulls federal procurement rules in behind it through a proposed FAR rule for covered contractors. NIST’s deprecation schedule in draft IR 8547 reinforces the same arc, deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035.
The European Union’s coordinated roadmap runs on a parallel track, expecting member states to establish cryptographic inventories by the end of 2026, with high-risk systems secured by 2030 and full transition by 2035. Even outside government, these dates set the market expectation, because vendors that want to keep selling will ship post-quantum-capable products on this timeline, and those products become the baseline for everyone.
How Encryption Consulting Helps
Encryption Consulting’s PQC Advisory uses a 9-phase roadmap to turn this from a research problem into a sequenced program, from cryptographic discovery through prioritization, hybrid deployment, and crypto-agility.
CBOM Secure builds the continuous cryptographic inventory the first move depends on, finding quantum-vulnerable algorithms across code, certificates, keys, and cloud so the inventory stays current as the estate changes. CertSecure Manager keeps the certificate and signature layer, the part of the migration the internet has barely started, under control as you move to post-quantum trust. Together, they give you a defensible plan against a deadline that keeps moving forward.
- Key Takeaways
- Why The Deadline Moved Earlier
- The Risk That Does Not Wait: Harvest Now, Decrypt Later
- The Internet Is Migrating Unevenly, And The Gap Is The Warning
- Why Migration Takes Longer Than Leaders Expect
- Three Moves To Make Now
- Common mistakes that cost organizations time
- What The Deadlines Signal for Everyone
- How Encryption Consulting Helps
