DeepFalcon1313 — Quantum Readiness & Crypto Agility Weekly Briefing

Weekly Briefing — All 7 Blocks

Block 1 NIST PQC Standards & Mandate Tracker — HAWK Withdrawn After AI-Discovered Vulnerability; FIPS 140-2 → Historical in 33 Days Major Development ▼

Last edition (August 12) covered EO 14412's PQC implications for federal contractors. This week: two significant updates — the HAWK candidate withdrawal and the approaching FIPS 140-2 deadline.

HAWK Candidate Withdrawn — July 28–29, 2026 (Covered Here for First Time)
This development fell between editions — it occurred July 28, after Edition #2 closed. HAWK, a lattice-based digital signature scheme, was one of nine candidates NIST advanced to Round 3 of its additional post-quantum signature standardization process in May 2026. On July 28, Anthropic disclosed that its Claude Mythos Preview model had identified a nontrivial automorphism in HAWK's lattice structure — a symmetry that reduces the cost of key recovery attacks against HAWK-256 from approximately 2^64 operations to 2^38, effectively halving the scheme's security level. Doubling the key sizes to compensate would eliminate the compact signature size that made HAWK an attractive candidate. The HAWK team confirmed the finding and withdrew from the NIST process the following day, July 29. Important: this withdrawal does not affect any finalized NIST PQC standard. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) all use different mathematical foundations and are unaffected by this attack. The key for organizations currently migrating: do not let this headline slow your planning. The three deployed standards are secure. NIST's additional signature process now continues with 8 remaining candidates.

⚡ FIPS 140-2 → Historical Status: September 21, 2026 — 33 days
On September 21, 2026, NIST transitions all remaining FIPS 140-2 validated module certificates to Historical status. After that date, new US federal procurement must use only FIPS 140-3 validated cryptographic modules. If your organization serves federal clients, holds federal contracts, or plans HSM or hardware security module acquisitions that must meet federal requirements, verify that any planned purchases are validated under FIPS 140-3, not FIPS 140-2. The Cryptographic Module Validation Program (CMVP) database at csrc.nist.gov/Projects/cryptographic-module-validation-program is the authoritative source for validation status.

Date / Deadline	Event	Status
August 2024	FIPS 203, 204, 205 finalized	Complete — deploy now
September 21, 2026 — 33 days	FIPS 140-2 modules → Historical status	⚠ Approaching — verify procurement
Late 2026 / Early 2027	FIPS 206 (FN-DSA / Falcon) expected	Pending — NSA will NOT add to CNSA 2.0
January 1, 2027 — 135 days	CNSA 2.0: all new NSS acquisitions must support PQC	Hard mandate — NSS operators
2027–2028	CA/Browser Forum PQC cert baseline requirements expected	In progress — no merged standard yet
After 2030 (federal)	RSA/ECDH/ECDSA deprecated in federal systems	NIST IR 8547 guidance
2035 (federal)	RSA/ECDH/ECDSA prohibited in federal systems	Hard prohibition — NIST IR 8547

Sources: NIST PQC Project Page (primary) · The Hacker News — HAWK withdrawal reporting · CNSA 2.0 Complete Guide (postquantum.com) · NIST CMVP at csrc.nist.gov

Block 2 Vendor Crypto-Agility Moves — No New Announcements This Week; Hybrid TLS Deployment Status Unchanged No Movement ▼

No new vendor PQC or crypto-agility announcements were identified in the August 13–19 coverage window. The landscape from Edition #2 remains current:

Hybrid TLS Key Exchange — Where Things Stand (August 2026):
Chrome, Edge, and Firefox all negotiate X25519MLKEM768 by default for HTTPS connections. Apple iOS 26 / macOS Tahoe 26 brought Safari into the fold in 2026, completing major browser coverage. Cloudflare reports that more than two-thirds of human-generated TLS traffic to its network now uses hybrid ML-KEM key exchange. Across the broader web, estimates for hybrid TLS adoption range from 30–50% of TLS handshakes.

What is NOT yet deployed: ML-DSA signatures for server certificates remain absent from public web PKI. Public root CAs have not issued ML-DSA certificates that chain into the major trust stores. The CA/Browser Forum Server Certificate Working Group has a PQC ballot tracker but no merged baseline requirement. IETF draft-ietf-tls-mldsa is in working group last call as of May 2026. The practical consequence: when your browser connects over X25519MLKEM768, the session key is post-quantum-secure, but the server certificate authenticating the handshake is still ECDSA or RSA.

The 12 tracked enterprise security vendors (Check Point, Cisco, Fortinet, Palo Alto Networks, VMware/Broadcom, Ivanti, Citrix, F5, SonicWall, Oracle, Arista, Microsoft) — no new PQC-specific announcements from any this week. AWS Private CA and OpenSSL 3.5 ML-DSA support (covered in prior editions) remain current.

