Post-Quantum Cryptography Is Here: We Need to Adapt

On July 28, 2026, Anthropic published AI-assisted research that weakened HAWK, a post-quantum signature candidate that had survived two rounds of NIST review. Anthropic said finding, developing, and verifying the attack took about 60 hours. Within days, the submission team withdrew HAWK from NIST’s additional signature process.  

One paper had changed which candidates remained viable. No quantum computer was involved. 

HAWK was never deployed, so nobody had to rip it out. The next finding may not be that polite. Thirty-four days before Anthropic published, the White House had already pulled the federal post-quantum deadline forward from 2035 to 2030. The algorithms are moving, and so are the deadlines. 

That is the question I would put to a post-quantum cryptography (PQC) program: when the next finding changes what we can trust, how quickly can we act? Finding the affected systems should not be the first step of an emergency. Crypto agility is the ability to adapt cryptographic protection while preserving security and operations. It belongs in the PQC program from the beginning, because the ability to move quickly takes time to build. 

TL;DR 

• Start PQC preparation now: sensitive data may need to remain confidential longer than the cryptography protecting it remains secure, and replacing that protection takes time. 

• NIST has already standardized a backup for its own winning algorithm. The standards body is planning for change, and so should the program. 

• In July 2026, AI-assisted cryptanalysis halved the security of HAWK, a third-round NIST signature candidate, and its team withdrew it within days. The ground under any algorithm can shift in a month. 

• Measure both protection coverage and demonstrated transition time. A deployed algorithm and the ability to replace it are separate outcomes. 

• Build crypto agility through shared encryption controls, a living inventory, accountable service owners, and rehearsed changes across infrastructure and applications. 

Adopt the Standards, But Stay Flexible

NIST’s first three PQC standards arrived in August 2024 following a process that began with its 2016 call for submissions: ML-KEM for key establishment, and ML-DSA and SLH-DSA for signatures. Establishing a shared secret and proving who signed something are different jobs with different migration requirements. 

The candidates that failed supply a useful warning. In 2022, Ward Beullens demonstrated recovery of a Rainbow secret key in an average of 53 hours on a laptop, using the second-round security-level-1 parameters. Wouter Castryck and Thomas Decru reported breaking SIKEp434 in about an hour on a single CPU core. Neither attack required quantum hardware or affected the three finalized standards. 

HAWK brings that history into the AI era. Ars Technica’s coverage followed the Mythos-assisted finding. Anthropic explained that compensating for the improved method required larger keys, eroding the advantages that had made HAWK attractive. Better cryptanalysis changed the security and performance tradeoff on which its candidacy depended. 

HAWK was a candidate, and the researchers said the result did not affect ML-DSA or Falcon. The separate AES result concerned a reduced-round research version; it did not break full-standard AES. 

We have already lived through one of these. Three years ago, the AI policy at most companies was one sentence about not pasting customer data into a chatbot. By November 2025, Anthropic was documenting a state-sponsored campaign that was 80 to 90 percent automated, with humans touching four to six decisions per intrusion. The policies did not fail because they were wrong, but because nothing underneath them could change as fast as the threat did. HAWK is the same lesson pointed at cryptography. 

I do not need to predict the next mathematical finding to ask for a replacement plan. If a security assessment changes halfway through deployment, the team needs authority to reconsider the choice, vendor support to implement an alternative, and a way to keep the service running. That is what the PQC budget should buy alongside the algorithms. 

These findings support continued scrutiny and a plan for alternatives. NIST had already taken that approach: in March 2025, it selected HQC for standardization as a backup to ML-KEM. HQC relies on error-correcting codes, giving it a different mathematical foundation from ML-KEM’s lattices. Selection for standardization does not mean an interchangeable replacement is already available in every product. 

Procurement should support that learning through upgrade rights, compatible protocols, testing capacity, and vendor commitments for later transitions. The objective is to avoid making today’s choice so difficult to replace that tomorrow’s findings become a business crisis. 

The Preparation Must Come Before the Certainty 

Estimates of the computing resources needed to break RSA also change. Craig Gidney’s May 2025 research estimated factoring RSA-2048 with fewer than one million noisy qubits in less than a week, compared with an earlier estimate of 20 million in eight hours. Those are engineering estimates with different assumptions and runtimes. They are not a forecast of when one will arrive. 

Federal planning already calls for action before the hardware timeline is settled. In November 2024, NIST’s draft IR 8547 gave the federal government until 2035 to retire today’s public-key algorithms. On June 24, 2026, OMB M-26-15 moved the objective to December 31, 2030 and gave agencies 120 days to produce a migration plan. Five years of runway gone in one memo. It excludes national security systems and does not bind the private sector, but it tells you how the people with the most classified view of the threat read the clock. 

