Six Control Points in a Rented Quantum Computer

Almost nobody will own a quantum computer. The machines need a dilution refrigerator or an ultra-high vacuum chamber, a team of physicists to keep them calibrated, and a replacement cycle measured in single-digit years. What organisations will have instead is an account, an API key, and a contract. Circuits go out over the network, measurement results come back, and someone else’s engineers keep the hardware running.

That arrangement is called quantum-compute-as-a-service, and it changes the sovereignty question. The debate is usually framed as who owns the qubits. For anyone reviewing a procurement file, the operative question is narrower and more answerable: which decisions about this workload can we still make after signing, and which ones has the provider reserved for itself?

There are six of those decisions. Each is a control point. Each is negotiable, and each one that goes unnegotiated is quietly transferred. This article walks through all six, then maps them onto the access models available today and the clause language that holds them in place.

What the Contract Actually Decides

The physical location of a quantum processor tells you less than you would expect. A machine on your own soil, operated entirely by a foreign vendor under foreign terms, may leave you with less practical control than a remote machine accessed under a contract that specifies scheduling priority, audit rights, and an exit path. Sovereignty in a service model is a property of the agreement, not of the geography.

This is familiar ground for anyone who has governed cloud procurement. The EuroHPC Joint Undertaking – the European Union body that pools member state and EU funding to procure supercomputers on European soil – has spent years demonstrating the point. Its machines run a great deal of imported technology. American processors and accelerators sit in European halls. What Europe kept was the layer above: the systems are owned under EU contracts, allocated through European access calls, and operated under European law. The silicon is foreign; the governance is not.

Quantum procurement is arriving at the same distinction faster, because the hardware is scarcer and the vendor list is shorter. When supplier options for a given modality are limited, the contract carries more weight than usual.

Six control points, then, in the order a reviewer should work through them.

Control Point One: Scheduling and Priority

A quantum processor is a queue. Jobs arrive, wait, run, and return results, and the queue discipline is set by whoever operates the machine. On a public service, that discipline is opaque to you and revisable at will.

This is fine while quantum work is exploratory. It stops being fine the moment a result feeds a decision with a deadline attached – a portfolio rebalance, a regulatory filing, a scheduled simulation run that has to complete before a hardware maintenance window closes. At that point the difference between a two-hour queue and a two-day queue is the difference between a working process and a broken one.

The instrument here is the service level agreement, the SLA: the contractual schedule that states what performance the provider guarantees and what happens when it fails to deliver. Most quantum cloud SLAs today cover API availability, which is the wrong thing. An API that responds promptly with “your job is position 340 in the queue” is technically available and operationally useless.

What to specify instead:

• Reserved capacity in device time, not API uptime. A stated number of hours per month on a named device or device class, or a stated number of shots available per period.
• Queue position or turnaround commitment. Maximum wait time from submission to execution, measured separately from execution duration.
• Named devices, with substitution rules. Quantum processors differ in qubit count, connectivity and error rates. A result obtained on one is not automatically reproducible on another, so a clause permitting the provider to route your job to “an equivalent device” needs a definition of equivalent that you wrote.
• Behaviour under contention. What happens when the provider’s own research teams, or a larger customer, want the same window.

Expect resistance. Many quantum services are still labelled experimental or preview precisely so that providers can avoid warranties. That is a defensible position for a technology at this maturity, and the correct response is not to demand enterprise SLAs from a research service. It is to recognise which of your workloads have genuinely moved past experimentation, and to renegotiate only those out of preview terms – or to accept that the workload is not ready for a service that cannot guarantee it a slot.

Control Point Two: Data Residency and Jurisdiction

Two things travel to the provider when a job is submitted: the circuit, and whatever input data parameterises it. Both land on the provider’s infrastructure, in whichever legal jurisdiction that infrastructure occupies.

Circuits are the underrated exposure. A quantum circuit is a structured description of a problem, and its structure is informative even without the input data. The number of qubits, the gate sequence, the choice of ansatz in a variational algorithm – these disclose what class of problem you are solving and roughly how large it is. A competitor or a foreign authority reading your circuit library learns your research direction. Treat circuits as sensitive intellectual property rather than as configuration.

The residency clauses that matter:

