Crypto-Agility Is the Goal. The PQC Migration Is Only Its First Test.

On July 29, 2026, the designers of HAWK withdrew it from NIST’s search for additional post-quantum signature schemes, one day after an AI-assisted attack on the scheme went public. After China published the 119 first-round candidates of its Next-generation Commercial Cryptographic Algorithms competition (NGCC) on September 20, researchers posted 191 findings against 89 of them within seven days. On October 1, Germany’s Federal Office for Information Security (BSI) advised against using Classic McEliece in new developments. ISO had standardized Classic McEliece, a key-encapsulation mechanism, only in June.

None of the three events affects the algorithms most organizations are adopting: ML-KEM (formerly CRYSTALS-Kyber) for key establishment, with ML-DSA (formerly CRYSTALS-Dilithium) and SLH-DSA (formerly SPHINCS+) for signatures. Nor does any of them change estimates of when a cryptographically relevant quantum computer (CRQC) will exist.

Most post-quantum cryptography (PQC) programs I review are still built as projects with an end: replace RSA and elliptic-curve cryptography with ML-KEM and ML-DSA, verify, close and reassign the team. The people who plan them assume the new algorithms will stay in place for decades, but this year experts changed their assessments of HAWK and Classic McEliece within weeks. I would therefore build these programs around a different deliverable. Fund a program whose output is the ability to change cryptography on a date you choose, and make the PQC migration the first thing it delivers.

I put the migration first because regulators have set dates for it and boards will pay for it. It is also the capability’s first test. The program closes when the organization passes a second test, a rehearsed algorithm change made on schedule. After that, the capability belongs to a named owner with a budget of its own.

That capability is crypto-agility. NIST defines it in Cybersecurity White Paper (CSWP) 39 as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructures while preserving security and ongoing operations. I use the term for an organization’s ability to replace its cryptography safely, with or without runtime negotiation among algorithms.

I have written about crypto-agility as an architecture problem, as the factor in Marin’s Law that sets the length of every cryptographic migration, and as the method of version 3.0 of my PQC Migration Framework. Here I go a step further and argue for chartering a program to deliver the capability itself, with the PQC migration as its first output.

Six Reasons Organizations Will Change Algorithms Again

Quantum computing is one of six reasons organizations will change their algorithms again. It is the only one that depends on a machine being built, and the one for which regulators have set their firmest dates. The other five are cryptanalysis of the new algorithms, faster cryptanalysis with AI tools, implementation flaws in new PQC libraries, national algorithm choices and deprecation schedules.

Cryptanalysis of the New Algorithms

HAWK is a lattice-based signature scheme that NIST advanced to the third round of its additional signature process on May 14, 2026, as the only lattice candidate left. On July 28, Anthropic disclosed that its Claude Mythos Preview model, in a research setup run by Zygimantas Straznickas and Stephen Weis, had found a symmetry in HAWK’s ring. The symmetry reduces key recovery to a lattice problem in dimension $$n/2+1$$, about half the previous size. The researchers’ paper puts the cost of recovering a HAWK-512 key at no more than $$2^{108}$$, down from $$2^{150}$$, in the gate-count model of HAWK’s own specification. The authors also recovered a key for the small HAWK-256 parameter set end-to-end, in a few hours on one server.

Anthropic had shared the attack with HAWK’s designers in June, and they withdrew the scheme the day after it went public. On their project site, the designers say the obvious fixes, doubling parameters or moving to higher-rank modules, would leave HAWK uncompetitive with lattice schemes that are already standardized. As I explained in July, the attack does not transfer to FN-DSA (Falcon), ML-DSA or ML-KEM.

Classic McEliece, a code-based scheme, was far better established than HAWK: an ISO standard, a BSI recommendation since 2020 and a reputation as the conservative choice, with deployments in VPNs, hardware security modules (HSMs) and optical network encryption. Since early August, three research groups have published estimates, under different cost models, that put key recovery below its claimed security for every parameter set. The first group’s preprint reached the IACR’s ePrint archive on August 7, and a later revision added details of its key-recovery algorithm. I covered the details in my October 2 analysis.

