Microsoft does not sell a quantum computer. We ran ours through its shop anyway.

Our three earlier pieces ran security problems on IBM's quantum hardware: splitting an AI agent's tools so it cannot both raise and approve a purchase, scheduling convoys the way the Army's vendor did, and choosing which held agent actions an approver reviews in 35 minutes. Each time the lesson was the same: what survives on today's hardware is decided by how many two-qubit gates the circuit compiles to, and on IBM's chip the dense problems compiled to hundreds.

Microsoft is the other quantum name a CISO is likely to hear in a vendor meeting, so we took the same problems to Azure Quantum. What we found is less about quantum physics than about procurement, and the result that matters came from a machine Microsoft does not own. The comments are open at the bottom.

What Azure Quantum is

Microsoft has announced its own quantum chip, Majorana 1, and it is not on this platform. Azure Quantum is a marketplace. You create a workspace, which is an ordinary Azure resource with a managed identity and a storage account, and you add providers to it from a list: Quantinuum and IonQ, who build trapped-ion machines, Rigetti, who build superconducting ones, and Pasqal, who build neutral-atom ones. Each provider is a marketplace plan with its own billing unit, its own quota and its own terms. Jobs go in as compiled circuits, results come back as files in your storage account, and the portal shows you a list and a cost table.

The free tier is real. Rigetti's simulator is free without limit. Quantinuum's emulator of its H2-1 ion-trap machine runs on 1,000 free emulator credits per subscription that never renew. Pasqal gives five emulator hours a month, though its machine is analogue and cannot run gate circuits like ours. IonQ's simulator is free of charge, but adding IonQ failed: the plan is a paid marketplace offer, and the subscription we used was a type that cannot buy those. Real hardware from any of them is money, and the pricing page is explicit about it. An IonQ job carries a minimum charge of USD 12.42 with error mitigation off and USD 97.50 with it on, which is the default.

Two things went wrong on the way in, and both are Azure, not quantum. A fresh subscription had never registered the Storage resource provider, so the workspace's storage account silently failed to create and every job died with a permissions error until we fixed it. And the IonQ purchase was refused by a marketplace policy on the subscription. If you are the person who owns cloud governance, that is the point: a quantum workspace is a resource in your tenant, with an identity, a storage account holding every circuit and result, and marketplace purchases attached to it. It sits inside the controls you already have, or outside them if nobody set it up.

The same circuits, two kinds of chip

Every circuit we ran on IBM was compiled again for Quantinuum's machine. IBM's processor connects each qubit to two or three neighbours in a hexagonal lattice, so a gate between distant qubits costs extra swap operations. A trapped-ion machine can apply a two-qubit gate between any pair. The difference is not small.

The tool-splitting problem is sparse, each tool only conflicts with a few others, and it ran well on IBM's chip at 37 gates. The convoy and approval problems are dense, every variable touches every other, and they compiled to 431 and 464 gates on IBM against 132 on ions.

The dense problems, again

On IBM's real hardware the 12-convoy problem was indistinguishable from random guessing, and we said so. On Quantinuum's emulator, which runs the published noise model of the H2-1 machine rather than the machine itself, the same circuit matched the perfect simulator to the first decimal place.

Two readings of this are both true and a vendor will only give you one. The first is that for dense, constrained problems, the kind a procurement or scheduling demo always uses, trapped-ion architectures have a real advantage today, because connectivity decides gate count and gate count decides whether the answer survives. The second is that the emulator matched the simulator's failures as faithfully as its successes. Nine cards with two layers covered 8.4 of a possible 29 on the emulator and 8.3 on a noiseless simulator. The algorithm did not find the best queue on either. Better hardware removes noise. It does not add an answer the algorithm never had.

What it cost, and how long it took

Quantinuum bills in credits computed from the circuit: five per job, plus shots times single-qubit gates, ten times two-qubit gates and five times measurements, divided by five thousand. The 12-convoy circuit at 1,000 shots cost 317 emulator credits and the two approval circuits 96 and 192, against estimates of 293, 79 and 178 from the published formula. The portal's cost table showed a unit price of zero, because the Basic plan's credits are free, and the same credits on the real H2 machine would be real money at a price you negotiate with Quantinuum's sales team.

