Research

Where the quantum software stack breaks

I find where the quantum software stack breaks — and make it measurable and secure.

My research looks at how quantum software stacks can be breached — at the level of the quantum software ecosystem, and in the cloud pipelines (Quantum-as-a-Service) that run circuits on real hardware — and at what can be done to make them secure.

What breaksWhere it breaksHow to measure itMitigationsOpen questions

What breaks

Four attack families, fourteen attack classes

In the classification paper we group the known attacks on quantum software into four families and break them down into fourteen classes, each with its origin, its consequences and the published specimens.

CrosstalkUnwanted interaction between qubits that another tenant or a malicious circuit can provoke on shared hardware.4 classes
  • Operational crosstalk
  • Idling crosstalk
  • Double-sided crosstalk
  • Qubit-flipping attacks
Side-channelInformation that leaks through what the execution consumes or emits rather than through the result itself.4 classes
  • Power side-channels
  • Timing side-channels
  • Quantum side-channels
  • Hybrid side-channels
Fault injectionDeliberately induced faults in the processor, its controller or the classical co-processors around it.3 classes
  • QPU faults
  • Controller faults
  • Auxiliary-processor faults
Pulse-levelAttacks that reach below the gate abstraction, into the control channels and pulses that drive the qubits.3 classes
  • Channel attacks
  • Pulse attacks
  • Compound attacks

Where it breaks

The Quantum-as-a-Service pipeline

A circuit travels through six stages between a developer’s laptop and real hardware. The threat model paper applies STRIDE end to end across them. Compilation and shared hardware lie past the trust boundary, outside the user’s control.

  1. S1
  2. S2
  3. S3
  4. S4
  5. S5
  6. S6

threats studied here → S3 – S5

  1. S1Developer environment

    SDK, notebooks and credentials on the developer’s own machine.

  2. S2Authentication & submission

    The job is authenticated, queued and handed over to the provider.

  3. S3Cloud & compilation

    The provider compiles the circuit for its hardware, out of the user’s sight.

  4. S4Hardware execution

    The circuit runs on a shared quantum processor next to other tenants’ jobs.

  5. S5Result return

    Measurement counts travel back to the user through the provider’s API.

  6. S6Hybrid loop

    Results feed the classical optimiser and the next iteration of the circuit.

results feed the next iteration (S6 → S1)

Six stages: 1. Developer environment: SDK, notebooks and credentials on the developer’s own machine. 2. Authentication & submission: The job is authenticated, queued and handed over to the provider. 3. Cloud & compilation: The provider compiles the circuit for its hardware, out of the user’s sight. 4. Hardware execution: The circuit runs on a shared quantum processor next to other tenants’ jobs. 5. Result return: Measurement counts travel back to the user through the provider’s API. 6. Hybrid loop: Results feed the classical optimiser and the next iteration of the circuit. The trust boundary lies between stage 2 and stage 3; threats were studied at stages 3 to 5.

How to measure it

Security figures of merit and one posture score

Performance has agreed figures of merit: qubit count, Quantum Volume, CLOPS. Security had none. The figures-of-merit paper proposes thirteen Security Figures of Merit (S-FoMs), organised by ISO/IEC 25010 security sub-characteristics and mapped to the six pipeline stages, and a three-step rubric that turns them into one Quantum Software Security Posture (QSSP) score.

  1. 1adversary

    Declare the adversary

    State who is attacking, what they can reach and what they want, so every measurement is read against the same threat.

  2. 2[0, 1]

    Normalise each S-FoM

    Map every Security Figure of Merit onto the interval [0, 1], so a timing indicator and a crosstalk indicator become comparable.

  3. 3QSSP

    Aggregate

    Combine the normalised figures into one Quantum Software Security Posture score. Security overhead is reported alongside, never inside, the score.

  4. Result

    1

    QSSP score

    + security overhead, reported separately

Mitigations

Thirty-plus approaches, mapped to the attack families