None of the groups has run its attack against a real parameter set, and BSI’s advice concerns new developments. Even so, organizations that picked Classic McEliece as the safest option now have an algorithm change to schedule.

On August 3, the ePrint archive received a preprint from Daniel Simon of AWS claiming a polynomial-time quantum algorithm for the dihedral coset problem. Had the algorithm worked, it would have threatened the lattice problems behind ML-KEM and ML-DSA, through reductions that go back to Oded Regev’s work in 2004. On August 15, Aparna Gupte, Seyoon Ragavan and Mark Zhandry showed that the algorithm cannot solve the problem it targets. They released Lean 4 code so anyone can check the refutation by machine.

For 12 days, organizations migrating to lattice cryptography had a serious claim to assess and no verdict. As I wrote in August, an agile organization still has to wait for the answer, but it can lower the cost of being wrong while the argument is open.

Faster Cryptanalysis With AI Tools

Researchers disclosed AI assistance in several of this year’s results, including the HAWK attack and the lead Classic McEliece papers. In the NGCC competition, Markku-Juhani Saarinen of Tampere University reports that his agentic workflow found and verified 110 of the 191 findings, 47 of them rated critical.

Anthropic put the API cost of each of its July results, including the HAWK attack, at about $100,000. Another of those results concerned a reduced version of AES. In its paper on 7-round AES-128, the company reports that the core idea took tens of hours of model time and that two researchers needed hundreds of hours to validate it. The result has no practical effect on full AES.

Researchers have also used the same kind of tools against RSA. In early September, Eric Lu of Cognition factored RSA-260 with a GPU version of the CADO-NFS factoring software that Cognition’s Devin agent had built. On September 19, Stephen Weis factored RSA-896 with Claude. When I scaled Weis’s run with the standard number field sieve complexity estimate, RSA-1024 came out at about $28 million in GPU time, close to Lu’s estimate of $30 million. The same model puts RSA-2048 at about 35 billion times the work of RSA-896, so neither record brings it within reach.

Implementation Flaws in New PQC Libraries

In June, wolfSSL, the maker of a TLS library common in embedded devices, fixed two bugs in the hand-written assembly code that checks ML-KEM ciphertexts (CVE-2026-10097 and CVE-2026-6330). In August, Bhabani Sankar Das showed that an incomplete check of this kind allows near-complete recovery of a static ML-KEM-1024 private key, given a plaintext-checking oracle and up to about a million decapsulation queries. TLS handshakes that use ephemeral keys are not exposed to this key recovery.

In 2023 and 2024, researchers found the KyberSlash timing flaws in 12 libraries, all of which had inherited the vulnerable code from one reference implementation. PQClean, one of the projects in that lineage, was archived read-only on August 4, 2026, so code copied from it gets no further upstream fixes.

Fixing flaws like these means patching every copy of the implementation and replacing any static key that was exposed. An organization can do that only if it knows which of its systems run each copy.

National Algorithm Choices

China’s NGCC competition will produce the post-quantum algorithms intended for Chinese commercial systems, and I would not expect standards from it before 2029. South Korea selected four algorithms of its own in January 2025, and European agencies differ on hybrid deployment and on which non-lattice schemes to accept. As a result, a multinational that operates in several of these jurisdictions will run more than one algorithm family. Each new national requirement can add another algorithm, parameter set or profile to support.

Deprecation Schedules

NIST’s draft transition schedule proposes deprecating the 112-bit-security versions of today’s quantum-vulnerable public-key algorithms after 2030 and disallowing all of them after 2035. The CA/Browser Forum has voted to cut the maximum lifetime of public TLS certificates to 47 days, starting in March 2029.

For comparison, NIST has disallowed RSA keys shorter than 2,048 bits for new signatures since the start of 2014. Eleven years later, in 2025, DMARC.org still reported 1,024 bits as one of the two most common sizes among the DomainKeys Identified Mail (DKIM) keys it observed. When I find RSA-1024 in production, I take it as a forecast of how that organization will handle its post-quantum deadlines.

Quantum Computing