Block 3 "Harvest Now, Decrypt Later" Risk Watch — AI Cryptanalysis Lowers the Research Bar for Adversaries Too Contextual Update ▼

No new HNDL incidents or confirmed bulk-collection operations were reported this week. The standing HNDL assessment is unchanged: sensitive data with long confidentiality requirements (government, defense, financial, healthcare records) is the primary exposure category, as the data collected today need not be decrypted until a cryptographically relevant quantum computer (CRQC) exists — which most credible estimates place somewhere between 2030 and 2040, with substantial uncertainty on both ends.

The HAWK episode has one concrete HNDL implication worth naming: The Anthropic attack cost approximately $100,000 in API usage and was completed in roughly 60 hours. Anthropic's team estimates this is the "rough cost" of this class of AI-assisted cryptanalysis today. That cost trajectory is declining, not stable. Adversaries with nation-state resources can now dedicate serious AI compute to probing candidate algorithms — not just the finalized standards, but also interim implementations. This does not change HNDL risk for currently deployed RSA or ECDH (those are classical attacks, and the quantum timeline is what governs them), but it does mean that any PQC candidate algorithm should be assumed to receive AI-assisted cryptanalysis at scale before it is ever finalized. The HAWK episode was the process working — NIST advancing only to Round 3 candidates means the discovery happened before any deployment. But organizations should not treat any unfinalized PQC candidate as deployable for long-lived sensitive data.

Sector urgency note: NSA's CNSA 2.0 January 2027 mandate creates concrete HNDL urgency for defense contractors and NSS operators specifically — any long-lived data generated between now and PQC migration that is protected only by classical cryptography is HNDL-exposed. For organizations outside the NSS community, NIST's 2030 deprecation guidance is the relevant horizon, but "start your inventory now" remains the practical advice since migration timelines for large enterprises are typically 3–7 years.

Block 4 Quantum Computing Progress, Contextualized — No New Hardware Milestones; AI-Assisted Classical Cryptanalysis Is the Week's Signal Contextual Update ▼

Important distinction this week: the HAWK and McEliece developments below are AI-assisted classical cryptanalytic attacks, not quantum computing advances. They do not change the timeline for a cryptographically relevant quantum computer (CRQC) or the security of classical cryptography against quantum attack. They are relevant here because they affect the PQC candidate landscape and illustrate how the cost of cryptanalytic research is falling.

AI-Assisted Classical Cryptanalysis — HAWK and McEliece (both July 2026):
HAWK (above): Anthropic's Claude Mythos Preview found a nontrivial automorphism in HAWK's lattice structure in ~60 hours. The attack is classical (exponential cost, not polynomial), but reduces HAWK-256's effective security from 2^64 to 2^38. Source: Anthropic disclosure July 28, 2026, independently confirmed by NIST cryptographers on the pqc-forum the same day.

McEliece TII-252 (separate): Markku-Juhani Saarinen (noted separately on the NIST pqc-forum following the HAWK announcement) disclosed new structural key-recovery records for McEliece, including a break of the TII-252 parameter set, obtained with HOVER (a new AI-extended version of the Hemmert-Wiemers higher-order-vanishing attack, described in ePrint 2026/1339). McEliece itself is not a NIST PQC finalist — it was evaluated but not standardized due to key size. This is a research-track finding. The attack requires significant memory; the McEliece code-based schemes that did not advance to NIST standardization were not chosen for good reason.

Editorial note on scope: Both findings are AI-assisted classical cryptanalysis. Neither advances a quantum computer's ability to break RSA or ECDH, and neither affects FIPS 203/204/205. Including them here because they directly affect the PQC candidate landscape and represent the emerging intersection of AI capability and cryptographic research — a trend this briefing will continue to track under Block 4 as it develops.

Quantum Hardware — No New Milestones This Week: No new independently-verified quantum hardware milestones were published in the August 13–19 window. The central estimate for CRQC capability remains unchanged at the range cited in Editions #1 and #2: most credible technical estimates place a cryptanalytically relevant quantum computer (capable of running Shor's algorithm at meaningful key sizes) somewhere between 2030 and 2040, with wide expert disagreement and substantial uncertainty. NIST's and NSA's 2030–2035 deprecation timelines are calibrated to this range. This briefing will not report incremental qubit-count announcements without independent technical validation that they represent meaningful progress toward a CRQC — a single headline number without context is not a milestone.

Block 5 Practical Readiness Checklist — This Week's Focus: TLS 1.3 + Hybrid PQC Adoption Planning Actionable ▼

