Securing a Quantum Computer: The Hardening Decisions a Builder Has to Make

Why a quantum computer is a target

In late 2024, Dutch intelligence publicly disclosed a Chinese cyber operation that had breached dozens of Western government and industry networks to steal advanced technology, explicitly including quantum innovations. Russian state-backed hackers have been caught probing U.S. quantum research laboratories. Western counter-intelligence agencies now warn that quantum computing faces espionage at “real scale,” targeting not just military programs but startups, university labs, and component suppliers. My espionage article catalogs over a dozen documented incidents spanning Chinese talent program infiltration, Russian procurement fronts, and cyber attacks on quantum research infrastructure.

These are not future threats. They are current operations. And they target a specific vulnerability: every quantum computer is controlled, calibrated, read out, and connected to the world through classical systems. The qubits may sit at 10 millikelvin inside a dilution refrigerator, isolated from everything, but the control electronics that drive them are a rack of FPGAs running firmware. The calibration software that tunes the qubits is a Python application on a Linux server. The NVQLink connection to the HPC cluster is a standard Ethernet link. The user API that accepts quantum circuits is a REST endpoint. Every one of those classical components can be attacked, compromised, or exploited using the same techniques that have been used against classical infrastructure for decades. My deep dive on securing quantum computers models the full attack surface. This article is shorter and more specific: it covers the security decisions a builder makes during integration and deployment, not the theoretical threat model.

The facility: security requirements beyond the physics

The facility preparation guide in this series covers vibration isolation, EMI shielding, floor loading, power conditioning, and chilled-water loops. Those are physics requirements. A quantum computer deployed in a government, defense, or national laboratory context has security requirements on top of them, and the two sets of requirements can conflict.

Physical access control is the first decision. The cryostat room contains the QPU, the wiring tree, and often the first-stage amplifiers. In a research university, this room might be accessible to any graduate student with a lab key card. In a defense program, it may need to be a controlled area with two-person integrity, access logging, and visitor escort policies. The difference in cost between those two configurations is small. The difference in operational overhead is large. A buyer should decide the access-control tier before the facility build-out, not after the first classified workload arrives, because retrofitting access controls into an existing quantum lab means downtime while the cryostat is warm.

TEMPEST considerations apply to quantum computing infrastructure in ways that classical server rooms do not face. The control electronics generate microwave pulses at 4 to 8 GHz to drive superconducting qubits. Those signals travel through cables, connectors, and the control rack itself, and some fraction of that energy radiates. In a classical data center, 4 to 8 GHz emissions from a server rack are noise. In a quantum computing facility processing sensitive workloads, those emissions are a potential side channel: the pattern of pulses encodes the quantum circuit being executed, and a sufficiently sensitive receiver outside the shielded room could, in principle, reconstruct the sequence of gates. Research has demonstrated power-based and electromagnetic side-channel attacks on quantum processors that can recover the circuit being run. The EMI shielding the facility article specifies for physics reasons (protecting qubits from external interference) also provides some TEMPEST protection (preventing internal signals from leaking out), but the two requirements have different specifications. Physics shielding keeps external fields below 1 µT near the cryostat. TEMPEST shielding prevents internal emissions from being detectable at the facility boundary. A classified program needs both, and the shielding design should be specified for the more demanding of the two requirements.

For deployments that will process classified data, the question of air gap versus connected operation must be answered during network design, not after commissioning. The HPC integration article describes NVQLink’s real-time GPU-QPU coupling, which requires the GPU node to be within Ethernet distance of the control electronics. A fully air-gapped quantum computer can still run, but it cannot do real-time error correction over NVQLink, because the GPU decoder must be on the same network segment as the control rack. The design choice is whether the entire NVQLink segment sits inside the classified boundary (which means the GPU node, the control rack, and the cryostat are all in the controlled area) or whether the quantum computer operates in a lower classification tier with results transferred to the classified network after processing. Both are valid architectures. They have different cost, latency, and operational implications, and the decision constrains the facility layout.