Organizations are migrating now because a CRQC running Shor’s algorithm would break RSA and elliptic-curve cryptography. Traffic recorded today could be decrypted once an adversary has one, the risk known as harvest now, decrypt later (HNDL). Under Executive Order 14412, US federal high-value assets and high-impact systems other than national security systems need post-quantum key establishment by December 31, 2030, and post-quantum signatures by December 31, 2031.

How Quickly the Assessment of an Algorithm Can Change

Of the two durations I track, one runs from the first credible public result against an algorithm to the day its designers, a standards body or a national authority change their advice. It shows how quickly the assessment changed, not how long an attacker needed. The other is time-to-change: how long an organization needs to assess its exposure, decide, change and verify on its most important systems.

Cryptanalysts have often eliminated competition candidates quickly: Castryck and Decru broke SIKE 25 days after NIST advanced it. By contrast, SHA-1 was already a NIST standard when the first collision attack on the full SHA-1 appeared in 2005, and NIST deprecated it about six years later. Classic McEliece was also a standard, published by ISO in June and recommended by BSI since 2020, yet BSI changed its advice eight weeks after the first preprint. The researchers behind both of this year’s entries disclosed AI assistance. I left Simon’s claim out of the table because Gupte, Ragavan and Zhandry refuted it within 12 days.

In the enterprises I work with, time-to-change is measured in years. Most of the elapsed time goes to change approvals, vendor releases, FIPS validation and coordination with counterparties. I have worked with one organization, on and off, for more than 10 years on a single cryptographic transition.

An organization can’t know in advance how much warning it will get. HAWK’s designers heard about the attack privately in June, weeks before Anthropic disclosed it on July 28. An organization can, however, measure its own time-to-change, and it needs that number before the advice on one of its algorithms changes again. Under Marin’s Law, a heuristic I proposed in 2025, the more agile an organization is, the less time it needs to replace a cryptographic primitive.

There may be no public warning at all. In the NIST forum discussion I covered on October 2, Daniel Apon of Anduril Industries wrote that he would not release an unpublished analysis of Classic McEliece, because further cryptanalysis would only harm current users. I give no weight to unpublished estimates, so I report only his decision not to publish. In July I argued that papers on quantum cryptanalytic progress will stop appearing before the progress does. Researchers can withhold classical results in the same way, and an organization that waits for public evidence before preparing will be late.

What a Crypto-Agility Program Contains

The charter I would write names one deliverable, the capability to change cryptography on a date the organization chooses. The PQC migration, with its regulatory dates, is the first change. The program closes when the organization has rehearsed a second change on its most important systems inside a window it has defined.

In version 3.0 of my framework, the default window is 48 hours to assess plus 10 business days to make the change, provided the products already support both the old and the new algorithm. If switching requires new code, a rebuild or a vendor release, the team records the system as agility debt. After the program closes, a named owner runs the capability as a funded, standing function with a rehearsal schedule.

When an organization runs its PQC migration as a one-off project, it reassigns the team once the migration is done. Without an owner, the inventory can be out of date within months, and the organization may then need a new discovery phase and new vendor negotiations for its next algorithm change.

In the first year, the organization funds six pieces of work that serve the PQC migration and that it can reuse for every later algorithm change:

• A cryptographic inventory that is maintained after discovery ends, with the parameter set and implementation lineage of each system.
• An approved-algorithms policy in a machine-readable form that systems can consume.
• Provider-pattern abstraction in Tier-1 services, built as each migration wave reaches them, so that applications call a cryptographic provider instead of a hard-coded algorithm.
• Automated certificate lifecycle management, needed anyway for 47-day certificate lifetimes.
• An agility clause with an acceptance test in every new contract.
• A standing authority that approves cryptographic policy changes without waiting for the weekly change board.

Under a crypto-agility program, a system counts as migrated only when four conditions hold:

1. The post-quantum outcome is observed in production traffic.
2. Classical-only connections are refused where policy requires it, and someone has tested that behavior.
3. The algorithm can be changed by configuration.
4. That change has been rehearsed with rollback.

