On the Figures of Merit for Quantum Software Security: Toward a Benchmarking Rubric

arXiv:2608.05831v1 [cs.CR] 6 Aug 2026

On the Figures of Merit for Quantum Software Security: Toward a Benchmarking Rubric Badhon Rahman

Majid Haghparast

Tommi Mikkonen

Faculty of Information Technology University of Jyväskylä Jyväskylä, Finland badhon.b.rahman@jyu.fi

Faculty of Information Technology University of Jyväskylä Jyväskylä, Finland majid.m.haghparast@jyu.fi

Faculty of Information Technology University of Jyväskylä Jyväskylä, Finland tommi.j.mikkonen@jyu.fi

Abstract—Quantum software is increasingly provided through multi-tenant and cloud-based Quantum-as-a-Service (QaaS) stacks. A growing concern about the diverse attack vectors across the pipeline has been demonstrated in recent research. Yet the community has converged on three mature pillars: Scale (Qubit Count), Quality (Quantum Volume), and Speed (Circuit Layer Operations per Second (CLOPS)) for the merit performance figures. Moreover, it has also begun to define software-quality metrics. However, the security of quantum software remains largely unmeasured. A few quantitative security indicators, such as Total Variation Distance (TVD) and Degree of Functional Corruption (DFC), exist. Although they were introduced ad hoc for individual circuit obfuscation techniques, they are incompatible. We assert that the security of quantum software deserves the same attention as the performance: an explicit set of Security Figures of Merit (S-FoMs). The research of this paper is threefold: (i) characterizes a three-layer measurement gap, (ii) proposes a structured S-FoM set organized by ISO/IEC 25010 security sub-characteristics, QaaS pipeline mapping, and measurement maturity, and (iii) defines a benchmarking rubric that normalizes and aggregates S-FoMs into a combined Quantum Software Security Posture (QSSP) score. Additionally, an illustrative reanalysis of published obfuscation techniques has been presented. Our aim is a first step toward security-aware benchmarking of the Quantum Software Stack (QSS). Index Terms—Quantum Software Engineering, Quantum Security, Quantum Software Security, Security Metrics, Quantumas-a-Service, Benchmarking.

I. I NTRODUCTION Quantum Software is swiftly moving from a theoretical curiosity to engineering practice [1]. However, its security properties remain far less standardized than its functional or performance characteristics. As quantum programs are progressively executed through the Quantum-as-a-Service (QaaS) platforms, where scheduling, compilation, and multi-tenant hardware remain outside the user’s trust boundary and stealthy attacks have already been demonstrated [11], [12], [20], [21]. The classification of the security challenges of Quantum Software Engineering (QSE) has now been documented [18]; now we are lacking a way to quantify them. A defense is as functional as our ability to measure it. For performance, it has standardized terminology, Figures of This work has been supported by the Business Finland through project SeQuSoS (Grant No. 112/31/2024), and Research Council of Finland through project Profi 8 - qSIME (Grants No. 365343).

