Security, Governance, and Access Control

Quantum platforms are expensive, scarce, and easy to misuse accidentally. A single poorly scoped token can leak experiment results, burn reservation time, expose proprietary circuits, or allow unreviewed workloads onto a shared device. Security for a quantum computer is therefore not only about protecting secrets. It is about protecting a constrained scientific instrument from unauthorized use, unsafe workloads, irreproducible changes, and governance drift.

The security model must cover both cloud-facing platform access and the local control environment. In cloud platforms, access is managed through accounts, instances, workspaces, roles, and provider-specific permissions. IBM Quantum controls access through assigned instances that manage workload execution and usage configuration [R29]. Amazon Braket documents permissions and restrictions through AWS users, roles, policies, devices, notebooks, and S3 buckets [R30]. Azure Quantum uses Azure RBAC for workspaces, including roles such as Owner, Contributor, Quantum Workspace Data Contributor, and Reader [R31].

For the operator, the practical rule is simple: treat the quantum stack as a production platform, not as a shared lab notebook.

12.1 Security boundary model

A quantum platform has at least five security boundaries.

flowchart TB
    User[User or service account] --> Portal[Cloud portal / API]
    Portal --> Workspace[Workspace / instance / project]
    Workspace --> Scheduler[Quantum scheduler]
    Scheduler --> Control[Control plane]
    Control --> QPU[QPU and measurement system]
    QPU --> Results[Result storage]
    Results --> User

    Secrets[Tokens and credentials] -. protect .-> Portal
    Policies[Policy engine] -. constrains .-> Workspace
    Safety[Hardware safety rules] -. constrains .-> Control
    Audit[Audit logs] -. observes .-> Portal
    Audit -. observes .-> Scheduler
    Audit -. observes .-> Results

Each boundary needs a different control.

A mature platform names these boundaries explicitly. An immature platform spreads them across dashboards, notebooks, shell scripts, and tribal knowledge.

12.2 Identity is not enough

Authentication answers “who are you?” Authorization answers “what may you do?” Quantum operations require a third question: “under what physical and economic constraints may this run?”

flowchart LR
    AuthN[Authentication] --> AuthZ[Authorization]
    AuthZ --> Entitlement[Device and project entitlement]
    Entitlement --> Budget[Usage and cost budget]
    Budget --> Safety[Hardware safety policy]
    Safety --> Admission{Admit workload?}
    Admission -- yes --> Run[Submit job]
    Admission -- no --> Reject[Reject with reason]

A user may be authorized to use a platform but not authorized to:

• target a premium device,
• use a reserved QPU window,
• submit pulse-level or timing-sensitive workloads,
• request excessive shots,
• bypass mitigation defaults,
• access calibration data for restricted devices,
• export result artifacts outside the project boundary.

This is why quantum access control should be policy-based, not only role-based.

12.3 Project isolation

A project is the smallest unit that should combine people, workloads, devices, budgets, secrets, and data-retention policy.

flowchart TB
    Org[Organization] --> ProjectA[Project A]
    Org --> ProjectB[Project B]
    ProjectA --> UsersA[Users]
    ProjectA --> SecretsA[Secrets]
    ProjectA --> DataA[Result bucket]
    ProjectA --> BudgetA[Budget]
    ProjectA --> DevicesA[Allowed targets]
    ProjectB --> UsersB[Users]
    ProjectB --> SecretsB[Secrets]
    ProjectB --> DataB[Result bucket]
    ProjectB --> BudgetB[Budget]
    ProjectB --> DevicesB[Allowed targets]

Project isolation prevents accidental cross-contamination. A chemistry team should not have to trust that a finance-optimization notebook never reads its result bucket. A compiler team should not be able to run experimental transformations on production workloads without a promotion gate.

The project object should be treated as infrastructure:

project: catalyst-screening
owners:
  - quantum-platform@example.com
allowed_targets:
  - ibm:premium:specific-family
  - simulator:statevector
max_shots_per_job: 100000
max_jobs_per_day: 200
result_retention_days: 365
data_export: restricted
calibration_visibility: summarized
review_required_for:
  - pulse_level_control
  - reserved_windows
  - public_release_results

This kind of policy is more useful than a prose wiki page because it can be evaluated automatically.

12.4 Token and credential hygiene

Quantum users often start from notebooks. Notebooks are dangerous credential environments because they encourage copying tokens into cells, committing stateful files, and sharing execution contexts.

flowchart TD
    Token[Long-lived token] --> Notebook[Notebook cell]
    Notebook --> Repo[Accidental commit]
    Notebook --> SharedImage[Shared VM image]
    Notebook --> Logs[Verbose logs]
    Repo --> Leak[Credential leak]
    SharedImage --> Leak
    Logs --> Leak

