Post-Quantum Key Management in Business

On September 19, 2026, Anthropic’s Stephen Weis published both prime factors of RSA-896, a 270-digit challenge number, after Claude adapted CADO-NFS to run on graphics processors and coordinated up to 2,048 GPUs over about ten days, totaling roughly 30 GPU-years, according to his primary disclosure. Sixteen days earlier, Cognition’s Eric Lu factored the 862-bit RSA-260. Neither result affected RSA-2048, but both lowered the cost of attacking the tier that enterprise archives, hardware security modules, and legacy TLS endpoints still rely on: RSA-1024.

Weis’s evaluation was focused: deployed RSA-2048 keys remain secure; RSA-1024 keys are now within reach of organizations with data-center GPU resources. This should prompt an enterprise key management review this quarter, since the data those keys protect often cannot be re-encrypted after the fact.

Key Takeaways:

• RSA-896, a 270-digit number, was factored on September 19, 2026 by Anthropic’s Stephen Weis using Claude and up to 2,048 GPUs over about ten days and roughly 30 GPU-years, marking the second AI-assisted factoring record in sixteen days after RSA-260 was factored on September 3.
• Neither record weakens RSA-2048, which requires about 35 billion times more work under the same scaling heuristic. The exposed tier is RSA-1024, which Weis judged vulnerable to organizations with data-center GPU fleets.
• The main enterprise risk is collecting encrypted records now for future decryption: encrypted data with long confidentiality lifetimes is already being stored for later decryption, and no action after transmission can reverse that.
• Hardware security modules create a physical bottleneck. FIPS 140-3 validation for post-quantum modules currently takes over 500 days on average, and some deployed modules cannot be updated at all.
• Only about 7 percent of enterprises have deployed quantum-safe or hybrid cryptography across most of their certificates, according to DigiCert’s July 2026 survey, even though 87 percent report planning or testing.

What the September 2026 Records Actually Changed

Public integer factorization records had remained unchanged for six and a half years. The previous record was RSA-250, an 829-bit number factored in February 2020 by a six-researcher academic team on CPUs at a cost of about 2,700 core-years, according to the 2020 paper by Boudot and colleagues. In September 2026, the record increased from 829 bits to 896 bits within sixteen days.

The mathematics remained the same. Both teams used the general number field sieve, the classical method applied by the 2020 team, but adapted to GPUs by AI coding agents. Weis stated clearly that he had not significantly improved the sieve’s running time. What changed was the engineering effort: adapting CADO-NFS to graphics processors and coordinating a fleet of idle machines previously required a specialist team with deep knowledge of both the software and GPU programming. An AI agent reduced that workload.

The scaling is straightforward and worth stating precisely, since coverage has exaggerated it in both directions. RSA-896 is 34 bits larger than RSA-260. Under standard number field sieve scaling, 34 extra bits require about 2.6 times more computation, and Weis’s roughly 30 GPU-years compared to Lu’s about 13.5 GPU-years matches that ratio closely. The PostQuantum technical analysis details the calculation: RSA-2048 requires about 35 billion times the work of RSA-896, roughly a trillion GPU-years, or a cost near $32 quadrillion at $3.50 per GPU-hour. No GPU fleet can close that gap.

For enterprise planning, the middle of the key-size range matters most. Lu estimated a hyperscaler could factor a 1,024-bit key for roughly $30 million at market GPU prices, and Weis judged that many organizations with data-center GPU fleets could break RSA-1024 keys. NIST disallowed 1,024-bit RSA for new federal protection in 2014, so this tier is already non-compliant in regulated contexts. The records change who can afford the attack and the cost, not the underlying mathematics.

Harvest Now, Decrypt Later and the Data-at-Rest Problem

The classical factoring records and the quantum threat follow separate paths, and mixing them leads to an incorrect migration schedule. However, they converge on one enterprise issue: data whose confidentiality must outlast the protection around its keys.

Harvest now, decrypt later describes an attack that is complete by the time it succeeds. An adversary records encrypted traffic or copies an encrypted archive today, then decrypts it once a cryptographically relevant quantum computer exists. A bank communication encrypted under RSA-2048 and intercepted this year becomes readable at that moment regardless of what the bank does between now and then. For data already transmitted, the clock has stopped.

The scale is concrete. DigiCert’s second annual Quantum Readiness Outlook, released July 23, 2026 and surveying 1,001 information technology and cybersecurity decision-makers across the United States, United Kingdom, and Australia, found that 84 percent of surveyed organizations believe at least some of their encrypted data is already vulnerable to harvest-now attacks, according to the DigiCert release. DigiCert commissioned that survey and also sells a quantum readiness platform, so the finding comes from a vendor’s own research; the trend matches independent assessments from the Cloud Security Alliance and NIST, but the source context is worth noting.

The framework that turns this into a decision is Mosca’s theorem, standard in quantum migration planning. If the time required to migrate cryptographic systems plus the duration for which data must remain confidential exceeds the estimated arrival of a cryptographically relevant quantum computer, migration is already urgent. For an enterprise holding financial records or health data with a ten-year or longer confidentiality requirement and facing a realistic three-to-five-year migration timeline, that inequality works against them if the machine arrives by 2031 or 2032.