• All project data, circuits and results remain on infrastructure located within named jurisdictions at all times, with no replication outside them without written consent.
• Named permitted jurisdictions, positively listed. Not “the EU or equivalent” – equivalence is the provider’s judgement, and you will not be consulted when they make it.
• Notification and consent before any routing change, including temporary rerouting during maintenance. This is where residency usually leaks.
• Deletion on demand and on termination, extending to backups, with a stated timeframe.
• No use of your circuits or results for provider purposes beyond executing the job. Standard cloud terms frequently permit use of customer data for service improvement. Carve your quantum workloads out explicitly.

Germany’s arrangement with IBM is the reference case for a residency-first approach. An IBM Quantum System One was installed at Ehningen in 2021 and operated in partnership with Fraunhofer, with project data held in Germany under German and EU law. IBM subsequently opened a European quantum data centre in the same region, positioned explicitly for customers with residency and compliance requirements. The hardware and its core software remained IBM’s throughout. What changed was where the data sat and whose law governed it – which for a great many regulated workloads is the binding constraint.

While you are in the residency clauses, address the transport layer. Circuits and results move over ordinary network connections, protected by ordinary cryptography, and quantum services are no exception to the harvest-now-decrypt-later problem, where an adversary records encrypted traffic today and decrypts it years later, once a quantum computer can break the algorithm that protected it. Ask the provider for a dated plan to migrate its control plane, APIs and stored data to the NIST post-quantum standards – ML-KEM for key establishment, ML-DSA or SLH-DSA for signatures. What you are really testing is crypto-agility: whether the provider can change cryptographic algorithms without re-engineering the system around them. A provider that cannot describe how it would swap an algorithm has told you something about its engineering discipline more generally.

Control Point Three: Auditability

Quantum results are probabilistic. A circuit is executed many times – each repetition is a shot – and the result is a distribution over measurement outcomes rather than a single answer. Two runs of the same circuit on the same machine an hour apart will not produce identical distributions, because the machine’s error characteristics drift and are recalibrated between them.

This has a direct governance consequence. You cannot verify a quantum result by re-running it and checking the numbers match. Verification depends entirely on the metadata the provider chooses to record and release. If that metadata is thin, the service is a black box and the result is unauditable, which in a regulated context means unusable.

Specify, per job:

• Device identifier and the exact hardware revision used.
• Calibration state at execution time – the per-qubit error rates and gate fidelities measured most recently before the run. This is what changes between sessions and what explains discrepancies.
• Shot count and any random seeds.
• The compiled circuit as it was actually executed. Providers transpile submitted circuits to fit the device topology, and the executed circuit can differ substantially from the one you wrote.
• Error mitigation settings applied, and whether they were applied by default.
• Queue and execution timestamps.

A financial institution using a quantum optimisation routine in a model that falls under model risk governance needs every one of these to document how an output was produced. So does anyone investigating an anomalous result six months later, when the machine has been recalibrated a hundred times since.

Audit rights should extend past job metadata to the provider’s own controls: workload isolation between customers, encryption at rest and in transit, and access management on the operations side. Third-party audit through a mutually agreed assessor is the usual compromise where direct audit is refused.

A provider that declines to supply run metadata, citing intellectual property in its calibration procedures, has made a legitimate commercial choice and given you a clear answer. That platform is suitable for experimentation and unsuitable for anything you will have to defend to a regulator.

Control Point Four: Export Control and Jurisdictional Reach

Quantum computing sits on control lists. The US Commerce Department’s Bureau of Industry and Security added quantum computing items to the Export Administration Regulations in an interim final rule covering advanced computing, quantum computing and additive manufacturing items, published in the Federal Register on September 6, 2024, and other jurisdictions have moved in the same direction. The immediate consequence for a cloud customer is that the provider’s home jurisdiction reaches into your workload.

This works in both directions. A provider may be legally prevented from serving certain users, or from executing certain algorithm classes for certain customers, without a licence. The determination is made by the provider’s counsel under the provider’s law, and you will learn the outcome as a service refusal.

There is also a second-order effect that GRC teams tend to catch late. If your organisation operates across borders, a job submitted by a colleague in one country to a processor in another may constitute an export of technology or technical data under one or both regimes. The compliance question belongs to your export control function, not only to procurement, and it is worth routing quantum cloud contracts through that function before signature rather than after the first refused job.

The mitigations available in contract are limited but real:

• A positive list of jurisdictions in which your workloads may execute, with the provider bearing the obligation not to route outside it.
• Advance notice of any regulatory change the provider believes will affect service to you, with a defined notice period.
• A termination right, without penalty, triggered by a restriction that materially limits the service.
• Clarity on which entity in the provider’s corporate structure holds your contract, and therefore which law governs it. A European subsidiary of an American parent is not automatically insulated from the parent’s obligations, and the answer depends on the corporate structure and the specific regime.

The AUKUS arrangement between Australia, the United Kingdom and the United States, which includes quantum technologies among its cooperation areas alongside eased export controls between the three, illustrates where this is heading: trusted blocs that lower friction internally and raise barriers for everyone outside. If your organisation operates across a boundary between blocs, that boundary belongs in your provider selection, not just in your compliance register.

Control Point Five: Supply Chain Provenance

A quantum service is a stack. Qubit chips, cryogenics or vacuum systems, control electronics, firmware, the compiler that transpiles your circuit, the scheduler that queues it, the cloud platform that fronts the whole thing. Each layer may come from a different supplier in a different country, and the provider you contract with may only build a few of them.

For most commercial buyers this is a continuity question rather than a security one. If a single supplier three layers down stops shipping, or falls under a new export restriction, what happens to your service? The provider may not know, which means your continuity depends on suppliers your organisation has never seen named.

Questions worth putting in a due diligence questionnaire:

• Which components of the stack does the provider manufacture, and which does it source?
• Where is the qubit substrate fabricated, and where are the cryogenic or vacuum systems built?
• Whose firmware runs the control electronics?
• Which parts of the software stack are open source, which are proprietary, and which are licensed from third parties?
• What is the provider’s own single-supplier exposure, and what alternates exist?

The European Commission’s cloud sovereignty work has pushed supply chain transparency into formal evaluation criteria for cloud providers, alongside legal jurisdiction and technological openness. Applying the same criteria to quantum services is straightforward, and providers are increasingly ready for the questions. A provider that has never been asked will improvise; one with an answer ready has been through the conversation with a government buyer already.

Diversity across modalities is the strategic version of the same hedge. Superconducting, trapped-ion, neutral-atom and photonic systems have different error profiles, different scaling constraints and different supply chains. An organisation whose entire quantum programme assumes one modality has taken a technology bet as well as a vendor bet. Europe’s approach through EuroHPC has been to host several modalities across different sites rather than standardise early, which spreads the bet across the continent’s portfolio. A single enterprise cannot do that at the same scale, but it can avoid writing its applications against the assumptions of one architecture.

Control Point Six: Exit and Portability

The last control point is the one that determines whether the other five stay negotiable. A customer who cannot leave has no bargaining power in any subsequent conversation.

Lock-in in quantum computing operates mainly through the software layer. Circuits written directly against a vendor’s proprietary SDK, using vendor-specific pulse-level controls and vendor-specific error mitigation calls, do not move. Neither does the accumulated tuning that makes them work: the parameter settings, the calibration workarounds, the empirically discovered configurations that took eighteen months of experimentation to find.

The technical defence is portability by design. OpenQASM – Open Quantum Assembly Language – and QIR, the Quantum Intermediate Representation, both exist to let a circuit target multiple backends. Open frameworks such as Qiskit and Cirq provide a further layer of abstraction. None of this is free: writing to a portable layer means giving up some device-specific optimisation, and on today’s noisy hardware that optimisation is often what makes a result usable at all. The honest position is that portability costs performance now and buys optionality later, and the trade should be made deliberately per application rather than by default in either direction.

Where a vendor-specific implementation is genuinely necessary, the contract carries the load:

• Source code escrow for any proprietary SDK or toolchain your applications depend on, released on defined trigger events including discontinuation of the service.
• Data extraction on termination in documented, non-proprietary formats, covering circuit libraries, run histories, calibration records and performance data. Specify the format, or you will receive a database dump.
• Transition assistance for a defined period after notice, with the scope written down.
• Notice periods for material change to APIs, pricing, device availability or terms – long enough to actually port something.
• Documented dependencies, so that a future migration team knows what it is untangling.

One further provision appears in public sector agreements and is worth asking about: an option to purchase the installed hardware at depreciated value if the provider exits the market or terminates the arrangement. It is rarely granted and occasionally is, and asking costs nothing.

Mapping the Control Points to Access Models

