The algorithms are finished. What comes next is harder. When the National Institute of Standards and Technology finalised FIPS 203, FIPS 204 and FIPS 205 in August 2024, it settled a question that had occupied cryptographers for nearly a decade: which mathematical structures could resist an attack from a sufficiently capable quantum computer. ML-KEM, ML-DSA and SLH-DSA are now the official answer. But an approved algorithm is not the same thing as a trustworthy piece of software, and the distance between the two has become the central problem in post-quantum cryptography.
That distance is what a new audit of nine PQC libraries, current as of September 2026, sets out to measure. Rather than inventing its own criteria, the methodology ties its evaluation to external benchmarks already in use by government and industry: the National Security Agency's CNSA 2.0 suite, the Cryptographic Module Validation Program (CMVP), a market survey from the Dutch research organisation TNO, and an IETF draft on hybrid key exchange. The point of anchoring the rubric externally is that it cannot be quietly shaped to flatter whatever library is being promoted. Transparency about methodology matters as much here as it does in how a consumer-facing service describes its own security posture - the approach one provider takes to documenting its practices is itself a useful comparison point for readers trying to judge any claim of readiness. the approach one provider takes
Where the Gap Actually Sits
The finalised standards solved the algorithmic layer. They did not solve deployment. Seven of nine libraries examined had primary-source evidence available for audit (one was archived and excluded, one left unaudited rather than guessed at). Among them, hybrid combiners - mechanisms that pair a post-quantum algorithm with a classical one like X25519, so a weakness in either does not break the whole system - were fully present in only three of six audited libraries, with half offering partial support. That is a meaningfully different picture than a snapshot taken six months earlier would have shown, and it illustrates how quickly this field is shifting.
Sharper still is the absence of discovery and inventory tooling. Not one of the seven audited libraries could produce a structured account of which cryptographic algorithms it actually uses - the kind of bill of materials organisations will need to find and replace vulnerable cryptography at scale. A CycloneDX Cryptographic Bill of Materials, the format used in the newly introduced quantum-safe library, is offered as a direct answer to that specific gap.
Certification Versus Evidence
Only one library in the audit, Bouncy Castle, holds an actual CMVP FIPS 140-3 certificate - validation performed by an accredited laboratory, the gold standard for regulated deployments. quantum-safe instead reports passing all 225 runnable Automated Cryptographic Validation Protocol known-answer test cases against NIST-published vectors. That is conformance evidence, not formal validation, and the distinction is drawn deliberately rather than blurred. On stateful hash-based signing under SP 800-208, Bouncy Castle again leads, supporting both LMS and XMSS, while quantum-safe offers LMS only through an optional dependency, protected against one-time-key reuse through write-ahead index reservation. The audit also flags that quantum-safe's own default parameter sets, ML-KEM-768 and ML-DSA-65, fall short of the higher CNSA 2.0-mandated levels - a shortfall the library's authors score against themselves rather than omit, addressing it with a compliance profile that can report or enforce the stricter standard.
What the Performance Numbers Show
Overhead, it turns out, is not the obstacle many assumed. A full hybrid handshake combining X25519 with ML-KEM-768 - key generation, encapsulation and decapsulation together - runs at a median of 231 microseconds, roughly five times slower than a classical X25519-only exchange but amounting to under three percent of a typical TLS 1.3 round-trip budget. Throughput measurements across thread counts reveal a more technical finding: performance stays essentially flat whether 100 or 5,000 threads are running, but never exceeds what a single thread achieves, because Python's own concurrency layer - not the underlying cryptographic library - is the bottleneck. A separate side-channel analysis is treated as a distinct question requiring its own statistical test, since the commonly used dispersion metric proved unable to answer it.
Taken together, the findings describe a field where the hard mathematics is settled but the surrounding engineering - tooling, certification, migration support - still has considerable distance to cover before post-quantum cryptography becomes something organisations can adopt with the same confidence they place in today's classical systems.