Preparing for Post-Quantum Cryptography

On September 19, 2026, Anthropic engineer Stephen A. Weis published both prime factors of RSA-896, a 270-decimal-digit challenge number, after Claude adapted the classical general number field sieve to graphics processors and coordinated 2,048 of them, as CryptoBriefing reported. Sixteen days earlier, Cognition’s Eric Lu had factored the 862-bit RSA-260 with the company’s Devin agent. The public factoring record had not moved since February 2020, and then it advanced from 829 to 896 bits in sixteen days. No deployed RSA-2048 key was affected, and no claim exists that RSA-896 is a practical break of live systems. The main change was the reduction in engineering cost to run an attack that has been understood for decades, on the key sizes that much infrastructure still depends on.

That is one of two dangers, and it is entirely classical. The second is quantum, and it operates on a different timeline. A sufficiently capable quantum computer running Shor’s algorithm would break RSA and every elliptic-curve scheme regardless of key length. Both threats target the same systems, which is why a migration plan focused on only one of them is incomplete.

This article is the hub for a six-part series explaining how public-key cryptography breaks, why each class of system fails differently, and what a developer or security engineer can do about it now. It is written for people who have to make decisions, not for cryptographers. If you run servers, hold crypto, or manage enterprise keys, one of the six parts is aimed directly at your infrastructure.

Key Takeaways:

• Two independent factoring records landed in sixteen days: RSA-260 on September 3, 2026, and RSA-896 on September 19, 2026. Neither used quantum hardware and neither improved the underlying algorithm.
• RSA-2048 remains considered secure against classical factoring. The exposed tier is smaller legacy RSA keys, which many organizations never retired.
• Quantum computers running Shor’s algorithm threaten RSA and elliptic-curve cryptography at every key size, including secp256k1 (Bitcoin, Ethereum) and Ed25519 (Solana, SSH).
• Key exchange has a “harvest now, decrypt later” exposure that signatures do not, so hybrid key exchange is the urgent first move while signature migration follows.
• Crypto-agility lets an organization absorb the next algorithm change without replacing infrastructure, which matters because the standards keep moving.

What Changed in 2026

For years, the largest publicly factored RSA challenge number was RSA-250, an 829-bit modulus broken in February 2020 by an academic team running the general number field sieve on central processing units, as documented in the 2020 paper by Boudot and colleagues. Then two records fell in sixteen days. The mathematics did not change. Both 2026 teams ran the same classical method used since the 1990s. The difference was who could run it and at what cost.

The engineering barrier dropped sharply. Cognition’s Eric Lu reported that Devin, the company’s AI coding agent, had a working graphics-processor lattice siever in a matter of hours and spent the following week optimizing the rest of the pipeline, with no algorithmic improvements, as Lu explained in Cognition’s technical writeup. Weis’s later RSA-896 run used 2,048 graphics processors over roughly ten days, according to TechTimes coverage of the result. Each record matched the curve the mathematics predicts, and the cost ratio between the two results follows standard number field sieve scaling.

The practical consequence is that scaling to a slightly larger number is now incremental rather than a multi-month specialist project. RSA-1024 sits in that reachable range, and Weis assessed that many organizations with data-center graphics processor fleets could break keys at that size, while deployed RSA-2048 keys remain secure, per the same TechTimes account. RSA-1024 was already non-compliant for new federal protection under NIST rules since 2014. What 2026 changed is the cost of attacking keys that organizations never retired.

Classical Factoring and Quantum Attack Are Not the Same Problem

The confusion between these two threats leads to poor migration schedules, so the distinction is worth stating precisely. Classical factoring, even when accelerated by artificial intelligence, attacks the integer factorization problem behind RSA. It succeeds when the key is small enough and the attacker has enough graphics processors. The response is larger keys or a move away from RSA, and RSA-2048 is not on the classical target list. Quantum computing running Shor’s algorithm attacks the integer factorization problem and the elliptic-curve discrete logarithm problem at once, so it breaks RSA and elliptic-curve cryptography regardless of key size. The response is entirely different primitives, because no key length fixes a quantum-vulnerable algorithm.

