Domain: Quantum Security / Regulatory Horizon

The Development

Between January 2025 and April 2026, a series of peer-reviewed papers, preprints, and architecture proposals substantially reduced the estimated quantum computing resources required to break the two cryptographic foundations most organisations depend on: RSA and elliptic curve cryptography (ECC).

The most consequential results came from three research groups working independently.

In May 2025, Craig Gidney at Google Quantum AI published a paper showing that RSA-2048 could be broken with fewer than one million physical qubits and a runtime under one week, down from the previous best estimate of 20 million qubits.[1] That paper drew on foundational work by Clémence Chevignard, Pierre-Alain Fouque, and André Schrottenloher at INRIA Rennes, who had published algorithmic improvements for quantum integer factorisation at CRYPTO 2025.[2]

In March 2026, the same Rennes team turned to elliptic curve cryptography. Their EUROCRYPT 2026 paper demonstrated a quantum algorithm that solves the 256-bit Elliptic Curve Discrete Logarithm Problem (ECDLP) using 1,193 logical qubits, roughly half the previous best estimate of 2,124 logical qubits.[3] For the P-224 curve used in some TLS implementations, the figure drops to 1,098 logical qubits.[3]

On 31 March 2026, Google Quantum AI published a 57-page whitepaper (co-authored with researchers from the Ethereum Foundation and Stanford University) presenting two optimised quantum circuits for breaking the secp256k1 curve, the cryptographic foundation of Bitcoin and Ethereum transaction signatures.[4] The circuits require fewer than 500,000 physical qubits on a superconducting architecture, roughly a 20-fold reduction over the prior best estimate for this curve. Runtime: approximately 9 minutes once the computation is primed with precomputed curve parameters.[4] In an unprecedented move, Google published a cryptographic zero-knowledge proof allowing independent verification of the claims without disclosing the attack circuits themselves.[4]

On the same day, a team at Oratomic, Caltech, and UC Berkeley published a proposal for running Shor’s algorithm on approximately 10,000 neutral-atom qubits, using a new compilation approach that exploits the native reconfigurability of atom arrays to reduce overhead.[5]

On 21 April 2026, IonQ published a 110-page architecture paper (the “walking cat architecture”) detailing a complete fault-tolerant quantum computing design built on trapped ions and quantum low-density parity-check (qLDPC) codes.[6] The paper estimates 110 logical qubits and one million T-gate operations per day using only 2,514 physical qubits, and compiles Shor’s algorithm for factoring 30-bit numbers with roughly 13,000 physical qubits.[6]

Also on 21 April, Coinbase’s Independent Advisory Board on Quantum Computing and Blockchain, a six-member panel including Scott Aaronson (UT Austin), Dan Boneh (Stanford), and Justin Drake (Ethereum Foundation), published a 51-page position paper concluding that a fault-tolerant quantum computer capable of breaking current cryptography will eventually be built and that organisations must begin preparing now.[7] The board stated that debate over exact timelines is “largely irrelevant” since migration planning should start immediately.[7]

On 24 April 2026, independent researcher Giancarlo Lelli broke a 15-bit elliptic curve cryptography key using publicly accessible quantum hardware, winning a 1 Bitcoin bounty from quantum security firm Project Eleven.[8] This is a 512-fold improvement over the previous public demonstration from September 2025. Bitcoin uses 256-bit encryption; the network remains far from vulnerable. But the acceleration in demonstrated capability, from 6-bit to 15-bit in seven months, is a measurable signal of hardware progress.[8]

On 29 April 2026, Aaronson published a statement on his widely followed blog, using a post announcing his election to the US National Academy of Sciences to relay a serious shift in expert consensus: the most reputable people in quantum hardware and error correction are now telling him that a fault-tolerant quantum computer able to break deployed cryptosystems “ought to be possible by around 2029.”[9] Aaronson, who has spent two decades as one of the field’s most prominent sceptics of quantum hype, characterised this as his public warning and urged organisations to begin switching to quantum-resistant encryption.[9]

On 30 April, Cloudflare published its post-quantum migration roadmap, targeting full migration to quantum-resistant cryptography by 2029.[10] Cloudflare reported that over 65% of human-initiated traffic on its network already uses post-quantum encryption for confidentiality, and framed its 2029 deadline as driven by the recognition that quantum resource estimates may stop being published openly as capabilities become commercially and strategically sensitive.[10]

