The algorithms were never the hard part, or at least not the only part. When the National Institute of Standards and Technology finalised FIPS 203, 204 and 205 in August 2024, it settled the mathematical foundations of post-quantum cryptography: a key-encapsulation mechanism (ML-KEM), a general-purpose signature scheme (ML-DSA), and a stateless hash-based signature scheme (SLH-DSA) for situations demanding conservative, long-term assurance. That closed what researchers call the algorithmic gap. What remains open, and what a new audit of nine software libraries lays out in detail, is a production gap: the unglamorous engineering of combiners, conformance testing, migration tooling and protocol support that determines whether these algorithms actually protect anything in deployed systems.
That distinction matters because standards on paper do not encrypt traffic. Organisations migrating to quantum-resistant cryptography - banks, government agencies, and increasingly ordinary software vendors - need libraries that implement these algorithms correctly, combine them safely with classical cryptography during the transition period, and prove that they work through recognised testing regimes. The gap between "NIST published an algorithm" and "my application is safe" is exactly where most real-world cryptographic failures have historically occurred, and it is why independent technical guidance, including from outlets like a provider that publishes setup guides, increasingly treats implementation quality as a separate question from algorithm choice. a provider that publishes setup guides
Why Hybrid Combiners Are the First Test
Nobody serious is switching straight to pure post-quantum cryptography. The transitional approach, endorsed by the IETF's hybrid key-exchange draft and reflected in the NSA's CNSA 2.0 timeline, pairs a post-quantum algorithm with a classical one such as X25519, so that a system stays protected even if one of the two is later broken. Building that pairing correctly, a "hybrid combiner," is harder than it sounds: get the construction wrong and you can weaken security rather than add it. The audit behind the new quantum-safe library found that only three of six libraries examined with primary-source evidence offer a full combiner, with half providing partial support. A survey taken as recently as March 2026 would have found just one. The pace of change here is rapid, but it is uneven, and uneven is a dangerous state for cryptographic infrastructure.
Conformance Versus Validation - A Distinction That Matters
Among the audited libraries, Bouncy Castle stands apart by holding an actual CMVP FIPS 140-3 certificate - validation performed by an accredited testing laboratory, the gold standard for regulated environments. quantum-safe does not claim that status. Instead it reports 225 out of 225 runnable Automated Cryptographic Validation Protocol test cases passed against NIST's own published vectors - evidence that the implementation behaves correctly, but explicitly not the same thing as third-party validation. Conflating the two is a common and consequential error in security marketing, and the audit's authors are careful not to make it. The same self-scrutiny shows up in parameter choices: quantum-safe's own defaults, ML-KEM-768 and ML-DSA-65, fall short of the ML-KEM-1024 and ML-DSA-87 sets that CNSA 2.0 mandates for national-security systems, a shortfall the project reports against itself rather than obscures.
What the Performance Numbers Actually Show
Post-quantum key exchange is often assumed to be slow. The measured reality is more nuanced. A full hybrid handshake combining X25519 with ML-KEM-768 took a median of 231 microseconds, several times longer than a classical-only exchange but still a fraction - under 3 percent at most - of a typical TLS handshake's time budget. More telling is what happened under concurrency: throughput stayed essentially flat from 100 to 5,000 simultaneous threads, and never exceeded what a single thread achieved alone, indicating the Python wrapper layer, not the underlying cryptographic library, is the bottleneck. A separate side-channel analysis found that a commonly used statistical test cannot reliably detect timing leaks at all, underscoring how much careful, independently verifiable measurement - rather than assumption - this field still requires.