Is ML-KEM Still Secure After HAWK Break?

Whether ML-KEM is still secure after the HAWK break comes down to one question: does a flaw in one lattice-based post-quantum candidate carry over to the standardized algorithms that protect site-to-site, cloud and remote connections? It does not. HAWK and ML-KEM rest on different hardness assumptions, so a break in one does not automatically affect the other.

For operators of OT and critical infrastructure, the HAWK episode is still worth understanding. It shows how the NIST Post-Quantum Cryptography Standardization process works when it does its job, why “lattice-based” is not one single risk, and why hybrid key exchange and crypto-agility are sensible engineering choices rather than marketing terms.

Does the 2026 HAWK signature vulnerability affect ML-KEM or ML-DSA?

No. NIST has stated that the HAWK finding does not affect FIPS 203 (ML-KEM) or FIPS 204 (ML-DSA), because they rely on different mathematical foundations that remain secure.

According to NIST, on July 28, 2026, a vulnerability was announced in a lattice-based digital signature algorithm called HAWK, which was under consideration for standardization. The discovery was made by an AI model. The HAWK development team subsequently withdrew its algorithm from consideration, and it will not be standardized or deployed. NIST’s own CSRC listing for the third round now notes that the submission team has withdrawn HAWK from the additional digital signatures standardization process.

NIST’s position on the finalized standards is explicit: “This finding does not affect any of NIST’s finalized PQC standards, such as ML-KEM and ML-DSA”. The agency adds that these algorithms rely on different mathematical foundations that remain secure, and which are ready for implementation now.

Where HAWK sat in the NIST process

HAWK was never a standard. It was a candidate in the NIST Additional Digital Signature Schemes process, a separate track meant to add signature diversity alongside FIPS 204 and FIPS 205. The scale of that filtering process puts the withdrawal in context:

NIST IR 8528 records that in June 2023, 50 candidate algorithms were submitted to NIST for consideration, and 40 met both the minimum acceptance criteria and submission requirements. After 18 months of evaluation, NIST selected nine candidates for the third round in May 2026, and on July 29, 2026, the HAWK development team withdrew its algorithm from consideration. Candidates are expected to drop out at each stage. That is how the process is supposed to work.

Why do lattice-based schemes with different mathematical foundations fail independently?

“Lattice-based” names a broad family, not a single assumption. HAWK, ML-KEM and ML-DSA each depend on a different hard problem, so a shortcut against one problem does not solve the others.

HAWK’s security came from the Lattice Isomorphism Problem. One recent analysis states plainly that Hawk is not a Module-LWE scheme and that there is no modulus q in the sense used in ML-KEM or ML-DSA; it is a Module-LIP (Lattice Isomorphism Problem) scheme. By contrast, the security of ML-KEM is based on the presumed hardness of the Learning With Errors (LWE) problem over module lattices, and the security of ML-DSA is based on the presumed hardness of the Module-LWE problem and the Module Shortest Integer Solution (SIS) problem.

Maturity matters as much as the label. HAWK’s assumptions are variants of more conventional lattice problems but have received less cryptanalytic attention than the M-LWE/M-SIS assumptions underlying ML-DSA. The HAWK team itself acknowledged in 2025 that its security is based on relatively new problems, but they are being actively researched and gaining maturity. Younger assumptions have had fewer years of attack, so they are more likely to give way.

Can AI models find weaknesses in post-quantum algorithms faster than human cryptanalysts?

The HAWK case shows that AI can contribute real cryptanalytic findings. One case is not enough to show that AI is generally faster than human experts, especially against well-studied assumptions such as Module-LWE.

The AI-found vulnerability did not come out of nowhere. Human researchers had already been finding cracks in HAWK’s foundations. In work presented at NIST’s Sixth PQC Standardization Conference, Daniël van Gent and Ludo Pulles noted that Luo et al. (ASIACRYPT 2024) recently found an automorphism that breaks omSVP, the initial underlying hardness assumption of HAWK. The HAWK team amended the definition of omSVP to include this so-called symplectic automorphism in their submission to the second round. The AI result therefore targeted a scheme whose assumptions were already under active pressure.