Hardening the quantum-classical interface

The securing quantum computers deep dive models the full attack surface at the quantum-classical boundary. For a builder, the hardening decisions that matter during integration are more specific.

Firmware integrity on the control electronics. The control system build guide describes the three Western control vendors and their FPGA-based architectures. Each of these systems runs firmware that translates high-level circuit descriptions into the analog pulses that physically manipulate qubits. Compromised firmware could subtly alter gate parameters, introduce biased errors that corrupt computations in ways that look like natural noise, or exfiltrate circuit descriptions to an external listener. The hardening step is verification at delivery: confirm the firmware hash against the vendor’s published reference, and establish a baseline. Any firmware update during the system’s operational life should go through the same verification. For sovereign programs, the question of whether the firmware source code is available for audit is a procurement decision, not an afterthought. Not all control vendors offer source-code access, and those that do may restrict it to government customers.

Network segmentation around NVQLink. The NVQLink connection between the control rack and the GPU decoder node is a high-bandwidth, low-latency Ethernet link carrying qubit measurement data and correction instructions. It should not sit on a routable network. The playbook specifies a dedicated VLAN with no gateway to the broader campus or data-center network. The GPU node should have two network interfaces: one for the NVQLink segment (isolated, no internet connectivity, no routing) and one for management and job submission (authenticated, monitored, firewalled). If the quantum computer offers cloud access to external users, the user-facing API should terminate on a separate front-end server that never touches the NVQLink segment directly. The control rack’s management interface should be on a third, isolated network. Three network segments, three security zones, no cross-routing. This is standard defense-in-depth for OT environments, and a quantum computer’s control infrastructure is, in security terms, an operational technology system with the same segmentation requirements as an industrial control system.

Calibration drift monitoring as a security baseline. The OS and orchestration article discusses calibration drift as an operational concern. It is also a security concern. A quantum computer’s qubit parameters (frequencies, coherence times, gate fidelities) drift naturally over hours and days due to TLS defects, thermal cycling, and environmental noise. An autonomous calibration system (Boulder Opal, QuantrolOx, QUAlibrate) continuously corrects for this drift and logs the corrections. That calibration log is a security telemetry source. If a qubit’s frequency shifts by 200 kHz overnight, that is normal drift. If three qubits shift simultaneously by the same amount in a pattern that correlates with a specific time window, that could indicate an external electromagnetic disturbance, whether accidental or deliberate. Establishing a drift baseline during commissioning and monitoring deviations from it gives the security team a signal they would not otherwise have. No quantum-specific security tool does this today. The calibration platform’s own logging, combined with a classical SIEM integration, is the current best practice.

Job audit trails. Every quantum circuit submitted to the machine, every result returned, and every calibration event should be logged with timestamps, user identity, and the circuit description (or its hash). For a multi-user system, this is the forensic record that answers “who ran what, when, and what did the machine look like at the time.” The OS and orchestration article covers the authentication and tenant-isolation requirements. The security addition is retention policy: for a government system, job logs may need to be retained for years, and the storage must be tamper-evident.

Multi-tenant access and side-channel risk

Most quantum computers deployed at national laboratories and universities will offer access to multiple users, often including external researchers. The security question is whether those users’ workloads can leak information to each other through the hardware.

The answer, for superconducting systems, is yes. Readout crosstalk in multi-qubit processors means that the measurement of one qubit can influence the readout signal of a neighboring qubit. In a shared-access model where two users’ circuits run on different qubits of the same processor, an attacker running a carefully designed circuit on their allocated qubits could observe correlated error patterns and infer information about the other user’s computation. Research has demonstrated this crosstalk-induced side channel on real cloud quantum hardware.

