cloudparts

Post-Quantum Cryptography Alliance

The Linux Foundation’s fund for open-source post-quantum cryptography: it hosts Open Quantum Safe, the PQ Code Package, CBOMkit and Longfellow ZK, paid for by members led by AWS, Cisco, Google and IBM.

2 projects in this catalogPart of the Linux FoundationWebsite

What it is

The Linux Foundation launched the Post-Quantum Cryptography Alliance (PQCA) on 6 February 2024 with eleven founding members: AWS, Cisco, Google, IBM, IntellectEU, Keyfactor, Kudelski IoT, NVIDIA, QuSecure, SandboxAQ and the University of Waterloo. Its stated aim is to be a central home for organisations and projects that need production-ready post-quantum libraries, to help them line up with the US NSA’s CNSA 2.0 timeline, and to make cryptographic algorithms easier to swap. It started with two projects, Open Quantum Safe, founded at Waterloo in 2014, and the new PQ Code Package. By October 2026 its members page listed four Premier members (AWS, Cisco, Google and IBM), twelve General members, among them Hewlett Packard Enterprise, Meta, SandboxAQ, Thales and Trail of Bits, and fourteen Associate members, including the University of Waterloo, MIT Connection Science and the US General Services Administration.

Like the GraphQL Foundation, the PQCA is a fund inside the Linux Foundation rather than a separate non-profit. A Governing Board of members sets the budget and priorities, and a Technical Advisory Council (TAC) coordinates the projects: one representative from each Premier member, up to seven, one academic or research representative, and representatives of eligible projects. The TAC elects a chair each year, who also sits on the board. Each project is a series of LF Projects with its own technical charter and steering committee, and contributing projects hand their name and accounts to the Linux Foundation; Open Quantum Safe’s steering committee, for example, includes people from Cisco, IBM Research, Microsoft Research and Waterloo.

The badge says a project is vendor-neutral and openly governed, not that it is ready to protect production data. The alliance deliberately hosts both research and production code: Open Quantum Safe’s liboqs carries dozens of candidate algorithms and warns against production use, while the PQ Code Package writes formally verified implementations of the NIST standards that AWS-LC and other libraries ship. The TAC adopted a lifecycle with stages for each track in August 2024, but as of October 2026 neither the alliance’s project page nor the projects’ own pages show which stage a project is in, so read each project’s README for its status.

Its projects in this catalog

In depth

Projects#

The four projects listed on pqca.org in October 2026. Only the first two produce cryptographic primitives.

ProjectWhat it doesWhere it came from
Open Quantum Safeliboqs, a C library of post-quantum KEMs and signatures for prototyping and research, plus oqs-provider for OpenSSL 3, demos and language wrappersFounded at the University of Waterloo in 2014 by Michele Mosca and Douglas Stebila; founding PQCA project in February 2024
PQ Code PackageHigh-assurance, formally verified implementations of standard algorithms: mlkem-native, mldsa-native and slhdsa-c, plus Rust and Jasmin workCreated for the PQCA’s launch in February 2024, starting with ML-KEM
CBOMkitTools to build and analyse cryptographic bills of materials (CBOMs), such as a SonarQube plugin that finds cryptography in source code (Go support was added in 2026), to inventory what needs migratingProposed by IBM maintainers in October 2025, Apache 2.0, onboarding completed on 4 December 2025; it asked to start in the Incubation stage
Longfellow ZKA zero-knowledge proof library for existing identity formats (ISO mdoc, JWT and W3C Verifiable Credentials), so a wallet can prove a fact such as age without revealing the credentialOpen-sourced by Google in 2025 and donated to the PQCA on 2 September 2026

The lifecycle on paper#

The TAC approved a project lifecycle policy on 28 August 2024. Projects join one of two tracks, can switch with TAC approval, and every move between stages needs a two-thirds TAC vote.

Experimentation

Research track

