By Garrv Sipani
Say “quantum security” to most people and they’ll start talking about post-quantum cryptography — swapping RSA and ECC for algorithms that can survive a future quantum computer. That work matters, and it’s overdue. But look closely at what it actually defends: classical systems, against quantum computers. Nobody in that conversation is defending the quantum computer itself.
I kept running into that gap, and it struck me as odd. We’re building an entirely new class of machine, spending billions to stand it up in data centers and rent it out over the cloud, and we have almost no shared way to talk about how someone might attack it. Part of the problem is a mental image. People picture a quantum computer as a sealed box of pure physics. It isn’t. Strip away the mystique and what’s left is a very classical machine: a compiler, a scheduler, a calibration database, a control stack running in real time, and now an error-correction loop where a classical decoder reads measurements and decides how to steer the qubits. That’s all ordinary software and hardware. The qubits are just what sits at the end of the pipe.
Whenever I raise this, the first response is almost always the same: aren’t these machines air-gapped? It’s a fair question. It used to be a reasonable answer, too. It isn’t one now. Commercial quantum computing is a cloud business. IBM, AWS Braket, Azure Quantum, Google, IonQ, Quantinuum — the whole model is remote job submission over the internet. A machine anyone can send a circuit to from a laptop is not air-gapped; it’s one of the most reachable computing surfaces we’ve ever built. And even for a device that genuinely sits on an isolated network, an air gap only stops one kind of attacker: the remote intruder. It does nothing about the rest. On shared hardware you don’t breach the gap at all — you rent legitimate time on the same chip as your target. The classical control and calibration stack has to be networked, or jobs don’t come in and results don’t go out. The compiler and SDK toolchain pull dependencies and updates like any other software, which is a supply-chain road straight into the control plane. We settled this debate a decade ago in the classical world: Stuxnet jumped an air gap into physically isolated centrifuges in 2010, and ever since, “air-gapped” has been an assumption, not a guarantee. Where a gap exists it narrows the problem. It doesn’t remove it. And for cloud quantum, which is most of the market, there’s no gap to narrow.
So what does the surface actually look like? At the physical layer, qubits are driven by microwave or laser pulses, and the quality of a run depends on calibration data that is, in the end, just files. At the error-correction layer, fault-tolerant machines will depend on a classical decoder that reads stabilizer measurements and computes the fix — feed it tampered measurements and it will cheerfully apply the wrong correction, producing logical errors that look exactly like noise. In the control stack, every submitted circuit runs a gauntlet of transpiler, scheduler, and result path; anyone sitting in that path can change what actually executes while the circuit you submitted still looks pristine. On multi-tenant hardware, coupled qubits bleed into each other through crosstalk, so one tenant’s activity can bias or corrupt another’s — again, no gap to cross, because the attacker is a paying customer. And dynamic circuits, with mid-circuit measurement and feed-forward, make it possible to build a covert channel between registers that never share a gate.
None of this is hypothetical hand-waving. The literature already has demonstrations: crosstalk side channels on multi-tenant NISQ devices, attacks that fool decoders, silent edits to compiled circuits. What it doesn’t have is structure. These results live as scattered papers, each with its own terms, and there’s no shared map a security team or a hardware vendor could use to ask the simple question — what are we actually covering? Plenty of individual exploits, no framework to hang them on.
Why has nobody built that framework? A few reasons, I think. The field is young and hardware was scarce, so the urgent problems were physics problems, not adversary problems. There’s a quiet assumption baked in that quantum error means random error — that noise is just nature, never malice. And there’s a skills gap running both directions: the people who understand this hardware rarely think like attackers, and the attackers rarely understand the hardware. So the surface sits there, unowned.
That’s the gap a threat model fills. When enterprise security drowned in disconnected techniques, MITRE ATT&CK gave everyone a shared vocabulary — a way to say, precisely, what you defend against and what you don’t. You can’t protect what you can’t name. Quantum hardware is at that stage now. It needs a plain, defense-agnostic catalog of what can be done to the machine, one that doesn’t belong to any single vendor or any single paper.
That’s what I set out to build with QHTM, the Quantum Hardware Threat Matrix. It sorts the surface above into five tactics and twenty-six techniques, and it tags each one with a maturity level: demonstrated on real hardware, shown only in simulation, theoretical, or already mitigated in practice. Those tags are the part I care about most. A threat model that cries wolf teaches people to tune it out, and a lot of this surface is genuinely early-stage — saying so is what lets you trust the parts that aren’t. QHTM is vendor-neutral, contains no product claims, and is published under CC BY 4.0 for anyone to use or extend. I’ve also filed the matching weaknesses and attack patterns with MITRE’s CWE and CAPEC programs, to tie it back to established practice.
I’d rather be honest about its limits than oversell it. QHTM is a starting point, not a finished science, and it’s a map of attacks rather than a set of defenses. It’s also surely incomplete — which is exactly why it’s open instead of frozen in a paper. A shared map only gets better as more people argue with it.
The quantum industry has spent a decade earning real credibility. As these machines move out of the lab, into the cloud, and onto fault-tolerance roadmaps, they pick up the one thing every serious computing platform eventually attracts: adversaries. Mapping that surface now, while it’s still small enough to map, is a lot cheaper than reverse-engineering it after the first incident. The post-quantum migration already taught us what starting late costs. It’d be a shame to learn it twice, one layer down.
Garrv Sipani is an independent researcher and the author of the Quantum Hardware Threat Matrix (QHTM), github.com/garrv105/qhtm