Long-Term Data Security in Banking

Key Takeaways:

• On September 19, 2026, Anthropic’s Stephen Weis published the factors of RSA-896, a 270-digit number, after Claude ported CADO-NFS to graphics processors and coordinated up to 2,048 of them for roughly 10 days and about 30 GPU-years. It was the second AI-assisted factoring record in sixteen days.
• RSA-2048 is about 35 billion times harder than RSA-896 under the same scaling heuristic, so no deployed 2048-bit key falls to this work. Weis assessed that RSA-1024 keys are now vulnerable to organizations with data-center GPU fleets.
• The real exposure for banks and government archives is harvest now, decrypt later: encrypted records with a long confidentiality lifetime are already being collected for future decryption.
• Hardware security modules are the physical bottleneck. Vendors hold FIPS 140-3 Level 3 validation, and several have CAVP certification for ML-KEM and ML-DSA, but none combine both.
• Hybrid TLS is deployable now. The federal M-26-15 memorandum sets December 31, 2030 as the mitigation objective, while SWIFT’s mandatory Release 8.0 lands at the end of July 2027.

The September 2026 RSA-896 Record

On September 19, 2026, Stephen Weis of Anthropic published the two prime factors of RSA-896, a 270-digit challenge number that had resisted public attack since the RSA Factoring Challenge. He used Claude to port CADO-NFS, the open-source number field sieve implementation, to graphics processors and to coordinate the run across up to 2,048 of them drawn from idle capacity. The job took roughly 10 days and about 30 GPU-years, as PostQuantum’s technical writeup documents. (Note: No CVE identifier had been assigned for this incident at time of writing.)

It was the second AI-assisted factoring record in sixteen days. On September 3, Eric Lu of Cognition published a factor of RSA-260, an 862-bit number, using a GPU version of CADO-NFS that the company’s Devin agent built. That run consumed about 4,900 GPU-days, or 13.5 GPU-years, at a cost Lu put near $400,000. Before September, the public record had stood at 829 bits since February 2020, when the RSA-250 team factored it on CPUs at a cost of about 2,700 core-years.

The result is directly checkable. Each of Weis’s two published primes has 135 digits and 448 bits, both pass primality tests, and their product equals the RSA-896 value on the public challenge list. The significance is not the number that fell, but that AI tools removed the engineering bottleneck that kept these records confined to specialized research groups, compressing the schedule every organization assumed it had.

Why AI Changes the Cost of Classical Factoring

The jump from 862 bits to 896 bits looks like acceleration. It is not. Under the standard number field sieve scaling heuristic, 34 extra bits of key length cost about 2.6 times the computation. Weis’s 30 GPU-years against Lu’s 13.5 is close to that ratio, so each record still cost about what the curve predicts. Nothing about the curve changed.

What changed is who can run the computation. Both records came from GPU ports of CADO-NFS written with AI agents. The hard step was the first GPU lattice siever that beat CPU, which Devin reportedly had working in about nine hours. Once a GPU pipeline exists, moving it to a slightly larger number is incremental work. Two teams independently built that pipeline within weeks, which is why two records landed in sixteen days after none in six and a half years.

The gap to the keys that protect banking infrastructure is enormous. RSA-2048 is about 35 billion times harder than RSA-896 under the same heuristic, roughly a trillion GPU-years and about $32 quadrillion at $3.50 per GPU-hour. No GPU fleet closes that gap, and no improvement to GPU sieving changes the scaling curve. Weis stated plainly that he had not meaningfully improved the running time of the general number field sieve, and that deployed RSA-2048 keys are unaffected.

The exposure sits in the middle. Weis’s assessment was that RSA-1024 keys are now vulnerable to many organizations with data-center GPU fleets. Lu estimated a hyperscaler could factor RSA-1024 for about $30 million. Legacy 1024-bit keys in certificate authorities, older hardware security modules, and long-lived signing certificates are the concrete target, and they need their own schedule separate from quantum risk.

Harvest Now, Decrypt Later and Data at Rest

The quantum threat to data at rest follows a different logic than the classical records. An adversary does not need to break a key today. They copy the ciphertext now and wait for a cryptographically relevant quantum computer running Shor’s algorithm, which would solve the integer factorization and discrete logarithm problems that RSA and elliptic curve cryptography rest on. Palo Alto Networks describes the pattern as a present-day risk, with long-lived government records, financial data, and healthcare information the most exposed.

Data at rest is the worst case because the ciphertext has already been captured. A TLS session key can be rotated, but a mortgage file, a trust account record, or a declassified archive encrypted under RSA stays on disk for decades. The CSIS analysis of US banking readiness, published September 17, 2026, makes the point bluntly: any record that must remain confidential past 2030 is already exposed, because the traffic and files are being collected now. Migration does not recover what has already been harvested. It stops the accrual.

