Pith. sign in

REVIEW 4 major objections 6 minor 21 references

Quantum Software Security Challenges within Shared Quantum Computing Environments

T0 review · 4 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Pith's one-line read Shared quantum clouds carry a new class of software-security attacks.

desk verdict A well-organized survey of known quantum multi-tenant attack classes; the synthesis is useful, but the paper overstates present risk and leans on an unverified adoption premise. read the letter →

arxiv 2507.17712 v1 pith:PNNONHBG submitted 2025-07-23 quant-ph cs.CR

classification quant-phcs.CR
keywords quantumsoftwaresecuritymulti-programmingmulti-tenantcomputingcrosstalkattacksqubitsensingadversarialSWAPinjectionpulse-levelside-channel
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that the coming practice of multi-programming—running several customers' quantum circuits in parallel on one machine to boost utilization—turns physical imperfections in current quantum hardware into software-security channels. It surveys six concrete attack families: crosstalk-based result corruption and denial of service, adversarial SWAP injection that inflates a victim's gate count, qubit sensing that reads a neighbor's output, pulse-level attacks that flip or read qubits, circuit reconstruction through execution-order side channels, and hardware blueprinting that defeats topology hiding. The takeaway is that shared quantum environments need isolation mechanisms, security-aware compilers, and quantum-specific side-channel mitigations before confidential workloads can be processed. A sympathetic reader would take this as a call to treat co-tenant quantum execution as an adversarial setting rather than a performance-optimization problem only.

What carries the argument

The carrying mechanism is multi-programming in a shared NISQ environment: multiple quantum circuits are compiled onto the same physical chip, with qubits partitioned among tenants and executed in parallel or in close succession. The physical couplings between partitions—unwanted crosstalk between neighboring qubits and control lines, restricted connectivity that forces compiler-inserted SWAP gates, access to control pulses that reach higher energy states, and queue ordering that lets probing circuits run before and after a victim's—are what each attack exploits. In other words, the architecture that raises hardware utilization is itself the attack surface.

What would settle it

Run a controlled co-tenancy experiment on a current multi-programming quantum cloud: execute a victim circuit while a co-tenant repeatedly runs the adversary circuits from the paper—CNOT trains on a shared bus, dense occupation of high-connectivity qubits, and pulse-level hammering—and measure whether the victim's success probability degrades with adversary activity. If the error rate stays flat across all three vectors, or if provider logs show tenants are never co-scheduled, the paper's central threat picture would be falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that sharing a noisy quantum computer among multiple programs is not security-neutral: because qubits physically couple through crosstalk, connectivity limits, control-pulse lines, and execution scheduling, a co-tenant can corrupt a victim's results or learn information about the victim's circuit. The evidence assembled is a set of proof-of-concept attacks from the literature—degrading a search algorithm until correct results appear less than a fifth of the time, injecting up to 55 percent more SWAP gates into victim circuits, sensing adjacent qubit values with up to 96 percent accuracy, flipping qubits through pulse-level hammering, and reconstructing single-gate test circuits from side-channel measurements. The paper does not claim these attacks are unsolvable; most have known countermeasures. It claims the countermeasures are partial, that buffer qubits and topology hiding are not enough, and that the exploit-and-patch cycle familiar from classical computing is already beginning in quantum clouds.

Load-bearing premise

The threat assessment rests on the assumption that providers will actually co-locate different customers' circuits on the same hardware at scale for profitability and that the cited experimental demonstrations on current machines are accurate; if co-tenancy never becomes common or future hardware removes the noise couplings, the surveyed attacks lose their practical relevance.

Editorial extensions

