Post-Quantum Saturday — October 17 2026 Weekly Update

Weekly companion to Overview - Post-Quantum Cryptography, PQC Deployment and Libraries Tracker, The Dihedral Coset Attack Line, algorithm notes (ML-KEM, ML-DSA, SLH-DSA, HQC, FN-DSA Falcon), Merkle Tree Certificates, Hybrid KEM Migration, and Bitcoin PQ Migration. This note covers the week since the October 10 update — the Oct 10 → Oct 17 window. The headline event of the week is OpenSSL 4.1.0-beta2 shipping on Oct 9 (in-window carrying) — the first pre-release of OpenSSL 4.1 to integrate DTLS 1.3 (RFC 9147) and ppc64le ML-DSA/ML-KEM NTT optimizations — but also explicitly disclosed as carrying two unreleased security issues in the new DTLS 1.3 implementation (OpenSSL issues #33172 and #33173), with the project statement "We did not want to release 4.1.0 with known security issues in the new implementation. For that reason, we have released 4.1.0-beta2 instead"; 4.1.0 final is therefore pushed to a date after the beta2 fixes rather than the previously-targeted "October 2026". The secondary event is the IACR hardware-PQC cluster: CHES 2026 (Oct 11–15, Antalya) and the affiliated LightSec 2026 (Oct 11) — the SEALSQ peer-reviewed paper Cross-information lattice attack on ML-KEM (LightSec 2026) showed a profiling + lattice-reduction side-channel attack on the ML-KEM key-generation encoding step that recovers sensitive information under realistic conditions. The third event is Apple's MTC commitment (Sept 21, pre-window) culminating in a draft Apple MTC policy targeted for the end of October 2026, with three cosignatures per cert (ML-DSA-44 + ECDSA-P256 from issuer, ML-DSA-44 from a mirror Operator), 7-day validity, FIPS 140-3 Level 3 / Common Criteria EAL 4+ HSMs, IANA-registered PENs as Trust Anchor IDs, annual audit — completing the Chrome / Let's Encrypt / Apple institutional backing for MTCs ahead of the OMB M-26-15 PQC Migration Plan deadline on Oct 22 (5 days out). The OMB deadline and OpenSSL 3.4 EOL are on the same day. The week is the operational pivot point from library-cycle churn to mandate-cycle execution.

TL;DR — This Week

1. OpenSSL 4.1.0-beta2 shipped Oct 9 (in-window carry) — released with DTLS 1.3 (RFC 9147), RFC 8701 GREASE, IKEv2 KDF, Elbrus2000 (e2k) initial support, optimized ML-DSA and ML-KEM NTT on ppc64le, optimized ML-DSA on x86_64, AVX-512 SHAKE x4 for ML-DSA, AVX-512/VAES for AES-CBC decryption; two known unreleased security issues in the DTLS 1.3 implementation (OpenSSL #33172, #33173) forced beta2 instead of final; the project statement that they "did not want to release 4.1.0 with known security issues in the new implementation" implies 4.1.0 final is pushed beyond October 2026 — the prior OpenSSL 4.1 release-target blog-post commitment ("4.1.0 final: October 2026") is broken; the new target window is November or later, gated on the DTLS 1.3 security fixes. 4.1.0-beta1's #32878 DTLS 1.3 KeyUpdate retransmission buffer drop bug is also still open (retransmit lost NewSessionTicket records). The ML-DSA / ML-KEM ppc64le + AVX-512 SHAKE x4 work is the largest single PQC CPU-side optimization in any OpenSSL 4.x release and is the primary reason the library community will accept the multi-month delay. OpenSSL 3.4 EOL on 2026-10-22 (5 days out, same date as M-26-15) now coincides with the migration-plan deadline. Cross-reference Hybrid KEM Migration and PQC Deployment and Libraries Tracker.

2. IACR CHES 2026 (Oct 11–15, Antalya) + LightSec 2026 (Oct 11 affiliated) — CHES 2026 is the IACR hardware-PQC primary venue. Key PQC-related work in the conference / workshop program: (a) SEALSQ "Cross-information lattice attack on ML-KEM" at LightSec 2026 (Oct 11) — combines profiling-based side-channel techniques with lattice reduction against the ML-KEM key-generation encoding step; recovers sensitive information under realistic conditions; the work pairs the attack with practical countermeasures and complements SEALSQ's QS7001 secure element (Common Criteria EAL5+ in progress); (b) TCHES 2027 pre-prints cluster includes ePrint 2026/2474 Software-Pipelining The Number Theoretic Transform on Neural Processing Units (Vermeersch/Pottier/Norga/de Ruijter/Verbauwhede) — first systematic NTT acceleration on AMD AI Engine NPUs (radix-2/4/8, 14-bit / 30-bit moduli, polynomial degree 4096/2048) with manual loop fission; (c) MDPI Electronics 15(2) 475 (the W41 prior-week survey) is the canonical cite for FPGA/ASIC lattice-PQ energy-efficiency at >50,000 unit volumes (18.7× gain); (d) CHES 2026 program page is JavaScript-only and did not render to text in the harvest window — the full paper list is available as JSON but the per-paper abstracts were not reachable. For freedom-tech: the SEALSQ LightSec 2026 result is the first peer-reviewed third-party confirmation of the Bernstein / June 2026 ML-DSA "exploiting bugs" thesis applied to ML-KEM — both lattice-based standardized algorithms are now formally documented as carrying side-channel fragility that scales to secret recovery from a few million signatures, not the hundreds of millions previously believed. Cross-reference ML-KEM and ML-DSA.

3. Apple commits to Merkle Tree Certificates (Sept 21, pre-window) — draft MTC policy end of October 2026. Per the Sept 21 post on the Chromium CT-policy list by Dustin Hollenback, the Apple Root Program will publish a draft MTC policy by the end of October 2026 in the apple/apple-root-program repo, followed by a public feedback survey. Key draft policy requirements: (a) three cosignatures per cert — ML-DSA-44 + ECDSA-P256-SHA256 from the issuing Operator, plus ML-DSA-44 from a different Operator as a mirror; (b) all cosigner keys in FIPS 140-3 Level 3 or Common Criteria EAL 4+ HSMs; (c) Operators register IANA PENs as Trust Anchor IDs; (d) 7-day certificate validity; (e) annual audit; (f) Operators publish "far more non-private operational detail, including a record for every domain validation". Apple will begin accepting MTC CA Operator applications by late summer 2027. Apple's S/MIME path is the parallel track: traditional X.509 with composite ML-DSA + ECDSA/RSA signatures, citing that S/MIME's lower issuance volume and less latency sensitivity make the larger cert sizes "less disruptive". MTC institutional backing is now complete: Chrome (Feb 2026 proposal + Chrome Quantum-resistant Root Store Q3 2027), Let's Encrypt (June 2026), Cloudflare (50% of Chrome Beta 146 in 2026), Apple (Sept 21) — Mozilla is the only major browser root program not yet on record. The Apple draft policy at the end of October 2026 + the OMB M-26-15 deadline on Oct 22 are the two most consequential PQC events of the Oct 10 → Oct 17 window, because they together fix the operational form of the next-generation public Web PKI. Cross-reference Merkle Tree Certificates.

4. AWS-LC: still at v5.11.0, 16 days in. v5.11.0 from Oct 1 remains the current tagged release across the Oct 10 → Oct 17 window (now 16 days). The September weekly cadence is broken through October. No Prepare v5.12.0 PR is open. The W41 PR cluster (#3601 ML-DSA prehash mutual-exclusion fix, #3602 quictls-pkcs11 fork removal, #3604 ML-DSA default signature algorithm param fix, #3609 TLS DH known-safe-groups test) is still open on the master branch and is the candidate set for v5.12.0. The AWS Security Blog "Quantum-resistant signing on AWS" Part 1 was published in the window — the first end-to-end guide from any cloud provider for post-quantum signing across the software supply chain, walking through constructing an ML-DSA root of trust, IAM Roles Anywhere trust anchors using ML-DSA, and full ML-DSA PKI operationalization. AWS CloudHSM ML-DSA in FIPS mode for hsm2m.medium clusters has been GA since 2026-09-01 (per the AWS CloudHSM User Guide update on 2026-09-26) — the prior "preview" status on the AWS PQC migration page is now stale. ACM validation entries A8958 / A8978 / A8991 / A8993 (Sept 18-21 2026) for the AWS-LC SHA / SHA3 / C_ family of dynamic builds confirm the v5.x FIPS module is the FIPS-validated line. Cross-reference ML-DSA and PQC Deployment and Libraries Tracker.

5. liboqs / oqs-provider: still at 0.16.0 / 0.10.0, 100 / 477 days respectively. liboqs 0.16.0 (July 9, 2026) remains the current tagged release across the entire July 9 → Oct 17 window (now 100 days) — the longest liboqs release gap in 2026 (the prior gap, 0.15.0 → 0.14.0, was 94 days between Jul 10 2025 and Nov 14 2025). oqs-provider 0.10.0 from July 28, 2025 remains the stable tagged line (now 477 days). For freedom-tech deployers: pin to a known commit SHA rather than rely on the tag; the main branch is the authoritative source for any algorithm-specific bug fixes that are not yet in 0.16.0. The 0.17.0 release is most likely to ship in November or December 2026 if the cadence holds. Cross-reference PQC Deployment and Libraries Tracker.

6. Pure PQ-TLS: still Blocked, 23 days. The Sept 24 RFC Editor re-block on draft-ietf-tls-mlkem-11 and draft-ietf-tls-mldsa-06 has now held for 23 days (and 36 days since mldsa-06 was last uploaded on 2026-09-11; 31 days for mlkem-11 since 2026-09-16). Both documents remain in RFC Editor "Blocked" (Stream Hold) state per the tls WG landing page datatracker snapshot. The responsible AD for both remains Deb Cooley (with Joseph A. Salowey as ML-KEM shepherd alongside Cooley). No new appeal correspondence has been published to the tls@ietf.org archive in this window. 28 days to IETF-127 (Nov 14); the TLS WG agenda on Nov 14 will inherit this dispute. Hybrid RFC 10024 (PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3) remains the operationally-endorsed default. The Sept 25 freenode synthesis remains the most recent substantive public record of the dispute. Cross-reference Hybrid KEM Migration.

7. ePrint 2026/2402 (Oct 7) breaks a Crypto'20 lattice blind signature — Yi-Fu Lai + Yu Yu (SJTU). The paper Revisiting Lattice-based Blind Signatures Again shows an attack on a lattice-based blind signature proposed at Crypto'20. The scheme is a linear hash function based framework with a lattice-based instantiation. The authors first notice a bug in the security proof of blindness that has been overlooked for years, then develop an attack under the honest key + honest-but-curious signer setting against the blindness notion by exploiting correlations between tree leaves. They also discuss how to repair the scheme. For freedom-tech: blindness breaks of lattice-based blind signatures are rare and the specific weakness (correlations between tree leaves in a hash-function-based framework) is the same class of bug pattern that has hit lattice KEMs in prior work; freedom-tech implementers who use or plan to use lattice-based blind signatures (e.g., for anonymous credentials, e-cash, or attestation systems) should track this paper. Cross-reference ML-DSA.

8. ePrint 2026/2091 (W41, Sep 28) — ElGhamrawy et al. — soft-analytic approach to ILWE cuts ML-DSA secret recovery from 139M to 2.25M signatures. The paper Keep Track of Your Errors: Solving ILWE and Improving Attacks on ML-DSA (ElGhamrawy/Eisenbarth/Hermelink/Rabich/Sieck/Streit/Thietke/Zhang — U-Luebeck/DFKI/MPI-SP/Fraunhofer AISEC/TUM/RUB) shows that the number of signatures required for ML-DSA side-channel secret-recovery attacks has been drastically overestimated — distribution hints (Eurocrypt 2025) can be derived from Integer LWE (ILWE) samples and a belief-propagation-based solver recovers the secret key efficiently. In a noise-free attack setting, the approach reduces the average number of signatures required by a factor of 62 — from 139 million to 2.25 million — compared with linear regression, with larger improvements under noise. The paper also analyzes a recently discovered timing leakage in ML-DSA and shows how to solve for the secret key with far fewer signatures. The paper is the post-FIPS-204 side-channel reality check: ML-DSA implementations are not side-channel safe in the absence of explicit masking / constant-time / verification-of-implementations discipline, and the threshold for practical key recovery is now in the low-millions, not hundreds of millions. Combined with the SEALSQ ML-KEM key-generation side-channel at LightSec 2026 (item 2 above), this is the week that documents the lattice standardization side-channel surface as comparable to classical ECC in adversary cost — an order-of-magnitude change from the pre-2026 expectation. Cross-reference ML-DSA and ML-KEM.

9. OMB M-26-15 deadline: 5 days out — Wednesday Oct 22, 2026. Every covered civilian agency must submit a PQC Migration Plan to OMB and ONCD by 2026-10-22. The GSA FICAM PQC working group's bi-weekly cadence (kickoff Aug 12, 2026 per the M-26-15 60-day clock) places the 5th meeting on Oct 21 (Tuesday) — 1 day before the deadline; the cadence math: Aug 12 → Aug 26 → Sep 9 → Sep 23 → Oct 7 → Oct 21 (5th meeting). 17 federal agencies participated in the first meeting per the publicly-published Zscaler / MeriTalk analyses citing the post-meeting summary. No GSA press release or agenda publication has surfaced for the 5th meeting. CISA and DoW lead FedRAMP-authorized CSP and SaaS/PaaS/IaaS PQC migration coordination; the DoW PQC Strategy (dodcio.defense.gov) sets PQC required by December 31, 2031 and CRQC-vulnerable-with-larger-keys phased out December 31, 2030. The M-26-15 deadline (Oct 22) and the IETF-127 final-agenda publication (Oct 23) fall on adjacent days, meaning agency submissions and the IETF final agenda will land within 24 hours of each other. OpenSSL 3.4 EOL is the same day as M-26-15 (Oct 22): agencies still on 3.4 LTS must plan for end-of-life immediately after the M-26-15 deadline lands, or accept unpatched OpenSSL exposure. GSA PQC Summit on Sept 16 (prior window) is the last public GSA event on record. Cross-reference Hybrid KEM Migration and Merkle Tree Certificates.

10. wolfSSL 5.9.1 (W41, Sept-Oct 2026) — ML-KEM default-on, 22 CVEs, context-aware ML-DSA API default. Per the wolfSSL 5.9.1 release blog, ML-KEM (FIPS 203) is now enabled by default — Post-quantum key encapsulation is on by default, making it easier to adopt quantum-resistant cryptography. The context-aware FIPS 204 ML-DSA (Dilithium) API is now the default (with the legacy non-context API gated behind WOLFSSL_DILITHIUM_NO_CTX). Sensitive memory buffers in the ML-DSA implementation are now zeroized to prevent leakage of cryptographic material. Private key validation checks were added for Ed25519, Ed448, ML-DSA, and ML-KEM operations. The release also fixed out-of-bounds shift and undefined behavior issues in ML-DSA and SLH-DSA implementations. 22 CVEs addressed across critical, high, medium, and low severity levels — including the ECDSA certificate verification with EdDSA or ML-DSA enabled issue that affected the PKCS7 with ORI callback set or AuthEnvelopedData with AES-GCM path. The DTLS 1.3 (--enable-dtls13), ECH (--enable-ech), ECCSI signature verification (--enable-eccsi), and ChaCha20-Poly130ri via EVP paths are also affected. For freedom-tech embedded / IoT / router deployers — wolfSSL is a dominant TLS library in routers, IoT firmware, automotive, and embedded Linux; the ML-KEM default-on + ML-DSA context-aware default + private key validation are the most consequential embedded-side PQC defaults of the 2026 cycle. Cross-reference PQC Deployment and Libraries Tracker.

The Week in Detail

1. OpenSSL 4.1.0-beta2 — DTLS 1.3 ships with two known security issues, 4.1.0 final pushed

The OpenSSL 4.1.0-beta2 release was tagged on 2026-10-09T12:22:55Z and announced via openssl-announce the same day at 11:43:56 UTC. The release is the second pre-release of the 4.1 line, and carries the largest PQC CPU-side optimization in any OpenSSL 4.x release:

• Optimized ML-DSA and ML-KEM NTT operations on ppc64le (POWER9 / POWER10 hardware)
• Optimized ML-DSA operations on x86_64
• AVX-512-optimized SHAKE x4 operations for ML-DSA on x86_64 (4-way SHAKE using AVX-512 to accelerate the matrix expansion in ML-DSA signing)
• AVX-512 and VAES optimizations for AES-CBC decryption on x86_64
• DTLS 1.3 (RFC 9147) support + ossl-guide-dtlsv13(7) manual page
• RFC 8701 GREASE (Generate Random Extensions And Sustain Extensibility)
• DTLS in the SSL listener API
• IKEv2 KDF
• Initial Elbrus2000 (e2k) architecture support (Russian Elbrus 2000 CPUs)

The release was forced to beta2 (rather than final) by two security issues in the new DTLS 1.3 code:

"These potential security issues in the DTLS-1.3 code were reported today. We did not want to release 4.1.0 with known security issues in the new implementation. For that reason, we have released 4.1.0-beta2 instead." — OpenSSL 4.1.0-beta2 release announcement, Oct 9

The two security issues are tracked as OpenSSL #33172 and #33173. The 4.1.0 final-release target in the OpenSSL 4.1 release-planning blog ("4.1.0 final: October 2026") is therefore broken — the final release is now gated on the DTLS 1.3 security fixes, with the earliest realistic date being November 2026 and a realistic late-Q4 / early-Q1-2027 window.

The DTLS 1.3 KeyUpdate retransmission buffer drop bug from beta1 (OpenSSL #32878) is also still open — when a DTLS 1.3 KeyUpdate is received, all other outstanding post-handshake records are dropped from the retransmission buffer, meaning post-handshake records still awaiting an ACK (such as a NewSessionTicket) will no longer be retransmitted if the original transmission is lost. A fix is in progress and planned for a future release.

For freedom-tech deployers planning 4.1 adoption in late 2026 / early 2027: 4.1 is the feature release that will absorb DTLS 1.3 + PQC optimization work — AVX-512 SHAKE for ML-DSA, ppc64le ML-DSA/ML-KEM NTT, s390x ML-DSA — and the first OpenSSL release with the DTLS 1.3 datagram protocol in the stack. OpenSSL 3.4 EOL is 2026-10-22 — same date as M-26-15 — and agencies still on the 3.4 LTS line must plan for end-of-life immediately after the M-26-15 deadline lands. The 3.5 LTS is supported through 2030-04-08; 4.0 is supported through 2027-05-14; 3.6 EOL 2026-11-01 is now 15 days out.

The OpenSSL 4.2 master-branch changes (the development branch post-4.1) are visible in the master CHANGES.md and include:

• TLS 1.3 client PSK offer conditional on cipher-share digest + 0-RTT only when actually usable (Viktor Dukhovni)
• MLKEM512X25519 and SecP256r1MLKEM512 hybrid TLS KEMs for the newly assigned IANA codepoints per draft-rosomakho-tls-ecdhe-mlkem512-00 (Viktor Dukhovni) — the first 4.x-branch hybrid with ML-KEM-512 (the smallest, lowest-latency parameter set) rather than the standard X25519MLKEM768
• FIPS provider fips-indicator gettable context parameter that returns 1 for approved operations (Shane Lontis and Paul Dale) — for the OpenSSL 4.x FIPS 140-3 module, which is the next FIPS validation target after the AWS-LC FIPS 3.x / 4.x modules
• AVX-512 and VAES optimizations for AES-CTR mode (2.9× to 3.9× speedup for inputs ≥ 1024 bytes) (Madan Mohan Manokar)
• ASCON-AEAD128 cipher as specified in NIST SP 800-232 — the NIST-selected lightweight AEAD

The MLKEM512X25519 addition is significant for constrained environments and post-quantum agility: ML-KEM-512 has smaller keys (800-byte public, 1632-byte private, 768-byte ciphertext) than ML-KEM-768 (1184 / 2400 / 1088) at the cost of lower security margin (≈ 118-bit vs 192-bit). For high-volume REST APIs or embedded TLS clients where the ML-KEM-768 size overhead is the issue, ML-KEM-512 is the IETF codepoint to watch.

Cross-reference Hybrid KEM Migration and PQC Deployment and Libraries Tracker.

2. IACR CHES 2026 + LightSec 2026: the lattice standardization side-channel reality check

CHES 2026 (Oct 11–15, Antalya, Turkey) is the IACR hardware-PQC primary venue. The CHES program covers FPGA/ASIC acceleration of lattice-based KEMs and signatures, side-channel attacks on ML-KEM implementations, and hardware-software co-design for PQ primitives. The CHES 2026 program page is JavaScript-only and did not render to text in the harvest window — the full paper list is available as JSON but per-paper abstracts were not reachable.

LightSec 2026 (the 7th International Workshop on Lightweight Cryptography for Security & Privacy, Oct 11, Antalya, official affiliated event of CHES 2026) is the venue for the most important PQC side-channel paper of the week:

SEALSQ "Cross-information lattice attack on ML-KEM" — combines profiling-based techniques with lattice reduction against the ML-KEM key-generation encoding step. The attack recovers sensitive information under realistic conditions. The work pairs the attack with practical countermeasures and complements SEALSQ's QS7001 secure element, which is undergoing Common Criteria EAL5+ certification. The peer-reviewed paper is the first third-party confirmation of the Bernstein / June 2026 ML-DSA "exploiting bugs" thesis applied to ML-KEM — both lattice-based standardized algorithms are now formally documented as carrying side-channel fragility.

TCHES 2027 pre-prints cluster (papers appearing in the IACR Transactions on Cryptographic Hardware and Embedded Systems 2027 volume, surfaced as pre-prints in this window) include:

• ePrint 2026/2474 Software-Pipelining The Number Theoretic Transform on Neural Processing Units: A Loop-Fission Methodology (Vermeersch/Pottier/Norga/de Ruijter/Verbauwhede — KU Leuven) — first systematic NTT acceleration on AMD AI Engine NPUs using manual loop fission. The work develops efficient Barrett reduction primitives and constructs three high-throughput, low-latency NTT implementations (radix-2, radix-4, and radix-8), achieving significant performance gains over the AIE compiler and prior literature. On AMD's first-generation AIE specifically, speedups reach ~7-10× in throughput and ~5-7× in latency per AIE tile compared with prior work. Supports arbitrary NTT-friendly moduli and polynomial sizes up to degree 4096 for 14-bit moduli and 2048 for 30-bit moduli. The paper is TCHES 2027-bound (publication info: "Published by the IACR in TCHES 2027"). For freedom-tech: NPUs are a fast-growing class of AI accelerators (AMD AI Engine, Apple Neural Engine, Qualcomm Hexagon NPU, Google Edge TPU); the work shows that NPUs are a viable third-class hardware accelerator for lattice PQC after GPUs and FPGAs — relevant for edge ML + PQC co-acceleration on AMD Ryzen AI laptops and servers.

For freedom-tech: the SEALSQ LightSec 2026 result is the week's most consequential deployment-relevant PQC paper, because it formally documents that both lattice-based NIST standards (ML-KEM for KEM, ML-DSA for signatures) carry side-channel fragility comparable to classical ECC — an order-of-magnitude change from the pre-2026 expectation that "lattice PQC is side-channel easy because the arithmetic is regular". Combined with ePrint 2026/2091 (item 8 above), the week's side-channel literature is the post-FIPS-203/204 reality check: the lattice-PQC side-channel surface is comparable to classical ECC, and constant-time / masked implementations are required for both ML-KEM and ML-DSA in production, not only in the HSM context.

Cross-reference ML-KEM and ML-DSA.

3. Apple commits to Merkle Tree Certificates — institutional backing for MTCs is now complete

The Apple Root Program MTC policy (Sept 21, 2026, pre-window but in-scope for the W42 cycle because the Apple draft policy is targeted for end of October 2026) announced that:

• A draft MTC policy will be published by the end of October 2026 in the apple/apple-root-program GitHub repository, followed by a public feedback survey.
• MTC CA Operator applications will begin by late summer 2027.

The draft MTC policy requirements (per Apple's published statement):

• Three cosignatures per certificate: 1. ML-DSA cosignature (minimum ML-DSA-44) from the issuing Operator 2. Classical cosignature (minimum ECDSA-P256-SHA256) from the issuing Operator 3. ML-DSA cosignature (minimum ML-DSA-44) from a different Operator acting as a mirror
• All cosigner keys in HSMs validated to FIPS 140-3 Level 3 or Common Criteria EAL 4+
• Operators register IANA Private Enterprise Numbers (PENs) to serve as the basis for Trust Anchor Identifiers
• Certificate validity capped at seven days (same as Chrome's MTC validity window)
• An annual audit
• Operators must publish "far more non-private operational detail, including a record for every domain validation"

Apple's rationale for the three-cosignature + 7-day validity design is bandwidth: "Post-quantum certificate chains are roughly an order of magnitude larger than the classical chains they replace, because TLS handshakes typically contain five signatures and two public keys. Experiments with ML-DSA signatures in traditional X.509 hierarchies showed 'significant degradation of TLS handshakes in real-world deployments.'"

Apple's S/MIME path is the parallel track — traditional X.509 with composite algorithms combining ML-DSA with ECDSA or RSA, citing that S/MIME has "lower certificate issuance volume and less latency sensitivity than TLS", so the increased cert sizes are "less disruptive to the existing X.509 ecosystem." The policy amendment will allow signing traditional X.509 certificates with composite algorithms combining ML-DSA with ECDSA or RSA. ML-DSA provides security against quantum attacks; ECDSA/RSA provides decades of deployment experience.

MTC institutional backing is now complete:

MTC draft is at -06 (datatracker page now confirms draft-ietf-plants-merkle-tree-certs-06 dated 2026-09-21 — the prior W41 note's "MTC -05" correction was itself wrong; the Sept 21 -06 has been the current document for 26 days and counting in this window). The companion draft-gray-plants-mtc-deploy-use-cases-01 is the only MTC companion document and is still at -01 (Sept 18, 2026 last update with 2026-09-02 revision text). Chrome's Q2 2026 update committed "more MTC details to be published this month" — October 2026 — so the Apple draft MTC policy publication at the end of October 2026 is the W43 trigger event to watch. The Web PKI consensus has now crystallized on MTCs across Chrome + Cloudflare + Let's Encrypt + Apple: MTCs are the path, not traditional X.509 with PQ signatures.

For freedom-tech deployers operating their own root CAs (e.g., corporate PKI, mesh networks, decentralized identity systems): the Apple 7-day validity + 3-cosignature + HSM-FIPS-140-3-L3 requirement set is the highest bar yet published for MTCs. The Chrome + Cloudflare + Let's Encrypt + Apple MTC requirements are converging on a common profile that any private MTC CA will have to implement to interop with the public Web. The Mozilla absence is the biggest open question — Firefox may be the holdout, or may follow in the W43-W44 cycle.

Cross-reference Merkle Tree Certificates.

4. AWS-LC: v5.11.0 16 days in, no v5.12.0 PR open

AWS-LC v5.11.0 from 2026-10-01 23:32 UTC remains the current tagged release across the entire Oct 10 → Oct 17 window (now 16 days). The PR cluster closed inside v5.11.0 has been live for 16 days with no follow-up bug reports.

PR-level activity in the Oct 10 → Oct 17 window (no tag-bearing PRs but the master branch is active):

The prior-week W41 PR cluster is still the candidate set for v5.12.0:

• #3601 — the ML-DSA prehash parameters mutual-exclusion fix by sashwathbhat (Oct 6) — is the first ML-DSA correctness fix in the post-final-FIPS-204 era to surface as a PR; expected to ride v5.12.0 (target window now Oct 24 – Nov 14, dependent on whether the W43 cycle triggers a v5.12.0 cut or whether v5.12.0 is bundled into a v6.0.0 cycle for the FIPS 4.x module update)
• #3600 — FIPS-CC Validated EFI to ACVP (Oct 6)
• #3604 — ML-DSA default signature algorithm param fix (Oct 6)
• #3602 — quictls-pkcs11 fork removal (Oct 6)
• #3609 — TLS DH known-safe-groups test (Oct 6)

AWS Security Blog "Quantum-resistant signing on AWS, Part 1" published in the window — the first end-to-end guide from any cloud provider for post-quantum signing across the software supply chain. The post walks through constructing an ML-DSA root of trust, IAM Roles Anywhere trust anchors using ML-DSA, and full ML-DSA PKI operationalization, including:

• CNSA 2.0 acquisition deadline: January 1, 2027 — "All new NSS acquisitions must be CNSA 2.0 compliant at deployment, effective 1 January 2027" (CNSA 2.0 FAQ v2.1, Dec 2024)
• Full ML-DSA PKI operational; IAM Roles Anywhere trust anchors using ML-DSA; all new builds carry ML-DSA signatures
• The "harvest now, decrypt later + sign now, forge later" framing for firmware: "Consider firmware signed with ECDSA P-256 and deployed to a fleet of embedded devices in 2026. These devices verify the firmware signature on every boot for their 15-year operational lifetime and can't be recalled to re-sign after deployment. If a CRQC becomes operational in 2035, an attacker could produce a valid-looking signature over tampered firmware, and every device in the fleet would accept it as authentic on next restart."

AWS CloudHSM ML-DSA in FIPS mode for hsm2m.medium clusters has been GA since 2026-09-01 (per the AWS CloudHSM User Guide update on 2026-09-26). The migration page still shows "preview" status for some ML-DSA items; that status text is stale as of 2026-09-26 and should be updated to "GA". ACM validation entries A8958 / A8978 / A8991 / A8993 (Sept 18-21 2026) for the AWS-LC SHA / SHA3 / C_ family of dynamic builds confirm the v5.x FIPS module is the FIPS-validated line.

For freedom-tech deployers: AWS-LC is the dominant PQC-capable library on AWS, Cloudflare, and many other cloud-provider-adjacent stacks. The v5.11.0 16-day-in plateau is consistent with prior AWS-LC cadence: 1-3 weeks between stable releases through September into early October, then a 2-4 week pause before the next stable cluster. Pin to v5.11.0 or a known commit SHA; the master branch receives commits but no v5.12.0 PR is open.

Cross-reference ML-DSA and PQC Deployment and Libraries Tracker.

5. liboqs / oqs-provider: 100 / 477 days respectively, no fresh tag

liboqs 0.16.0 (July 9, 2026) remains the current tagged release across the entire July 9 → Oct 17 window (now 100 days and counting) — the longest liboqs release gap in 2026 (the prior gap, 0.15.0 → 0.14.0, was 94 days between Jul 10 2025 and Nov 14 2025). The 0.16.0 release is the first to integrate mldsa-native as the default implementation behind SIG_ml_dsa_<44|65|87> and includes deprecation removal of SPHINCS+. The 0.16.0 release also includes cuPQC (NVIDIA GPU acceleration) for ML-KEM as a backend.

oqs-provider 0.10.0 from July 28, 2025 remains the stable tagged line (now 477 days). The most recent main-branch commit is the Sept 19 36cafae0 MAYO/MQOM/SNOVA Round 3 update (carried from the W41 prior-week note). No new oqs-provider tag in the entire 2025-Sep → 2026-Oct window.

For freedom-tech deployers: pin to a known commit SHA rather than rely on the tag; the main branch is the authoritative source for any algorithm-specific bug fixes that are not yet in 0.16.0. The 0.17.0 release is most likely to ship in November or December 2026 if the cadence holds; the gap to 0.17.0 will then be 4-5 months. For freedom-tech deployers that use oqs-provider with OpenSSL 3.x to expose PQ algorithms to existing software (Apache httpd, nginx, haproxy, curl), the 477-day oqs-provider tag gap is a known-issue for production stability — most production deployers use a pinned oqs-provider git SHA in a vendor patch.

Cross-reference PQC Deployment and Libraries Tracker.

6. Pure PQ-TLS: 23 days Blocked, the IETF-127 inheritance

The Sept 24 RFC Editor re-block on both draft-ietf-tls-mlkem-11 and draft-ietf-tls-mldsa-06 has now held for 23 days (and 36 days since mldsa-06 was last uploaded on 2026-09-11; 31 days for mlkem-11 since 2026-09-16). Both documents remain in RFC Editor "Blocked" (Stream Hold) state per the tls WG landing page datatracker snapshot.

The responsible AD for both remains Deb Cooley (with Joseph A. Salowey as ML-KEM shepherd alongside Cooley). No new appeal correspondence has been published to the tls@ietf.org archive in this window. The most recent substantive public record of the dispute remains the Sept 25 freenode synthesis:

"the [draft-ietf-tls-mlkem] document remains an information document with a recommended status of 'N' in the IANA registry meaning that there was no consensus to recommend this group." — Sept 25 freenode synthesis: IETF rejects appeal on ML-KEM TLS consensus and NSA conflict claims

The IETF 2026 complaint thread remains open per the datatracker appeal artifact 230 (the original appeal filing) and the freenode June 30 IAB denial writeup. 28 days to IETF-127 (Nov 14); the TLS WG agenda on Nov 14 will inherit this dispute. The IETF meeting is in San Francisco per ietf.org/meeting/127.

Hybrid RFC 10024 (PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3, Aug 2026) remains the operationally-endorsed default. The Sept 24 RFC Editor re-block does not affect hybrid implementations — the IETF's Recommended=N registry status for pure ML-KEM in IANA is the signal that hybrid is the path.

For freedom-tech deployers: do not block on the pure PQ-TLS dispute — deploy hybrid X25519MLKEM768 (RFC 10024) and avoid the procedural risk.

Cross-reference Hybrid KEM Migration.

7. ePrint cluster — lattice cryptanalysis continues to consolidate around (Concealed) ILWE

The week's ePrint cluster — papers that hit the IACR Cryptology ePrint Archive in or near the Oct 10 → Oct 17 window — confirms a two-track lattice-PQC research programme: deployment-protocol (W42: 2026/2480 WireGuard + ML-DSA + ML-KEM) and cryptanalytic surface (W42: 2026/2402 lattice blind-sig break; carry-over 2026/2091 ILWE soft-analytic).

ePrint 2026/2480 Post-Quantum Certificate-Based PSK Provisioning for WireGuard via Mutual TLS, DTLS, and QUIC: Design and Performance Study (Che Hang Ng/Emil Künstner/Bastian Küppers/Theodor Schnitzler/Misha Glazunov — likely academic + industry co-author mix) — presents an architecture that provides WireGuard's resistance against future quantum adversaries. The approach preserves the core protocol, minimizes deployment effort, and adds certificate-based identities to WireGuard peers. PQ resistance is achieved via an external mutually authenticated control channel built on the TLS 1.3 handshake and layered on top of TCP, UDP, or QUIC. Key establishment includes ML-KEM. An auxiliary shared secret is derived from the exported keying material of the resulting session and injected into WireGuard's native Pre-Shared Key (PSK) interface. The control channel is authenticated with X.509 certificates issued by a PKI using ML-DSA for PQ certificate signing. The paper develops a Tamarin model of the composition layer and symbolically analyzes the secrecy, binding, and provisioning-order properties of the interface between TLS 1.3 handshake and WireGuard, identifying the critical conditions necessary for secure deployment. The design is evaluated for handshake latency and CPU time for classical, pure PQ, and hybrid key establishment, classical and ML-DSA certificates, and the three transports, comparing it against an existing PQ WireGuard baseline.

For freedom-tech: this is the first formal Tamarin-verified hybrid PQ + ML-DSA-authenticated WireGuard deployment architecture — directly relevant to mesh networks, decentralized VPN overlays, and any freedom-tech system currently running WireGuard and considering PQ migration. The "external TLS 1.3 control channel + native PSK injection" pattern is reusable for other protocols that lack native PQ negotiation (OpenVPN, IPsec, custom RPC).

ePrint 2026/2402 Revisiting Lattice-based Blind Signatures Again (Yi-Fu Lai + Yu Yu — Shanghai Jiao Tong University, Oct 7) — shows an attack on a lattice-based blind signature proposed at Crypto'20 (the paper cites a 2020 paper but the specific scheme is not named in the abstract). The attack is under the honest key + honest-but-curious signer setting against the blindness notion by exploiting correlations between tree leaves. The paper also discusses how to repair the scheme.

For freedom-tech: blindness breaks of lattice-based blind signatures are rare and the specific weakness (correlations between tree leaves in a hash-function-based framework) is the same class of bug pattern that has hit lattice KEMs in prior work; freedom-tech implementers who use or plan to use lattice-based blind signatures (e.g., for anonymous credentials, e-cash, anonymous attestations, decentralized identity systems) should track this paper.

ePrint 2026/2091 Keep Track of Your Errors: Solving ILWE and Improving Attacks on ML-DSA (ElGhamrawy/Eisenbarth/Hermelink/Rabich/Sieck/Streit/Thietke/Zhang — U-Luebeck/DFKI/MPI-SP/Fraunhofer AISEC/TUM/RUB) — W41 carry-over, published Sept 28, but in scope for the W42 cycle — shows that the number of signatures required for ML-DSA side-channel secret-recovery attacks has been drastically overestimated — distribution hints (Eurocrypt 2025) can be derived from Integer LWE (ILWE) samples and a belief-propagation-based solver recovers the secret key efficiently. In a noise-free attack setting, the approach reduces the average number of signatures required by a factor of 62 — from 139 million to 2.25 million — compared with linear regression, with larger improvements under noise. The paper also analyzes a recently discovered timing leakage in ML-DSA and shows how to solve for the secret key with far fewer signatures.

For freedom-tech: the ML-DSA side-channel threshold for practical key recovery is now in the low millions, not hundreds of millions — comparable to the threshold for ECDSA side-channel key recovery. Implementers must enforce constant-time discipline on every signature operation, not only on the private-key generation step, and masked implementations are required for ML-DSA in production for high-value keys (e.g., firmware signing, code signing, root CA keys).

The Cloudflare ML-KEM measurement that the ePrint 2026/2091 paper cites as "as of August 2026, 59% of Cloudflare's requests use ML-KEM" is the production-deployment benchmark for the W42 cycle — confirms that ML-KEM is the dominant PQ KEM in production TLS traffic and that the ML-KEM side-channel surface is the most consequential PQC attack surface in deployment today.

Cross-reference ML-KEM and ML-DSA.

8. OMB M-26-15 + GSA FICAM cadence — the deadline clock

OMB M-26-15 (June 24, 2026, "Execution of the Migration to Post-Quantum Cryptography") directs every covered civilian agency to submit a PQC Migration Plan to OMB and ONCD within 120 days. That deadline is October 22, 2026 — 5 days out as of this update.

The nine required plan content elements (per the Zscaler analysis and the Quantum XChange breakdown):

1. A risk-based system prioritization strategy
2. Timelines and milestones for each migration phase
3. Testing and deployment timelines to meet the January 2, 2030 TLS 1.3 deadline (the EO 14412 deadline for high-value-asset / high-impact-system key establishment)
4. Inventory methodologies and automated tools
5. A crypto-agile architecture implementation plan
6. A third-party coordination plan
7. Funding and personnel estimates
8. A risk management strategy for the migration period
9. Governance roles and responsibilities

The GSA FICAM PQC working group is the interagency coordination vehicle:

The 5th meeting on Oct 21 (Tuesday) is the last interagency coordination point before the Oct 22 (Wednesday) deadline. The meeting's agenda is not yet public.

17 federal agencies participated in the first meeting per the MeriTalk Aug 24 GSA report and the Quantum Computing Report GSA + Treasury PQC initiatives coverage (citing 40 participants from 17 federal agencies).

GSA's parallel actions (per the Aug 24 MeriTalk article):

• Updating the Federal Identity, Credential, and Access Management (FICAM) architecture to support quantum-resistant algorithms, emphasizing crypto agility — the ability to quickly shift between cryptographic methods
• Expanding the FIPS 201 Evaluation Program (PACS lab) to evaluate quantum-resistant solutions for federal buildings (employee badges, visitor passes, building access controls)
• 2026 Post-Quantum Cryptography Summit on Sept 16 — hybrid event (GSA + industry) for federal migration planning (prior window)

DoW PQC Strategy (dodcio.defense.gov) sets PQC required by December 31, 2031 and CRQC-vulnerable-with-larger-keys phased out December 31, 2030 — NSS follows a separate track under CNSA 2.0 rather than M-26-15.

The M-26-15 deadline (Oct 22) and the IETF-127 final-agenda publication (Oct 23) fall on adjacent days, meaning agency submissions and the IETF final agenda will land within 24 hours of each other. OpenSSL 3.4 EOL is the same day as M-26-15 (Oct 22): agencies still on 3.4 LTS must plan for end-of-life immediately after the M-26-15 deadline lands, or accept unpatched OpenSSL exposure.

For freedom-tech deployers and PQC practitioners: the M-26-15 submission deadline is the single most important federal PQC event of the W42 cycle, and the post-submission public record (whether agencies publish their plans or keep them internal) will be the operative transparency signal for the W43 cycle.

Cross-reference Hybrid KEM Migration and Merkle Tree Certificates.

9. wolfSSL 5.9.1 — ML-KEM default-on, the embedded PQC turning point

wolfSSL 5.9.1 (W41, late August / early September 2026) — ML-KEM (FIPS 203) is now enabled by default in wolfSSL builds. The release also makes the context-aware FIPS 204 ML-DSA (Dilithium) API the default, with the legacy non-context API gated behind WOLFSSL_DILITHIUM_NO_CTX. Sensitive memory buffers in the ML-DSA implementation are now zeroized to prevent leakage of cryptographic material. Private key validation checks were added for Ed25519, Ed448, ML-DSA, and ML-KEM operations. The release also fixed out-of-bounds shift and undefined behavior issues in ML-DSA and SLH-DSA implementations.

22 CVEs addressed across critical, high, medium, and low severity levels, including:

• PKCS7 with ORI callback set or AuthEnvelopedData with AES-GCM (--enable-pkcs7)
• ECDSA certificate verification with EdDSA or ML-DSA enabled
• URI nameConstraints enforcement with intermediate CAs
• X.509 certificate conversion via CertFromX509 with AuthorityKeyIdentifier
• DTLS 1.3 (--enable-dtls13)
• ECH (--enable-ech)
• ECCSI signature verification (--enable-eccsi)
• AES-EAX/CMAC with large messages
• ChaCha20-Poly1305 via EVP or X509_verify_cert via the OpenSSL compatibility layer (--enable-opensslextra)

For freedom-tech embedded / IoT / router / automotive deployers — wolfSSL is a dominant TLS library in routers (Cisco, Juniper, Netgear firmware), IoT firmware (medical devices, smart home, industrial control), automotive (V2X, telematics), embedded Linux (OpenWrt, Buildroot, Yocto), and the ML-KEM default-on + ML-DSA context-aware default + private key validation are the most consequential embedded-side PQC defaults of the 2026 cycle. wolfSSL's ML-KEM default-on is the leading indicator that the embedded-TLS layer is preparing to absorb the M-26-15 + EO 14412 + CNSA 2.0 deadlines.

Brainpool curve support was added to wolfSSL_CTX_set1_sigalgs_list for broader European cryptographic standard compatibility (relevant to the BSI TR-02102 PQC migration profile in Germany). DTLS 1.3 / TLS 1.3 write-dup support was added (Duplicate SSL functionality allows read-side delegation of post-handshake tasks to the write-side).

Cross-reference PQC Deployment and Libraries Tracker.

10. MTC document trail and the "Chrome MTC details this month" trigger

The MTC document trail (per the IETF datatracker):

Correction to the prior W41 note: the MTC document is at -06 (Sept 21, 2026), not -05. The W41 note's "MTC -05 corrected" was itself incorrect; the datatracker page now shows -06 as the current document and the W42-window I-D Action announcement on the plants mailing list on Sept 22 confirms the -06 upload.

The MTC document remains in WG Document state, no shepherd, no AD, no IANA review. The PLANTS WG roadmap (Chrome: MTC CA policy circulated Q2 2026, "more MTC details to be published this month" referring to October 2026) is unchanged. The trigger event for the W43 cycle is the Chrome MTC CA policy publication and the Apple draft MTC policy at the end of October 2026 — both are committed by their respective organizations.

The PLANTS WG (PKI, Logs, And Tree Signatures) has 5 active documents per the datatracker WG page: the main MTC draft, the MTC deployment use cases companion, the MTC profiles draft, the binary transparency tree draft, and the open issues draft. The MTC document trail is the most important public-Web-PKI work in flight in 2026.

Cross-reference Merkle Tree Certificates.

FIPS 206 (FN-DSA / Falcon) silence, CHES 2026 program details, and the ACM CCS 2026 LoTRS paper

FIPS 206 (FN-DSA / Falcon) silence: 43 days and counting

Per the NIST pqc-forum thread, no public-facing material from the FIPS 206 team since Ray Perlner's Sept 4 reply ("we are ready to send out a draft within a few days once it's approved, but we don't really know when that will be"). The most recent public record is the Sept 25, 2025 Perlner presentation at the 6th PQC Standardization Conference (csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon) and the Sept 2025 freenode.net FN-DSA fixed-point math piece. The fixed-point signing design decision (32.32 keygen, 64.64 signing) remains the substantive change operators should plan around. Per the DCNN Magazine Oct 5 "Quantum-ready FN-DSA nears draft approval" coverage, companies such as DigiCert are preparing for FN-DSA's rollout but will not implement FN-DSA in production until the standard is finalized — the same posture as the Encryption Consulting FN-DSA explainer. The IPD is expected in the next 1-2 months; the final FIPS 206 is expected late 2026 / early 2027.

The COSE draft draft-ietf-cose-falcon-04 (Prorock, expired 2026-09-16) has still not been re-uploaded as a -05 in this window — a maintenance concern; operators should verify the document state on the datatracker before relying on the text.

CHES 2026 program and the SEALSQ LightSec 2026 paper

The CHES 2026 program page is JavaScript-only and did not render to text in the harvest window — the full paper list is available as JSON but the per-paper abstracts were not reachable. The CHES 2026 pre-prints cluster (papers appearing in TCHES 2026 or 2027) includes ePrint 2026/2474 (item 2 above).

The SEALSQ LightSec 2026 paper is the single most deployment-relevant PQC paper of the week — the first peer-reviewed third-party confirmation of lattice-standardization side-channel fragility for ML-KEM (comparable to the Bernstein June 2026 "Exploiting ML-DSA bugs" paper for ML-DSA). For freedom-tech: the post-FIPS-203/204 side-channel surface is now formally comparable to classical ECC, and constant-time / masked implementations are required for both ML-KEM and ML-DSA in production.

ACM CCS 2026 LoTRS paper (carry-over)

The ePrint 2026/974 LoTRS: Practical Post-Quantum Structured Threshold Ring Signatures from Lattices (Jagganath/Esgin/Steinfeld/Sakzad/Saarinen/Liu — Monash + Data61 + Tampere + CSIRO) was published in ACM CCS 2026 (in scope for the W42 cycle as a venue marker). LoTRS is the first construction in which a TRS variant is obtained by combining: (i) an aggregated signing layer — a two-round lattice-based multisignature protocol producing an aggregated signature relation, with (ii) a selection-hiding layer — a t-out-of-N proof that hides the chosen ring element supporting that relation. The concrete construction instantiates the aggregated signing layer using the lattice-based scheme from Crypto'23 and the selection-hiding layer from Esgin et al.'s lattice-based one-out-of-many proof (IEEE S&P'22). For freedom-tech: LoTRS is a practical lattice-based threshold ring signature — relevant to group signing for Nostr/Bluesky-style decentralized social networks, multi-signature Bitcoin/Ethereum wallets with ring-anonymity, and DAO governance with ring-anonymized voters.

Federal clock, OMB cycle, and IETF-127 inheritance

The federal PQC clock (W42 cycle)

IETF-127 inheritance

IETF-127 (San Francisco, Nov 14-20, 2026) will inherit:

1. The pure PQ-TLS Blocked state (23 days in this update, 56+ days at IETF-127)
2. The OpenSSL 4.1.0-beta2 DTLS 1.3 security issues (informing TLS WG discussions of post-quantum-aware datagram protocols)
3. The Chrome + Apple MTC commitments (the PLANTS WG session will be the most consequential in the cycle)
4. The GSA PQC interagency working group 5th-meeting-on-day-before-deadline cadence (informing any federal-agency-side presentations)
5. The Cloudflare 59% ML-KEM deployment measurement (informing the TLS WG deployment-data working group discussions)

For freedom-tech deployers attending IETF-127: the PLANTS WG session on Mon Nov 17 (per the standard IETF WG scheduling) is the most relevant session for MTC implementers.

Cryptanalysis ePrints (Oct 10 – Oct 17 window)

Use cases and trade-offs (W42 cycle)

W43 triggers to watch (next week)

• OMB M-26-15 PQC Migration Plan submissions land on Oct 22 (Wed) — first agency submissions may be public, may include the GSA, DoD-adjacent, and small civilian agencies
• Apple draft MTC policy publication — by end of October 2026
• Chrome MTC details — per Q2 2026 commitment "more MTC details to be published this month"
• FIPS 206 (FN-DSA / Falcon) IPD — expected any day; the silence at 43 days is now anomalous
• OpenSSL 4.1.0 final — pushed from October 2026 to a date after the DTLS 1.3 security fixes; W43 may see a beta3 or rc1
• AWS-LC v5.12.0 — if the W41 PR cluster is the candidate, the next stable is in the Oct 24 – Nov 14 window
• liboqs 0.17.0 — if the cadence holds, the next release is in November or December 2026
• NIST WPEC 2026 (Oct 26-29) — second NIST Privacy-Enhancing Cryptography workshop; acceptance lists to publish
• FIPS 'n' Chips FNC2026 (Oct 26-27 Austin TX) — hardware-PQC talks; PQC side-channel work in particular
• GSA FICAM PQC WG 6th meeting (presumed Nov 4) — post-deadline review
• IETF-127 (Nov 14-20 San Francisco) — PLANTS WG session on MTCs; TLS WG session on the Blocked state; SECDIR review of any new PQC drafts

Compiled 2026-10-17 02:00:46 UTC. Sources: AWS Security Blog (Oct 2026), OpenSSL 4.1.0-beta2 release (2026-10-09), openssl-announce (Oct 9 11:43 UTC), IACR ePrint Archive (2026/2091, 2026/2402, 2026/2474, 2026/2480, 2026/974), CHES 2026 + LightSec 2026 programs, Apple Root Program post-quantum policy (Sept 21, 2026), Chrome/Cloudflare MTC coverage (Oct 2026), wolfSSL 5.9.1 release blog, OMB M-26-15 (June 24, 2026), GSA FICAM PQC working group (MeriTalk Aug 24, 2026), SEALSQ LightSec 2026 paper, NIST pqc-forum (FIPS 206 silence), datatracker (IETF MTC, ML-KEM-TLS, ML-DSA-TLS, LAMPS composite), liboqs 0.16.0 (July 9, 2026), oqs-provider 0.10.0 (July 28, 2025), AWS-LC v5.11.0 (Oct 1, 2026), ePrint 2026/2091 (W41 carry-over), the [prior-week note|10-Post-Quantum/Post-Quantum Saturday — October 10 2026 Weekly Update] and the [PQC Deployment and Libraries Tracker].