History also shows that human cryptanalysis can move abruptly. The polynomial-time break of SIKE, a fourth-round NIST candidate, by Castryck and Decru in 2022 is a salient reminder that confidence in new mathematical assumptions can collapse abruptly. The lesson for operators is the same whether the analyst is a person or a model: the risk sits mostly with young assumptions and with implementations. ML-KEM is not immune to implementation flaws. Chosen-ciphertext, EM, and power side-channel attacks have recovered ML-KEM and Dilithium keys from masked and unmasked implementations, which is a reason to keep both algorithms and software updatable.

Is hybrid key exchange a better choice than pure ML-KEM given new cryptanalysis methods?

For most critical infrastructure connections, yes. A hybrid combines a classical and a post-quantum key exchange, so an attacker must break both, and several European security agencies explicitly recommend this approach.

The IETF’s guidance for engineers explains the reasoning: post-quantum algorithms selected for standardization are relatively new and they have not been subject to the same depth of study as traditional algorithms. Hybrid key exchange performs both a classical and a post-quantum key exchange in parallel. If an unexpected weakness appears in ML-KEM, the classical part still holds against today’s attackers. If a cryptographically relevant quantum computer arrives, ML-KEM protects against harvest-now-decrypt-later attacks.

European agencies have taken a clear position. A joint position paper by ANSSI, BSI, the Netherlands’ NLNCSA and Swedish authorities states that “the clear priority should therefore be the migration to post-quantum cryptography in hybrid solutions”. The JRC reports that the German BSI advises the use of hybrid schemes combining post-quantum and classical cryptography to compensate for possible lack of maturity in terms of security for some of the newer post-quantum algorithms.

• 18 European countries stated in a joint statement that they chose a hybrid transition from classical to post-quantum cryptosystems (European Commission JRC, citing the 2024 joint statement).

The approach is not universal. The United States will transition their federal systems directly to post-quantum algorithms, according to the JRC. The trade-off is extra complexity and larger handshakes. For OT links with long asset lifetimes and infrequent change windows, though, the extra protection against an unexpected break usually outweighs a small increase in handshake size.

In practice, a hybrid design looks like this. Quantum Network’s QPN gateway combines a classical part and a post-quantum part into one session key, with ML-KEM (FIPS 203) as the post-quantum algorithm in the standard product. Both handshakes renew every two minutes.

How should critical infrastructure operators react to news of broken post-quantum candidate algorithms?

Check first whether the broken algorithm is actually in use, then fix any agility gaps that the news exposes. Most candidate breaks, HAWK included, require verification and planning rather than emergency changes.

Triage by algorithm status

Build agility before you need it

The backup path for key agreement is already defined. NIST selected HQC because it is based on different math than ML-KEM, which could be important if a weakness were discovered in ML-KEM. Dustin Moody, NIST mathematician and project head, put it this way: “We are announcing the selection of HQC because we want to have a backup standard that is based on a different math approach than ML-KEM.” The standardization is occurring as FIPS 207, identified as HQC-KEM, and NIST expects a finalized standard in 2027. Note that HQC is a lengthier algorithm than ML-KEM and therefore demands more computing resources, which matters for constrained OT links.

Deadlines also argue against waiting. According to a 2026 summary of NIST IR 8547:

• 2030 and 2035: NIST IR 8547 sets a deprecation horizon of 2030 for 112-bit-strength or weaker quantum-vulnerable algorithms (e.g., RSA-2048, P-256) and full disallowance by 2035.

Concrete steps for OT and multi-site networks

• Map algorithms to links, not just to products. Record which key agreement and signature algorithm protects each site-to-site tunnel, cloud connection and remote-access path. A HAWK-style announcement then becomes a quick lookup instead of an investigation.
• Verify that algorithm changes need no hardware swap. In substations or plants, replacing a box can take a planned outage. Make sure the post-quantum component can be changed by software or configuration.
• Keep update channels alive. Crypto-agility is only real if updates actually arrive. As an example of the dependency, with QPN the post-quantum algorithm can be changed if necessary, but automatic updates of the algorithms and software require an active subscription; without one, the gateway keeps working in its current state without security updates.
• Plan for air-gapped sites. Networks without internet access need a documented, offline process for distributing cryptographic updates, tested before an urgent algorithm change is needed.
• Separate signature and key-agreement risk. HAWK was a signature scheme. Breaks in signature candidates affect authentication and firmware signing, not the confidentiality of traffic recorded today. Prioritise accordingly.

The HAWK withdrawal shows the standardization pipeline filtering out a weak candidate before deployment. For operators already running ML-KEM in hybrid mode, it confirms the design choice rather than undermining it.