If this is right

  • If the paper is right, confidential workloads should not be scheduled on today's shared quantum clouds without isolation guarantees, because co-tenants can measurably corrupt or infer results.
  • Security-aware compilers will need to allocate qubits and schedule gates with adversarial co-tenancy in mind, not just error rates and connectivity.
  • Buffer qubits and topology hiding are necessary but insufficient: pulse-level attacks can cross large buffers, and hardware blueprinting can recover the topology.
  • Fully disabling pulse-level access would break legitimate applications such as quantum machine learning, so providers need mediated pulse access and monitoring rather than a simple kill switch.
  • As program sizes grow and circuit-loading delays shrink, the mostly-theoretical higher-energy-state and alternating-execution attacks become practical.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the surveyed attacks suggest an end-to-end side channel is plausible: combining qubit sensing with circuit reconstruction could recover not just a result bit but the full victim circuit, something no single proof of concept currently demonstrates.
  • A testable extension would be to benchmark how much isolation an error-corrected quantum computer provides; logical qubits may suppress crosstalk, but shared control electronics and calibration data could create new co-tenancy channels.
  • The classical-cloud analogy implies that quantum providers will need continuous adversarial monitoring, not one-time mitigations, if multi-tenancy becomes standard.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. Ovaskainen, Haghparast, and Mikkonen survey software security challenges in quantum cloud environments that may adopt multi-programming, in which multiple circuits run concurrently on one QPU. The paper summarizes six attack classes drawn from the literature: crosstalk denial-of-service/result corruption, adversarial SWAP injection, qubit sensing, higher-energy state and QubitHammer pulse-level attacks, circuit reconstruction from side-channel measurements, and hardware blueprinting. It closes with a call to action listing six research directions (isolation mechanisms, security-aware compilers, side-channel mitigation, benchmarks, hardware-software co-design, crosstalk mitigation). The authors do not perform new experiments; the contribution is a synthesis and risk assessment.

Significance. If the premise of widespread multi-programming is accepted, the paper provides a useful and largely accurate map of a young literature, and the descriptions of cited attacks match the sources. Its explicit acknowledgment that most attacks are proofs of concept is honest, and the call-to-action items are concrete. The main limitation is that the motivating premise is assumed rather than evidenced, and the conclusion overstates the current risk level. With revision, the paper could serve as a balanced entry point for researchers and practitioners.

major comments (4)
  1. [Section III, first paragraph] The claim that cloud providers 'can reasonably expect them to turn to multi-programming to increase profitability further' is presented without evidence or citation. This is load-bearing because the entire survey's relevance depends on the adoption of multi-programming by commercial providers. Please either cite evidence of existing or planned multi-programming offerings (e.g., provider roadmaps or academic-industry collaborations) or explicitly reframe the paper as a preemptive analysis of a hypothetical future scenario. The current phrasing makes an untested assumption sound like an industry trend.
  2. [Section V, first paragraph] The conclusion that 'the present situation already paints a stark picture' is not supported by the body of the paper. Section III states that most attacks were proofs of concept with known countermeasures (III-A through III-F), and III-D explicitly describes higher-energy state attacks as 'mostly theoretical' due to circuit-loading delays. Recommending a sharper distinction between attacks demonstrated on current hardware and attacks that require future conditions (e.g., reduced load delays or a scheduler that allows co-placement) would make the conclusion accurate.
  3. [Section III-A] The statement that crosstalk 'may even be the largest source of errors in quantum computers [9]' is not supported by the cited reference [9], which experimentally characterizes crosstalk errors but does not compare their magnitude against all other error sources. Please qualify this claim (e.g., 'some studies suggest crosstalk is among the dominant error sources') or provide a reference that makes the comparative claim.
  4. [Section III] The survey lacks a systematic threat-model summary. Each attack assumes different adversarial capabilities: crosstalk assumes co-placement on connected qubits; adversarial SWAP injection assumes the attacker can occupy specific qubits; qubit sensing assumes prior reference signatures; pulse attacks assume pulse-level access; circuit reconstruction assumes control of the execution queue. A table listing, for each attack, the required capabilities, whether it was demonstrated on real hardware or a simulator, and whether it is mountable through current cloud APIs would greatly increase the paper's practical value and would temper the conclusion about present-day risk.
