The algorithms are finished, but the plumbing is not. When the National Institute of Standards and Technology finalized FIPS 203, FIPS 204, and FIPS 205 in August 2024, it closed a question that had occupied cryptographers for nearly a decade: which mathematical constructions can resist an attack from a sufficiently capable quantum computer. What remains unresolved, and far less discussed, is whether the software libraries developers actually use are ready to put those algorithms into production systems without introducing new risks of their own.
That distinction matters because standardizing an algorithm is not the same as making it usable safely. A finalized standard tells engineers which mathematical operations are trustworthy; it says nothing about whether a given library correctly combines a post-quantum algorithm with a classical one, whether it can prove conformance to an auditor, or whether it tracks which cryptographic primitives are running where across a sprawling codebase. These are the unglamorous mechanics of migration, and they are where real-world security failures tend to originate. For everyday users trying to keep pace with the shift toward quantum-resistant protections, even simple tools like a lightweight browser extension increasingly need to account for hybrid cryptographic schemes rather than relying on classical algorithms alone. a lightweight browser extension
Measuring a Gap That Vendors Would Rather Not Admit
A recent audit of nine post-quantum cryptography libraries, current as of September 2026, set out to measure this production gap using criteria drawn from outside sources rather than from any single vendor's preferences - anchoring its nine scoring dimensions to the National Security Agency's CNSA 2.0 suite, NIST's Cryptographic Module Validation Program, the TNO CADI market survey, and an active IETF draft on hybrid key exchange. Of seven libraries with verifiable primary-source evidence, only three offered a complete hybrid combiner - the mechanism that pairs a post-quantum algorithm with a classical one so that a system remains secure even if one of the two is later broken. Half provided partial support at best. Discovery and inventory tooling, which lets an organization see which cryptographic algorithms are actually running across its systems, was absent from all seven.
Conformance evidence told a similarly uneven story. Bouncy Castle, a long-established library, holds an actual CMVP FIPS 140-3 certificate - meaning an accredited laboratory independently validated its implementation. The quantum-safe library built around this rubric makes no such claim; instead it reports passing all 225 runnable Automated Cryptographic Validation Protocol test cases against NIST-published vectors, a meaningfully weaker form of evidence that its own documentation describes candidly as conformance testing rather than formal validation. On stateful hash-based signatures, a scheme useful for firmware and long-lived signing keys, Bouncy Castle supports both LMS and XMSS, while quantum-safe offers only LMS through an optional add-on, protected against key reuse through a write-ahead reservation mechanism.
What the Numbers Say About Real-World Cost
Security upgrades are often resisted because of assumed performance penalties, so the audit paired its scoring with timing measurements. A full hybrid handshake combining X25519 with ML-KEM-768 took a median of 231 microseconds, about 5.3 times slower than a classical-only handshake in the same library, but that overhead amounts to under 2.3 percent of a typical TLS round-trip budget - a cost most applications will never notice. Throughput held steady as concurrent threads scaled from 100 to 5,000, though it never exceeded what a single thread achieved, indicating that the Python layer wrapping these libraries does not parallelize well even when the underlying cryptographic engine does.
Honesty as a Design Principle
Perhaps the most unusual feature of this exercise is its willingness to score its own library below a market incumbent on multiple dimensions, including default parameter strength: quantum-safe ships with ML-KEM-768 and ML-DSA-65, both below the ML-KEM-1024 and ML-DSA-87 sets that CNSA 2.0 mandates for the highest-assurance use cases. Rather than omit that shortfall, the project reports it openly and ships a compliance profile that flags or enforces the stricter parameters where required. In a field where vendors routinely emphasize favorable comparisons, publishing a methodology capable of lowering one's own standing is itself a notable departure - and arguably a more useful signal to engineers deciding what to trust.