For functions that are not negotiated protocols, such as a firmware signature or a wrapped key store, the team checks the first two conditions against that function’s own verification evidence. A system that meets the first two conditions but not the last two is recorded as migrated with agility debt, on a register where each entry has an owner and a closure date. At each wave’s exit gate, the team reports protection and agility as separate results.

The team also reports a rehearsed time-to-change. In each migration wave, it rehearses one algorithm change in staging and times assessment, decision, change and verification separately. It then invests in shortening the longest of the four. In the framework’s hypothetical worked example, two-thirds of the elapsed time went to the approval queue, and the fix was a standing authorization for cryptographic policy changes.

Funding a Crypto-Agility Program Through PQC Deadlines

Boards fund obligations, and in cryptography today the most pressing deadlines are post-quantum ones. US federal agencies owe the Office of Management and Budget (OMB) and the Office of the National Cyber Director migration plans for their systems other than national security systems by October 22, 2026. Under the Committee on National Security Systems’ Policy 15, new national security system acquisitions must be CNSA 2.0-compliant from January 1, 2027, unless the policy notes an exception. The EU’s coordinated roadmap, a recommendation to member states rather than a regulation, asks for high-risk use cases to be transitioned by the end of 2030.

The OMB deadline, CNSA 2.0 and the EU roadmap set no date or target for an organization’s time-to-change. I would therefore present the budget request and the external reporting as readiness against those dates, because that is what boards and supervisors ask about.

Inside the program, the team delivers the migration through agility mechanisms. Most of the agility work is migration work with a stricter acceptance test. In a 120,000-task program, one of several on which my framework is based, roughly a quarter of the tasks involved changing cryptography. The remainder covered governance, vendor engagement, training, policy, infrastructure, testing and operations. An organization that builds agility later, in a separate program, pays for discovery and vendor negotiation twice.

Organizing the program around agility does not relax the PQC dates. If the first change is late, the organization cannot make up for it. Traffic recorded before the migration finishes stays exposed to HNDL whatever the organization does afterward.

How Regulators and Standards Bodies Treat Crypto-Agility

Regulators, supervisors and standards bodies have started to name crypto-agility in their documents, and a program owner can cite them to the board. The documents differ in legal force. The EU’s technical standard under the Digital Operational Resilience Act (DORA) is binding law, and OMB’s memorandum binds US federal agencies. The other five are supervisory guidance, model contract clauses, a supervisory survey, a voluntary roadmap and technical guidance.

• European Union (binding). Article 6(4) of Delegated Regulation (EU) 2024/1774, DORA’s technical standard on ICT risk management, requires a financial entity’s cryptographic policy to provide for updating or changing its cryptographic technology on the basis of developments in cryptanalysis. An entity that cannot do so must record its mitigation and monitoring measures and explain why. The Classic McEliece results that led to BSI’s advice are developments of that kind. As I read Article 6(4), a bank that runs the algorithm in a VPN or an HSM will have to show what it did about that advice under its policy.
• United States (binding on federal agencies). In Memorandum M-26-15, OMB requires each agency’s migration plan to cover how the agency will implement a cryptographically agile architecture. OMB also tells program offices to put cryptographic agility into vendor requirements. The memorandum does not apply to national security systems.
• Switzerland (supervisory guidance). The Swiss Financial Market Supervisory Authority (FINMA) recommends in Guidance 05/2026 that institutions make crypto-agility a requirement for new systems, whether procured or developed, and for new software and data outsourcing arrangements. For existing arrangements, FINMA asks institutions to add it at the earliest opportunity.
• Canada (model contract clauses). ITSM.00.501, the Canadian Centre for Cyber Security’s set of recommended contract clauses for cryptography, calls for configurable algorithms, parameters and cryptoperiods, as well as support for vendor-signed updates.
• Hong Kong (supervisory survey and toolkit). In its whitepaper, the Hong Kong Monetary Authority (HKMA) reports that 71% of responding banks had never conducted or planned any proof-of-concept or live testing of post-quantum algorithms or cryptographic agility solutions. The HKMA is building a toolkit with the Hong Kong University of Science and Technology (HKUST) that includes a reference architecture for agility.
• G7 (voluntary roadmap). The G7 Cyber Expert Group’s roadmap for the financial sector aims at migration to quantum-resistant cryptography and a transition to cryptographic agility. The group states that the roadmap sets no guidance or regulatory expectations.
• NIST (technical guidance). CSWP 39, updated in June 2026, surveys agility mechanisms. NIST presented it as a starting point for organizations developing mechanisms for their own environments.

