Post-Quantum Migration Has a Deadline: What Qrisp 0.8 Changes

5 min read

The post-quantum migration deadline is now quantifiable. Security teams have known for years that Shor’s algorithm threatens RSA. What they have lacked is a precise engineering target — the specific gate counts, qubit overhead, and compilation benchmarks that convert a theoretical timeline into a project plan. On 5 April 2026, IQM Quantum Computers and Fraunhofer FOKUS supplied those numbers. The release of Eclipse Qrisp 0.8 marks the first gate-level compilation of Shor’s algorithm at full 2048-bit RSA key size, running at 109 gates per second. The migration clock is not at zero — current quantum hardware cannot execute this at scale — but the parameters are now fixed. Post-quantum cryptography (PQC) migration is no longer a horizon item; it now has a computable planning trigger.

What Qrisp 0.8 Actually Did

Shor’s algorithm solves integer factorisation in polynomial time on a quantum computer, attacking the mathematical problem that makes RSA secure. The algorithm has existed since 1994; the open question has always been what hardware resources a real implementation would require. Compiling it at the gate level against a specific key size answers that question.

Qrisp 0.8 does not run Shor’s algorithm to completion on physical hardware — current machines lack the error-corrected logical qubits needed for that. What the release provides is a precise resource model: the framework compiles the full circuit for 2048-bit RSA factorisation and processes it at 109 gates per second — IQM and Fraunhofer FOKUS reported this gate processing rate in the Qrisp 0.8 release documentation. That gate rate and circuit depth, mapped against published hardware improvement trajectories, gives security architects a credible planning input.

The operational significance is the shift from “quantum computing is a future risk” to “we have a gate count; how long before available hardware meets it?” Those are different conversations. The first belongs in a risk register. The second belongs in a project plan with a remediation timeline.

Qrisp 0.8 establishes the gate count for the algorithm. The second input — how many logical, error-corrected qubits are required to execute it at that gate rate, and how current hardware improvement trajectories map to that threshold — remains an active area of research. Security teams seeking a complete planning model should pair this gate-count benchmark with published logical qubit overhead estimates from NIST’s PQC programme documentation and their quantum hardware vendor’s roadmap. Organisations now have a specific gate count to work backwards from — a meaningful planning input even as the qubit overhead calculation continues to be refined.

QuEra Tsim: Lowering the Simulation Barrier

Three days before the Qrisp release, QuEra Computing published Tsim, an open-source GPU-accelerated quantum circuit simulator. Running on NVIDIA GH200 hardware, Tsim processes 85-qubit circuits at 600 nanoseconds per shot — fast enough to support iterative error-correction research without access to physical quantum hardware.

For engineering teams beginning quantum-readiness assessments, Tsim removes a significant cost barrier. Prior to open-source GPU-accelerated simulators, comparable 85-qubit circuit simulation required either access to physical quantum hardware (typically via cloud QPU pricing that runs to hundreds of dollars per hour for meaningful workloads) or proprietary simulation software. Tsim’s open-source release under GPU acceleration removes both cost barriers for teams with existing NVIDIA compute.

QuEra designed Tsim specifically for error-correction workloads, which is where the meaningful near-term engineering work is. The gap between current noisy intermediate-scale quantum (NISQ) devices and the logical qubit counts needed to execute Shor’s algorithm at RSA-2048 scale is primarily an error-correction problem. Tsim gives teams a practical environment to study that gap rather than theorise about it.

The NIST Standards Are Ready — The Deployments Are Not

The algorithmic side of PQC migration is settled. NIST completed its standardisation process in August 2024, publishing three algorithms. ML-KEM (based on CRYSTALS-Kyber) handles key encapsulation and replaces the key exchange functions currently using elliptic-curve Diffie-Hellman (ECDH) or RSA. ML-DSA (based on CRYSTALS-Dilithium) covers digital signatures. SLH-DSA (based on SPHINCS+) provides a stateless hash-based signature scheme as a conservative fallback.

The gap is operational, not cryptographic. TLS libraries, hardware security modules (HSMs), certificate authorities, firmware stacks, and embedded systems all require coordinated updates. Many of these components run on multi-year procurement and deployment cycles. An organisation running a custom HSM with no ML-KEM support cannot migrate its key infrastructure regardless of what its application layer does.

There is a second, more immediate exposure category: harvest-now-decrypt-later (HNDL) attacks. Adversaries can capture and store encrypted traffic today, holding it against the day quantum hardware reaches the threshold Qrisp 0.8 has now defined. For organisations in finance, government, and critical infrastructure — where sensitive data has a shelf life exceeding the 10–15 year planning horizon cited in NSA post-quantum guidance — that exposure is present now, regardless of when factorisation at scale becomes feasible. The NSA’s 2022 guidance on post-quantum cryptography cited a planning horizon of 10–15 years for cryptographically relevant quantum computers — a window that Qrisp 0.8’s benchmarks now allow security teams to evaluate against their specific infrastructure.

PQC Migration Readiness: A Checklist

Where does your organisation stand?

• Cryptographic inventory: Have you catalogued every system using RSA-2048 or ECDH key exchange, including HSMs, PKI, code signing, and TLS termination endpoints?
• HNDL exposure assessment: Which data classifications in your estate have a sensitivity lifetime exceeding five to ten years? Those are your immediate HNDL risk assets.
• Library readiness: Are your TLS stacks (OpenSSL, BoringSSL, or equivalents) on versions with ML-KEM or hybrid PQC/classical mode support? (OpenSSL 3.x supports ML-KEM and ML-DSA in hybrid mode; BoringSSL support is in active development.)
• HSM vendor roadmap: Have you confirmed your HSM vendor’s published timeline for ML-KEM and ML-DSA support? This is often the longest-lead item. (Thales, Utimaco, and AWS CloudHSM have published or announced PQC-capable firmware roadmaps as of 2025–2026.)
• Certificate authority timeline: Has your CA provider announced a schedule for PQC-capable certificate issuance? (Let’s Encrypt and major CAs have not yet announced PQC certificate issuance timelines; NIST standardisation completed August 2024.)
• Dependency mapping: Have you identified third-party integrations and API partners whose encryption posture you cannot control directly?

Implications and What to Watch

For CTOs in regulated industries, the Qrisp 0.8 milestone strengthens the case for board-level disclosure. The shift from abstract risk to defined engineering parameters moves post-quantum exposure closer to the threshold where it belongs in material risk disclosures rather than appendices. The U.S. Office of Management and Budget — through Memorandum M-23-02 issued in January 2023 — required federal agencies to complete cryptographic inventories as a foundational step toward post-quantum migration; the private-sector equivalent is increasingly a governance expectation rather than a best practice.

For platform and infrastructure PMs, the combination of Qrisp 0.8 and QuEra Tsim means there is now a full open-source stack — from algorithm compilation benchmarking to error-correction simulation — available for quantum-readiness testing without hardware access or vendor relationships.

The near-term signals worth tracking are HSM vendor support announcements for ML-KEM and ML-DSA, hybrid PQC mode adoption rates in major TLS library releases, and the emergence of HNDL-specific threat modelling frameworks from NIST or equivalent standards bodies. The standards exist. The tooling to measure and plan migration exists. The remaining question is how fast operational teams move from inventory to deployment.

This article was produced with AI assistance and reviewed by the editorial team.

Further reading: advances in quantum computing hardware | enterprise AI security priorities for 2026