Financial transaction records and banking data were identified as the categories most likely to be targeted first once quantum decryption becomes viable, followed by cryptocurrency private keys, according to the DigiCert survey. These are also the categories with the longest audit and compliance retention requirements, where the math is least forgiving. The G7 Cyber Expert Group presented this scenario to financial regulators in its January 2026 statement on a coordinated post-quantum roadmap.

The Hardware Security Module Bottleneck

Hardware security modules slow enterprise key management migration to the pace of procurement and certification. These devices store and manage cryptographic keys, and they are central to the data-at-rest problem because they protect the keys that secure archived ciphertext.

Two constraints dominate. First, validation. The FIPS 140-3 validation process that post-quantum modules must complete currently takes over 500 days on average, according to PostQuantum’s review of the United States post-quantum regulatory framework. That queue delays deployment from vendor firmware release to enterprise use in regulated environments. Second, physical replaceability. Some deployed modules cannot accept new firmware and require hardware replacement, adding procurement lead times measured in quarters to any migration schedule.

Key and certificate sizes add to the problem. An ML-KEM-768 public key is 1,184 bytes compared to 32 bytes for an X25519 elliptic-curve public key, about 37 times larger, affecting PKI storage, certificate chain sizes, and handshake bandwidth. Migrating a root certificate authority to issue ML-DSA certificates requires deploying a parallel CA hierarchy rather than an in-place upgrade, increasing project scope beyond most migration estimates.

There is progress. FortifyIQ announced in September 2026 that its post-quantum signature verification library completed NIST’s Cryptographic Algorithm Validation Program, confirming compliance with FIPS 204 for post-quantum digital signatures, as reported by AnySilicon. CAVP validation matters because it provides procurement teams with a verifiable artifact rather than a vendor roadmap promise. When evaluating hardware security modules, request each vendor’s supported standards, validation submission dates, and queue position, not just a readiness badge.

Hybrid TLS and the Key Exchange Priority

Key exchange is the first issue to address and the easiest, since hybrid modes are already shipping and enabled by default in major platforms. The Internet Engineering Task Force standardized hybrid post-quantum key agreement for TLS 1.3 in RFC 10024, published August 2026, defining the named groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, according to the specification.

The term hybrid refers to the safety margin. Each group combines a classical key exchange with ML-KEM, so even if the newer post-quantum component is later broken by cryptanalysis, the combined result is no weaker than the classical exchange it replaced. X25519MLKEM768 is the default post-quantum key exchange in Chrome, Firefox, Safari, Cloudflare’s edge, OpenSSL 3.5 and later, and Go, and is the most widely deployed post-quantum cryptography on the internet.

The operational challenge is the ClientHello size. A TLS 1.3 ClientHello with X25519MLKEM768 includes an ML-KEM-768 public key of 1,184 bytes alongside the 32-byte X25519 key, increasing the message from roughly 300-500 bytes to about 1,300-1,500 bytes. That expands the handshake across multiple TCP segments and causes middlebox and MTU issues that do not appear in lab tests. The audit guidance for the group notes key-share encoding order as a common interoperability bug: X25519MLKEM768 places the ML-KEM encapsulation key before the X25519 key, the reverse of the P-curve variants.

Hybrid transport security protects new sessions. It does not re-encrypt archives, replace legacy key-wrapping keys, or update certificate authorities. That distinction explains why migration splits into two tracks: replace key exchange now, and run a separate, longer workstream for stored keys, certificates, and hardware.

Inventorying Cryptographic Assets Before Migration

You cannot migrate what you cannot identify, and most organizations cannot quickly find every place they use cryptography. The first task is a service-linked cryptographic inventory recording, for each asset, the algorithm, key size, protocol, certificate chain, library, hardware security module, data class, confidentiality period, system owner, vendor, and replacement method.

Francis Gorman, head of the Security and Resilience Center of Excellence at Bank of Ireland, warned in BankInfoSecurity’s September 2026 practitioner coverage that a comprehensive, unfocused scan produces hundreds of thousands of findings without telling leaders what to address first. He recommends starting with a bounded problem that has a visible business deadline, such as public certificates, where shrinking certificate lifetimes already make manual renewal unsustainable. Build the automation, orchestration, and validation processes on that bounded problem, then reuse them when updating systems to quantum-resistant algorithms.

The regulatory direction is now explicit. A June 2026 executive order directs the Cybersecurity and Infrastructure Security Agency and NIST to publish guidance on minimum elements for a cryptographic bill of materials, an inventory of all cryptographic assets in a system that enables automated assessment, according to FedTech Magazine’s analysis. NIST and CISA had not yet published the detailed element list at the time of that reporting, but the direction is clear: a structured, machine-readable inventory is becoming a compliance artifact, not just an engineering convenience.

Prioritize by business exposure rather than asset count. Begin with systems that generate revenue or support the most important services, then determine within those services which data must remain protected and for how long. Biometric records, identity documents, intellectual property, and long-lived financial records carry confidentiality requirements that may already be exposed. Rank them by business importance, sensitivity, and required confidentiality period, and note whether each system connects to public endpoints, third parties, or cloud environments.