The build decision is straightforward: time-slice access so that only one user’s job runs on the processor at a time. This eliminates the cross-user side channel at the cost of reduced throughput. Every major cloud quantum provider (IBM, Amazon Braket, Azure Quantum) currently time-slices for exactly this reason. For an on-premises multi-user system, the same policy should be the default. If a future deployment needs to multiplex users for throughput, the risk acceptance should be explicit, documented, and approved by the security authority, not treated as an engineering optimization that someone decided on a Tuesday.

The deeper question is whether quantum error correction changes this picture. In a fault-tolerant system, logical qubits are encoded across many physical qubits, and the error correction process adds a layer of abstraction between the user’s logical circuit and the physical hardware. Whether that abstraction also provides security isolation (preventing a physical-layer side channel from leaking logical-level information) is an open research question. Until it is answered, time-slicing remains the safe default.

Personnel security: who has pulse-level access

The people who calibrate a quantum computer have a level of system access that has no classical analogue. A calibration engineer can send arbitrary pulses to any qubit, read out any measurement result, and modify the parameters that define how the machine interprets a circuit. In classical terms, this is root access to the physics. A malicious calibration engineer could bias computation results, exfiltrate circuit descriptions, or introduce subtle errors that look like natural decoherence.

In a defense context, calibration engineers need security clearances commensurate with the data the machine will process. In a university context, the calibration team might include visiting postdoctoral researchers from any country, with no background check beyond an academic reference letter. The gap between those two models is the gap between a secured deployment and an open one, and a buyer should decide which model applies before the first hire, not after the first incident.

The playbook’s staffing model (Chapter 19) identifies five to eight FTEs for a production deployment. Of those, the one to two quantum control specialists and the facility/cryogenic engineer have the highest-privilege physical access. They can touch the control rack, the cryostat, and the wiring. The HPC/DevOps engineers have the highest-privilege network access. They configure the NVQLink segment, the Slurm plugin, and the API surface. In a security-conscious deployment, these privilege sets should be separated rather than combined. The engineer who calibrates qubits should not be the engineer who manages the user-facing network. That separation of duties is standard in classified environments and worth implementing even in unclassified ones.

For the full catalog of espionage tactics targeting quantum researchers, including unvetted visitors, unauthorized devices, pretext invitations, honey traps, and planted interns, see my espionage article. The threat is not hypothetical. Applied Quantum itself has been directly targeted, and as I noted in that article, the fact that even an advisory firm (not a research lab) draws espionage interest tells you how wide the net is.

PQC on the classical API surface

The HPC integration article covers this in detail: the classical API surface of a quantum computing service should be migrated to post-quantum cryptography during the initial deployment. ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for authentication. The PQC Migration Framework provides the methodology. This is not repeated here except to make one point: for a government buyer, PQC migration of the quantum service’s API surface may be a compliance requirement under CNSA 2.0 or equivalent national frameworks, not a discretionary improvement. Confirm the requirement before commissioning, not after the first compliance audit.

What a buyer should take away

Security decisions are build decisions. They constrain the facility layout, the network architecture, the staffing model, and the operational procedures. They should be made during the design phase, not retrofitted after commissioning.

Decide the physical access-control tier before the facility build-out. Specify TEMPEST and EMI shielding for the more demanding of the physics and security requirements. Segment the NVQLink network into three isolated zones. Verify control-electronics firmware at delivery and establish a baseline. Integrate calibration drift logging into the security monitoring stack. Time-slice multi-tenant access as the default. Separate calibration-privilege and network-privilege roles. Apply PQC to the classical API surface from day one.

For the full threat model of the quantum-classical interface, my deep dive on securing quantum computers covers what this article deliberately does not: nation-state attack scenarios, cross-user side-channel exploitation in detail, hardware Trojan risks, and the strategic question of why an adversary might hack a quantum computer instead of building one. For the espionage threat targeting the people, not just the hardware, see what every researcher must know. For the supply chain trust decisions that constrain component sourcing, see the supply chain article in this series.