Zero-Trust Quantum Access and Runtime Isolation

Quantum access should not be governed by a shared provider token, a lab workstation account, or a notebook that happens to work. Quantum systems combine expensive resources, sensitive intellectual property, export-sensitive workflows, experimental hardware, and evidence that may later support claims. Access control must be explicit and continuously evaluated.

NIST SP 800-207 describes zero trust as a model that moves away from implicit trust based on network location and toward resource-centric protection. CISA's Zero Trust Maturity Model adds a practical maturity framing across identity, devices, networks, applications, data, and cross-cutting capabilities. A quantum platform should apply these ideas to cloud targets, lab systems, control infrastructure, evidence stores, and automation agents. [R153] [R154]

Diagram loads as you read

Zero-Trust Quantum Access and Runtime Isolation · Figure 1

View diagram source

flowchart LR
    Principal[Principal] --> Decision[Policy decision point]
    Device[Device posture] --> Decision
    Workload[Workload manifest] --> Decision
    Target[Target sensitivity] --> Decision
    Data[Data classification] --> Decision
    Decision --> Enforcement[Policy enforcement point]
    Enforcement --> Resource[Quantum resource]

Quantum resources are not homogeneous

Access to a simulator is not the same as access to a live QPU. Access to a cloud QPU is not the same as access to pulse controls. Access to evidence may be more sensitive than access to raw execution.

Diagram loads as you read

Quantum resources are not homogeneous · Figure 2

View diagram source

flowchart TB
    Access[Quantum access] --> Simulator[Simulator]
    Access --> Runtime[Cloud runtime]
    Access --> Lab[Lab control plane]
    Access --> Pulse[Pulse/control primitives]
    Access --> Evidence[Evidence and results]
    Access --> Admin[Provider and billing admin]

Use resource classes.

Resource class	Risk
public simulator	low cost, low device risk
managed QPU runtime	cost, queue, data, evidence risk
reserved QPU session	denial-of-capacity, commercial risk
pulse/control access	device safety and validity risk
calibration systems	fleet-wide reliability risk
evidence store	IP, customer, scientific, and audit risk

Access is a runtime decision

Zero trust for quantum is not “login once and run anything.” Admission must evaluate context.

Diagram loads as you read

Access is a runtime decision · Figure 3

View diagram source

sequenceDiagram
    participant User
    participant Broker
    participant PDP as Policy decision point
    participant PEP as Enforcement point
    participant QPU
    User->>Broker: submit workload
    Broker->>PDP: principal + workload + target + data
    PDP-->>Broker: decision and obligations
    Broker->>PEP: scoped token + obligations
    PEP->>QPU: execute allowed operation
    PEP-->>Broker: audit event

Obligations may include:

maximum spend;
allowed targets;
required evidence level;
prohibition on pulse access;
retention period;
approval before external sharing;
mandatory simulation before hardware execution.

Runtime isolation

Isolation should separate tenants, projects, evidence, credentials, and provider contexts.

Diagram loads as you read

Runtime isolation · Figure 4

View diagram source

flowchart TB
    TenantA[Tenant A] --> BrokerA[Broker namespace A]
    TenantB[Tenant B] --> BrokerB[Broker namespace B]
    BrokerA --> VaultA[Secrets A]
    BrokerB --> VaultB[Secrets B]
    BrokerA --> EvidenceA[Evidence A]
    BrokerB --> EvidenceB[Evidence B]
    BrokerA --> Provider[Provider account boundary]
    BrokerB --> Provider

Provider-side isolation may be weaker than enterprise isolation. The platform broker must compensate with project-level accounts, scoped credentials, tags, logs, and evidence partitioning.

Capability-based access

Do not grant access by broad role alone. Grant capabilities.

Diagram loads as you read

Capability-based access · Figure 5

View diagram source

flowchart LR
    Role[Role] --> Capabilities[Allowed capabilities]
    Capabilities --> Compile[compile]
    Capabilities --> Simulate[simulate]
    Capabilities --> Submit[submit hardware job]
    Capabilities --> Reserve[reserve capacity]
    Capabilities --> Pulse[modify pulse]
    Capabilities --> Publish[publish claim]

