PQC Deployment and Libraries Tracker

Summary

Post-quantum cryptography has moved from research competition to production deployment. The decisive shift was NIST's 2024 publication of FIPS 203, 204, and 205, which standardized ML-KEM, ML-DSA, and SLH-DSA. By 2026, the practical state is uneven but no longer hypothetical:

• Key exchange is real in production. TLS 1.3 hybrid key exchange, especially X25519MLKEM768, is deployed by Cloudflare, Google-facing stacks, Go 1.24+ programs, OpenSSL 3.5-based stacks, and modern browsers / CDNs. OpenSSH has shipped PQ hybrid KEX by default since 9.0, first with sntrup761x25519-sha512, then with mlkem768x25519-sha256 in OpenSSH 10.x. RFC 10024 (PQ/T hybrid key agreement for TLS 1.3, ex-draft-ietf-tls-ecdhe-mlkem) published August 2026 as Proposed Standard (Kwiatkowski / Kampanakis / Westerbaan / Stebila; AD Paul Wouters) — cite this, not the draft, in migration docs.
• Messaging led early. Signal deployed PQXDH in 2023; Apple deployed iMessage PQ3 in 2024. Both use hybrid designs rather than pure PQ trust.
• Signatures are the laggard. PQ signatures are standardized, but public Web PKI, code signing, package repositories, hardware attestation, blockchain signatures, and long-lived identity keys remain mostly classical. This matters because authentication failures are not only future risks; they affect whether a recorded handshake or signed artifact can be trusted later.
• Libraries are mature enough for integration, not for complacency. liboqs, oqs-provider, PQClean, CIRCL, RustCrypto KEMs, Go's standard library, Bouncy Castle, OpenSSL 3.5, and AWS s2n-tls provide usable building blocks. The risk is choosing obsolete pre-standard Kyber/Dilithium parameter names, non-constant-time code, or a stack that quietly falls back to classical crypto.
• The migration pattern is hybrid + crypto-agility. For 2026 deployments, hybrid KEMs are the safest default: combine X25519 or another classical primitive with ML-KEM, feed both secrets into a transcript-bound KDF, and keep algorithm negotiation upgradeable.

For ungovernable infrastructure, the immediate priorities are: enable hybrid TLS and SSH where available; inventory long-secrecy data stores; migrate encrypted backups and source-protection workflows; avoid exposing blockchain public keys before spend; and pressure wallet, mesh, attestation, and decentralized identity systems to publish explicit PQ roadmaps.

Historical context

1994-2015: the warning phase

Shor's algorithm showed that a large fault-tolerant quantum computer would break RSA, finite-field Diffie-Hellman, DSA, and elliptic-curve cryptography. For years the problem was academically obvious but operationally distant. Symmetric primitives such as AES and hash functions were less threatened: Grover's algorithm changes security margins, but AES-256 and SHA-256-family choices are broadly viable.

2016-2024: NIST standardization

NIST launched its post-quantum standardization project in 2016. The competition created a public cryptanalytic gauntlet: lattice KEMs, lattice signatures, code-based schemes, hash-based signatures, multivariate signatures, isogeny systems, and MPC-in-the-head designs were proposed, attacked, optimized, and culled.

The cautionary story is SIKE: an isogeny-based finalist was dramatically broken in 2022. The lesson is not "PQC is unsafe" but "hybrid deployment is prudent while cryptanalytic confidence matures." This is why production systems generally combine classical and PQ primitives.

On August 13, 2024, NIST approved three FIPS standards:

NIST is also standardizing FN-DSA Falcon for compact signatures and selected HQC in 2025 as a code-based backup KEM to diversify away from a single ML-KEM family.

2024-2026: deployment phase

The deployment phase is defined by libraries and defaults rather than papers. Go 1.24 introduced standard-library crypto/mlkem and made hybrid TLS key exchange part of the default curve preferences. OpenSSL 3.5 added ML-KEM, ML-DSA, and SLH-DSA. Ubuntu 25.10 / 26.04-era systems expose those capabilities to ordinary applications such as curl, nginx, OpenSSH, wolfSSL, rustls, and Libgcrypt. Cloudflare reports large-scale hybrid TLS use and targets full PQ security, including authentication, by 2029.