The six control points give you a way to compare arrangements that otherwise look incomparable. Four models are realistically available.

Public quantum cloud. Access to a provider’s devices under standard published terms. Maximum breadth of hardware, minimum friction, near-zero control across all six points. Correct for learning, benchmarking and early experimentation, which is where most organisations genuinely are. It becomes a strategic exposure only when a workload it hosts becomes something the organisation depends on, and the failure mode is that this transition happens without anyone noticing.

Regional hosting under negotiated terms. The provider’s hardware and software, installed in your jurisdiction or a permitted one, operated under a contract you negotiated. This is where residency, audit and export exposure improve substantially, and it is the model most regulated buyers should be targeting. Scheduling can be strong if you paid for capacity. Supply chain and exit remain the provider’s, because the stack is still entirely theirs.

Domestic control plane over external hardware. You operate the layer that handles identity, authorisation, queueing and result routing – the control plane – while the processors sit elsewhere, possibly with several providers. Your users interact with your interface; your policies decide who may run what; your logs record it. Substituting one backend for another becomes an engineering task rather than an organisational upheaval. This buys real portability and real policy control, and it costs a team that can build and run middleware. Large research infrastructures and national programmes take this route; most enterprises should not, unless quantum access is being provided to many internal users under differentiated policy.

On-premise ownership. You buy the machine. Jülich’s supercomputing centre took this path with a D-Wave annealer installed alongside its exascale system, and the reasoning was as much technical as strategic: owning the hardware allowed a direct high-bandwidth coupling between the classical and quantum systems rather than a cloud API round trip, and gave the centre’s researchers access to machine parameters that a service does not expose. Full control on all six points, at the cost of capital, facilities, staff and a depreciation schedule against a technology generation that turns over quickly. Justifiable where the coupling to classical infrastructure is the point, or where the workload cannot leave the building for legal reasons.

Most organisations will end up running two or three of these at once – public cloud for exploration, a negotiated regional arrangement for anything regulated, and possibly a small local system as a testbed and a hedge. The mix is not the interesting decision. The interesting decision is which workloads sit in which model, and whether anybody reviews that assignment when a workload’s importance changes.

What to Do With This

The practical exercise, in order:

Inventory the workloads. List what your organisation currently runs or plans to run on quantum services, and for each one record which of the six control points would actually hurt if it were lost. Most exploratory work fails this test on all six, which is the correct answer and worth having on paper.

Read the terms you are already under. Free-tier and research-tier quantum accounts carry terms that nobody in procurement has ever seen. Find out what they say about data use, retention and jurisdiction, because an experiment that quietly became load-bearing is the most common way an organisation discovers it has no control points at all.

Set the negotiating floor by workload class. Different classes justify different positions. A reasonable default for regulated production work: named-jurisdiction residency, full per-job metadata, positive-list execution jurisdictions, capacity commitment in device hours, documented exit with data extraction in specified formats.

Route the contract through export control. Before signature, not after the first refused job.

Write applications to portable interfaces where the performance cost is tolerable, and record the decision where it is not, so that the future migration team knows which components were deliberately locked in and why.

Re-review when a workload’s status changes. The assignment of workloads to access models should be revisited on a schedule, because workloads drift from experimental to operational without any explicit decision marking the transition.

None of this requires forecasting when a cryptographically relevant quantum computer arrives, or which modality wins. It requires reading a contract with the six control points in hand and noticing which ones the draft has silently assigned to the other party. That is ordinary vendor governance applied to an unfamiliar technology, and the unfamiliarity is the only genuinely new part.

Building the Capability to Ask

The clauses above are only as good as the person reviewing the answers. A provider’s response about calibration metadata, transpilation behaviour or modality trade-offs is either informative or evasive, and telling the difference takes enough technical grounding to know what a good answer looks like.

That grounding is what our Certified Quantum Solutions Architect program at quantumacademy.com/ is built to provide for teams evaluating quantum infrastructure: how the modalities differ, what the error characteristics mean for a workload, and where the real dependencies in a quantum stack sit. Governance and procurement professionals who will never write a circuit still need to read one well enough to know what it reveals.

For the wider policy and jurisdictional picture behind these control points, PostQuantum.com carries deeper analysis of quantum sovereignty and national programmes. And for organisations whose quantum exposure runs through cryptography rather than compute access, the migration methodology at pqcframework.org is the companion piece to this one.