Regulatory deadlines are now concrete and tightening across jurisdictions. NIST Interagency Report 8547 sets deprecation of quantum-vulnerable algorithms by 2030 for US federal systems and full disallowance by 2035.[11] NSA’s CNSA 2.0 requires all new National Security Systems acquisitions to be post-quantum compliant by January 2027.[12] The UK NCSC has published a three-phase migration timeline: discovery and planning by 2028, high-priority migration by 2031, and full migration by 2035.[13] The European Commission adopted a coordinated PQC implementation roadmap in June 2025, urging Member States to begin transition by end of 2026 and recommending that critical infrastructure complete migration by end of 2030.[14] Australia’s ASD recommends eliminating classical public-key cryptography by 2030.[15]

NIST finalised three post-quantum cryptographic standards in August 2024: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) as a hash-based signature alternative.[16] FN-DSA (formerly FALCON) is expected in late 2026, and HQC was selected as a backup KEM in March 2025. These standards run on existing hardware. Post-quantum migration is a software and protocol programme, not a quantum hardware purchase.[16]

No quantum computer has yet factored a number larger than 21 using Shor’s algorithm.[17] The largest experimental demonstrations remain orders of magnitude away from the qubit counts, error rates, and sustained operation times required for cryptographic relevance. None of the papers above claims a cryptographically relevant quantum computer (CRQC) exists today or is imminent.

In future issues, the following sections (Reality Check, Action Brief, CISO Governance Briefing, and Board Brief) will be available exclusively to paid subscribers. This issue is published in full so you can experience the complete Stratsec intelligence product.

The Reality Check

Assessment: Significant. The convergence of multiple independent research results in a single quarter represents a genuine acceleration in the theoretical path toward cryptographically relevant quantum computing. It does not mean a CRQC is arriving imminently.

Here is what actually changed. For two decades, the estimated physical qubit requirement to break RSA-2048 hovered around 20 million. In the past 18 months, independent work by Gidney, the Rennes team, and several architecture groups using qLDPC codes has compressed that to under one million, with some proposals suggesting fewer than 100,000.[1][2][6] For elliptic curve cryptography, the reduction is sharper still: Google’s new circuits need fewer than 500,000 physical qubits to break Bitcoin’s secp256k1 curve, down from roughly 9 million in the best prior estimate.[4] These improvements are purely algorithmic and compilational. They assume the same conservative hardware parameters. The engineering challenge of building these machines has not changed, but the size of the machine you need to build has shrunk by one to two orders of magnitude.

The Aaronson signal matters because of who is saying it. For twenty years, Aaronson has been the person sceptics cite when dismissing quantum threats. His blog carries a permanent tagline correcting the most common misconception about quantum computing. When he uses a celebratory post (his election to the National Academy of Sciences) to relay that his most trusted hardware colleagues now believe a CRQC “ought to be possible by around 2029,” and when he characterises this as a formal warning, that represents a shift in the informed consensus that security leaders should register.[9] The Coinbase advisory board’s independent conclusion, from a panel spanning quantum theory, applied cryptography, and blockchain architecture, reinforces this: timeline debates are beside the point; preparation must begin now.[7]

Four realities keep this at “Significant” rather than “Critical.”

First, the gap between theoretical architecture papers and working machines remains enormous. IonQ’s walking cat architecture is a 110-page blueprint. Nothing at that scale has been built or experimentally validated.[6] The Google circuits assume hardware that does not exist. The Oratomic/Caltech proposal is a compilation scheme, not a demonstrated factorisation.[5]

Second, the largest number ever factored by a quantum computer using Shor’s algorithm is 21.[17] The distance from 21 to a 2,048-bit RSA modulus is not a gap that closes overnight. The Project Eleven demonstration (15-bit ECC key) attracted attention as the most advanced publicly demonstrated quantum attack on elliptic curve cryptography, but security leaders should weigh it carefully: prominent cryptographers (including Google’s Craig Gidney) argued that the 15-bit search space is small enough for the key to be recovered via classical filtering of noisy quantum output rather than genuine quantum advantage. The demonstration remains 241 bits short of the target.[8] Getting from laboratory demonstrations to cryptographic relevance requires sustained progress across at least ten distinct engineering capabilities: error correction, syndrome extraction, below-threshold operation, qubit connectivity, logical gates, magic state production, algorithm integration, decoder performance, continuous operation, and manufacturing scalability.[18]