For private organizations, the immediate planning input is exposure. As Ari Krakauer wrote here in August, encrypted traffic collected today can stay valuable for decades. Joint CISA, NSA, and NIST guidance describes harvest-now, decrypt-later risk: adversaries could retain vulnerable encrypted traffic for decryption by future capable hardware. That is not evidence that a particular organization’s data has been collected, but it does mean changing protection later cannot retroactively secure a copy already collected under vulnerable cryptography. 

A service carrying information that must remain confidential for fifteen years deserves a different priority from one carrying short-lived public content. Combine that confidentiality lifetime with the time needed to replace the service’s cryptography. That comparison gives the board a funding priority even while the hardware timeline remains uncertain. 

Separate work we can start today from decisions that require more evidence. Discovery, service ownership, vendor commitments, and representative migration tests can begin now. Specific rollout choices can follow supported implementations and risk priorities. Uncertainty about when cryptographic protection may weaken should sharpen that sequencing, not postpone the entire program. 

Retirement Takes Nineteen Years When Nobody Knows Where the Algorithm Lives 

SHA-1 was deprecated for new digital signatures in 2011, and Google and CWI demonstrated a practical collision in 2017. NIST’s broader phaseout target is December 31, 2030. Nineteen years from deprecation to disappearance, spent on product updates, validation, and service replacement. 

MD5 shows what the gap costs. Microsoft’s 2012 analysis of Flame described an MD5 collision used to create a fraudulent certificate chaining to a Microsoft root. A weakness in cryptography became a way to make malicious code appear trustworthy. The business question is which services still rely on the protection and what it takes to change them. 

NIST’s crypto-agility guidance spans protocols, applications, software, hardware, firmware, and infrastructure. The inventory needs to connect protection across those layers to the business services that rely on it. 

Shared platforms can move part of that estate quickly. Cloudflare reported in October 2025 that more than half of human HTTPS traffic reaching its network used post-quantum key agreement. Its analysis describes hybrid protection combining a classical method such as X25519 with ML-KEM. It also explains why certificates and signatures pose a separate migration challenge. A protected key exchange does not complete the entire connection’s transition. 

Shared Controls Reduce the Work, but Ownership Completes It

For workload traffic protected by a managed encryption layer, central governance can coordinate deployment across compatible endpoints. That can reduce separately-managed changes and provide a common place to enforce approved protection. That is the case for shared infrastructure: one place to change and one place to verify. 

An encrypted tunnel protects traffic between its endpoints, but it does not automatically update an application’s certificate validation, replace a software-signing key, or change stored-data protection. Network observations should be combined with endpoint, configuration, and vendor evidence. A list of connections alone cannot answer every cryptographic inventory question. 

After twenty years in security, the question I would ask first is who can make the change. An inventory can look complete and still leave a service waiting on an unsupported appliance, an application release, or a vendor contract. I want to see those constraints before the clock belongs to someone else. A spreadsheet of algorithms is only useful if it leads to people with the means to replace them. 

Consider a payment service carried over centrally managed encrypted tunnels. The infrastructure team may update tunnel protection while the application still relies on an older certificate library. Both changes belong to the same business service. Its owner needs evidence of both before declaring the service’s migration complete. 

When the board asks how long it takes to replace a broken algorithm and the honest answer is “we would start by finding it,” the program has a deliverable but not a capability. 

If the application vendor cannot support the transition within the service’s required timeline, the decision becomes a business one: fund replacement sooner or document the exposure the organization will continue to accept. Give one executive sponsor the authority to settle the cross-team priorities and funding gaps a service owner cannot. 

Communication Governance decides which workloads may talk. Where a managed encryption layer protects those paths, cryptographic policy can also define the approved algorithms and the conditions for continued use. Together, these controls let teams restrict unnecessary reachability, reduce Blast Radius, and coordinate protection changes across compatible endpoints. The program should be able to name the paths covered, the exceptions, and who can change each one. 

Central control also concentrates the consequences of a bad rollout. A common setting should support staged deployment, compatibility checks, and a recovery path that preserves approved protection. The team should know what can change, what will interrupt service, and which exceptions need a business decision. 

Five Ways to Build Crypto Agility

Measure protection coverage and the ability to move again. Report which critical services have the required protection, which were represented in the last migration exercise, and how long the change took. Name the vendor and hardware constraints that remain untested. Set triggers for revisiting priorities when cryptanalytic findings, standards, or vendor support change. 

Fund the services whose exposure outlasts their replacement cycle. Prioritize confidentiality lifetime, service criticality, vendor readiness, and the time needed to replace software or hardware. Ask which services cannot meet their protection needs through normal refresh budgets. Assign an executive sponsor to resolve those gaps and service owners to document the risk decisions. 