Research code that is, or could become, important to post-quantum cryptography, from a fresh paper’s implementation to a long-lived tool with few maintainers. No requirements on community size; minimal foundation support.

Labs

Research track

Long-term research code with a large maintainer community and academic impact: at least five governing members with no more than a third from one employer, documented governance, a stable API and a list of research users. It gets a binding vote on the TAC.

Incubation

Production track

An early or small production project. Users are told to evaluate it carefully, since the stage sets no requirements on community, governance or production readiness.

Growth

Production track

A project with a growth plan, at least two independent production users, a steady flow of contributions and a stable API, expected to move on within two years.

Impact

Production track

Mature, widely used in enterprise production, with diverse maintainers, published adopters, release and long-term support plans, and a documented security policy, threat model and audit history. It gets a binding vote on the TAC.

Emeritus

Either track

Projects at or near end of life: the foundation keeps the name and domains, but the project is not actively developed and may only get security fixes.

What the TAC works on#

The TAC meets every two weeks in public and keeps its minutes on GitHub. Its 2026 chair is Aditya Koranga, and in October 2026 its roster of eight included representatives from Amazon, Cisco, Google, IBM, NVIDIA and zeroRISC. Besides admitting projects it runs working groups, first proposed in 2024 for algorithms, tooling, documentation and security, a blog with its own review process, and LFX mentorships, such as one in 2026 to add languages to CBOMkit.

In April 2026 the TAC voted to start a readiness tracking working group, proposed by Google, to build a vendor-neutral, crowdsourced record of which versions of cryptographic libraries and common open-source projects support post-quantum algorithms, so organisations know what they need to upgrade to.

Where it came from2014–2026

Open Quantum Safe had been the main open-source test bench for post-quantum algorithms since 2014, with contributors from Cisco, IBM, Microsoft Research and others, while NIST ran its competition. With the first NIST standards expected in 2024, companies that would have to ship them wanted a neutral place to build shared, high-quality implementations. On 6 February 2024 the Linux Foundation announced the PQCA, with Open Quantum Safe finding what the announcement called a permanent home, and the PQ Code Package started to write production-grade code for the coming standards, beginning with ML-KEM.

The first year went on structure. The TAC formed in spring 2024, took proposals for working groups, and on 28 August 2024 approved the project lifecycle with its separate research and production tracks. The PQ Code Package released the first alpha of mlkem-native in December 2024 and v1.0.0 in June 2025; by then liboqs and AWS’s AWS-LC had both adopted it.

From late 2025 the alliance grew beyond algorithm code. IBM’s CBOMkit, tools for inventorying cryptography, became a project in late 2025, the TAC set up a readiness tracking working group in April 2026, and on 2 September 2026 Google donated its Longfellow zero-knowledge proof library for digital identity, saying it wanted vendor-neutral stewardship so others could trust, audit and adopt it.

Why it’s built this way

A fund inside the Linux Foundation
Using the LF’s directed-fund model gave members a governing board, legal home and staff from day one, while each project keeps its own charter and steering committee.
Separate research and production tracks
Prototyping libraries like liboqs and verified production code like mlkem-native have different goals, so the lifecycle judges each against the right bar instead of one maturity ladder.
Implement standards, don’t choose them
Algorithm selection stays with NIST and other standards bodies; the alliance’s mission is software that helps adopters meet timelines such as CNSA 2.0.
Formal verification for production code
Subtle bugs and timing leaks are the main risk in new cryptographic code, so the PQ Code Package proves its C and assembly correct rather than relying on testing alone.

Timeline

  1. 2014

    Open Quantum Safe founded at the University of Waterloo

  2. 2024

    PQCA launched on February 6 with eleven founding members; lifecycle policy approved August 28

  3. 2025

    mlkem-native v1.0.0 (June); CBOMkit proposed in October, onboarded by December 4

  4. 2026

    Readiness tracking working group approved (April); Google donates Longfellow ZK (September 2)

Sources · facts checked 2026-10-28

Improve this page on GitHub