Third, the 2029 timeline Aaronson relays is optimistic by the standards of most credible assessments. The 7th edition of the Global Risk Institute’s Quantum Threat Timeline Report, published in January 2025 and surveying 37 quantum experts, found a median estimate of roughly a 24% probability of a CRQC existing by 2034.[19] Informed opinion spans a wide range, and anyone offering a precise date is either selling something or guessing.

Fourth, the threat that requires immediate action is not the CRQC itself. It is the harvest-now-decrypt-later (HNDL) problem: adversaries (state intelligence services in particular) are collecting encrypted data today to decrypt later once quantum capability arrives.[20] If your organisation handles data with a confidentiality requirement longer than ten years, and your data transits networks accessible to state-level actors, you have a current exposure. The second current exposure is to digital signature forgery: if a CRQC arrives while your systems still depend on RSA or ECC signatures, those signatures can be forged retroactively, undermining trust in signed documents, software updates, and identity credentials.[21]

One further observation deserves attention. Google has set 2029 as its own internal PQC migration deadline.[10] Cloudflare has set the same target.[10] These are two of the few organisations that simultaneously build quantum hardware or publish quantum resource estimates and operate global digital infrastructure. Their internal deadlines are not predictions of Q-Day. They are organisational judgments about how much lead time responsible preparation requires. Boards should weigh that signal accordingly, even if they discount every sensational headline.

The central message: a quantum computer that can break your encryption does not exist today and is unlikely to arrive in the next two to three years. But migration to post-quantum cryptography takes most organisations three to eight years to complete.[11] The regulatory deadlines are already set (2030 deprecation, 2035 disallowed). The mathematics underlying the threat has improved faster in the past 18 months than in the preceding decade. If you have not started your cryptographic inventory, you are already behind the timeline set by your own regulators.

The Action Brief

Commission a cryptographic inventory. This is the single most important first step and the one most organisations have not taken. You cannot migrate what you have not mapped. Identify every system, protocol, certificate, and key exchange in your estate that depends on RSA, ECC (ECDSA, ECDH, EdDSA), or Diffie-Hellman. Treat this as a standalone, resourced programme deliverable with its own milestone and reporting. Use the Cryptographic Bill of Materials (CBOM) framework as the output format. If you have already completed an inventory, verify it is current; cryptographic dependencies change with every software update and vendor integration.

Assess your HNDL exposure. Identify data in your estate with confidentiality requirements extending beyond 2035. If that data traverses networks accessible to state-level adversaries (and for most large organisations, it does), you have a current risk. Prioritise these data flows for early migration to quantum-resistant encryption. This is not a future problem; intelligence services are collecting now.

Establish a PQC migration programme. Designate an accountable programme owner, secure board-level sponsorship, and build a phased roadmap. The NIST-standardised algorithms (ML-KEM for key encapsulation, ML-DSA for digital signatures, SLH-DSA as a hash-based alternative) are finalised and available. This is a software and protocol migration; no quantum hardware is required. Begin with hybrid deployments that combine classical and post-quantum algorithms, allowing you to gain operational experience while maintaining backward compatibility. Target your TLS connections, VPN infrastructure, PKI certificates, and code-signing workflows first.

Engage your major technology suppliers. Ask whether their products support the NIST PQC standards. Ask for their migration roadmap. Google Chrome and Apple Safari deployed experimental ML-KEM support in 2024. Cloudflare has published a PQC migration roadmap targeting 2029 and reports that over 65% of human-initiated traffic on its network already uses post-quantum encryption.[10] Major HSM vendors have announced PQC support. Your suppliers’ readiness determines your migration speed; surface their plans now rather than discovering gaps during implementation.

Do not wait for a CRQC to justify action. The regulatory deadlines are set independently of the quantum timeline: CNSA 2.0 requires post-quantum compliance for new National Security Systems acquisitions by January 2027; NIST IR 8547 deprecates RSA and ECC by 2030 for federal systems; the European Commission’s roadmap targets critical infrastructure migration by end of 2030; 2035 is the hard disallowance date.[11][12][14] For European organisations, NIS2’s requirement to manage emerging technology risks proportionately already applies, and the European Commission is tracking PQC migration as an area of regulatory interest.[23] These deadlines do not care whether a CRQC arrives in 2029 or 2039. They create compliance obligations regardless.

CISO Governance Briefing

Enterprise Risk Management