Make the inventory a shared operational record. Combine network observations with application, certificate, signing, hardware, and vendor evidence. Link each entry to a business service and a team that can change it, with a date showing when the evidence was last verified. Continue urgent protection work while discovery improves; a perfect inventory should not become a prerequisite for an obvious risk reduction. 

Buy for replaceability. Ask vendors how they support later transitions, including protocol compatibility, hardware requirements, upgrade rights, and emergency disablement of vulnerable algorithms. Evaluate shared encryption controls where they reduce coordination work, and document their coverage boundaries. Procurement should establish who supplies the next change, who tests it, and who pays for it. 

Rehearse the transition and its service impact. Exercise a supported cryptographic change on a representative service. Measure compatibility, performance, prohibited fallback, and the time required to recover safely. Agree on acceptable disruption with the service owner before the exercise, then use the results to fund the fixes that an emergency would otherwise expose. 

Make the Next Security Review a Test of Readiness

A third-round NIST candidate lost half its security in 60 hours of AI-assisted work and was out of the process within days. That is what the next decade of cryptography looks like: the algorithms will keep changing, and the only durable question is how fast you can change with them. We need to reduce today’s exposure, identify what will take longest to replace, and prove that the next change can happen without starting from scratch. 

Govern workload communication centrally and manage encryption changes across the paths that shared infrastructure protects. Keep application, identity, and signing transitions tied to the same service owners. That is the Containment Era applied to cryptography. The algorithm will change again, but the network path won’t. Governing the path is what makes the algorithm replaceable on your timeline instead of someone else’s.  

Ask which services remain exposed and what the last migration exercise proved. The next change should begin with an executable plan, not an archaeology project. 

Explore workload threat research at the Aviatrix Threat Research Center.  

Use the free Workload Attack Path Assessment to examine attack paths in your cloud environment. 

References

Anthropic, "AES Möbius Bridge," July 28, 2026, https://anthropic.com/document/aes_mobius_bridge.pdf

Anthropic, "Discovering cryptographic weaknesses with Claude," July 28, 2026, https://www.anthropic.com/research/discovering-cryptographic-weaknesses

Anthropic, "Disrupting an AI-orchestrated cyber espionage campaign," November 13, 2025, https://www.anthropic.com/news/disrupting-AI-espionage

Ars Technica, "Mythos uncovers crypto weaknesses that went unknown for years," July 2026, https://arstechnica.com/security/2026/07/mythos-uncovers-crypto-weaknesses-that-went-unknown-for-years/

arXiv, Craig Gidney, "How to factor 2048 bit RSA integers with less than a million noisy qubits," May 21, 2025, https://arxiv.org/abs/2505.15917Cloudflare Blog, "State of the post-quantum Internet in 2025," October 28, 2025, https://blog.cloudflare.com/pq-2025/

CWI Amsterdam and Google, "SHAttered," February 23, 2017, https://shattered.io/

IACR ePrint, Ward Beullens, "Breaking Rainbow Takes a Weekend on a Laptop," February 25, 2022, https://eprint.iacr.org/2022/214

Microsoft Security Response Center, "Flame malware collision attack explained," June 6, 2012, https://www.microsoft.com/en-us/msrc/blog/2012/06/flame-malware-collision-attack-explained

NCCoE (NIST), "Quantum Readiness: Migration to Post-Quantum Cryptography Fact Sheet," August 22, 2023, https://www.nccoe.nist.gov/publications/fact-sheet/quantum-readiness-migration-post-quantum-cryptography-fact-sheet

NIST, "NIST Releases First 3 Finalized Post-Quantum Encryption Standards," August 13, 2024, https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

NIST, "NIST Retires SHA-1 Cryptographic Algorithm," December 15, 2022, https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm

NIST, "NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption," March 11, 2025, https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption

NIST CSRC, "Considerations for Achieving Crypto Agility: Strategies and Practices" (CSWP 39upd1), June 29, 2026, https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final

NIST CSRC, "Post-Quantum Cryptography: Additional Digital Signature Schemes," August 29, 2022, https://csrc.nist.gov/projects/pqc-dig-sig/round-3-additional-signatures

NIST CSRC, "Transition to Post-Quantum Cryptography Standards" (IR 8547), November 12, 2024, https://csrc.nist.gov/pubs/ir/8547/ipd

NIST PQC Forum, "Key recovery attack on SIDH," July 30, 2022, https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ygqtBcCdfF4/m/WsszjlLkBwAJ

Office of Management and Budget, "M-26-15: Execution of the Migration to Post-Quantum Cryptography," June 24, 2026, https://www.whitehouse.gov/wp-content/uploads/2026/06/M-26-15-Execution-of-the-Migration-to-Post-Quantum-Cryptography.pdf