The National Institute of Standards and Technology settled the theoretical half of the post-quantum cryptography problem in August 2024, when it finalized three standards: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a hash-based signature backup. That milestone answered the question of which mathematical constructions can resist attacks from a sufficiently powerful quantum computer. It did not answer a separate, less glamorous question: whether the software libraries that developers actually use to implement these algorithms are ready for production systems that must run for years without failure.
That second question is what a new audit of nine post-quantum cryptography libraries, current as of September 2026, sets out to answer. Rather than inventing its own criteria, the methodology anchors nine evaluation dimensions to external, pre-existing requirements - the CNSA 2.0 suite mandated for US national security systems, the CMVP validation process run by NIST and its Canadian counterpart, a market survey from the Dutch research organization TNO, and an IETF draft on hybrid key-exchange combiners. The point of anchoring to outside standards rather than self-selected ones is that the library built to accompany the audit, called quantum-safe, cannot grade itself a winner by picking favorable metrics. It does not. Developers evaluating these tools for real deployments, much as they would when comparing DNS leak protection across competing VPN services, need criteria set independently of the product being judged. DNS leak protection
Where the Production Gap Actually Bites
Seven of the nine libraries examined could be verified against primary-source evidence; one was archived and dropped from scoring, and one was left out entirely rather than scored on guesswork - a restraint that itself signals the audit's seriousness. Hybrid combiners, which pair a post-quantum algorithm with a classical one like X25519 so that a break in either algorithm alone does not compromise the connection, exist in only three of six audited libraries in full form, with half offering partial support. That is a meaningfully different picture than a snapshot taken six months earlier would have shown, when only a single library offered any combiner at all - a reminder that this field is still moving quickly.
The sharper gap is inventory and discovery tooling: none of the seven audited libraries can produce a machine-readable account of which cryptographic algorithms are actually in use across a codebase. quantum-safe addresses this with a CycloneDX Cryptographic Bill of Materials, letting organizations audit their own exposure to deprecated algorithms before regulators or auditors ask. On formal conformance, Bouncy Castle stands alone with an actual CMVP FIPS 140-3 certificate - validation by an accredited laboratory, the gold standard. quantum-safe instead reports passing all 225 runnable Automated Cryptographic Validation Protocol known-answer test cases against NIST-published vectors, a distinction the project is careful to describe as conformance evidence rather than equivalent validation.
Honest Scoring, Including Against Itself
The audit does not spare its own library. quantum-safe's defaults - ML-KEM-768 and ML-DSA-65 - fall below the parameter sets CNSA 2.0 mandates for national security systems, ML-KEM-1024 and ML-DSA-87. Rather than omit that shortfall, the project scores it as a deficiency and ships a compliance profile that can report or enforce the stricter parameters. On stateful hash-based signing under SP 800-208, Bouncy Castle again leads, supporting both LMS and XMSS schemes, while quantum-safe offers LMS only, through an optional dependency with write-ahead index reservation to guard against one-time-key reuse - a narrower but still meaningful safeguard.
What the Performance Numbers Show
Beyond compliance, the research measured real-world overhead. A full hybrid handshake combining X25519 with ML-KEM-768 - key generation, encapsulation, and decapsulation together - takes a median of 231 microseconds, about 5.3 times longer than a classical X25519-only handshake in the same library, yet still under one percent to roughly two percent of a typical TLS 1.3 connection budget. Throughput stays essentially flat from 100 to 5,000 concurrent threads, actually falling slightly, because the underlying C library releases Python's Global Interpreter Lock during longer operations while the Python wrapper code around it does not scale with added threads. For most applications, the practical cost of going quantum-safe today is small; the harder work, this audit suggests, lies in combiners, tooling, and certification rather than raw speed.