Evidence at a glance

Major implementations and libraries

Open Quantum Safe: liboqs and oqs-provider

• Repository: https://github.com/open-quantum-safe/liboqs
• OpenSSL provider: https://github.com/open-quantum-safe/oqs-provider
• Maturity check, 2026-05-02 via GitHub API: open-quantum-safe/liboqs was active, not archived, ~2.9k stars, C, pushed 2026-05-01. oqs-provider was active, not archived, ~470 stars, pushed 2026-04-30.

liboqs remains the central prototyping and interoperability library for many PQ experiments. It is not simply a "use in production blindly" library; its value is breadth, test vectors, benchmarking, bindings, and integration with TLS/OpenSSL experiments. The older open-quantum-safe/openssl fork is deprecated/archived; new work should use OpenSSL 3's provider model through oqs-provider or native OpenSSL 3.5+ support where available.

Use when: testing algorithm support, benchmarking, building prototypes, integrating non-default PQ algorithms, or tracking NIST round candidates.

Avoid when: a system already has a well-maintained native implementation in its language runtime or TLS library. Prefer the platform default when it is current and audited.

OpenSSL 3.5+ (GA March 2026)

• Release planning / announcement: https://openssl-library.org/post/2025-02-04-release-announcement-3.5/
• Core support: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205).
• Practical impact: any OpenSSL-backed program can negotiate or use PQ algorithms once built against 3.5+ and configured correctly. Ubuntu 26.04 LTS and derivative distributions expose PQ through the standard OpenSSL interface — curl, nginx, haproxy, and any linked program inherit PQ capability without application-level changes.
• Signature API: EVP_SIGNATURE-SLH-DSA man page documents the SLH-DSA signing interface.
• EVP_SIGNATURE-ML-DSA and EVP_KEM-MLKEM similarly for the other standards.

OpenSSL 3.5 is the inflection point for mainstream server administrators. Before OpenSSL 3.5, PQ TLS often meant BoringSSL, Cloudflare-specific stacks, patched forks, or OQS experiments. With 3.5, distributions can expose NIST-standard algorithms through ordinary package lifecycles.

Trade-off: support in the library does not guarantee end-to-end PQ security. You still need protocol support, group configuration, client support, and no middlebox breakage.

Go standard library and CIRCL

• CIRCL repository: https://github.com/cloudflare/circl
• Go TLS issue / implementation discussion: https://github.com/golang/go/issues/69985
• Go source defaults: https://go.dev/src/crypto/tls/defaults.go

Go is unusually important because so much cloud-native infrastructure, Kubernetes tooling, relays, agents, reverse proxies, and decentralized infrastructure are written in Go. Go 1.24 added ML-KEM support and default hybrid TLS preferences around X25519MLKEM768. That means many services inherit PQ-capable TLS merely by rebuilding on a recent toolchain, provided their TLS configuration does not override curve preferences.

CIRCL is Cloudflare's Go cryptographic library and has been a key implementation bed for PQ experiments, including KEMs, signatures, HPKE-related work, and pairing/zk primitives.

Operational caveat: Go services that explicitly set CurvePreferences can accidentally disable the default hybrid group. Audit custom TLS configs.

Meta's PQC migration framework (April 2026)

Meta's engineering blog published the most detailed hyperscaler PQC migration account to date in April 2026:

• PQC Migration Levels: a 5-level maturity ladder (PQ-Unaware → PQ-Aware → PQ-Ready → PQ-Hardened → PQ-Enabled). Most organizations are PQ-Aware or below.
• Six-step methodology: Prioritization (offline HNDL vs online Shor's attack); cryptographic inventory (automated discovery + developer reporting); external dependency mapping (standards, hardware, library maturity); PQC-secure component design; phased rollout; guardrails and monitoring.
• Key insight: Meta classifies applications by susceptibility to offline attacks (key exchange, where harvest-now-decrypt-later applies) versus online attacks (digital signatures, requiring a working CRQC). This distinction drives prioritization.
• Meta reports reaching PQ-Enabled for portions of internal traffic, demonstrating production-scale deployment is operationally tractable.
• Meta cryptographers are co-authors of HQC, signalling that assumption diversity (lattice + code-based) is part of serious migration strategy, not just academic interest.

PQClean and generated bindings

• Repository: https://github.com/PQClean/PQClean
• Maturity check, 2026-05-02: active, not archived, ~900 stars, C, pushed 2026-01-09.

PQClean provides clean, portable C implementations with a consistent API and test discipline. Many language bindings and packages derive from PQClean metadata and source trees. It is valuable as a bridge from academic implementations to auditable, portable code.

Use when: comparing implementations, generating bindings, or needing simple C implementations for embedded experimentation.

Caveat: clean portability is not the same as hardened side-channel resistance on every target. Hardware leakage analysis is workload- and architecture-specific.

Rust ecosystem

• RustCrypto KEMs: https://github.com/RustCrypto/KEMs
• ml-kem crate: https://lib.rs/crates/ml-kem
• rustpq/pqcrypto: https://github.com/rustpq/pqcrypto

Rust now has multiple PQ paths. RustCrypto's KEM work provides pure-Rust implementations aligned with the wider RustCrypto traits. rustpq/pqcrypto wraps/generates from PQClean. Which one to use depends on whether the project values pure Rust/no-std integration, compatibility with PQClean, audit status, or ecosystem fit.

Operational caveat: Rust cryptography projects move quickly. Pin versions, read changelogs for parameter-name changes, and avoid stale pre-standard Kyber crates when building new systems.

BoringSSL, AWS s2n-tls, rustls, wolfSSL, Bouncy Castle

• BoringSSL is the browser/Google deployment path for hybrid TLS.
• AWS s2n-tls is actively maintained and used in AWS infrastructure: https://github.com/aws/s2n-tls
• rustls has PQ support paths influenced by provider and backend choices.
• wolfSSL and Libgcrypt are appearing in distribution PQ support matrices.
• wolfSSL CVE-2026-5194 (critical, April 2026): wolfSSL v5.9.1 patched a critical vulnerability in ML-DSA (and ECDSA/EdDSA) signature verification: missing hash/digest size and OID checks allowed undersized digests to be accepted. Reported by Nicholas Carlini (Anthropic). Affects any wolfSSL build with both ECC and ML-DSA enabled doing certificate verification. Deployments using wolfSSL for PQ certificate validation should update immediately. See: https://github.com/advisories/GHSA-f5h9-5q52-qrx7
• Bouncy Castle provides broad Java PQ algorithm coverage and is relevant for enterprise and Android-adjacent systems.

For decentralized infrastructure projects, the key question is not "does a PQ algorithm exist?" but "does the exact runtime and TLS library used by my relay, node, gateway, or wallet negotiate a hybrid group by default?"

Protocol and platform deployments

TLS 1.3

TLS is the most mature high-volume PQ deployment surface. X25519MLKEM768 is the dominant hybrid group because it composes a classical X25519 secret with an ML-KEM-768 shared secret. The system remains safe if either side of the hybrid remains secure.

Cloudflare's public docs describe PQ support for TLS 1.3 and HTTP/3, note that PQ key agreements are disabled for websites in FIPS mode, and state a target of full PQ security across its product suite by 2029. Its docs also distinguish visitor-to-Cloudflare, internal Cloudflare traffic, and Cloudflare-to-origin traffic. This distinction matters: a site can be PQ-secure from browser to CDN but classical from CDN to origin unless origin connectivity is upgraded.

Ungovernable use cases: public relays, Nostr relays, coordination servers, package mirrors, gateways, WebRTC signaling servers, LLM inference APIs, self-hosted dashboards, and federation endpoints.

Verification pattern: use a recent client and check negotiated groups, e.g. OpenSSL 3.5 s_client, recent curl -v, Cloudflare's PQ test endpoint, or browser security instrumentation. Do not assume support from version strings alone.

SSH

OpenSSH has been ahead of most infrastructure. Its PQ page says OpenSSH has offered PQ key agreement by default since 9.0 in April 2022, initially via sntrup761x25519-sha512. mlkem768x25519-sha256 was added in OpenSSH 9.9 and became the default in OpenSSH 10.0 (April 2025). This protects against store-now-decrypt-later for SSH session key establishment.

Important limitation: SSH KEX migration does not automatically migrate host keys or user authentication keys. Ed25519/RSA host keys are still quantum-vulnerable signatures. For most users, confidentiality of captured sessions improves before authentication becomes PQ.

End-to-end messaging

Signal's PQXDH specification extends X3DH with a post-quantum KEM component. The security goal is hybrid initial key agreement: compromising only the classical curve side or only the PQ side should not reveal the shared secret. Formal analyses have examined PQXDH using tools such as ProVerif and CryptoVerif.

Apple's PQ3 for iMessage goes further than one-time initial PQ key agreement by adding post-quantum ratcheting. The IACR ePrint formal analysis of PQ3 is a useful primary research artifact for evaluating its claims.

Ungovernable relevance: messaging systems show that PQ migration can be hidden under product UX. Protocols like Overview - Encrypted Messaging, Nostr DMs, Matrix, SimpleX, Cwtch, and off-grid messengers need similar migration strategies but must balance packet sizes, asynchronous delivery, and identity persistence.

VPNs, IPsec, WireGuard, and overlays

VPN migration is mixed. IPsec/IKEv2 has RFC and draft work for post-quantum shared keys / KEMs. Cloudflare documents PQ IPsec and Cloudflare One Appliance deployment paths. WireGuard's base protocol remains Curve25519-centric; product-specific approaches either layer PQ in control planes or use out-of-band pre-shared secrets.

Pragmatic pattern: for high-stakes overlays, use hybrid TLS control channels and regularly rotated symmetric PSKs while native PQ WireGuard remains unsettled. For Overview - Off-Grid Networks, packet-size and bandwidth constraints make ML-KEM feasible for setup but not free.

Operating systems and distributions

Ubuntu 25.10 and the 26.04 LTS line are a visible example of PQ becoming a distribution default: OpenSSL 3.5, OpenSSH 10.0+, and libraries such as wolfSSL/rustls/Libgcrypt expose PQ-capable paths. The Ubuntu Discourse article demonstrates curl negotiating TLSv1.3 / ... / X25519MLKEM768 against a Cloudflare PQ test endpoint on a modern stack. This matters because most self-hosters do not hand-compile cryptographic libraries. PQ adoption accelerates once distro defaults carry it into normal package management.

Criminal adoption: Kyber ransomware

The Kyber ransomware family (active since September 2025, confirmed by Rapid7 in April 2026, Ars Technica reporting April 23, 2026) is the first confirmed criminal use of NIST-standardized post-quantum cryptography. It deploys ML-KEM-1024 alongside X25519 (classical) and AES-256-CTR for bulk encryption — a hybrid scheme similar to production defender deployments. The dual-layer approach means even a future quantum computer would need to break both layers. Rapid7's Anna Širokova noted the ML-KEM implementation required "relatively little work" given liboqs availability. The operational implication: PQ is no longer a theoretical concern exclusive to defenders — it is in the adversary toolkit, making attribution harder and underscoring that PQ is operationally neutral technology.

Migration priorities by system type

Trade-offs and failure modes

Larger handshakes and signatures

ML-KEM is compact by PQ standards but still much larger than X25519. ML-DSA signatures are measured in kilobytes, and SLH-DSA can be much larger/slower. This affects TLS ClientHello size, certificate chains, DNS records, QR-code key exchange, LoRa/mesh links, blockchain transactions, package metadata, and firmware update channels.

Silent downgrade and false confidence

Many stacks advertise PQ capability but negotiate classical crypto because of old peers, FIPS mode, custom curve preferences, TLS termination at a CDN, or middleboxes. A system is not PQ-secure because a library supports ML-KEM; it is PQ-secure only if the actual connection negotiated a hybrid or PQ group on every relevant segment.

Pre-standard algorithm names

Old code often refers to Kyber and Dilithium rather than ML-KEM and ML-DSA. Some pre-final parameters or encodings differ from the FIPS standards. New systems should prefer final FIPS names and implementations unless compatibility with a specific older deployment is required.

Side channels and constant-time behavior

PQC does not remove implementation risk. Lattice schemes have decapsulation, rejection, sampling, and arithmetic paths that must avoid secret-dependent timing and memory access. Embedded and hardware-backed implementations need separate leakage evaluation.

Authentication is harder than encryption

Hybrid KEMs can be added to a handshake without changing human-visible identities. PQ signatures are harder: certificates, public keys, fingerprints, package signatures, blockchain addresses, and WoT identities are all socially embedded. That is why key exchange is ahead and signatures lag.

August 2026 update: IETF 126 standardization milestones

Additional August 2026 milestones: - Go 1.27: ML-DSA added to standard library (crypto/mldsa). - CISA PQC Product Categories (July 23, 2026): Operationalizes EO 14412 procurement requirements. - Cloudflare ML-DSA timeline: hybrid ML-DSA cert standard July 2026; ML-DSA-in-TLS RFC August 2026; first WebPKI certs early 2027. - GRI Threat Survey: 28–49% CRQC probability within 10 years (record high).

See Merkle Tree Certificates and Post-Quantum Saturday — August 01 2026 Weekly Update for full details.

Primary sources and documentation

• NIST FIPS approval announcement: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
• NIST PQC project: https://csrc.nist.gov/projects/post-quantum-cryptography
• FIPS 203 ML-KEM: https://csrc.nist.gov/pubs/fips/203/final
• FIPS 204 ML-DSA: https://csrc.nist.gov/pubs/fips/204/final
• FIPS 205 SLH-DSA: https://csrc.nist.gov/pubs/fips/205/final
• FIPS 206 FN-DSA (Falcon) IPD: https://csrc.nist.gov/pubs/fips/206/ipd
• Open Quantum Safe liboqs: https://github.com/open-quantum-safe/liboqs
• OQS OpenSSL provider: https://github.com/open-quantum-safe/oqs-provider
• PQClean: https://github.com/PQClean/PQClean
• CIRCL: https://github.com/cloudflare/circl
• RustCrypto KEMs: https://github.com/RustCrypto/KEMs
• rustpq/pqcrypto: https://github.com/rustpq/pqcrypto
• OpenSSL 3.5 release announcement: https://openssl-library.org/post/2025-02-04-release-announcement-3.5/
• OpenSSL PQC integration (ICMC 2026): https://openssl-corporation.org/files/ICMC2026-PQC.pdf
• Cloudflare PQC docs: https://developers.cloudflare.com/ssl/post-quantum-cryptography/
• Cloudflare 2029 roadmap: https://blog.cloudflare.com/post-quantum-roadmap/
• Cloudflare Radar (live stats): https://radar.cloudflare.com/post-quantum
• OpenSSH PQ page: https://www.openssh.com/pq.html
• Go TLS ML-KEM issue: https://github.com/golang/go/issues/69985
• Signal PQXDH specification: https://signal.org/docs/specifications/pqxdh/
• Apple iMessage PQ3: https://security.apple.com/blog/imessage-pq3/
• PQ3 formal analysis: https://eprint.iacr.org/2024/1395
• Meta PQC Migration Framework: https://engineering.fb.com/2026/04/16/security/post-quantum-cryptography-migration-at-meta-framework-lessons-and-takeaways/
• Ars Technica — Kyber ransomware: https://arstechnica.com/security/2026/04/now-even-ransomware-is-using-post-quantum-cryptography/
• AWS Secrets Manager PQ TLS: https://aws.amazon.com/about-aws/whats-new/2026/04/aws-secrets-manager-post-quantum-tls/
• AWS PQC migration page: https://aws.amazon.com/security/post-quantum-cryptography/migrating-to-post-quantum-cryptography/
• PQCC international requirements: https://pqcc.org/international-pqc-requirements/
• Ubuntu PQ support in 26.04-era stack: https://discourse.ubuntu.com/t/post-quantum-support-in-the-upcoming-26-04-lts/76840
• NIST IR 8528 (HQC selection): https://vlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8528.pdf

Open questions

• ~~When will Web PKI deploy PQ or hybrid certificate chains without unacceptable size and compatibility costs?~~ Partially answered (August 2026): Merkle Tree Certificates (Let's Encrypt staging late 2026, production 2027; Chrome preferred approach; PLANTS WG Last Call) provide the PQ Web PKI path. Composite ML-DSA certs (LAMPS WG Last Call, RFC Q4 2026) provide the enterprise PKI path. See Merkle Tree Certificates. Open question becomes: will browsers support both simultaneously?
• Which decentralized identity systems will define key-transition proofs that preserve pseudonymous reputation without making users deanonymize?
• Will blockchain ecosystems converge on hash-based, lattice-based, or STARK/account-abstraction migration paths?
• How should off-grid and low-bandwidth systems amortize PQ handshakes across intermittent links?
• Will major TEE vendors publish PQ attestation timelines before CRQC risk becomes operationally urgent?
• How will CISA's PQC Product Categories (July 23, 2026) reshape vendor roadmaps for networking hardware, HSMs, and email systems in the "transitioning" category?

Standardization state, verified 2026-09-26

Library state, 2026-09-26

Cryptanalysis ePrints (Sept 19–25 window)

Federal clock

See Post-Quantum Saturday — September 26 2026 Weekly Update for sourcing and analysis.

Library state, 2026-10-10 (status check)

Cryptanalysis ePrints (Sept 26 – Oct 10 window)

No first-line PQC cryptanalysis paper published in the Oct 3 → Oct 10 IACR ePrint window that breaks or weakens ML-KEM / ML-DSA / SLH-DSA / Falcon deployments. The week is a "between-cycles" week for cryptanalysis — the IACR ePrint Archive shows fresh papers but none with direct PQC-primitive cryptanalytic impact.

Hardware-PQC (CHES 2026 anchors)

• Electronics 2026, 15(2), 475 "Lattice-Based Cryptographic Accelerators for the Post-Quantum Era" — survey of FPGA/ASIC implementations; 18.7× energy-efficiency gain at >50,000-unit volumes for ASIC lattice-PQ vs general-purpose CPU; cites both mlkem-native v2.0.0 (Aug 7) and mldsa-native v2.0.0 (Aug 7) as the canonical software anchors. Most current hardware-PQC survey.
• IACR CHES 2026 (Oct 11-15, Antalya) opens 1 day after this update — hardware-PQC primary venue; side-channel mitigations for ML-KEM / ML-DSA on FPGAs and ASICs.

Federal clock (refreshed 2026-10-10)

Sept 26 → Oct 10 deltas (week-over-week deltas vs. the Sept 26 base)

• AWS-LC v5.10.0 → v5.11.0 (Oct 1) — ML-KEM BMI2+AVX2 gate (correctness), FIPS 3.x EOS to Feb 2030, KEM EVP_PKEY_check APIs (PR #2709)
• OpenSSL 4.1.0-beta1 (Sept 23) — unchanged through W41; final October 2026 target remains
• liboqs 0.16.0 — unchanged through W41
• oqs-provider — unchanged through W41
• draft-ietf-tls-mlkem-11 and draft-ietf-tls-mldsa-06 — unchanged (Blocked under Sept 24 appeal); +16 days blocked
• draft-ietf-lamps-pq-composite-sigs — unchanged (Awaiting Second editor from Sept 23); +17 days in state
• draft-ietf-plants-merkle-tree-certs-05 — unchanged; no -06 visible in W41
• draft-ietf-cose-falcon-04 — unchanged (expired Sept 16); no -05
• FIPS 206 — unchanged (NIST silence); +36 days since last Perlner post

See Post-Quantum Saturday — October 10 2026 Weekly Update for the W41 detailed analysis and Post-Quantum Saturday — October 03 2026 Weekly Update for the W40 cycle (the prior week).

Library state, 2026-10-17 (status check, refreshed)

Cryptanalysis ePrints (Oct 10 – Oct 17 window)

The week's cryptanalysis headline is the lattice-standardization side-channel reality check — the ePrint 2026/2091 ILWE soft-analytic paper (139M → 2.25M signatures) and the SEALSQ LightSec 2026 paper on ML-KEM key-generation encoding side-channel together establish that both lattice-based NIST standards (ML-KEM and ML-DSA) carry side-channel fragility comparable to classical ECC in adversary cost, an order-of-magnitude change from pre-2026 expectations. For freedom-tech deployers: constant-time + masked implementations are required for both ML-KEM and ML-DSA in production, not only in HSM contexts.

IACR CHES 2026 + LightSec 2026 anchors (Oct 11-15 Antalya)

• SEALSQ "Cross-information lattice attack on ML-KEM" at LightSec 2026 (Oct 11, affiliated event of CHES 2026) — peer-reviewed paper; combines profiling-based techniques with lattice reduction against the ML-KEM key-generation encoding step; recovers sensitive information under realistic conditions; pairs the attack with practical countermeasures; complements SEALSQ's QS7001 secure element (Common Criteria EAL5+ in progress). First third-party confirmation of lattice-standardization side-channel fragility for ML-KEM.
• Electronics 2026, 15(2), 475 "Lattice-Based Cryptographic Accelerators for the Post-Quantum Era" — W41 carry survey of FPGA/ASIC implementations; 18.7× energy-efficiency gain at >50,000-unit volumes for ASIC lattice-PQ vs general-purpose CPU; cites both mlkem-native v2.0.0 and mldsa-native v2.0.0 as canonical software anchors. Most current hardware-PQC survey.
• ePrint 2026/2474 (TCHES 2027) — first NTT acceleration on AMD AI Engine NPUs.

Federal clock (refreshed 2026-10-17)

Oct 10 → Oct 17 deltas (week-over-week vs. the W41 base)

• AWS-LC v5.11.0 — unchanged through W42 (16 days current, +7d from W41)
• OpenSSL 4.1.0-beta1 → 4.1.0-beta2 (Oct 9, in-window) — first pre-release with DTLS 1.3 (RFC 9147) + ppc64le ML-DSA/ML-KEM NTT + AVX-512 SHAKE x4 + AVX-512/VAES AES-CBC; 2 known DTLS 1.3 security issues force beta2 not final; 4.1.0 final pushed beyond October 2026
• OpenSSL 4.2 master — MLKEM512X25519 + SecP256r1MLKEM512 hybrid TLS KEMs (draft-rosomakho) + fips-indicator gettable context parameter for the 4.x FIPS 140-3 module + ASCON-AEAD128 (NIST SP 800-232) added
• liboqs 0.16.0 — unchanged through W42 (100 days current, +7d from W41)
• oqs-provider — unchanged through W42 (477 days as stable tag, +7d from W41)
• wolfSSL — 5.9.1 ships (W41 release, in window) — ML-KEM default-on + context-aware ML-DSA API default + 22 CVEs
• draft-ietf-tls-mlkem-11 and draft-ietf-tls-mldsa-06 — unchanged (Blocked under Sept 24 appeal); +23 days blocked
• draft-ietf-lamps-pq-composite-sigs-19 (Ounsworth et al, April 2026) — expires 23 October 2026 (6 days out); still in RFC Editor "Awaiting Second editor" state from Sept 23; +24 days in state; companion draft-ietf-lamps-cms-composite-sigs expires 23 November 2026
• draft-ietf-plants-merkle-tree-certs-05 → -06 (Sept 21, 2026) — correction: the prior W41 "MTC -05" note was itself wrong; the datatracker page now shows -06 as the current document; still in WG Document state, no shepherd, no AD, no IANA review
• draft-gray-plants-mtc-deploy-use-cases-01 — unchanged (revision 2026-09-02; last updated 2026-09-18); expires 6 March 2027
• draft-ietf-cose-falcon-04 — unchanged (expired Sept 16); no -05
• FIPS 206 — unchanged (NIST silence); +43 days since last Perlner post
• Apple MTC commitment (Sept 21, in scope) — draft MTC policy end of October 2026; 3 cosignatures + 7-day validity + FIPS 140-3 L3 HSMs
• AWS Security Blog "Quantum-resistant signing on AWS" Part 1 — first end-to-end cloud-provider ML-DSA supply-chain guide
• IACR CHES 2026 (Oct 11-15 Antalya) + LightSec 2026 (Oct 11) — SEALSQ "Cross-information lattice attack on ML-KEM" peer-reviewed paper

See Post-Quantum Saturday — October 17 2026 Weekly Update for the W42 detailed analysis and Post-Quantum Saturday — October 10 2026 Weekly Update for the W41 cycle (the prior week).

Primary sources

• OpenSSH post-quantum defaults

Continue with Build a post-quantum cryptographic inventory.