Last updated: June 2025
[IMAGE: A macro-level cinematic shot of a quantum processor chip with entangled cyan light beams threading between logic gates, surrounded by deep black negative space, with faint lattice-structure overlays suggesting ML-KEM mathematical geometry, dramatic low-angle perspective, 8K photorealistic quality]
Key Takeaways
- NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024 — but across nine evaluated PQC libraries, only 11% support hybrid KEM, 22% include migration tooling, and 33% offer protocol integration
- A full X25519 + ML-KEM-768 hybrid handshake completes in 243 microseconds under Docker/Linux — consuming just 0.5–2.5% of a typical TLS 1.3 round-trip budget — proving production-grade performance is achievable today
- The ecosystem’s production gap in hybrid combiners, versioned key formats, and migration tooling means most organizations attempting PQC deployment without a purpose-built library will write insecure manual implementations
The Algorithmic Gap Closed. The Production Gap Didn’t.
Your security team has been waiting for NIST to finalize post-quantum cryptography standards before committing to a migration path. That wait ended in August 2024. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — the three standards that define how organizations encrypt data and verify signatures in a post-quantum world.
But a new research paper (arXiv:2605.17061) evaluating nine PQC libraries across eight production-readiness dimensions exposes a problem your procurement checklist won’t catch: the algorithmic gap closed in August 2024; the production gap did not.
Consider what happens when your engineering team picks a PQC library off GitHub and starts integrating it into your TLS termination layer. Without hybrid KEM support built into the library, they write a manual combiner — typically 45 lines of custom cryptographic code that no one on your team has formally verified. That code sits in your authentication path for years. This is not a theoretical risk. It is the current state of 89% of the evaluated PQC library ecosystem.
What “Production-Ready” Actually Requires
Post-quantum cryptography production readiness means a library supports not just the FIPS 203/204/205 algorithms themselves, but the surrounding infrastructure required for safe, compliant deployment: hybrid key encapsulation mechanisms (KEMs) that combine classical and post-quantum algorithms during the transition period, versioned key formats for forward compatibility, protocol integration helpers for TLS and other handshake layers, and migration tooling that lets teams audit and upgrade existing cryptographic assets.
The research evaluated nine PQC libraries across eight such dimensions. Three dimensions showed coverage below 35% across the entire ecosystem:
| Production-Readiness Dimension | Ecosystem Coverage | Risk if Missing |
|---|---|---|
| Hybrid KEM support | 11% | Teams write unverified manual combiners |
| Migration tooling | 22% | No systematic path to audit existing key material |
| Protocol integration | 33% | Manual TLS/handshake wiring introduces implementation errors |
| (Other five dimensions) | Not disclosed | Varies by deployment context |
These are not edge-case features. Hybrid KEM is the NIST-recommended transition strategy — running classical X25519 alongside ML-KEM-768 so that a compromise of either algorithm alone doesn’t break confidentiality. An 11% support rate means that if you pick a PQC library at random, you have roughly a 1-in-9 chance of getting hybrid KEM out of the box.
“The August 2024 finalisation of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) closed the algorithmic gap in post-quantum cryptography. The production gap — hybrid combiners, versioned key formats, protocol helpers, and migration tooling — remains open.” — arXiv:2605.17061v1
Technical Deep-Dive: Benchmarks, Timing Variance, and What the Numbers Mean
Hybrid Handshake Performance Under Load
The research benchmarked the quantum-safe Python library — the only library in the evaluated set to score “Full” across all eight production-readiness dimensions — using 3,000 iterations with CPU-pinned execution and bootstrapped 95% confidence intervals.
Results under Docker/Linux:
| Metric | Value | Context |
|---|---|---|
| Full X25519 + ML-KEM-768 handshake | 243 microseconds | 0.5–2.5% of typical TLS 1.3 round-trip budget |
| Throughput at 5,000 concurrent users | 2,848 ops/s | Only 4.9% degradation vs. single-user baseline |
| ML-KEM-768 decapsulation CoV | 3.9% | Close to AES-256-GCM noise floor |
| AES-256-GCM CoV (noise floor) | 2.1% | Classical baseline for comparison |
| ML-DSA-65 signing CoV | 51.5% | Caused by FIPS 204 rejection sampling |
The 243-microsecond handshake figure directly addresses the most common objection CISOs hear from engineering teams: “PQC will kill our latency budget.” At 0.5–2.5% of a TLS 1.3 round-trip, the overhead is negligible for any application not operating at sub-millisecond SLA requirements.
The throughput result is equally significant. At 5,000 concurrent users, quantum-safe delivers 2,848 ops/s with only 4.9% degradation versus single-user baseline. This is possible because liboqs — the underlying C library — releases the Python GIL during C-level operations, enabling genuine parallelism within a Python process.
The CoV Methodology: A New Lens on Side-Channel Risk
The research introduces Coefficient of Variation (CoV) as a practical timing side-channel proxy across all FIPS 203/204 operations — an application that has not previously appeared in PQC library evaluation literature.
CoV measures relative timing variance: a low CoV suggests consistent execution time regardless of input, which is a necessary (though not sufficient) condition for resistance to timing side-channel attacks. The ML-KEM-768 decapsulation CoV of 3.9% sits close to the AES-256-GCM noise floor of 2.1%, indicating timing behavior consistent with a well-implemented constant-time operation.
The ML-DSA-65 signing CoV of 51.5% warrants attention — but the research attributes this variance to FIPS 204’s rejection sampling mechanism, not a side-channel vulnerability. Rejection sampling is an algorithmic property of lattice-based signatures: the algorithm retries signing until output meets a statistical criterion, producing inherently variable execution times. Security architects should document this distinction explicitly when presenting PQC timing profiles to compliance teams.
The CoV methodology provides a lightweight, reproducible proxy for timing side-channel assessment that security teams can run against any PQC library without formal verification tooling — a practical addition to any PQC evaluation framework.
API Complexity as a Security Surface
The quantum-safe library reduces hybrid KEM implementation from 45 lines of manual combiner code to 3 lines. This is not a developer-experience improvement — it is an attack surface reduction. Every line of custom cryptographic code is a line that can mishandle key material, skip validation, or introduce timing variance. Standardizing on a library that encapsulates the combiner logic removes that surface entirely.
Industry Context: Compliance Timelines and Who’s Moving
NIST Timelines Create a Hard Deadline
NIST’s August 2024 publication of FIPS 203, 204, and 205 starts the compliance clock for organizations subject to federal procurement requirements, FedRAMP authorization, and CMMC certification. The U.S. Office of Management and Budget has signaled that agencies must begin inventorying cryptographic assets and developing migration plans — a process that requires exactly the migration tooling that 78% of evaluated PQC libraries lack.
For private-sector organizations, the timeline pressure comes from a different direction: “harvest now, decrypt later” attacks. Adversaries with sufficient storage capacity are already collecting encrypted traffic today, betting on future quantum capability to decrypt it. Data with a confidentiality horizon beyond 5-10 years — health records, intellectual property, financial instruments — is already at risk under this threat model.
The Cost of Manual Implementation
The ecosystem coverage data quantifies a hidden cost that doesn’t appear in library licensing fees. When 89% of PQC libraries lack hybrid KEM support, organizations face a binary choice: delay migration until better tooling exists, or build manual combiners. Manual combiners require cryptographic engineering expertise that most organizations don’t employ internally, external audit to validate correctness, and ongoing maintenance as NIST guidance evolves. The research’s 45-line-to-3-line comparison illustrates what that manual effort looks like at the implementation level — and that’s before accounting for the audit and maintenance burden.
The BeQuantum Perspective
The production gap identified in arXiv:2605.17061 maps directly onto the problem BeQuantum’s PQC Layer was designed to address. The research confirms what we observe across enterprise deployments: organizations that treat PQC adoption as an algorithm swap — drop in ML-KEM, done — consistently underestimate the integration surface.
BeQuantum’s Digital Notary service, for example, requires not just post-quantum key encapsulation but versioned signature formats that remain verifiable as algorithm recommendations evolve. An ML-DSA-65 signature notarizing a document today must be verifiable in 2035, potentially against updated FIPS 204 guidance. That requires the versioned key format infrastructure that only 22% of evaluated libraries provide.
The CoV methodology introduced in the research aligns with BeQuantum’s approach to PQC library evaluation for IceCase hardware deployments. Timing consistency under load is a hardware security module requirement, not just a software concern — and the 3.9% CoV for ML-KEM-768 decapsulation provides a concrete benchmark against which hardware implementations can be validated.
Organizations evaluating PQC libraries for production deployment should treat the eight production-readiness dimensions in arXiv:2605.17061 as a minimum evaluation checklist, not an aspirational framework. The three dimensions below 35% ecosystem coverage — hybrid KEM, migration tooling, protocol integration — are the dimensions most likely to create compliance gaps and implementation vulnerabilities in the 1-2 year deployment window.
What Your Team Should Do in the Next 90 Days
Step 1: Audit your cryptographic inventory against the eight production-readiness dimensions. Within 30 days, identify every PQC library currently in use or under evaluation across your stack. Score each against hybrid KEM support, migration tooling availability, and protocol integration coverage. Any library scoring zero on hybrid KEM support should be flagged for replacement before production PQC deployment begins.
Step 2: Run the CoV benchmark against your candidate libraries. The research methodology is reproducible via a single Docker command. Within 60 days, establish CoV baselines for ML-KEM-768 decapsulation and ML-DSA-65 signing in your target deployment environment. A decapsulation CoV significantly above 3.9% warrants investigation before you commit to that library for production key exchange.
Step 3: Prioritize hybrid-by-default architecture for any new TLS deployments. Within 90 days, update your TLS configuration standards to require X25519 + ML-KEM-768 hybrid key exchange for any new service deployments. The 243-microsecond handshake data removes the performance objection. The 11% ecosystem coverage data means you need to verify hybrid KEM support explicitly — don’t assume it.
Frequently Asked Questions
Q: If NIST finalized the PQC standards in August 2024, why can’t we just implement ML-KEM directly without hybrid mode?
A: Pure ML-KEM deployment eliminates classical cryptography before the security community has accumulated sufficient real-world cryptanalysis experience with lattice-based algorithms. NIST and NSA both recommend hybrid mode — combining X25519 with ML-KEM-768 — during the transition period so that a future algorithmic weakness in either component doesn’t compromise confidentiality alone. The 243-microsecond hybrid handshake benchmark demonstrates that the performance cost of hybrid mode is negligible, removing the primary engineering objection to this approach.
Q: What does the ML-DSA-65 CoV of 51.5% mean for our signing infrastructure?
A: The 51.5% CoV reflects FIPS 204’s rejection sampling mechanism — an algorithmic property that causes variable execution time based on how many signing attempts are required before output meets the statistical criterion. This is not a side-channel vulnerability. However, your compliance documentation should explicitly distinguish between timing variance caused by algorithmic design and variance caused by input-dependent branching. Auditors and penetration testers unfamiliar with lattice-based signatures may flag the high CoV without this context.
Q: How does the 4.9% throughput degradation at 5,000 concurrent users translate to our environment?
A: The 2,848 ops/s figure at 5,000 concurrent users was measured under Docker/Linux with CPU-pinned execution. The research does not provide hardware specifications beyond this, so direct extrapolation to your environment requires your own benchmarking. The key finding is the degradation rate — 4.9% — which indicates near-linear scaling behavior rather than the cliff-edge degradation that poorly parallelized cryptographic code typically exhibits. The GIL-release behavior of liboqs during C-level operations is the mechanism enabling this scaling.
Source: “quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library”, arXiv:2605.17061v1