The quantum threat to cryptography is not a new risk category. It sits within your existing information security or technology risk taxonomy, under the subcategory of cryptographic failure or key compromise. The change is to the likelihood and timeline parameters, not to the impact classification.

Register or update a risk entry for “compromise of classical public-key cryptography by a cryptographically relevant quantum computer.” Set the impact assessment based on your organisation’s specific dependency: for most enterprises, a compromise of RSA and ECC would affect TLS connections, VPN tunnels, PKI trust chains, digital signatures, code signing, and potentially authentication systems. The likelihood assessment depends on your planning horizon. For data with a confidentiality requirement beyond 2035, the HNDL risk is current and the likelihood should be rated accordingly. For operational cryptographic compromise (a CRQC breaking your systems in real time), the consensus range is somewhere between 2030 and 2040, with wide uncertainty in both directions.

If you use a quantitative model, the variable to revisit is the time horizon over which encrypted data retains value versus the estimated arrival of a CRQC. If you use a qualitative model, the appropriate shift for HNDL-exposed data is from “possible” to “likely” for organisations handling state-sensitive, financial, or long-lived personal data.

Budget and Resourcing

Post-quantum migration is a software programme, not a hardware procurement. The primary costs are in people and process: cryptographic inventory tooling, testing environments for hybrid deployments, PKI certificate lifecycle management, and staff time for integration testing.

For most organisations, the initial phase (inventory and assessment) requires one to two dedicated resources or a short-term advisory engagement. Budget for this now; it is the prerequisite for everything that follows and the step most organisations defer indefinitely.

The migration itself will extend over multiple budget cycles. Plan for incremental spend over three to five years. The largest cost drivers are typically PKI overhaul, HSM firmware or replacement, and application-level testing of post-quantum cipher suites. If your current PKI infrastructure is already due for modernisation, align the two programmes to avoid duplicate spend.

Policy and Procedure Updates

Three areas warrant review.

Cryptographic standards policy: add the NIST PQC standards (ML-KEM, ML-DSA, SLH-DSA) to your approved algorithms list. Where new systems are being procured or developed, require PQC support as a procurement criterion. For existing systems, establish a phased migration timeline consistent with regulatory deadlines.

Data classification: ensure your data classification scheme accounts for long-term confidentiality requirements. Data classified at the highest sensitivity level with retention periods extending beyond 2035 should be flagged for priority migration. This directly informs your HNDL risk assessment.

Procurement and vendor management: add PQC readiness questions to your standard technology procurement evaluation criteria (see Supplier Assurance Questions below). For new contracts, include provisions requiring the supplier to support quantum-resistant algorithms within a defined timeline.

Regulatory Exposure

The regulatory picture is concrete and tightening across all major jurisdictions.

In the US, NIST IR 8547 sets deprecation of quantum-vulnerable algorithms by 2030 for federal systems and full disallowance by 2035.[11] CNSA 2.0 mandates PQC for new National Security Systems acquisitions from January 2027.[12] Organisations in the US defence supply chain face flow-down obligations regardless of their own classification.

In Europe, the European Commission adopted a coordinated PQC implementation roadmap in June 2025, setting explicit milestones: Member States should begin transition by end of 2026, and critical infrastructure should complete migration by end of 2030.[14] While the roadmap is a recommendation rather than binding legislation, it carries practical weight under NIS2’s requirement to manage emerging technology risks proportionately. NIS2 and DORA impose board-level accountability for that proportionate management. Neither regulation names quantum computing explicitly, but the requirement to address foreseeable threats to the confidentiality and integrity of network and information systems applies. A board that can demonstrate awareness of the quantum threat, a documented migration plan, and measurable progress will be in a stronger regulatory position than one that waited for a CRQC to appear.

The UK NCSC has published a structured three-phase timeline: complete discovery and initial planning by 2028, execute high-priority migration by 2031, and achieve full migration by 2035.[13] Australia’s ASD recommends eliminating classical public-key cryptography by 2030.[15]

Team Skills

The capability required is applied cryptographic engineering, not quantum physics. Your team needs people who can conduct a cryptographic inventory across a complex estate, evaluate PQC algorithm options for specific use cases, test hybrid deployments without disrupting production, manage PKI certificate lifecycle migrations, and work with HSM vendors on firmware updates.

For most organisations, this means targeted upskilling of existing security engineers and architects over the next 12 months. Practical training in PQC algorithm selection, hybrid TLS configuration, and CBOM tooling is the priority. One or two team members should develop deeper competence and serve as internal subject-matter experts.

