QCBRIEF
University of Jyväskylä researchers map the pipeline for renting cloud quantum compute and find the major platforms cannot prove what ran, who authorized it, or which tenant bled into which run.
A researcher on a laptop submits a hybrid algorithm to a rented quantum processor. On the other end, almost no one can prove what ran, who authorized it, or which tenant's job bled into which other run. That gap is the headline finding of a new University of Jyväskylä threat model for Quantum-as-a-Service (QaaS), released this month as an arXiv preprint.
QaaS lets anyone rent time on a shared quantum processor to run hybrid quantum-classical algorithms such as VQE and QAOA. It is in active rollout across IBM Quantum, Amazon Braket, and IonQ Quantum Cloud.
The team decomposes the hybrid workflow into six stages: developer laptop, authentication, cloud orchestration, hardware execution, result return, and the iteration loop. They then plot a color-coded STRIDE matrix (the threat-modeling shorthand for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) across them. Published quantum attacks such as QubitHammer and SWAP attacks are tagged orange, inherited classical risks blue, and under-studied gaps green.
The gap the paper itself flags is the audit trail. Repudiation and elevation-of-privilege are sparsely addressed; many stages lack verifiable execution logs, so neither customer nor provider can reconstruct which code ran on which qubits. One chain links passive side-channel observation on the hardware stage to a targeted crosstalk attack on a co-tenant's run.
Industry has hardened the network layer: IBM has shipped quantum-safe primitives for its Quantum Platform, and AWS runs ML-KEM post-quantum TLS across KMS, ACM, and Secrets Manager. The execution-log layer, the record of which tenant ran which job, is the part the paper says remains open.