The portal also showed an average queue of 14 hours 55 minutes for the emulator. All three jobs completed in about two minutes. Queue estimates on shared quantum infrastructure are not forecasts.

What error correction would cost

Every result above, on every machine, is from noisy hardware or its emulation. The field's answer to noise is error correction, where many physical qubits encode one reliable logical qubit, and Microsoft's bet is that its Majorana qubits will make that cheap. Microsoft publishes a Resource Estimator that takes a circuit and a set of assumptions about the physical qubits and says what a fault-tolerant run would need. It is free and runs on a laptop, so we gave it our circuits.

The nine-card approval circuit uses 12 logical qubits. Under the estimator's superconducting-like model at today's error rate of one in a thousand, a fault-tolerant run needs about 553,000 physical qubits and finishes in two milliseconds. Of those, 541,000 are not holding the problem at all. They are factories producing the special states that rotation gates need, and our circuit has 90 rotations that each consume about fifteen of them. Assume qubits ten times better, at one error in ten thousand, and the count falls to 32,000. Assume Microsoft's Majorana model at one error in a million and it is 53,000, with a code distance of three instead of thirteen. IBM's largest machine today has 156 physical qubits and no error correction.

The estimator optimises for speed by default. Ask it for the trade-off instead and the 12-convoy circuit runs on 29,270 physical qubits if you accept 183 milliseconds per shot. That is the honest floor: a problem a laptop solves in a millisecond needs a 29,000-qubit error-corrected machine to produce one noise-free sample. The estimator is Microsoft's own tool and these are Microsoft's own qubit models, so when a roadmap slide says a problem of this size is within reach, this is the number to ask about.

What this means for a CISO

Azure Quantum is governed like Azure, so govern it like Azure. The workspace has a managed identity, a storage account with every circuit and result in it, and marketplace plans that are purchases. Resource provider registration, marketplace purchase policy and storage access rules all apply, and in our case all three bit. Someone will create one of these in your tenant; make sure it lands inside the same controls as everything else.

Architecture is a procurement question, not a physics one. Dense problems compile to a third of the gates on trapped ions, and that was the difference between noise and a usable answer. If a vendor's demo is a scheduling or budgeting problem, ask which machine it ran on and how many two-qubit gates it compiled to there.

Emulators tell you what the algorithm can do, not what the hardware will. The Quantinuum emulator matched the perfect simulator exactly, including where the simulator failed. A result on an emulator is evidence about the algorithm. It is not evidence that the machine exists at that scale, and the machine is where the money is.

Error correction is the real roadmap, and the numbers are large. Microsoft's own estimator puts a fault-tolerant version of a 12-qubit problem at tens of thousands of physical qubits at best, and hundreds of thousands at today's error rates. Every roadmap claim about solving real problems should come with that estimate attached.

Where do you stand?

Sign in below with an email address and tell us:

• Who owns the quantum workspace? If someone in your organisation created one tomorrow, would it be inside your cloud governance or a surprise on a bill?
• Do emulator results count? A vendor shows you a perfect answer from a noise model of their machine. Is that evidence, a demo, or marketing?
• Which number do you want on the roadmap slide? Logical qubits, physical qubits, or the estimator's trade-off curve?
• Ions or superconductors? Three times fewer gates on the same problem. Does that change which vendor's roadmap you read first?

We will read every comment and reply to the ones that argue.

---

Sources: Our Azure Quantum runs are from 8 and 9 October 2026 on two workspaces in the West US region, using azure-quantum 3.13 with Qiskit 2.5, on Rigetti's QVM simulator and Quantinuum's H2-1 emulator (quantinuum.sim.h2-1e), with the same tuned one- and two-layer QAOA circuits as our IBM runs. Gate counts are from compiling each circuit for each target. Pricing and plan details are from Azure Quantum's pricing page and the IonQ provider page. Resource estimates are from Microsoft's Resource Estimator in the qdk Python package, version 1.33, with an error budget of 0.001 and the named qubit models qubit_gate_ns_e3, qubit_gate_ns_e4, qubit_gate_us_e3, qubit_gate_us_e4 and qubit_maj_ns_e6, using the surface code for the first four and the Floquet code for the last. IBM hardware figures are from our earlier pieces on tool splitting, convoys and approval queues.