Second-Line and Third-Line Oversight

Risk management (second line) should verify that the security team has registered the quantum cryptographic threat in the risk framework, assessed HNDL exposure for high-sensitivity data, and established a migration programme timeline consistent with applicable regulatory deadlines.

Internal audit (third line) should consider including PQC migration readiness in its next technology risk review cycle. The audit should verify that a cryptographic inventory has been completed or is underway, that regulatory deadlines are documented and tracked, and that supplier assurance has been extended to cover PQC readiness.

Supplier Assurance Questions

Send these to your critical technology suppliers, cloud providers, PKI and certificate authorities, and managed security service providers this quarter.

Do your products currently support the NIST post-quantum cryptographic standards (ML-KEM/FIPS 203, ML-DSA/FIPS 204, SLH-DSA/FIPS 205)? If not, what is your published implementation timeline?
Do you offer hybrid mode deployments that combine classical and post-quantum algorithms during the transition period? Which protocols and products support this?
What is your roadmap for deprecating RSA, ECDSA, ECDH, and Diffie-Hellman in the products and services you provide to us? Is this timeline aligned with NIST IR 8547 milestones and the European Commission’s 2030 critical infrastructure deadline?
Have you completed a cryptographic inventory of the algorithms used in the products and services deployed in our environment? Can you provide a Cryptographic Bill of Materials (CBOM)?
For hardware security modules (HSMs) in our environment, do current firmware versions support PQC algorithms? If not, is this a firmware update or a hardware replacement?
How do you address the harvest-now-decrypt-later risk for data encrypted at rest or in transit using your products?
What testing have you conducted on PQC algorithm performance (latency, key sizes, bandwidth) in configurations comparable to our deployment?

Team Readiness Checklist

Use these questions with your security leadership team:

Cryptographic inventory

Have we completed a comprehensive inventory of cryptographic algorithms, protocols, and certificates across the estate?
Do we know which systems depend on RSA, ECC, or Diffie-Hellman for key exchange, digital signatures, or authentication?
Which third-party integrations and APIs use quantum-vulnerable cryptography, and do we have visibility into their migration plans?

HNDL exposure

Have we identified data with confidentiality requirements extending beyond 2035?
Do we know which data flows transit networks accessible to state-level adversaries?
Is HNDL risk reflected in our current risk register with an appropriate likelihood rating?

Migration readiness

Have we designated an accountable programme owner for PQC migration?
Do we have a phased migration roadmap aligned with NIST IR 8547, the European Commission’s 2030 milestone, and applicable regulatory deadlines?
Have we tested any PQC algorithms in a non-production environment?

PKI and certificate management

Do we know the total number of certificates in our estate and their cryptographic algorithms?
Can our certificate management tooling issue and manage PQC or hybrid certificates?
What is our plan for root and intermediate CA migration to PQC?

Second-Line and Third-Line Assurance Questions

For risk management (second line):

Has the security team registered the quantum cryptographic threat in the enterprise risk framework?
Is HNDL exposure assessed and documented for data classified at the highest sensitivity levels?
Has a PQC migration programme been established with board-level sponsorship, an accountable owner, and a timeline?
Are applicable regulatory deadlines (NIST IR 8547, CNSA 2.0, NIS2, European Commission 2030 milestone) documented and tracked?
Has supplier assurance been extended to cover PQC readiness for critical technology providers?

For internal audit (third line):

Has the organisation completed a cryptographic inventory? If not, what is the target completion date?
Is there a documented, board-approved PQC migration roadmap?
Does the procurement process include PQC readiness criteria for new technology acquisitions?
Is the board receiving reporting on PQC migration progress against regulatory deadlines?
Has the organisation assessed its exposure to retroactive signature forgery in addition to decryption risk?

Tabletop Exercise: Quantum-Accelerated Cryptographic Compromise

Hand this scenario to your incident response team. It requires no additional preparation. Allow 90 minutes.

Scenario:

It is a Tuesday morning. A credible open-source intelligence report, corroborated by your national cybersecurity agency, indicates that a state actor has demonstrated the ability to break 256-bit elliptic curve cryptography in a laboratory environment. The capability has not been publicly confirmed, but your government’s signals intelligence agency has issued a classified advisory (shared at TLP:AMBER with critical infrastructure operators) recommending immediate action on ECC-dependent systems.