Merit (FoMs) measured via agreed protocols. For example, Quantum Volume apprehends the largest square circuit that one device runs reliably [2]. CLOPS frame device capability along speed, quality, and scale as a speed FoM [3]. Quantum software quality is also emerging, and classical metrics (size and structure measures) are starting to be adapted to quantum programs [4]. A set of circuit-understandability metrics has been published that aligns with ISO/IEC 25010 [5], [6]. But for security, the quantitative security indicators that are currently available reside in one specific defense. To illustrate, within circuit obfuscation, the Total Variation Distance (TVD) [7] and the Degree of Functional Corruption (DFC) [8] measure how well a transformation hides functionality, yet they are not comparable. Therefore, no shared definition or rubric is currently available to permit one practitioner to say that tool A is more secure than tool B for quantum software. In this paper, we present Security Figures of Merit (SFoMs) and a rubric that combines them so that security can be measured like performance. Our contributions are as follows: (i) Characterization of three-layer measurement gap among performance FoMs, software-quality metrics, and fragmented/absent security metrics section II; (ii) For quantum software, a structured set of candidate S-FoMs organized by ISO/IEC 25010 security sub-characteristics, QaaS pipeline mapping, and maturity tag section III; (iii) a benchmarking rubric that normalizes S-FoMs and aggregates into a composite Quantum Software Security Posture (QSSP) score section IV; and (iv) an illustrative reanalysis of published obfuscation techniques substantiating non-comparability of current reporting and the comparability our rubric restores section V. In section VI, we present a conclusion and discuss our future work. II. BACKGROUND & M EASUREMENT G AP A. Layer 1: Performance Figures of Merit (Mature) For quantum computers, benchmarks are defined by FoMs or key performance indicators and measured under a stated protocol. Component level FoMs encompass coherence times (T1 /T2 ), single-qubit, two-qubit gates, and readout fidelities. In addition, the system level FoMs aggregate Quantum Volume [2] and the speed / quality / scale with CLOPS [3]. The application level FoMs mainly report success on the real

workloads. This layer is proportionately standardized and supported by tools. As a result, provides us with a template with a metric, a protocol, and a normalization that makes devices comparable. B. Layer 2: Software Quality Metrics (Emerging) Quantum Software Engineering (QSE) has started to import software measurements into quantum programs. Various research, for example, Zhao [4] adapted structure and size metrics, including lines of code, Halstead, cyclomatic complexity, and information flow, to the quantum software. In another research work, proposed and empirically validated metrics for quantum circuit complexity and understandability aligning with the ISO/IEC 25010 quality model and supported by an automatic computation tool (QMetrics) [5], [6]. Primarily, these efforts are operationalized in understandability and maintainability but not security. However, security holds a place in the nine characteristics of ISO/IEC 25010:2023, and sub-characteristics contain integrity, confidentiality, nonrepudiation, accountability, authenticity, and resistance. C. Layer 3: Security Metrics (Fragmented / Absent) Circuit obfuscation is the only domain in the security level that is frequently assessed against the untrusted compilers. TVD quantifies the statistical distance of the original and obfuscated output distributions [7]. The higher the value of TVD, indicates stronger the obfuscation. In contrast, DFC measures the functional corruption on [-1, 1], and here lower value of DFC means greater concealment [8]. A methodology called ”Split Compilation” was presented to keep the intellectual properties (IPs) secure from untrusted compilers by splitting the quantum circuit into different parts and sending them to multiple compilers at different times [9]. Additionally, a secure compilation methodology of quantum circuits for untrustworthy compilers by embedding one small random circuit was shown in recent research [10]. However, all these available indicators are valuable but fragmented. Each one of them is linked to one technique; none is crafted as a reusable FoM. Likewise, the other wider threat surface, like authentication, multi-tenant isolation, and accountability, has no comparable metric. At present, post-quantum cryptography benchmarking surfaces as ”quantum security metrics” and evaluates mainly the cryptographic strength of quantum algorithms. It is a completely different layer from the security of the QSS. Hence, the gap is specific, and there is no shared, multi-property set of S-FoMs and rubric to compare quantum software tools on security. III. S ECURITY F IGURES OF M ERIT F OR Q UANTUM S OFTWARE We define the Security Figures of Merit for quantum software as a quantity that (a) measures one security characteristic or overhead experienced by a quantum software artifact or its execution, (b) are calculated by a stated protocol against one declared attack model, and (c) can be normalized to a common [0,1] scale; here, a higher score denotes stronger security. In

