Imperative vs. Important: PQC edition
Two factoring records, one compliance cut-off, and four clocks that don’t agree
How this works: The Imperative covers what happened this week that calls for a response. The Important covers what will still be true after the headlines fade.
The Imperative: AI cryptography hacks prove Harvest Now Decrypt Later [HNDL] works
1. RSA-896 falls: AI changed the effort, not the math
On September 19, Steve Weis reported that he had factored RSA-896, a 270-digit RSA (Rivest–Shamir–Adleman) challenge number. He used Claude to port CADO-NFS, an open-source implementation of the number field sieve, to run on GPUs (graphics processing units). The job ran on up to 2,048 GPUs over about 10 days, roughly 30 GPU-years of compute, using idle time between regular jobs.
Two parts of his statement matter most. First, the work “did not meaningfully improve the runtime” of the underlying algorithm, and it “does not impact the security of deployed RSA-2048 keys.” Second, it “demonstrates that RSA-1024 keys are vulnerable to many actors with data center-level fleets of GPUs.”
This came 16 days after RSA-260 (862 bits) was factored on September 3 with help from AI coding agents. The engineer behind that result estimated his run at about $400,000 of GPU time. He extrapolated roughly $30 million for RSA-1024 and said RSA-2048 is not meaningfully affected. These are the researcher’s own estimates, not independent measurements.
Business impact: No quantum computer was involved in either result. What changed is who can realistically attempt the attack. AI tools cut the engineering effort, and GPU fleets supply the compute. RSA-1024 has been prohibited for new signatures since 2013, but it still turns up in legacy devices, old code-signing chains, embedded systems, and forgotten internal PKI (public key infrastructure). Any 1024-bit key still in use should now be treated as exposed, not merely out of policy.
2. FIPS 140-2 moves to the Historical List
The remaining FIPS 140-2 (Federal Information Processing Standard) validated modules have moved to the Cryptographic Module Validation Program (CMVP) Historical List. Sources give the date as either September 21 or 22.
OpenSSL describes it as “a procurement cut-off, not an expiry.” New federal systems need a module on the Active List, meaning a FIPS 140-3 validation. Existing systems can keep running, but the agency owns the risk decision. OpenSSL also notes that “validated is not the same as compliant.”
Business impact: For federal suppliers, and for companies that write FIPS into their own contracts, sales cycles are affected now. Every open proposal, renewal, and product roadmap that cites a 140-2 certificate needs to be reviewed. This is a separate issue from PQC, but it tests the same thing: can you find the affected cryptographic module, identify who owns it, and replace it on schedule?
3. National deadlines cluster around 2030 but differ in scope
At DigiCert’s World Quantum Readiness Day on September 17, speakers described how national requirements are converging on 2030 while covering different things. Australia’s cyber agencies want full migration by 2030. Nordic and Baltic countries are generally following EU timelines. In the U.S., Executive Order 14412 requires federal agencies to name PQC migration leads and to move high-value assets and high-impact systems to PQC key establishment by December 31, 2030.
Separately, Google published a PQC roadmap with dates for individual services. It targets 2029 for its own readiness and schedules Merkle Tree Certificates, a new certificate format designed to keep larger post-quantum signatures from slowing web connections, for 2028.
Business impact: A multinational company does not face a single deadline. It faces several deadlines with different scopes, and its major vendors are setting dates of their own. One of the speakers, Naomi Wynn of NEPKI, put it this way: “There is no one-size-fits-all; there is no template.” Most of these are milestones, not direct post-quantum mandates on private companies. Even so, they are already shaping procurement and supervisory expectations.
The Important: Four clocks, one execution gap
IonQ’s Simon Patkovic recently described PQC migration as four clocks that don’t agree:
· the regulator clock (deadlines and procurement rules)
· the adversary clock (what attackers can do, and what they are storing today to decrypt later)
· the vendor clock (when suppliers actually ship support)
· your own execution clock (how fast your organization can change)
His central point is that “quantum exposure is not a date.” Risk builds up in the gaps between those clocks.
This week added a lesson of its own. The adversary clock doesn’t just tick for quantum computers. Classical attacks keep getting cheaper, and AI tools speed that up. An RSA-1024 key that nobody inventoried was never going to be protected by a Q-Day forecast.
The durable lesson is that you can’t control three of the four clocks. You can only control the fourth, and that is the one boards should measure.
Discovery: know what is exposed today
Find every RSA-1024 key, every FIPS 140-2 module, and every quantum-vulnerable algorithm. Tie each one to the data it protects and how long that data must stay confidential. The same inventory covers this week’s classical risk and next decade’s quantum risk.
Agility: shorten your execution clock
Measure how long it takes to replace a key, certificate, library, or module, from the decision to the change running in production. If replacing a weak key takes 18 months, a 2030 deadline is already tight. Include vendor-controlled and OT (operational technology) systems, since they are usually the slowest.
Governance: decide which clock you manage to
Name an accountable owner who reconciles all four clocks and reports the gaps. Put vendor PQC and FIPS 140-3 timelines into contracts. Record risk-acceptance decisions explicitly, with an owner and an expiry date, so they don’t stay open indefinitely.
Three Questions for the Board
1. How many RSA-1024 keys and FIPS 140-2 modules are still in our environment, and who owns removing them?
2. How long does it take us to replace a weak key or cryptographic module, measured from decision to production?
3. Which of the four clocks is setting our migration schedule, and who reconciles the gap between them?