Your organisation’s externally facing web services use TLS certificates signed with ECDSA. Your VPN concentrators use ECDH for key exchange. Your code-signing infrastructure uses ECDSA. Your internal PKI root certificate uses RSA-2048. You have not yet begun post-quantum migration.

At 10:15, your CISO receives a call from a major client’s Chief Risk Officer asking whether your systems are protected against quantum attack and requesting written assurance within 48 hours.

Discussion questions:

What is our immediate containment posture? Which systems should we prioritise for emergency action, and what does “emergency action” look like when the vulnerability is in the cryptographic primitive itself?
Do we have an inventory of every certificate, key, and cryptographic protocol in our estate? If not, how long would it take to produce one under crisis conditions?
Our TLS certificates use ECDSA. Can we reissue certificates using a quantum-resistant algorithm within 48 hours? What dependencies would block this?
The client’s CRO wants written assurance. What can we honestly say? What cannot we say?
Our code-signing keys use ECDSA. If an adversary can forge signatures, what is our exposure for software already distributed to customers?
What would we have done differently if we had started a PQC migration programme 18 months ago?

What to Tell Your Board

A board-ready slide summarising this briefing is available as a separate PPTX file for inclusion in your next risk committee deck.

Board-Ready Slide [.pptx]

Recent research has sharply reduced the estimated computing resources needed to break the encryption that protects most of our digital infrastructure. Multiple independent research teams have published results in the first four months of 2026 showing that the quantum computers required are far smaller than previously assumed: roughly one-tenth the size estimated just two years ago. A quantum computer capable of breaking current encryption does not exist today, but the path to building one is shorter than we previously understood.

For our organisation, this means three things.

First, we need to know what cryptography we use and where. We are commissioning a cryptographic inventory across our technology estate to identify every system that depends on the algorithms that quantum computers will eventually compromise. This inventory is the prerequisite for any migration and should be completed within the current quarter.

Second, we need a migration plan. NIST has published post-quantum cryptographic standards and set deprecation deadlines: quantum-vulnerable algorithms will be deprecated for federal systems by 2030 and disallowed by 2035. The European Commission’s roadmap targets critical infrastructure migration by end of 2030. The UK NCSC expects high-priority systems migrated by 2031. We need a phased migration programme with board-level sponsorship, a designated owner, and a timeline. We will present a proposed programme structure at the next risk committee meeting.

Third, there is a current risk that requires attention now. Adversaries, state intelligence services in particular, are collecting encrypted data today with the intention of decrypting it once quantum capability arrives. If our organisation holds data whose confidentiality extends beyond 2035 (and most of our sensitive data does), we should prioritise protecting those data flows first.

This is not a crisis. It is a long-duration infrastructure programme comparable in scope to the Y2K remediation or the migration from SHA-1 to SHA-2, which took the industry over twelve years. The difference is that we now have clear standards, concrete deadlines, and a narrowing window. We recommend the board endorse the establishment of a PQC migration programme this quarter, with a first progress report at the Q3 risk committee meeting.

Indicator Watch

Stratsec is tracking the emergence of commercial PQC compliance verification services and the speed at which major cloud providers operationalise NIST PQC standards in production. Google and Cloudflare have both set 2029 as their internal PQC migration deadlines; Cloudflare reports that over 65% of human-initiated traffic on its edge already uses post-quantum encryption.[10] The rate at which enterprise software, hardware vendors, and certificate authorities follow will determine whether the 2030 deprecation timeline is achievable for most organisations or whether it becomes a compliance cliff.

We are also monitoring the acceleration of experimental quantum attacks on elliptic curve cryptography. The Project Eleven demonstration (15-bit ECC key broken on public hardware in April 2026, up from 6-bit in September 2025) provides a measurable benchmark of hardware progress.[8] While the gap to 256-bit cryptographic relevance remains immense, the trajectory bears watching.

Separately, we are monitoring for classified or TLP-restricted government advisories that may indicate a revision in official threat timelines. Any acceleration in government advisory language, from “prepare” to “act now,” would be a leading indicator that intelligence community assessments have shifted.

References

[1] C. Gidney, “How to Factor 2048 Bit RSA Integers in 8 Hours Using 20 Million Noisy Qubits” (May 2025), arXiv:2103.06159. https://arxiv.org/abs/2505.15917

[2] C. Chevignard, P-A. Fouque, A. Schrottenloher, “Reducing Quantum Factoring to Modular Exponentiation Through Quantum Fast Residue Multiplication,” CRYPTO 2025. https://eprint.iacr.org/2024/222