Table I, we propose a set of candidates organized by ISO/IEC 25010:2023 security sub-characteristics with a cross-cutting overhead row. In addition, the table also mapped with the the QaaS pipeline stages of [13] (S1: Developer Environment, S2: Authentication & Submission, S3: Cloud Orchestration & Compilation, S4 - Quantum Hardware Execution, S5: Result Return Path, S6: Hybrid Iteration Loop), and labeled with measurement maturity: E = Established (Existing and defined metric or protocol), A = Adaptable (Existing measurable quantity), and P = Proposed (no quantum-specific quantity yet). We have observed two essential points from the table. Firstly, confidentiality is the sole well-instrumented property (obfuscation FoMs) and confirms that at present quantitative security research is concentrated at S3. Secondly, the accountability row (PC & ALT) labeled with P is the least explored property without an existing quantum-specific metric. In addition to the maturity column, the empty cell resembles the place where new protocols are urgently needed. IV. B ENCHMARKING RUBRIC A set of S-FoMs develops into a benchmark only when the metrics are commensurable and integrated under explicit assumptions. Here, we propose three steps that are designed with the classical benchmark requirements: relevance, reproducibility, fairness, verifiability, and usability [26]. Attack-model declaration: Each and every S-FoM will be reported against one stated adversary. A security number without an adversary is meaningless. For instance, obfuscation strength is conditional on the reverse-engineering attack keeping in mind. One defense that is strong against one specific attack may fail against another. Hence, the rubric requires a oneline threat model (capabilities, access, and stage) per reported S-FoM. So that, all together with the measurement protocol (backend, calibration snapshot, workload suite, shot budget, seed) makes the number reproducible. Normalization: For each S-FoM value mi is mapped to an orientation-corrected score m̂i ∈ [0, 1], here 1 is strongest security. The score is calculated by max-min scaling between two declared reference points. The weakest value m◦i and a strongest or saturation value m⋆i [27]:   m̂i = min 1, max 0, (mi − m◦i )/(m⋆i − m◦i ) (1) The reference absorb orientation (m⋆i < m◦i for lower is stronger metrics such as DFC, MER, XS, ASR, COD, and SO). For example, DFC applies (m⋆i = −1 , m◦i = 1) and force unbounded quantities (grows to infinity) such as adversary effort to declare a saturation point. They are part of the benchmark definition and are published with the scores. Weighted aggregation: A composite Quantum Software Security Posture score is a weighted sum over the chosen SFoMs: QSSP =

N X i=1

wi m̂i ,

X i

wi = 1, wi ≥ 0,

(2)

TABLE I C HARACTERISTICS S ECURITY F IGURES OF M ERIT FOR QUANTUM SOFTWARE SECURITY CORRESPONDING BY ISO/IEC 25010:2023 SECURITY SUB - CHARACTERISTICS , ALIGNING WITH Q AA S PIPELINE STAGES , AND ELUCIDATED WITH MEASUREMENT MATURITY (E: E STABLISHED , A: A DAPTABLE , P: P ROPOSED ). Property

Security Figure of Merit

What it quantifies

Stage

Mat.

IP obfuscation strength (OS)

Statistical distance (Obfuscation Quality) between original and obfuscated output (TVD) Degree of Functional Corruption (DFC) ∈ [−1, 1]; lower is stronger Adversary effort/success to recover circuit or compiler IP from circuit snapshots or passes Clone accuracy (comparison with the original) by an QML-model reverse-engineering extraction adversary; lower is stronger

S3

E

[7], [8]

S3

E

[8]

S3

A

[9], [14]

S5,S6

A

[15]

Detectability of adversarial result/parameter tampering via cross-device shot and iteration distribution Accreditation based upper bound on returned output deviation from ideal

S5,S6

A

[16]

S4,S5

A

[19]

Confidentiality Functional concealment (FC) Reverse-engineering resistance (RER) Model-extraction resistance (MER)

Integrity

Result tamper detectability (RTD) Output verifiability (OV)

Authenticity

Device attestation strength (DAS)

Quantum existential unforgeability classical-PUF fingerprint uniqueness)

with

S2,S4

A

[22]

Non-repudiation & accountability

Provenance completeness (PC)

Fraction of pipeline events carrying attributable, tamperevident records Cryptographic integrity coverage of job logs (e.g., hashchained)

S2–S6

P

[13]

S2–S6

P

—

