Quantum Threat Models and Abuse Cases

Quantum platforms deserve threat models that include ordinary cloud threats, laboratory threats, physics-control threats, provider threats, and scientific-integrity threats. A circuit can be stolen. A calibration can be poisoned. A benchmark can be gamed. A result can be overclaimed. A provider adapter can silently change the backend target. A malicious or careless operator can expose credentials, evidence, or sensitive problem encodings.

Data-centric threat modeling is useful because many quantum risks revolve around specific high-value artifacts: circuits, pulse schedules, backend snapshots, calibration data, measurement records, mitigation profiles, claims, and customer problem encodings. The initial public draft of NIST SP 800-154 frames threat modeling as a risk-assessment activity focused on attack and defense for selected logical entities, including data, applications, hosts, systems, or environments. [R180]

flowchart LR
    Asset[Quantum asset] --> Exposure[Exposure path]
    Exposure --> Actor[Threat actor]
    Actor --> Abuse[Abuse case]
    Abuse --> Control[Control or monitor]
    Control --> Residual[Residual risk]

Assets worth modeling

mindmap
  root((Quantum assets))
    Workload intent
    Circuit and IR
    Pulse schedules
    Calibration snapshots
    Measurement records
    Mitigation profiles
    Evidence packages
    Provider credentials

Abuse-case catalog

A conventional security review asks what can go wrong. A quantum platform review should ask what can go wrong physically, statistically, and operationally.

flowchart TB
    Abuse[Abuse cases] --> Cloud[Cloud abuse]
    Abuse --> Lab[Lab abuse]
    Abuse --> Runtime[Runtime abuse]
    Abuse --> Science[Scientific abuse]
    Abuse --> Provider[Provider abuse]
    Cloud --> Token[Credential theft]
    Lab --> Unsafe[Unsafe control change]
    Runtime --> Route[Wrong target routing]
    Science --> Claim[Unsupported claim]
    Provider --> Drift[Unannounced backend drift]

Important abuse cases include:

• submitting workloads under another tenant's quota;
• replaying old calibration records as if they were current;
• routing a sensitive workload to a disallowed region or provider;
• using a mitigation setting that narrows variance without disclosing bias;
• publishing a benchmark result without failed runs;
• modifying a pulse template without safety review;
• training an autonomous calibration agent on contaminated labels;
• deleting raw shots after only retaining favorable aggregate statistics.

Threat boundaries

Quantum platforms cross boundaries more often than ordinary applications. A single experiment may cross an enterprise control plane, a cloud provider, a quantum service provider, a simulator, a physical QPU, an HPC cluster, and a third-party validation environment.

flowchart LR
    User[Researcher or service] --> Enterprise[Enterprise control plane]
    Enterprise --> Broker[Quantum broker]
    Broker --> Provider[Provider API]
    Provider --> Runtime[Runtime service]
    Runtime --> QPU[QPU or simulator]
    QPU --> Evidence[Evidence store]
    Evidence --> Auditor[Reviewer or auditor]

Every boundary needs an explicit contract: identity, authorization, data classification, allowed target classes, logging, retention, and evidence integrity.

Quantum-specific threat questions

sequenceDiagram
    participant Reviewer
    participant Owner
    participant Broker
    participant Evidence
    Reviewer->>Owner: What is the asset being protected?
    Owner->>Broker: Map workload, target, and policy
    Broker->>Evidence: Retrieve prior execution facts
    Evidence-->>Reviewer: Return signed evidence
    Reviewer->>Owner: Approve, constrain, or block

Ask these questions before important workloads run:

1. What would be harmful if the problem encoding leaked?
2. Can this workload reveal customer, scientific, or strategic intent?
3. What backend targets are explicitly disallowed?
4. What calibration age or quality floor is required?
5. What evidence must exist before a claim is made?
6. What would a malicious provider adapter be able to change?
7. What human override paths exist, and are they logged?

Controls mapped to abuse cases

flowchart TB
    Abuse[Abuse case] --> Prevent[Preventive control]
    Abuse --> Detect[Detective control]
    Abuse --> Correct[Corrective control]
    Prevent --> Policy[Policy gate]
    Detect --> Telemetry[Telemetry and evidence]
    Correct --> Rollback[Rollback or quarantine]

Threat model as living artifact

The threat model must change whenever the platform changes. New compilers, mitigation strategies, runtime APIs, calibration agents, hardware accelerators, and provider regions all create new attack surfaces.

stateDiagram-v2
    [*] --> Draft
    Draft --> Reviewed
    Reviewed --> Active
    Active --> NeedsUpdate: interface or risk changes
    NeedsUpdate --> Reviewed
    Active --> Retired

A threat model is stale when it does not mention the current provider contracts, current evidence schema, current autonomous actions, and current operational boundaries.

Operational rule

Do not approve a quantum production workflow merely because its circuit is correct. Approve the workflow only when its assets, boundaries, abuse cases, controls, evidence requirements, and residual risks are explicit.

flowchart LR
    CorrectCircuit[Correct circuit] --> NotEnough[Not enough]
    NotEnough --> ThreatModel[Threat model]
    ThreatModel --> EvidencePlan[Evidence plan]
    EvidencePlan --> PolicyGate[Policy gate]
    PolicyGate --> Approved[Approved execution]