Edition #1 (August 6) covered: starting a cryptographic inventory — mapping all systems using RSA, ECDH, ECDSA, or Diffie-Hellman. Edition #2 (August 12) covered: certificate lifecycle and CA readiness. This week: TLS 1.3 + hybrid PQC adoption planning — how to verify and progressively enable hybrid key exchange in your environment, starting with what's already deployed.

Browser-side hybrid TLS (X25519MLKEM768) is already running by default in Chrome, Edge, Firefox, and Safari — which means if your public-facing web services are behind a CDN (Cloudflare, AWS CloudFront, Akamai, Fastly) or a modern load balancer, your browser-to-CDN connections are likely already using hybrid PQC without any configuration change. The gap that most organizations haven't addressed is the CDN-to-origin hop and internal service-to-service TLS, which typically still uses classical key exchange. This week's checklist walks through verifying where you are and planning the remaining steps.

// TLS 1.3 + Hybrid PQC Adoption Planning — Week of August 19

①

Verify your public sites are already negotiating X25519MLKEM768 at the edge. Use Cloudflare's test at pq.cloudflareresearch.com, or open Chrome DevTools → Security tab on your own domain. If your site is behind Cloudflare or most major CDNs, this is almost certainly already happening. If it's not, check whether your CDN or load balancer has hybrid PQC disabled — most have it enabled by default since 2025.

②

Audit the CDN-to-origin hop. This is where most organizations have the gap. Your CDN negotiates hybrid PQC with browsers — but then it may make a classical TLS connection to your origin server. Check whether your origin server's TLS implementation supports X25519MLKEM768. OpenSSL 3.5+ supports it; older OpenSSL versions do not. If your origin uses Go, Go 1.23+ enables X25519MLKEM768 by default in crypto/tls. Java (JDK 27+) is adding support.

③

Inventory internal service-to-service TLS. Microservices, API gateways, and internal mTLS (mutual TLS) traffic are typically still classical. Add these to the cryptographic inventory from Edition #1 if you haven't already. For each service: what TLS library version? What key exchange groups are configured? This doesn't need to change today, but it needs to be in your migration plan.

④

Do not deploy hybrid PQC X.509 certificates for public services yet. As documented in Block 2: CA/Browser Forum has not approved ML-DSA in publicly-trusted certificates, and no major root CA is issuing them. A "post-quantum certificate" for a public website has no trust chain. For internal PKI, ML-DSA certificates are available now via DigiCert Private CA, AWS Private CA (GA), and OpenSSL 3.5 — these are appropriate for internal services where you control the trust store.

⑤

Test for middlebox compatibility issues before broad rollout. Hybrid PQC TLS ClientHellos are larger than classical ones, which breaks some older deep-packet inspection devices and network middleboxes that incorrectly validate TLS message sizes. Run testssl.sh with the --groups X25519MLKEM768 option against your public endpoints to confirm no compatibility issues, and check whether any network appliances in your path need firmware updates to handle the larger handshake.

⑥

Capture this week's findings in your PQC migration tracker. The goal of this step is a clear inventory of: (a) where hybrid PQC is already active, (b) where you have a gap (CDN-to-origin or internal), (c) what TLS library versions need upgrading, and (d) what timeline you're working toward for internal service migration. This documentation is what CNSA 2.0's cryptographic inventory requirement is asking for — building it now means you're not starting from scratch when a regulator asks.

Block 6 This Week's Log — Research Decisions, Sources Checked, Changes from Prior Editions Logged ▼

2026-08-19 — Block 1: HAWK Withdrawal

HAWK was withdrawn July 28–29, 2026, between Editions #2 and #3. Covered this edition as a between-editions development. Sourcing: NIST pqc-forum primary; Anthropic's published research; THN reporting; independent confirmation by NIST cryptographers on the forum (Daniel Apon). The attack is classical, not quantum. FIPS 203/204/205 unaffected.

2026-08-19 — Block 1: FIPS 140-2 Timeline Verification

FIPS 140-2 → Historical status confirmed as September 21, 2026 via NIST CMVP documentation and postquantum.com CNSA 2.0 guide. 33 days from today. Escalated to deadline banner given the proximity.

2026-08-19 — Block 2: No New Vendor Moves

Checked all 12 tracked enterprise security vendors and major browsers/cloud providers for PQC announcements August 13–19. None found. Block 2 carries forward Edition #2 status — marked quiet rather than padding with recycled context.

2026-08-19 — Block 4: McEliece Note

Markku-Juhani Saarinen's McEliece TII-252 break (ePrint 2026/1339) noted in Block 4 as a companion to the HAWK discussion. McEliece was not standardized by NIST; included only for context on the broader AI-assisted cryptanalysis trend. Not a threat to deployed PQC standards.

2026-08-19 — Block 7: Introduced This Edition