Inter-circuit interference under co-tenancy, lower is stronger Hellinger distance between output distributions of colocated executions Fraction of injection/crosstalk attacks succeeding under a defense; lower is stronger

S4

A

[17], [23]

S4

A

[24]

S4

A

[11], [12], [24]

S1–S6

E

[8], [9], [16]

Audit-log tamper-evidence (ALT) Crosstalk susceptibility (XS) Resistance Co-tenancy output divergence (COD) Attack success rate (ASR) Cross-cutting

Security overhead (SO)

(qPUF

Basis

Added depth/gate/runtime/shot cost incurred by the controls

Additionally, these weights are elicited by a multi-criteria method such as Analytic Hierarchy Process (AHP) [25]. In order that conflicting and context-dependent priorities (e.g., IP secrecy) are made clear rather than hidden. The methodology of composite indicator includes two requirements [27]: i) One weighted sum is completely compensatory; one property’s strength can mask collapse on another. At times, it can happen with the weakest-link character of security. For this reason, QSSP is always published withQa score vector and its minimum with the geometric form ( i m̂iwi ) as the conservative alternative. ii) The reported rankings must be demonstrated to plausible weight perturbations. Since security ˆ score is purchased with resources, the Security Overhead (SO) is not incorporated into QSSP, but is stated alongside it. A tool that dominates another on both the QSSP and the overhead axes is preferred, analogous to the Pareto-frontier reading of the volumetric performance benchmark [28]. Here, a number ˆ is needed and QSSPλ = QSSP (1 − λ(1 − SO)) reveals the trade-off through a tunable λ. The Figure 1 summarizes our research by dividing it into three steps: 1. QaaS Pipeline, 2. Security sub-characteristics, and 3. The Rubric.

trust boundary S1

S2

S3

S4

S5

S6

S-FoMs per stage (Table I) Confidentiality OS FC RER MER

1. Declare Adversary + Protocol

Integrity RTD OV

2. Normalize Eq. (1): m̂i ∈ [0, 1]

Authenticity DAS

3. Aggregate QSSP = P i wi m̂i

Accountability PC ALT

Resistance XS COD ASR

Report QSSP + vector, min ˆ SO (Pareto)

Fig. 1. Three step overview of our research: Six stage QaaS pipeline outlined with the S-FoM candidates organized with standard security subcharacteristics and combines them with the rubric into QSSP.

V. I LLUSTRATIVE R EANALYSIS To demonstrate both the concern and the solution, we reanalyze two published quantum software security controls (confidentiality) at the Cloud Orchestration and Compilation level. The values are taken from the original papers and not new measurements. The Dummy CNOT gate insertion technique [7] reports TVD up to 28.83% with modest gate and depth overhead. In contrast, the randomized reversible gate