The resource estimates for the quantum track keep changing, which is why the timeline is uncertain rather than merely distant. Google Quantum AI’s Craig Gidney published a May 2025 estimate that factoring RSA-2048 would require fewer than one million noisy physical qubits running under a week, according to the paper on arXiv, a sharp drop from his earlier figure of 20 million. In June 2026, research from Caltech and the startup Oratomic put breaking the P-256 elliptic curve at as few as 10,000 qubits, which TechTimes covered as a source of renewed concern. No machine at either specification exists. The estimates are planning inputs, not demonstrations.

The two tracks also interact at the analysis layer. Anthropic announced in July 2026 that an AI model had found a key-recovery weakness in HAWK, a lattice-based signature candidate, and the HAWK team withdrew the scheme the following day, according to Anthropic’s research note. That finding did not affect the finalized ML-KEM and ML-DSA standards, which rest on different mathematics, but it shows AI tools now apply to the cryptanalysis that evaluates post-quantum candidates as well as to graphics processor engineering.

Which Systems Use Which Cryptography

A migration map starts with knowing what each system actually depends on. The families differ in ways that matter, because classical factoring and quantum attack affect them differently.

The split matters for sequencing. Infrastructure that uses RSA keys, meaning SSH, TLS, PKI, and enterprise certificate chains, carries classical risk today for any key at 1024 bits or below. Systems built on elliptic curves, meaning Bitcoin, Ethereum, and Solana, carry no classical risk from the 2026 factoring records at all, because the general number field sieve factors RSA moduli and does not solve elliptic-curve discrete logarithms. Their exposure is entirely quantum, and it is a coordination problem rather than a mathematics problem.

Post-quantum key encapsulation mechanisms do not replace digital signatures, so a migration plan has to track both. ML-KEM is a key-encapsulation mechanism used for key exchange, while ML-DSA and SLH-DSA are signature standards, and the NIST announcement of the finalized standards identifies each algorithm and its purpose. A blockchain account needs a signature construction, not a key-encapsulation mechanism, and a TLS handshake needs both.

The Post-Quantum Standards Landscape

Three standards are final and a fourth is coming. NIST published FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA digital signatures, and FIPS 205 for the hash-based SLH-DSA alternative on August 13, 2024, per the NIST post-quantum cryptography project page. ML-KEM and ML-DSA derive from the CRYSTALS-Kyber and CRYSTALS-Dilithium candidates and rest on lattice mathematics. SLH-DSA derives from SPHINCS+ and rests on hash functions, giving it a different security foundation that works as a hedge against a future break in the lattice assumptions.

Two more schemes are selected but not yet final. Falcon, to be published as FN-DSA in the draft FIPS 206, produces smaller signatures than ML-DSA at comparable security, at the cost of a harder implementation because its Gaussian sampling uses floating-point arithmetic. HQC was selected for standardization on March 11, 2025 as an additional key-encapsulation mechanism, according to NIST’s project page. Treat FIPS 203, 204, and 205 as the current final baseline and describe FN-DSA and HQC by their draft or selected status, not as approved standards.

The regulatory clock is now explicit. Executive Order 14409, signed June 22, 2026, directs federal civilian agencies to transition high-value key establishment to post-quantum cryptography by the end of 2030 and digital signatures by the end of 2031, with a NIST pilot migration completed by December 31, 2027, as TechTimes detailed. National security systems are exempted because the Pentagon has migrated under the National Security Agency’s Commercial National Security Algorithm Suite 2.0, which required new national security acquisitions to be quantum-safe by January 2027. The private sector faces softer but convergent guidance. NIST IR 8547, still a draft, targets deprecating RSA and elliptic-curve algorithms at the 112-bit security level after 2030 and disallowing them after 2035, per the NIST publication.

Hardware Validation and Hybrid Cryptography

Standards on paper do not secure anything until validated hardware and software can run them. Hardware validation is the gate that turns a finalized algorithm into something a procurement team can deploy, and the milestones are arriving. SEALSQ announced the commercial expansion of its VaultIC408 secure element platform after achieving FIPS 140-3 Level 3 validation under the Cryptographic Module Validation Program, per the company’s announcement. On the accelerator side, BTQ Technologies and Taiwan’s Industrial Technology Research Institute completed the first validation milestone for a compute-in-memory architecture designed to speed post-quantum cryptography, according to SDxCentral’s report. These are vendor-reported validation milestones, and the value for a buyer is the third-party artifact rather than the marketing claim: a validated module gives an auditor something to check.