The threat model includes more than balances. CSIS notes that payment traffic reveals supply chains, defense relationships, and sanctions activity, making decrypted financial messaging an intelligence problem before it is a compliance problem. A bank’s cryptographic migration is not only a security control for its own data; it protects the structure of the economy its messaging describes.

Symmetric encryption survives this transition. AES and other symmetric primitives degrade under Grover’s algorithm but remain usable with larger keys, which is why the migration effort concentrates on public-key algorithms: key exchange, signatures, and the certificate infrastructure built around them.

The Hardware Security Module Bottleneck

Every post-quantum migration eventually reaches the same physical constraint. Software libraries can implement ML-KEM and ML-DSA, but the root keys that anchor a certificate authority, a code-signing pipeline, or a payment switch live inside a hardware security module, and if that module cannot execute the new algorithms, migration stops there. QNu Labs’ analysis of post-quantum hardware security modules calls the module the root of trust and notes that a software-only rollout leaving root keys in software lowers the security posture while upgrading the algorithms.

The new algorithms carry materially larger keys and signatures. ML-DSA signatures run to several kilobytes against a few hundred bytes for ECDSA, which increases memory pressure, handshake size, and compute per operation inside the module. Vendors have responded. Thales launched Luna 8 in August 2026, a network appliance with an upgradeable architecture that the company says provides a path to post-quantum cryptography without disrupting existing investments, per The Quantum Insider’s coverage of the launch. Thales states that Luna 8 is being independently assessed to meet FIPS 140-3 Level 3 and EU Common Criteria. Those are vendor claims about an assessment in progress, not completed certifications.

The certification gap is the detail most procurement teams miss. Several vendors hold CAVP certification for post-quantum algorithms, and several hold FIPS 140-3 Level 3 validation for their modules, but as of late 2025 none had obtained both together, with all at Modules in Process or Implementation Under Test. The CMVP validation process averages more than two years from lab submission to certification. If your compliance regime requires validated post-quantum operations specifically, ask vendors for submission dates and queue position rather than accepting a “post-quantum ready” badge.

Hardware supply chains add a second constraint. Moona Ederveen-Schneider of Resilia Connect told BankInfoSecurity that some infrastructure cannot be updated and requires physical replacement, and that assuming a more trusted supply chain can be found on demand is a dangerous illusion. The migration involves procurement as much as engineering.

Hybrid TLS and the Key Exchange Priority

Key exchange is the part of the problem that is already solved and deployable. Hybrid TLS combines a classical algorithm with a post-quantum one so that a break in either does not immediately compromise the session. X25519MLKEM768, which pairs the X25519 elliptic curve exchange with the NIST-standardized ML-KEM, is already the default hybrid key exchange in major browsers, according to Encryption Consulting’s deployment guide. Microsoft shipped hybrid post-quantum key exchange into Schannel in its July 2026 Patch Tuesday, making three ML-KEM groups configurable in Windows TLS.

The priority order follows directly from the threat model. Key exchange carries harvest-now, decrypt-later exposure because a recorded session can be decrypted later. Signatures do not, because a forged signature requires a live attack. That means the urgency on key establishment is higher than on signature retirement, even though both eventually need to move. For an organization with a large TLS estate, enabling hybrid key exchange is the highest-value action available today and it does not require new hardware in most cases.

The migration plan should separate these two tracks explicitly. Key exchange moves now, using hybrid modes that are backward compatible. Signature keys and the certificate authorities that issue them move later, against NIST’s deprecation timelines, and depend on hardware security modules that can execute ML-DSA. Treating them as a single project causes migration plans to stall.

Building a Cryptographic Inventory

Every credible migration starts with the same step: finding where vulnerable cryptography actually lives. The NIST National Cybersecurity Center of Excellence migration project frames the work as understanding the use of quantum-vulnerable public-key algorithms across hardware, software, and services. For most institutions that is harder than it sounds. CSIS reports that roughly 8,500 federally insured depository institutions exist in the United States, and that only about 1 in 10 of the roughly 400 that file with the SEC mentions quantum at all, nearly always as a single line in a list of emerging technologies.

The inventory has to cover more than your own systems. Everest Group’s July 2026 analysis, cited by CSIS, found that financial institutions will not become quantum ready on their own because much of their cryptography sits outside their direct control or is shared in nature. Card processors, clearing infrastructure, and SaaS applications all carry cryptographic flows the institution cannot fully inventory. The US Treasury launched a Quantum-Readiness Task Force on August 24, 2026 with a Third-Party and Vendor Readiness workstream aimed squarely at this gap, and the Bank of England’s July 2026 Financial Stability Report states that firms should seek assurance on how material third parties are preparing.