Each instrument asks for a plan, a design property, a contract clause or a readiness measure, but none asks how long a change takes. The organization has to set that number itself and report it to the board next to the share of systems migrated.

Arguments Against Crypto-Agility

Cryptographers have argued against algorithm agility for more than a decade, and parts of their case are right.

Cipher Negotiation and Downgrade Attacks

Russ Housley wrote RFC 7696 in 2015 as guidance for IETF protocol designers. He defines algorithm agility there as a protocol’s ability to migrate from one mandatory-to-implement algorithm suite to another over time, and devotes a section to the complexity that agility adds. The same year, the researchers behind Logjam showed that a man-in-the-middle could push TLS connections down to export-grade Diffie-Hellman that servers still accepted. Every weak algorithm a protocol still accepts is one an attacker can try to force, unless the negotiation is authenticated and the weak option is refused by policy.

DNSSEC has a post-quantum version of the same problem. Under RFC 6840, a resolver may accept any single valid signature path, so once ECDSA is broken, an attacker can strip a zone’s ML-DSA signatures and serve a forged ECDSA answer. Cloudflare has set its resolver to require the ML-DSA path whenever the parent zone signals that one exists.

In its post-quantum strategy, the US Department of War warns that enabling agility must not introduce new vulnerabilities. The defense is to offer fewer options and to test that the weak ones are refused. For that reason, the second of the four conditions for counting a system as migrated requires classical-only negotiation to be refused and verified. The agility I’m arguing for is an organization’s ability to change what it deploys, on a date it chooses. Runtime negotiation among many suites is one way to achieve it, and often a poor one.

WireGuard’s Opinionated Design and Classic McEliece

Jason Donenfeld, who created the WireGuard VPN protocol, states in the WireGuard paper that the protocol deliberately has no cipher or protocol agility: if a primitive fails, every endpoint must update. He cites the run of SSL and TLS vulnerabilities as evidence that cipher agility adds enormous complexity. When WireGuard was proposed for the Linux kernel in 2018, James Bottomley, a kernel developer, replied that every cryptographic choice eventually needs updating, and asked for the ability to handle multiple protocol versions instead of full cipher agility.

Two projects that use WireGuard, the Mullvad VPN service and the open-source Rosenpass key exchange, now face the case Donenfeld and Bottomley argued about. Both added post-quantum protection through WireGuard’s pre-shared key, and both chose Classic McEliece. Mullvad uses it alongside ML-KEM, by default on desktop since January 2025, and Rosenpass uses it for static keys, with Kyber for ephemeral keys.

Mullvad’s tunnels stay quantum-resistant as long as ML-KEM remains unbroken, and BSI’s advice concerns new developments, so neither project faces an emergency. Unless an alternative is already built in, replacing Classic McEliece in either one means shipping new software to every endpoint, the update that Donenfeld assigned to whoever operates the network.

Designers who make a protocol opinionated move the agility requirement onto its operators. Given the SSL and TLS record, that is a defensible design. The operators then need the ability to update every endpoint on short notice, which is organizational agility under another name.

Recorded Traffic Stays Exposed After an Algorithm Change

Changing an algorithm protects only future sessions. Anyone who recorded traffic under the old algorithm can read it as soon as they break that algorithm. For data that must stay confidential for decades, an organization cannot protect recordings that already exist by changing algorithms later, so the key-exchange algorithms it chooses today have to be right on their own.

A classical-plus-post-quantum hybrid stays secure while either half remains unbroken. If the post-quantum half fails, an adversary with a CRQC can break the classical half as well, and nothing protects the recordings. After the Classic McEliece results, John Preuß Mattsson of Ericsson argued on the NIST forum that high-security key exchange should combine two post-quantum families, such as ML-KEM and Hamming Quasi-Cyclic (HQC). NIST selected HQC in March 2025 as a code-based backup to ML-KEM, and BSI says it will recommend HQC once a standard exists.