Example capability policy:

Illustrative listing · yaml

capabilities:
  researcher:
    - simulate
    - submit_research_job
    - read_own_evidence
  platform_sre:
    - drain_target
    - view_health
    - open_provider_case
  calibration_engineer:
    - run_calibration
    - approve_target_profile
  external_collaborator:
    - simulate
    - read_shared_evidence
forbidden_combinations:
  - [external_collaborator, pulse_modify]
  - [billing_admin, publish_claim]

Token design

Long-lived provider tokens are operational debt.

Diagram loads as you read

Token design · Figure 6

View diagram source

flowchart LR
    Identity[Identity provider] --> Broker[Quantum broker]
    Broker --> Token[Short-lived scoped token]
    Token --> Provider[Provider runtime]
    Broker --> Audit[Audit log]
    Token --> Expire[Automatic expiration]

Tokens should be short-lived, project-scoped, target-scoped, and bound to a workload manifest. When the provider does not support all of those constraints, enforce them at the broker.

Lab access and physical presence

Lab systems require stronger controls than remote notebook access.

Diagram loads as you read

Lab access and physical presence · Figure 7

View diagram source

flowchart TB
    LabAccess[Lab access request] --> Identity[Identity check]
    LabAccess --> Training[Training status]
    LabAccess --> Safety[Safety authorization]
    LabAccess --> Change[Approved change ticket]
    Identity --> Permit{Permit?}
    Training --> Permit
    Safety --> Permit
    Change --> Permit
    Permit -- yes --> Session[Time-bound lab session]
    Permit -- no --> Deny[Deny and record]

The same person may be allowed to run cloud jobs but not adjust control electronics or cryogenic procedures.

Data-plane isolation

Execution metadata can reveal sensitive information: problem class, molecular target, optimization model, customer name, budget, and research direction.

Diagram loads as you read

Data-plane isolation · Figure 8

View diagram source

erDiagram
    PROJECT ||--o{ WORKLOAD : owns
    PROJECT ||--o{ SECRET : uses
    WORKLOAD ||--o{ JOB : submits
    JOB ||--o{ RESULT : produces
    RESULT ||--o{ EVIDENCE_PACKAGE : supports
    PRINCIPAL ||--o{ AUDIT_EVENT : triggers

Protect metadata with the same seriousness as source code.

Break-glass operations

Emergency operations must be possible, but visible.

Diagram loads as you read

Break-glass operations · Figure 9

View diagram source

stateDiagram-v2
    [*] --> Normal
    Normal --> BreakGlassRequested
    BreakGlassRequested --> Approved
    Approved --> ElevatedSession
    ElevatedSession --> AutoExpire
    AutoExpire --> Review
    Review --> Normal
    BreakGlassRequested --> Denied

Break-glass sessions should require:

reason;
approver;
time limit;
session recording where practical;
post-action review;
automatic revocation.

Zero trust failure modes

Diagram loads as you read

Zero trust failure modes · Figure 10

View diagram source

flowchart TB
    Failure[Failure mode] --> SharedToken[Shared provider token]
    Failure --> NotebookSecret[Secret in notebook]
    Failure --> OverbroadRole[Overbroad role]
    Failure --> UnlabeledData[Unlabeled data]
    Failure --> MissingAudit[Missing audit trail]
    Failure --> AutomationRunaway[Automation outside policy]

The remedy is not more meetings. The remedy is policy evaluation in the submission path.

Minimal quantum zero-trust checklist

Control	Required behavior
identity	every run has a principal and project
device posture	high-risk operations require trusted device or lab station
workload manifest	target, data class, cost, and evidence level are declared
target policy	sensitive targets require approval
data policy	source/results/metadata are classified
audit	every decision and enforcement event is recorded
revocation	access can be disabled centrally

Quantum access is not a login. It is a continuously evaluated contract.