A workable inventory records five things for each cryptographic asset: the algorithm and key size, the data class it protects and that data’s confidentiality lifetime, the system or vendor that owns it, the contract renewal date that creates a natural migration window, and whether the asset is reachable for replacement or requires physical substitution. Marking each migration date by authority level, whether it is a final standard, a draft proposal, a vendor commitment, or an internal target, prevents a plan from treating a proposal as a mandate. ITECS makes this distinction for NIST IR 8547, whose 2030 and 2035 transition dates remain an Initial Public Draft rather than finalized policy.

Standards, Deadlines, and Readiness

The standards that migration targets are settled. NIST finalized FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a hash-based backup on August 13, 2024, and added HQC as a fifth algorithm in March 2025. The NIST post-quantum cryptography page states that these standards are ready to be implemented now. NIST also notes that an AI-assisted analysis in July 2026 found a vulnerability in HAWK, a lattice-based signature candidate, and the HAWK team withdrew it, without affecting the finalized standards that rest on different mathematical foundations.

Deadlines and readiness diverge sharply across sectors. The federal government has put itself on a clock while leaving the financial system it supervises largely on advisory timetables. The table below summarizes the verified positions.

The performance figure is measured, not estimated. When the BIS Innovation Hub, the Bank of Italy, the Bank of France, Deutsche Bundesbank, and SWIFT replaced traditional digital signatures with post-quantum equivalents in an operational payment flow, verification averaged 209.9 milliseconds against 28.1 milliseconds for the classical scheme. All test scenarios succeeded, which shows the problem is engineering rather than a configuration change. Every institution should benchmark post-quantum operations on its own hardware under production-like load before committing to cutover dates.

Audit Checklist for Banking and Government Archives

These steps are ordered by what a patient attacker or a well-funded factoring effort would target first.

• Inventory every RSA key at 1024 bits or below and treat each as urgent. The 2026 records put RSA-1024 within reach of organizations with data-center GPU fleets, per Weis’s assessment. Anything at or below 1024 bits should be rotated immediately.
• Classify data by confidentiality lifetime. Any record that must stay secret past 2030 is already exposed if it travels under RSA or elliptic curve protection. Prioritize long-lived archives, mortgage files, and trust records.
• Enable hybrid TLS key exchange now. X25519MLKEM768 is already a browser default and backward compatible. Key exchange carries the harvest-now risk, so it moves before signature retirement.
• Confirm your hardware security module roadmap. Ask each vendor for ML-KEM and ML-DSA firmware support, CAVP submission dates, and FIPS 140-3 Level 3 queue position, not just a readiness badge.
• Map third-party cryptography. Card processors, clearing infrastructure, and SaaS providers carry flows you cannot inventory internally. The Treasury Task Force’s vendor workstream exists because a bank’s readiness ceiling is set by its weakest critical vendor.
• Mark every deadline by authority level. Separate final standards from draft proposals and vendor commitments. NIST IR 8547’s 2030 and 2035 dates remain a draft, while M-26-15’s December 31, 2030 objective is binding on federal agencies.
• Benchmark before cutover. Post-quantum signature verification measured 209.9 milliseconds against 28.1 milliseconds in the BIS payment trial. Test on your own infrastructure under load.
• Plan for hardware replacement, not just patching. Some modules cannot be updated. Build procurement lead times into the schedule and identify systems that need physical substitution.

The September 2026 records do not break a deployed 2048-bit key, and the quantum machine that would does not exist yet. That combination is exactly the window in which migration is affordable. The records shortened the schedule by showing how fast AI-assisted engineering can move a specialized computation forward, and attackers are already collecting the archives that a future machine will read. Part 6 closes the series by combining the AI-driven classical factoring story and providing a full crypto-agility checklist across SSH, wallets, and enterprise systems.

Related Reading

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

• Post-Quantum Security for Ethereum Wallets
• Post-Quantum Security for Blockchain Systems
• Lessons from Solana’s Post-Quantum Migration
• Bitcoin Public Key Exposure and Risks
• SSH Key Management Strategies for Security

Sources and References

Sources cited while researching and writing this article:

• RSA-896 Factored With Claude, 16 Days After RSA-260
• Harvest Now, Decrypt Later: Quantum Security Risk
• Is the U.S. Banking System Ready for a Post-Quantum Future?
• PQC HSM: How Hardware Security Modules Fit Into Post-Quantum Migration
• Thales Launches Luna 8 Hardware Security Module for Post …
• Post-Quantum Cryptography Migration Faces a Hardware Problem
• X25519MLKEM768 TLS 1.3 Deployment Guide | Encryption Consulting
• Post-Quantum Cryptography: 2026 Migration Guide – ITECS
• Post-quantum cryptography – NIST
• M-26-15-Execution-of-the-Migration-to-Post-Quantum-Cryptography …
• Post-Quantum Encryption Gap: Enterprises Plan but Only 7% Have Deployed