The classification paper maps more than thirty mitigation approaches to the four attack families. The table reproduces its comparative overview (Table 3); maturity levels come from the classification itself (Table 2).

  • Randomized compiling and frequency-aware compilation

    Scales to larger circuits but extends execution time and overhead

    Targets
    CrosstalkOperational, idling, double-sided (QubitVise) and qubit-flipping crosstalk on superconducting NISQ devices
    Goal
    Reliability-driven
    Maturity
    Randomized compiling: industry-ready · frequency-aware compilation: prototype
    Hardware
    Superconducting NISQ devices; compiler/tool support, open-source prototypes

  • RNS parallel quantum addition and moving-target strategies

    Currently limited to simulators or platform-specific prototypes; may increase qubit usage and runtime

    Targets
    CrosstalkAlternate CNOT, superposition alternate CNOT (SAC) and alternate phase change (APC) attacks on ion-trap devices
    Goal
    Security-driven
    Maturity
    Theoretical prototype (ion-trap simulator)
    Hardware
    Ion-trap or neutral-atom devices, or a specific cloud platform; domain-specific designs

  • Transpiler masking and compile-time strategies

    Prototype compiler passes; add transpilation overhead but modest runtime impact

    Targets
    Side-channelPower and quantum side-channels
    Goal
    Security-driven
    Maturity
    Qiskit transpiler prototype
    Hardware
    Vendor-specific features (IBM virtual Z gates, reset semantics)

  • Strategic gate insertion, intelligent scheduling and timing-noise injection

    Deployment depends on provider cooperation and may affect performance and scheduling

    Targets
    Side-channelPower and timing side-channels
    Goal
    Security-driven (conceptual)
    Maturity
    Theoretical
    Hardware
    Cloud-provider policies; access to schedulers and timing APIs

  • QASM scanning and idle tomography with pyGSTi

    Limited by tomography and simulation cost; suitable for small to moderate systems

    Targets
    Fault injectionQPU faults and controller faults
    Goal
    Security-driven
    Maturity
    Prototype (idle tomography in pyGSTi; compile-time checks in the Qiskit transpiler)
    Hardware
    Requires accurate noise models and provider-side simulation/instrumentation

  • One-Class SVM (ML-based scheduler anomaly detection)

    Scales with the number of users and jobs; adds metadata collection and inference overhead to scheduling

    Targets
    Fault injectionAuxiliary-processor (scheduler) faults
    Goal
    Security-driven
    Maturity
    ML scheduler prototype
    Hardware
    Multi-tenant quantum cloud; access to job metadata and scheduler hooks

  • Three-layer verification (channel, pulse syntax, pulse semantics)

    Adds provider-side verification cost; complexity grows with circuit size and calibration-data volume

    Targets
    Pulse-levelChannel, pulse and compound attacks
    Goal
    Security-driven
    Maturity
    Prototype
    Hardware
    Pulse-level access, calibration logs, DAG-comparison infrastructure

  • Cascading Secure Reset (CSR)

    Linear in qubit count; requires extra calibration but can be faster than a full system reset

    Targets
    Pulse-level
    Goal
    Security-driven
    Maturity
    not rated in the paper
    Hardware
    Superconducting devices with fine-grained pulse control and multi-level resets

Source: Tables 2 and 3 in Rahman, Haghparast & Mikkonen (2026), Journal of Systems and Software 238, 112884

Also classified in Table 2 but not part of the comparative overview: dynamical decoupling (experimental; crosstalk and power side-channels), crosstalk-aware scheduling and mapping, dummy gates and fuzzing, padding policies, disabling qubit-0, provider isolation and tenant placement fences (theoretical), spectator/canary-qubit monitoring, error-amplification protocols, compile-time antivirus and verified optimizers.

Open questions

What I am working on next

  • Q1

    How can Security Figures of Merit be validated on real hardware, rather than on simulators and published specimens?

  • Q2

    How does the end-to-end threat model extend across providers, when each cloud exposes a different pipeline and a different trust boundary?

  • Q3

    How can mitigations be made composable, so that defending against one attack family does not reopen another?