Building Crypto-Agility Into Key Management

Crypto-agility is the ability to replace algorithms in protocols, software, hardware, firmware, and infrastructure while preserving security and service continuity. It provides durable control, since the specific algorithm that needs replacing keeps changing. As Andrew Gault, chief executive of ZeroTier, said in the BankInfoSecurity coverage: organizations want not just post-quantum cryptography, but the ability to measure and then change their cryptography in the future.

The standards targets are set. NIST finalized its first three post-quantum standards in August 2024: FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA digital signatures, and FIPS 205 for the hash-based SLH-DSA alternative, according to the NIST announcement. NIST IR 8547 sets expected deprecation of quantum-vulnerable algorithms by 2030 and disallowance by 2035, with high-risk systems transitioning earlier, according to the initial public draft. The United Kingdom National Cyber Security Centre independently set discovery and initial planning by 2028, early high-priority migration by 2031, and completion by 2035.

Deployment has lagged behind planning. 87 percent of organizations are planning, testing, or implementing post-quantum initiatives while only 7 percent had deployed quantum-safe or hybrid cryptography across most of their certificates, up from 5 percent in the first annual survey. Legacy system complexity was cited by 25.6 percent of respondents as the biggest obstacle, replacing uncertainty around standards. This shows progress: the question is no longer which algorithms to adopt but how to remove RSA-2048 and elliptic-curve P-256 from infrastructure that has accumulated cryptographic dependencies for decades.

Crypto-agility takes a modular form. Separate key establishment, digital signatures, and stored-key wrapping into distinct workstreams with separate schedules. Require vendors to document supported standards, validation status, upgrade paths, and replacement dates, and include an agility clause in procurement contracts: ask whether the vendor will provide a deployable patch within six months of a standards change rather than leaving customers dependent on an unspecified roadmap. Keep an emergency withdrawal plan for any scheme that later fails cryptanalysis or implementation review. The Anthropic finding that an AI model identified a weakness in the HAWK lattice signature candidate, leading the HAWK team to withdraw it the next day, reminds us that algorithm diversity is a feature, not redundancy to trim.

Audit Checklist for Enterprise Key Management

• Inventory every RSA key at 1,024 bits or below and treat each as urgent. The September records put this tier within reach of organizations with data-center GPU fleets. Block the creation of new keys at that size, and prioritize certificate authorities, code-signing pipelines, and long-lived signing certificates.
• Rank data by required confidentiality period, not storage location. Anything that must stay secret past 2035 is already exposed if it travels under RSA or elliptic-curve protection. Long-lived archives, financial records, and government material come first.
• Confirm hybrid key exchange is actually negotiating at 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.
• Measure the ClientHello size impact before rollout. A hybrid handshake adds roughly a kilobyte to the ClientHello, which can break middleboxes and MTU assumptions that a lab test will not surface.
• Ask each hardware security module vendor for validation submission dates and queue position. FIPS 140-3 validation averages more than 500 days, 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 TLS protects new sessions; it does not re-encrypt archives or replace legacy wrapping keys.
• Test certificate rollover, trust-anchor replacement, bulk rewrapping, failover, and backup recovery. A migration that cannot be rolled back is not a migration plan.
• Track NIST IR 8547 and the National Cyber Security Centre milestones as program dates, not background reading. The 2030 deprecation and 2035 disallowance dates are the outer bounds; high-risk systems move earlier.

The September records broke a benchmark and lowered the engineering barrier to running classical cryptanalysis at scale. They did not break a deployed 2,048-bit key, and the quantum machine that would break one is not built. That combination defines the window in which migration is affordable. Enterprises that treat agility as an ongoing capability rather than a one-time project will be the ones that close it.

Part 6 covers the AI-driven classical factoring story in full and provides a detailed crypto-agility checklist spanning SSH, wallets, and enterprise systems.

Related Reading

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

• Post-Quantum Cryptography
• Ethereum Post-Quantum Security Roadmap
• SSH Key Management Strategies for Security
• Lessons from Solana’s Post-Quantum Migration
• AI and Classical Factoring Security

Sources and References

Sources cited while researching and writing this article:

• RSA-896 – saweis.net
• the 2020 paper by Boudot and colleagues
• RSA-896 Factored With Claude, 16 Days After RSA-260
• G7 Cyber Expert Group Statement on Advancing a Coordinated Roadmap for …
• PostQuantum’s review of the United States post-quantum regulatory framework
• FortifyIQ Announces CAVP Validated ML DSA Post Quantum Digital Signature Verification Library
• the specification
• Hybrid TLS 1.3 key exchange (X25519MLKEM768) – pqaudit.org
• How to Boost Cryptographic Agility Across the Enterprise
• Cryptographic Bills of Materials Are Now a Federal Requirement
• the NIST announcement
• IR 8547, Transition to Post-Quantum Cryptography Standards | CSRC
• Timelines for migration to post-quantum cryptography