Operational controls:

The platform should reject workloads that arrive without a project identity and should record the identity used for every compilation, submission, result read, and export.

12.5 Governance for scarce devices

A QPU is not an ordinary cloud instance. Even when accessed through cloud APIs, it represents limited calibrated time. Governance must therefore include scarcity and fairness.

flowchart LR
    Demand[Incoming demand] --> Classify[Classify workload]
    Classify --> Quota[Apply quota]
    Quota --> Priority[Apply priority]
    Priority --> Reservation{Reserved window?}
    Reservation -- yes --> Window[Use reservation policy]
    Reservation -- no --> Shared[Use shared queue]
    Window --> Audit[Audit usage]
    Shared --> Audit

Governance decisions should be transparent. If one team receives priority during a reserved calibration window or a paper deadline, other teams should see that as a policy outcome rather than random queue behavior.

A useful governance report includes:

• QPU time consumed by project,
• useful-result rate by project,
• failed-job rate by cause,
• reserved-window utilization,
• cancelled or rejected jobs,
• budget exceptions,
• policy overrides and approvers.

12.6 Workload safety policy

Quantum workloads can be unsafe in ways that do not exist in ordinary software. The main risk is not that a circuit “crashes” the QPU like a process crashes a machine. The risk is that a workload drives the control system outside validated operating assumptions, invalidates calibration, or produces misleading results that look authoritative.

flowchart TB
    Workload[Submitted workload] --> Static[Static validation]
    Static --> Limits[Depth / width / shots limits]
    Limits --> Timing[Timing constraints]
    Timing --> Calibration[Calibration compatibility]
    Calibration --> Target[Target policy]
    Target --> Decision{Safe?}
    Decision -- yes --> Queue[Queue]
    Decision -- no --> Explain[Reject with diagnostics]

Safety policy should cover:

Policy failures should be explainable. A rejected user should see a repair path, not only a denial.

12.7 Auditability and non-repudiation

Every result should be reconstructible as an operational event. That does not mean the quantum state can be replayed. It means the platform can reconstruct the classical and operational context of the run.

sequenceDiagram
    participant U as User
    participant API as Platform API
    participant C as Compiler
    participant S as Scheduler
    participant Q as QPU
    participant R as Result store
    participant A as Audit log

    U->>API: submit workload
    API->>A: record identity and policy context
    API->>C: compile with target profile
    C->>A: record compiler version and options
    C->>S: submit executable
    S->>A: record queue decision
    S->>Q: execute
    Q->>R: write result artifact
    R->>A: record artifact hash and access policy

Audit records should include hashes of submitted artifacts, compiler outputs, calibration snapshots, result files, and trust reports. This makes disputes concrete: which artifact ran, under which policy, on which device state?

12.8 Post-quantum cryptography is part of the security roadmap

NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. A KEM establishes shared key material; it does not directly encrypt application payloads. In March 2025, NIST selected HQC for standardization as an additional KEM. Selection is distinct from a final standard [R32]. Quantum platform teams should coordinate migration with enterprise security owners.

flowchart LR
    Inventory[Cryptographic inventory] --> Classify[Classify assets]
    Classify --> Hybrid[Hybrid / migration plan]
    Hybrid --> Test[Test interoperability]
    Test --> Rollout[Roll out PQC-ready paths]
    Rollout --> Monitor[Monitor failures]
    Monitor --> Inventory

For quantum platform operators, this means:

• avoid hard-coding legacy cryptographic assumptions into platform protocols,
• inventory long-lived secrets and result archives,
• protect data that may be valuable under “harvest now, decrypt later” threat models,
• coordinate with central security teams on PQC migration timing.

12.9 Security review checklist

Before a quantum platform is production-facing, answer these questions:

Security is operational only when it can be tested.

flowchart TB
    Checklist[Security checklist] --> Tests[Automated policy tests]
    Tests --> DryRun[Dry-run workload submissions]
    DryRun --> AuditReview[Audit-log review]
    AuditReview --> Findings{Findings?}
    Findings -- yes --> Remediate[Remediate controls]
    Remediate --> Tests
    Findings -- no --> Approve[Approve production access]

12.10 Operating principle

The goal is not to make quantum research slow. The goal is to make legitimate work fast because boundaries are clear, access is scoped, and unsafe paths fail before they touch the device.

Security should become part of the developer experience:

• a user can see which targets they may use,
• a rejected workload explains why,
• a project owner can inspect cost and result provenance,
• an operator can trace every result back to identity, policy, compiler, calibration, and device state.

That is the difference between a shared experimental service and a production quantum platform.

Additional technical sources: [R257].