technique [8] reports 1.92 and uniformly negative DFC with 1-3% degradation in fidelity. However, obfuscation literature including these two reports ”TVD” under incompatible definitions. Such as normalizing the summed ℓ1 count difference by the number of shots varying in [0,2], while the textbook TVD divides by twice the shots and varies in [0,1]. Two different ”TVD” values defined on different scales cannot be compared. This is exactly the motivation for standardized SFoM definitions. When a single TVD definition and common attack model are fixed, then the OS, FC, and RER scores are normalized by equation (1). Scores will be combined with weights reflecting an IP protection priority on a multi-tenant cloud. As a result, the rubric will get a comparable confidentiality sub-score for ˆ individually, makes the each of the tool. By reporting SO security overhead tradeoff explicit. Ultimately, the contribution is not the ranking itself but that structured S-FoMs turn non-comparable and scattered numbers into an interpretable comparison. VI. C ONCLUSION AND F UTURE W ORK We have argued that quantum software security should be measured with the same precision as performance and proposed Security Figures of Merit organized and structured by ISO/IEC 25010, QaaS pipeline, and maturity tag. In addition, a rubric is defined that normalizes and aggregates them into a composite posture score with a security overhead tradeoff. A reanalysis of the published obfuscation techniques indicated that current reporting is non-comparable, and S-FoMs restore the compatibility. In our next step, we plan to design and develop a benchmarking tool that computes the established S-FoMs over Qiskit and Cirq programs, together with the protocols for the metrics that are currently unmeasured. R EFERENCES [1] J. M. Murillo et al., “Quantum Software Engineering: Roadmap and Challenges Ahead,” ACM Transactions on Software Engineering and Methodology, Jan. 2025, doi: https://doi.org/10.1145/3712002. [2] A. W. Cross, L. S. Bishop, S. Sheldon, P. D. Nation, and J. M. Gambetta, “Validating quantum computers using randomized model circuits,” Physical Review A, vol. 100, no. 3, Sep. 2019, doi: https://doi.org/10.1103/physreva.100.032328. [3] A. Wack et al., “Quality, Speed, and Scale: three key attributes to measure the performance of near-term quantum computers,” arXiv.org, Oct. 28, 2021. https://arxiv.org/abs/2110.14108 [4] J. Zhao, “Some Size and Structure Metrics for Quantum Software,” Ieee.org, 2021, doi: https://doi.org/10.1109/Q-SE52541.2021.00012. [5] J. A. Cruz-Lemus, Moisés Rodrı́guez, Raúl Barba-Rojas, and M. Piattini, “Quantum Software Quality Metrics,” pp. 125–142, Jan. 2024, doi: https://doi.org/10.1007/978-3-031-64136-7 6. [6] ISO, “Systems and software engineering—SQuaRE—Product quality model,” ISO, 2023. https://www.iso.org/standard/78176.html [7] A. Suresh, A. A. Saki, M. Alam, R. Onur Topaloglu, and S. Ghosh, “Short Paper: A Quantum Circuit Obfuscation Methodology for Security and Privacy,” Workshop on Hardware and Architectural Support for Security and Privacy, pp. 1–5, Oct. 2021, doi: https://doi.org/10.1145/3505253.3505260. [8] S. Das and S. Ghosh, “Randomized Reversible Gate-Based Obfuscation for Secured Compilation of Quantum Circuit,” arXiv.org, 2023. https://arxiv.org/abs/2305.01133