Hybrid cryptography is the software-side bridge that buys time during the transition. A hybrid scheme combines a classical algorithm with a post-quantum one so the combined result is no weaker than the classical half it replaced, which protects against a future break in the newer lattice mathematics. Microsoft shipped hybrid post-quantum key exchange directly into Schannel, the Windows TLS stack, with three ML-KEM groups now configurable, as TechTimes reported. The Internet Engineering Task Force standardized hybrid post-quantum key agreement for TLS 1.3 in RFC 10024, defining the X25519MLKEM768 group that now negotiates by default in Chrome, Firefox, Safari, Cloudflare’s edge, and OpenSSH. That is the easier half of the migration and largely a configuration exercise on modern stacks. Certificates, stored keys, and hardware modules are the harder, slower half.

Crypto-Agility as the Real Goal

Crypto-agility is the ability to replace algorithms, protocols, libraries, and implementations while minimizing disruption, ideally without replacing the underlying hardware. Cisco’s security team states the reason bluntly: a networking platform can take four or more years to develop and then stay deployed for a decade, so designing around one point-in-time snapshot of cryptography is the wrong objective, according to Cisco’s analysis of crypto-agility. PQC readiness covers the defenses available today. Crypto-agility keeps those defenses replaceable as standards, protocols, and threats change.

The practical work starts with visibility. Encryption Consulting’s six-step framework for crypto-agile readiness puts a cryptographic governance program and a full inventory of cryptography in use at the front, because a Cryptographic Bill of Materials is a prerequisite for every later step: you cannot migrate cryptography you cannot see, per the framework. A June 2026 executive order directs the Cybersecurity and Infrastructure Security Agency and NIST to publish guidance on minimum elements for such an inventory, turning a structured cryptographic bill of materials into a compliance artifact rather than an engineering convenience.

Adoption is moving faster at the platform layer than inside enterprises. Cloudflare reported that a majority of human-generated traffic on its network was already protected with post-quantum encryption as of April 2026, and it matched Google’s 2029 target for full post-quantum security, according to The Quantum Insider’s survey of migration timelines. Microsoft’s Quantum Safe Program targets full transition by 2033. Enterprise deployment lags well behind the platform providers. DigiCert’s July 2026 Quantum Readiness Outlook, which surveyed information technology and security decision-makers, found that most organizations were planning, testing, or implementing post-quantum initiatives while only a small minority had deployed quantum-safe or hybrid cryptography across most of their certificates, per TechTimes coverage. DigiCert both commissioned that survey and sells a readiness platform, so the figures come from a vendor’s own research, but the planning-versus-deployment gap is the central enterprise problem.

What Each Part Covers

The six parts move from infrastructure to money to data at rest, then close with the artificial intelligence story and a full checklist. Each part is self-contained, so you can start with the system you own.

• Part 1: SSH Keys and the First Domino. Infrastructure is where the classical risk bites first. This part covers how RSA, ECDSA, and Ed25519 keys are used for host and user authentication, why shorter RSA keys fall first, and how OpenSSH’s hybrid key exchange protects new sessions from store-now-decrypt-later collection.
• Part 2: Bitcoin and On-Chain Public Keys. Bitcoin signs with ECDSA over secp256k1, and on-chain public key exposure through address reuse and unspent-output spending creates a permanent, public attack surface. This part explains how Shor’s algorithm and AI-helped classical factoring differ for Bitcoin, and how fresh-address hygiene and draft improvement proposals change the risk profile.
• Part 3: Ethereum Post-Quantum Roadmap and Account Migration. Ethereum’s reliance on secp256k1 for externally owned accounts meets a roadmap that targets the base layer by 2029. This part covers account abstraction as a migration tool, the Layer 2 dependencies that do not inherit base-layer safety automatically, and custody hygiene during the transition.
• Part 4: Solana’s Post-Quantum Migration. Solana is further along than most chains. Anza and Firedancer independently shipped test builds of Falcon-512 in April 2026, and Ed25519’s seed-derived key design opens a proof-of-possession migration path that Bitcoin and Ethereum lack. This part covers what other blockchain teams can borrow from the approach and where the open questions sit.
• Part 5: Banking and Data at Rest. Long-lived secrets in banking, healthcare, and government archives face the sharpest harvest-now exposure, because the data must stay confidential for decades. This part covers RSA in TLS, PKI, and hardware security modules, the hybrid TLS modes shipping today, and enterprise crypto-agility planning.
• Part 6: AI-Driven Classical Factoring and Defenses. The final part ties the RSA-260 and RSA-896 records together, explains why AI accelerates classical cryptanalysis without changing the mathematics, keeps the quantum threat separate, and closes with a crypto-agility checklist spanning SSH, wallets, and enterprise systems.