When two families are combined correctly, a mathematical break in one does not expose the session key on its own. An agile organization can then replace the broken family. A flaw in implementation code that the two share, however, can still expose both.

Devices With Fixed Cryptography

Some cryptography is very hard to change:

• A verifier whose root key has no authenticated update path, such as a key burned into one-time-programmable memory.
• An HSM whose algorithm set is fixed in hardware.
• A device certified as a sealed unit that needs full recertification before it accepts a new algorithm.

An attacker able to factor a device’s 1,024-bit firmware-signing modulus could sign updates the device would accept, if the signature check is its only gate. For devices like these, agility means containment through gateways and segmentation, as I described in Rethinking Crypto-Agility, plus a replacement date on the agility-debt register and a procurement clause for anything bought from now on. Gateways reduce network exposure, but they cannot repair a compromised secure-boot root.

The EU’s Cyber Resilience Act does not name agility, but from December 2027 it requires products in its scope to use state-of-the-art encryption and to receive security updates throughout their support period.

Objections a Board Will Raise

“A Crypto-Agility Program Will Slow the Migration”

Organizations need most of the first-year work for the migration anyway, including an inventory, a policy, certificate automation and vendor clauses. On top of that, the team rehearses one change per wave and checks two extra acceptance conditions. A system that fails those two still counts toward the deadline, as migrated with agility debt. I would watch for scope creep, with teams trying to refactor every application at once. Each deferred fix goes on the agility-debt register with an owner and a date, so the team can still meet the regulatory deadlines.

“AI Will Make the Next Migration Fast”

AI tools reduce analyst and developer effort in discovery triage, candidate code changes and test generation. They do little for the critical path, which runs through approvals, vendor releases, FIPS validation and counterparties that no model controls. In July I put AI-compressible work at perhaps 15–20% of total effort in the programs I have observed, as an illustration and not a benchmark. Researchers, meanwhile, used the same tools to produce several of this year’s cryptanalytic results within weeks.

“We Will Pick the Safest Algorithm and Stop”

Several of the organizations that reasoned this way chose Classic McEliece. Standardized, publicly reviewed algorithms remain the right default. Long adversarial scrutiny is the best evidence anyone has that a design will last, and proprietary algorithms skip that review. Reviewers can tell you how a design has fared so far, but nobody can tell you when the next change will come. Vendors who sell “future-proof” encryption are claiming the one property the history of cryptography does not support.

What to Do Before the End of Q1 2027

1. Charter the program around the capability to change cryptography. Make the PQC migration its first change, set the closure condition as a rehearsed second change, and give the capability an owner and a budget that continue after closure. Keep the funding request framed by the PQC dates.
2. Find every Classic McEliece instance, every RSA key shorter than 2,048 bits and every non-standard primitive. Record the parameter set, the partner algorithm, the function it protects and how long the data must stay confidential.
3. Run one timed algorithm change in staging on a Tier-1 key-establishment path. Record assessment, decision, change and verification separately, and fix the longest interval.
4. Put an agility clause with an acceptance test into every contract signed from now on, and require vendors to disclose which implementation their products use.
5. For data that must stay confidential for decades, decide whether to combine two post-quantum families in the same key exchange once HQC is standardized.
6. Report rehearsed time-to-change to the board every quarter, next to migration coverage.
7. US federal agencies, before October 22: name an owner and the date of the first rehearsal in the agility section of the migration plan.
8. EU financial entities: assess BSI’s Classic McEliece advice against your DORA cryptographic policy now, record the decision, and use BSI’s revision of its Technical Guideline TR-02102-1, expected in early 2027, as the next review trigger.

Most programs I review can report the share of systems migrated to post-quantum algorithms, but few can say how long their last algorithm change took. Ask for the second number at the next steering committee. If nobody has it, schedule the rehearsal that produces it.

Applied Quantum sells post-quantum migration advisory services, and the argument above favors that business. The PQC Migration Framework, including the rehearsal method and the acceptance conditions described here, is free under CC BY 4.0, and anyone can use it without engaging us.