[9] A. A. Saki, A. Suresh, R. O. Topaloglu and S. Ghosh, ”Split Compilation for Security of Quantum Circuits,” 2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD), Munich, Germany, 2021, pp. 1-7, doi: 10.1109/ICCAD51958.2021.9643478. [10] S. Das and S. Ghosh, “Secure Quantum Circuit Compilation Methodology for Untrusted Compilers,” 2025 IEEE International Conference on Quantum Computing and Engineering (QCE), pp. 2191–2201, Aug. 2025, doi: https://doi.org/10.1109/qce65121.2025.00239. [11] Y. Tan, N. Choudhury, K. Basu, and J. Szefer, “QubitHammer: Remotely Inducing Qubit State Change on Superconducting Quantum Computers,” arXiv.org, 2025. https://arxiv.org/abs/2504.07875 (accessed May 26, 2026). [12] L. Wei, S. Wang, S. Dutta, M. W. El, and A. Chattopadhyay, “SWAP Attack: Stealthy Side-Channel Attack on Multi-Tenant Quantum Cloud System,” arXiv.org, 2025. https://arxiv.org/abs/2502.10115 [13] B. Rahman, M. Haghparast, and T. Mikkonen, “An End-to-End Threat Model for the Quantum-as-a-Service Pipeline,” 2026 IEEE International Conference on Quantum Computing and Engineering (QCE), Accepted, In-Press. [14] S. Kundu and S. Ghosh, “Inverse-Transpilation: Reverse-Engineering Quantum Compiler Optimization Passes from Circuit Snapshots,” Proceedings of the Great Lakes Symposium on VLSI 2025, pp. 273–277, Jun. 2025, doi: https://doi.org/10.1145/3716368.3735298. [15] A. Ghosh and S. Ghosh, “The Quantum Imitation Game: Reverse Engineering of Quantum Machine Learning Models,” Proceedings of the 2024 Workshop on Attacks and Solutions in Hardware Security, pp. 48–57, Nov. 2024, doi: https://doi.org/10.1145/3689939.3695783. [16] S. Upadhyay and S. Ghosh, “Trustworthy and reliable computing using untrusted and unreliable quantum hardware,” Frontiers in Computer Science, vol. 6, Aug. 2024, doi: https://doi.org/10.3389/fcomp.2024.1431788. [17] S. Ovaskainen, M. Haghparast, and T. Mikkonen, “Quantum Software Security Challenges Within Shared Quantum Computing Environments,” 2025 IEEE International Conference on Quantum Computing and Engineering (QCE), pp. 68–72, Aug. 2025, doi: https://doi.org/10.1109/qce65121.2025.10296. [18] B. Rahman, M. Haghparast, and T. Mikkonen, “Classification of security challenges and mitigation approaches in the quantum software engineering,” Journal of Systems and Software, vol. 238, p. 112884, Aug. 2026, doi: https://doi.org/10.1016/j.jss.2026.112884. [19] S. Ferracin, T. Kapourniotis, and A. Datta, “Accrediting outputs of noisy intermediate-scale quantum computing devices,” New Journal of Physics, vol. 21, no. 11, p. 113038, Nov. 2019, doi: https://doi.org/10.1088/1367-2630/ab4fd6. [20] C. Xu, F. Erata, and J. Szefer, “Exploration of Power Side-Channel Vulnerabilities in Quantum Computer Controllers,” Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, Nov. 2023, doi: https://doi.org/10.1145/3576915.3623118. [21] C. Xu and J. Szefer, “Security Attacks Abusing Pulse-level Quantum Circuits,” 2025 IEEE Symposium on Security and Privacy (SP), pp. 222–239, May 2025, doi: https://doi.org/10.1109/sp61157.2025.00083. [22] M. Arapinis, M. Delavar, M. Doosti, and E. Kashefi, “Quantum Physical Unclonable Functions: Possibilities and Impossibilities,” Quantum, vol. 5, p. 475, Jun. 2021, doi: https://doi.org/10.22331/q-2021-06-15-475. [23] Abdullah Ash-Saki, M. Alam, and S. Ghosh, “Analysis of crosstalk in NISQ devices and security implications in multi-programming regime,” Aug. 2020, doi: https://doi.org/10.1145/3370748.3406570. [24] A. Kumar, M. Wang, C. Liu, A. Li, P. J. Nair, and P. Das, “Context Switching for Secure Multi-programming of Near-Term Quantum Computers,” arXiv.org, 2025. https://arxiv.org/abs/2504.07048 [25] T. L. Saaty, “Decision making with the analytic hierarchy process,” International Journal of Services Sciences, vol. 1, no. 1, p. 83, 2008, doi: https://doi.org/10.1504/ijssci.2008.017590. [26] J. v. Kistowski, J. A. Arnold, K. Huppler, K.-D. Lange, J. L. Henning, and P. Cao, “How to Build a Benchmark,” Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering, Jan. 2015, doi: https://doi.org/10.1145/2668930.2688819. [27] Joint Research Centre. Handbook on constructing composite indicators: methodology and user guide. OECD publishing, 2008. [28] R. Blume-Kohout and K. C. Young, “A volumetric framework for quantum computer benchmarks,” Quantum, vol. 4, p. 362, Nov. 2020, doi: 10.22331/q-2020-11-15-362.

Related documents

• Quantum non-local games: Quantum relations, projection lattices and rule operators#799701
• Semi-definite optimization of the measured relative entropies of quantum states and channels#1076698
• Verifiable quantum advantage in extremely low depth#627594
• Quantum Computing and the Future of Cybersecurity#1178687
• Quantum Computing and the Future of Cybersecurity#1178686