Where to Start This Week

Every part in this series ends with a checklist aimed at its own systems. The hub-level version is organized by what an attacker would target first, and none of it requires a completed quantum machine to justify the work.

• Inventory every RSA key at 1024 bits or below and treat each as urgent. The 2026 records put this tier within reach of organizations with data-center graphics processor fleets. Block new keys at that size and prioritize certificate authorities, code-signing pipelines, and long-lived signing certificates.
• Rank data by required confidentiality period rather than storage location. Anything that must stay secret past 2035 is already exposed if it travels under RSA or elliptic-curve protection, because the encrypted copy may already be recorded.
• Confirm hybrid key exchange is actually negotiating on your public endpoints. Check that TLS 1.3 sessions select a hybrid group rather than falling back to a classical-only exchange, and alert on fallback events.
• Update SSH to a version with post-quantum key exchange and verify it is active. OpenSSH has defaulted to hybrid key exchange since release 10.0 in April 2025, according to the OpenSSH project, and release 10.1 warns when a connection falls back to a non-post-quantum scheme.
• Audit wallet and address hygiene for cryptocurrency holdings. Reduce address reuse, retire stale approvals, and keep long-term holdings separate from frequently used accounts whose public keys are already visible on-chain.
• Ask every hardware security module vendor for validation submission dates and queue position. The FIPS 140-3 validation process for post-quantum modules runs long, and some deployed modules cannot be updated at all and require physical replacement.
• Separate key establishment, signatures, and stored-key wrapping into distinct workstreams. Hybrid transport security protects new sessions and does nothing for archives or legacy wrapping keys.
• Test rollover and recovery before cutover. A migration that cannot be rolled back is not a migration plan, and larger keys and signatures change handshake size and compute cost in ways a lab test will not always surface.
• Track NIST IR 8547 and the national and industry milestones as program dates rather than background reading. The 2030 deprecation and 2035 disallowance dates are the outer bounds, and high-risk systems move earlier.

The September 2026 factoring records broke a benchmark and lowered the engineering cost of running classical cryptanalysis at scale. They did not break a deployed RSA-2048 key, and the quantum machine that would break one at every key size is not built. That combination defines the window in which migration is affordable. The six parts that follow show how that window looks from the perspective of each system that depends on public-key cryptography, starting with the SSH key management strategies on the infrastructure you already run.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Post-Quantum Cryptography
• Post-Quantum Key Management in Business
• Ethereum Post-Quantum Security Roadmap
• Lessons from Solana’s Post-Quantum Migration
• SSH Key Management Strategies for Security

Sources and References

Sources cited while researching and writing this article:

• the 2020 paper by Boudot and colleagues
• explained in Cognition’s technical writeup
• RSA-896 Cracked with Claude AI, Second Factoring Record in Sixteen Days
• the paper on arXiv
• Can 10,000 Qubits Break the Internet? Inside the P‑256 Quantum Attack That Has Cryptographers Worried
• Anthropic’s research note
• NIST Releases First 3 Finalized Post-Quantum Encryption Standards
• Post-Quantum Cryptography | CSRC
• Post-Quantum Encryption Mandate: Trump Sets 2030 Deadline as Adversaries Harvest Data Now
• IR 8547, Transition to Post-Quantum Cryptography Standards | CSRC
• SEALSQ Leverages NIST FIPS 140-3 Level 3 Validation to Accelerate Government, Critical-Infrastructure and Post-Quantum Hardware-Security Programs; Provides Updated …
• BTQ validates compute-in-memory accelerator for quantum-proof cryptography
• Post-Quantum Cryptography Comes to Windows TLS: Three ML-KEM Groups Now Configurable
• Crypto Agility: Why PQC Is Not a One-Time Upgrade
• 6 Steps to Crypto-Agile Post-Quantum Cryptography in 2026
• Post-Quantum Cryptography Timelines: When Will Organizations Migrate?
• Post-Quantum Encryption Gap: Enterprises Plan but Only 7% Have Deployed
• OpenSSH: Post-Quantum Cryptography

Series outline