[3] C. Chevignard, P-A. Fouque, A. Schrottenloher, “Quantum Cryptanalysis of Elliptic Curves: Improved Circuits for ECDLP,” EUROCRYPT 2026. https://eprint.iacr.org/2026/280

[4] Google Quantum AI, “Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations,” 31 March 2026. https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf

[5] Oratomic, Caltech, UC Berkeley, “Compiling Shor’s Algorithm on Neutral Atom Arrays,” 31 March 2026, arXiv preprint. Analysis: https://postquantum.com/security-pqc/10000-qubits-shors/

[6] IonQ, “Fault-Tolerant Quantum Computing with Trapped Ions: The Walking Cat Architecture,” arXiv:2604.19481, 21 April 2026. https://arxiv.org/abs/2604.19481 — Analysis: https://postquantum.com/quantum-research/ionq-walking-cat-trapped-ion-ftqc/

[7] Coinbase Independent Advisory Board on Quantum Computing and Blockchain, “Quantum Computing and Blockchain” (position paper), 21 April 2026. Authors: S. Aaronson, D. Boneh, J. Drake, S. Kannan, Y. Lindell, D. Malkhi. https://www.coinbase.com/blog/coinbase-quantum-advisory-council-publishes-position-paper-on-quantum-computing-and-blockchain — Analysis: https://postquantum.com/security-pqc/coinbase-quantum-blockchain-paper-analysis/

[8] Project Eleven / G. Lelli, 15-bit ECC key broken on public quantum hardware, 24 April 2026. https://intellectia.ai/blog/bitcoin-quantum-threat-2026

[9] S. Aaronson, “Will you heed my warnings NOW?”, Shtetl-Optimized (blog), 29 April 2026. https://scottaaronson.blog/?p=9718

[10] Cloudflare, “Post-Quantum Roadmap,” 30 April 2026. https://blog.cloudflare.com/post-quantum-roadmap/

[11] NIST Interagency Report 8547, “Transition to Post-Quantum Cryptography Standards,” Initial Public Draft, November 2024. https://csrc.nist.gov/pubs/ir/8547/ipd — Analysis: https://postquantum.com/security-pqc/nist-ir-8547-ipd/

[12] NSA, “Commercial National Security Algorithm Suite 2.0 (CNSA 2.0),” September 2022, updated through 2025. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

[13] UK NCSC, “Timelines for Migration to Post-Quantum Cryptography,” March 2025. Three-phase timeline: 2028 discovery, 2031 high-priority migration, 2035 full migration. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

[14] European Commission / NIS Cooperation Group, “A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography,” 11 June 2025. Milestones: Member State transition begins end of 2026; critical infrastructure migration targeted by end of 2030. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

[15] Australian Signals Directorate (ASD), ISM guidance on post-quantum cryptography, 2024, recommending elimination of classical public-key cryptography by 2030. https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism

[16] NIST, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), finalised August 2024. HQC selected March 2025. https://csrc.nist.gov/projects/post-quantum-cryptography

[17] Current record for Shor’s algorithm factorisation on quantum hardware: 21 = 3 × 7 (2012). See: https://postquantum.com/post-quantum/quantum-computer-factored-question/

[18] CRQC Quantum Capability Framework, PostQuantum.com: https://postquantum.com/post-quantum/crqc-quantum-capability-framework/

[19] Global Risk Institute / evolutionQ, “Quantum Threat Timeline Report,” 7th edition, January 2025, M. Mosca and M. Piani. https://globalriskinstitute.org/publication/2024-quantum-threat-timeline-report/

[20] Harvest Now, Decrypt Later: https://postquantum.com/post-quantum/harvest-now-decrypt-later-hndl/

[21] Trust Now, Forge Later: https://postquantum.com/post-quantum/trust-now-forge-later/

[22] Google Security Blog, September 2024 (ML-KEM in Chrome); Apple PQ3 protocol, 2024.

[23] ENISA, ECCG Cryptographic Mechanisms Report v2.0, 2025. https://www.enisa.europa.eu/publications/post-quantum-cryptography-integration-study — See also ETSI TS 103 744 on quantum-safe cryptography.

Stratsec: Emerging technology threats, without the hype.

Stratsec Emerging Threat Monitor

The Quantum Threat to Your Cryptography Just…