minor comments (6)
  1. [Section II, first paragraph] The opening sentence 'Term software security is often used without exact definitions' is missing the definite article; it should read 'The term software security...'.
  2. [Section III-C] The phrase 'qubits have an unwanted influence on each other' might better be 'unintended influence' to avoid implying malicious intent.
  3. [Section III-D] The sentence 'the delay caused by the loading of circuits on IBM machines is too long for these higher energy states not to collapse' is confusingly worded; consider 'too long for higher energy states to survive until the next circuit is loaded.'
  4. [Section III-E] The phrase 'previously accessible five-qubit IBM quantum computers' is vague; specify the hardware generation or remove 'previously accessible'.
  5. [References] Reference [2] is a web encyclopedia entry; for a formal survey, consider replacing it with a peer-reviewed definition of software security.
  6. [Abstract] The abstract does not mention that the surveyed attacks are mostly proofs of concept; adding a phrase such as 'several of which are currently proof-of-concept' would set reader expectations.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: this is a survey that makes no derived predictions and introduces no fitted parameters, so none of its claims reduce by construction to its inputs.

full rationale

The paper is a survey of existing quantum software security challenges in multi-tenant environments. It does not derive any new mathematical result, fit any parameters, or present a numerical prediction generated from the authors' own model. Every substantive claim is explicitly attributed to external references, including the crosstalk experiments on ibmqx2 and ibmq burlington [10], adversarial SWAP injection results on a 20-qubit simulator [12], qubit sensing accuracy [13], higher-energy state attacks [15], circuit reconstruction accuracy [17], and hardware fingerprinting [18, 19]. There are no self-citations and no author-specific uniqueness theorems or ansatze that the paper imports. The motivating assumption that cloud providers may adopt multi-programming for profitability is presented as a reasonable expectation rather than a derived conclusion, and the surveyed results are reported as proofs of concept with stated limitations, including the paper's own admission that higher-energy state attacks are 'mostly theoretical' because circuit-loading delays are too long. Concerns about whether the attacks are mountable through current cloud APIs or whether providers will actually co-locate circuits are evidence-gap and scope concerns, not circularity. The paper is therefore self-contained with respect to its contribution, which is the organization and reporting of externally established findings rather than a derivation of those findings from its own assumptions.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No new parameters or entities are introduced. The paper is a survey, so its loading comes from domain assumptions about the future of multi-tenant quantum computing and the fidelity of prior experimental claims.

assumptions (4)
  • domain assumption Cloud quantum providers will adopt multi-programming at scale.
    Section III introduces multi-programming as a likely profit driver; the entire set of surveyed attacks depends on shared execution being common.
  • domain assumption Attackers can co-schedule their circuits with victims on the same hardware.
    Each surveyed attack (crosstalk, swap injection, qubit sensing, pulse-level, circuit reconstruction) assumes an adversary and a victim run concurrently or adjacently; the paper does not discuss scheduling defenses that would prevent co-tenancy.
  • domain assumption Cited experimental results are correctly reported.
    The survey relies on numerical results from [10,12,13,15,16,17,18,19] without re-running the experiments, so accuracy of the survey is contingent on those sources.
  • domain assumption NISQ hardware behavior, including crosstalk and limited connectivity, matches the descriptions in the cited work.
    The threat models build on the NISQ characteristics from [5]; if hardware evolves away from these characteristics, the attacks become less relevant.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Quantum Software Security Challenges within Shared Quantum Computing Environments." pith.science (2026). https://pith.science/paper/PNNONHBG

@misc{pith2026250717712,
  author       = {Pith},
  title        = {Pith review of: Quantum Software Security Challenges within Shared Quantum Computing Environments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PNNONHBG}},
  note         = {Machine review of arXiv:2507.17712}
}
read the original abstract