Block 7 (Momentum Indicators) is new in prompt version v1.2-DM. First appearance this edition. Self-referential indicator (frequency of PQC mentions in this service's own archive): 2 references in the August 12–19 window, both relating to FudModule v3.1's ML-KEM C2 implementation (Lazarus Group, August 12 vuln report and August 14 threat intel report).

2026-08-19 — Archive Index: Edition #2 Missing

Noted that Edition #2 (August 12) was not added to the quantum-readiness-index.html archive page in the prior cycle. Correcting this edition by adding both Edition #2 and Edition #3 to the archive in this cycle's site file updates.

2026-08-19 — Known Corrections

No corrections to prior editions identified this cycle.

Block 7 Momentum Indicators — First Edition of Weekly PQC Maturity Signal Dashboard New — v1.2 ▼

New this edition (prompt v1.2-DM). Block 7 tracks seven standardized PQC maturity signals plus one self-referential indicator unique to this service. Every item is filtered by the Block 7 relevance rule: must connect specifically to the cryptographic/security implication of quantum computing — not quantum computing as a general category.

Indicator	Signal	Notes
1 — Research Publication Growth (cryptanalysis, PQC design, quantum algorithms with crypto relevance)	Active	HAWK cryptanalysis (Anthropic / July 28): formally published in two technical papers with reproducibility artifacts. McEliece TII-252 key-recovery via HOVER (Saarinen, ePrint 2026/1339): separate AI-assisted classical attack on a non-standardized code-based scheme. Both represent genuine PQC-cryptanalysis output. The HAWK result in particular is notable because it targeted a NIST third-round candidate and produced a confirmed finding within 60 hours. Publication volume trend: consistent with prior editions — post-quantum is a high-activity research area, AI-assisted cryptanalysis is a new and growing sub-category.
2 — Patent Filings (PQC algorithms, quantum-resistant hardware, crypto-agility tooling)	No signal	No new PQC-relevant patent filings identified in the August 13–19 window that meet the relevance filter. No meaningful signal this week.
3 — Startup Funding (PQC migration tooling, quantum-safe products, crypto-agility platforms)	No signal	No new funding rounds for PQC-specific companies identified this week. No meaningful signal this week.
4 — Product Releases (new PQC product categories or vendors entering PQC space for first time)	No signal	No first-time PQC product entrants identified this week. Incremental updates to products already covered in Block 2 (OpenSSL, AWS Private CA, etc.) are not counted here to avoid duplication. No meaningful signal this week.
5 — Standards Progress (ETSI, ISO, IETF, industry consortia — not NIST/NSA, already in Block 1)	Ongoing	IETF draft-ietf-tls-mldsa (ML-DSA in TLS 1.3 certificate authentication) remains in working group last call as of May 2026. No new drafts published or ballots advanced in the August 13–19 window, but this remains the key IETF dependency blocking PQC certificate adoption in public PKI. South Korea's KCMVP (Korea Cryptographic Module Validation Program) certified a hybrid PQC module this week per TechTimes reporting — the first such certification in the Korean market, driven by a five-sector government PQC pilot expansion. Not US-specific, but directionally significant for enterprise procurement in Korea.
6 — Enterprise Adoption (named orgs confirming PQC migration steps, pilots, or completed transitions)	No signal	DigiCert's 2026 Quantum Readiness Outlook (published prior to this window) reported 87% of organizations planning or testing PQC but only 7% deployed across most digital certificates — cited for context on where the market stands, not as a new this-week development. No named organizations publicly confirmed new migration steps this week. No meaningful signal this week.
7 — Regulatory References (financial sector, insurance, HIPAA/PCI-DSS updates, non-US jurisdictions)	Low activity	South Korea KCMVP certification noted above (indicator 5) has a parallel regulatory dimension — the certification is driven by a five-sector government mandate. No new US financial sector (FDIC, OCC, FINRA) or insurance (NAIC) PQC-specific guidance published this week. EU NIS2 and DORA continue to be cited in European regulatory context but no new PQC-specific updates this week.
8 — Frequency in Own Reports ★ self-referential	2 refs	2 references to ML-KEM/post-quantum in this service's own August 12–19 daily reports: (1) August 12 Vulnerability Report — FudModule v3.1 (Lazarus Group) uses ML-KEM (CRYSTALS-Kyber, post-quantum key encapsulation) for its C2 communications, documented in the Patch Tuesday analysis; (2) August 14 Threat Intelligence Report — the same FudModule v3.1 ML-KEM C2 detail, covered in depth as part of the Operation Dream Job attribution report. Both references relate to the same event: Lazarus Group deploying ML-KEM in active malware C2 — one of the first confirmed uses of post-quantum cryptography in deployed nation-state malware. This is notable precisely because ML-KEM is a FIPS 203 algorithm being used offensively before most organizations have begun deploying it defensively.