The number of qubits in quantum computers keeps growing, but most quantum programs remain relatively small because of the noisy nature of the underlying quantum hardware. This might lead quantum cloud providers to explore increased hardware utilization, and thus profitability through means such as multi-programming, which would allow the execution of multiple programs in parallel. The adoption of such technology would bring entirely new challenges to the field of quantum software security. This article explores and reports the key challenges identified in quantum software security within shared quantum computing environments.

Figures

Figures reproduced from arXiv: 2507.17712 by the authors.

Figure 1
Figure 1. Topologies of two five-qubit IBM quantum computers [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Simplified version of the setup presented in [10]. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 4
Figure 4. Victim program and adversarial swap injection pre [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figures from the paper (2 more)
Figure 3
Figure 3. Figure 3: SWAP gate implemented with 3 CNOT gates. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png]
Figure 5
Figure 5. Figure 5: Circuits utilized in qubit sensing attack [13]. [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 14 canonical work pages

  1. [9]

    Experimental Charac- terization of Crosstalk Errors with Simultaneous Gate Set Tomography,

    K. Rudinger, C. W. Hogle, R. K. Naik, A. Hashim, D. Lobser, D. I. Santiago, M. D. Grace, E. Nielsen, T. Proctor, S. Seritan, S. M. Clark, R. Blume-Kohout, I. Siddiqi, and K. C. Young, “Experimental Charac- terization of Crosstalk Errors with Simultaneous Gate Set Tomography,” PRX Quantum, vol. 2, no. 4, p. 040338, Nov. 2021, publisher: American Physical Society

  2. [1]

    Software security,

    G. McGraw, “Software security,” IEEE Security & Privacy , vol. 2, no. 2, pp. 80–83, Mar. 2004

  3. [2]

    Software Security,

    M. Gunnell, “Software Security,” Jan. 2024. [Online]. Available: https://www.techopedia.com/definition/24866/software-security

  4. [3]

    Present landscape of quantum computing,

    V . Hassija, V . Chamola, V . Saxena, V . Chanana, P. Parashari, S. Mumtaz, and M. Guizani, “Present landscape of quantum computing,” vol. 1, no. 2, pp. 42–48, 2020. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.1049/iet-qtc.2020.0027

  5. [4]

    Cybersecurity for Quantum Computing,

    N. Kilber, D. Kaestle, and S. Wagner, “Cybersecurity for Quantum Computing,” Oct. 2021, arXiv:2110.14701 [quant-ph]. [Online]. Available: http://arxiv.org/abs/2110.14701

  6. [5]

    Quantum Computing in the NISQ era and beyond,

    J. Preskill, “Quantum Computing in the NISQ era and beyond,” Quan- tum, vol. 2, p. 79, Aug. 2018

  7. [6]

    A Case for Multi- Programming Quantum Computers,

    P. Das, S. S. Tannu, P. J. Nair, and M. Qureshi, “A Case for Multi- Programming Quantum Computers,” in Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture , ser. MICRO ’52. New York, NY , USA: Association for Computing Machinery, Oct. 2019, pp. 291–303

  8. [7]

    Enabling Multi-programming Mechanism for Quantum Computing in the NISQ Era,

    S. Niu and A. Todri-Sanial, “Enabling Multi-programming Mechanism for Quantum Computing in the NISQ Era,” Quantum, vol. 7, p. 925, Feb. 2023

Show all 21 references
  1. [8]

    Detecting crosstalk errors in quantum information processors,

    M. Sarovar, T. Proctor, K. Rudinger, K. Young, E. Nielsen, and R. Blume-Kohout, “Detecting crosstalk errors in quantum information processors,” Quantum, vol. 4, p. 321, Sep. 2020, arXiv:1908.09855 [quant-ph]

  2. [10]

    Analysis of crosstalk in NISQ devices and security implications in multi-programming regime,

    A. Ash Saki, M. Alam, and S. Ghosh, “Analysis of crosstalk in NISQ devices and security implications in multi-programming regime,” in Proceedings of the ACM/IEEE International Symposium on Low Power Electronics and Design , ser. ISLPED ’20. New York, NY , USA: Association for ...

  3. [11]

    Software Mitigation of Crosstalk on Noisy Intermediate-Scale Quantum Com- puters,

    P. Murali, D. C. Mckay, M. Martonosi, and A. Javadi-Abhari, “Software Mitigation of Crosstalk on Noisy Intermediate-Scale Quantum Com- puters,” in Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems,...

  4. [12]

    Stealthy SW APs: Adversarial SW AP Injection in Multi-Tenant Quantum Computing,

    S. Upadhyay and S. Ghosh, “Stealthy SW APs: Adversarial SW AP Injection in Multi-Tenant Quantum Computing,” Oct. 2023, arXiv:2310.17426 [quant-ph]

  5. [13]

    Qubit Sensing: A New Attack Model for Multi-programming Quantum Computing,

    A. Ash Saki and S. Ghosh, “Qubit Sensing: A New Attack Model for Multi-programming Quantum Computing,” Apr. 2021, arXiv:2104.05899 [quant-ph]. [Online]. Available: http://arxiv.org/abs/2104.05899

  6. [14]

    Programming physical quantum systems with pulse-level control,

    K. N. Smith, G. S. Ravi, T. Alexander, N. T. Bronn, A. R. R. Carvalho, A. Cervera-Lierta, F. T. Chong, J. M. Chow, M. Cubeddu, A. Hashim, L. Jiang, O. Lanes, M. J. Otten, D. I. Schuster, P. Gokhale, N. Earnest, and A. Galda, “Programming physical quantum systems with pulse-lev...

  7. [15]

    Securing NISQ Quantum Computer Reset Operations Against Higher Energy State Attacks,

    C. Xu, J. Chen, A. Mi, and J. Szefer, “Securing NISQ Quantum Computer Reset Operations Against Higher Energy State Attacks,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security , ser. CCS ’23. New York, NY , USA: Association for Computing M...

  8. [16]

    Qubithammer attacks: Qubit flipping attacks in multi-tenant superconducting quantum comput- ers,

    Y . Tan, N. Choudhury, K. Basu, and J. Szefer, “Qubithammer attacks: Qubit flipping attacks in multi-tenant superconducting quantum comput- ers,” arXiv preprint arXiv:2504.07875 , 2025

  9. [17]

    Reconstructing quantum circuits through side- channel information on cloud-based superconducting quantum comput- ers,

    B. Bell and A. Tr ¨ugler, “Reconstructing quantum circuits through side- channel information on cloud-based superconducting quantum comput- ers,” in 2022 IEEE International Conference on Quantum Computing and Engineering (QCE) , 2022, pp. 259–264

  10. [18]

    Short Paper: Device- and Locality- Specific Fingerprinting of Shared NISQ Quantum Computers,

    A. Mi, S. Deng, and J. Szefer, “Short Paper: Device- and Locality- Specific Fingerprinting of Shared NISQ Quantum Computers,” in Pro- ceedings of the 10th International Workshop on Hardware and Archi- tectural Support for Security and Privacy , ser. HASP ’21. New York, NY , US...

  11. [19]

    Quantum Leak: Timing Side-Channel Attacks on Cloud-Based Quantum Services,

    C. Lu, E. Telang, A. Aysu, and K. Basu, “Quantum Leak: Timing Side-Channel Attacks on Cloud-Based Quantum Services,” Jan. 2024, arXiv:2401.01521 [cs]

  12. [20]

    Towards an Antivirus for Quantum Computers,

    S. Deshpande, C. Xu, T. Trochatos, Y . Ding, and J. Szefer, “Towards an Antivirus for Quantum Computers,” in 2022 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) , Jun. 2022, pp. 37–40

  13. [21]

    Design of Quantum Computer Antivirus,

    S. Deshpande, C. Xu, T. Trochatos, H. Wang, F. Erata, S. Han, Y . Ding, and J. Szefer, “Design of Quantum Computer Antivirus,” in 2023 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), May 2023, pp. 260–270, iSSN: 2765-8406

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.