A new arXiv paper shows quantum machine learning can be attacked through the physical behaviour of real hardware. The scary number is real, but it needs the right label: 92.4% fell to 1.07% in the adversarial example test, while the AQT Ibex hardware run exposed a messier problem.
Quantum machine learning is still being sold as a serious future layer of AI infrastructure, so you should pay attention when security researchers stop arguing in simulations and start running attacks on an actual quantum computer. Cedric Brügmann, Daniel Herr, Daniel Ohl de Mello, Pascal Debus, Maximilian Wendlinger, Kilian Tscharke, Juris Ulmanis, Alexander Erhard, Arthur Schmidt and Fabian Petsch published a paper on arXiv on July 3, 2026, showing a multi-stage attack against a quantum neural network on trapped-ion hardware.
That distinction matters. The paper doesn't prove that a production customer model was gutted in the wild. It proves something narrower and still uncomfortable: the same physical effects that make present-day quantum processors noisy can also become part of an attack path. That's enough to worry any provider selling quantum access through the cloud.
The victim model was a four-qubit quantum neural network with 96 trainable parameters, reduced from an eight-qubit design by applying principal component analysis to 16 by 16 pixel images. According to the paper, the model was trained on 1,000 samples and tested on 200, reaching 87.5% test accuracy in statevector simulation. On the training set, projected gradient descent produced successful adversarial examples for 840 out of 1,000 samples with epsilon no higher than 1.0. When the researchers evaluated the model on those adversarially perturbed inputs, accuracy fell from 92.4% to 1.07%.
That's the number. Use it carefully.
The hardware result is stranger than the headline
The attack chain had four parts. The researchers used side-channel reconnaissance to infer circuit information from power traces, characterised crosstalk between neighbouring qubits, generated adversarial examples from that information, and then tried to realise those perturbations physically through crosstalk. That's the important step, because it moves the threat from a neat machine-learning exercise into the awkward physics of real devices.
They ran the trapped-ion experiment on AQT Ibex, a 12-qubit system from Alpine Quantum Technologies. The QNN qubits were placed at positions 3, 5, 7 and 9 in the ion chain, with neighbouring rotations applied through ions 2, 4, 6, 8 and 10. For 50 randomly selected adversarially susceptible training samples, the hardware results did not behave like the clean simulator story. Clean images scored 64% accuracy, adversarial images scored 56%, and crosstalk images scored 68%.
It didn't collapse. It wobbled.
That doesn't make the paper weaker. Frankly, it makes it more useful. The authors say the result was counterintuitive, because samples chosen by behaviour on the PennyLane statevector simulator didn't necessarily stay correctly classified once hardware noise and shot noise entered the picture. If you're building with quantum machine learning, that's exactly the kind of ugly result you need before you trust a benchmark slide.
The paper also reports related superconducting-hardware experiments in the appendix, so this shouldn't be waved away as a trapped-ion curiosity. The mechanisms differ. The lesson doesn't. Shared quantum hardware gives attackers surfaces that classical cloud customers never had to think about: pulse schedules, crosstalk paths, qubit layout and timing.
The business problem is shared hardware
The authors' warning is aimed squarely at quantum-as-a-service providers. The crosstalk attack assumes a multi-tenant execution scenario, repeated query access, gradient access and accurate timing information about the victim circuit. That's not a casual drive-by attack from a random user. But it is close enough to the way cloud quantum systems are discussed that you can't ignore it.
Providers such as IBM Quantum, IonQ and Quantinuum have spent years making quantum machines available remotely, because almost nobody is going to buy and operate this hardware directly. That cloud model is the commercial bridge. It is also the risk. If two customers' circuits can share the same processor at the same time, a malicious workload may be able to influence a victim workload through neighbouring qubits rather than through an ordinary software vulnerability.
The researchers' proposed defences are not glamorous. Decoy pulses, power randomisation and constant-power operation can make side-channel reconstruction harder. Adversarial training and Lipschitz regularisation can make the model less sensitive to small perturbations. The cleanest system-level defence is also the most expensive one: don't allow shared execution on the same quantum processor at the same time.
That's the uncomfortable part. Multi-tenancy is what helps quantum cloud providers make scarce hardware usable and economically plausible. Dedicated execution is cleaner for security, but it pushes cost and scheduling pain back into the product. You can't sell quantum computing as enterprise-ready and then treat isolation as an academic detail.
Classical cloud computing already learned this lesson the hard way. Spectre and Meltdown forced the industry to think more seriously about hardware side channels in 2018, long after shared infrastructure had become normal. Quantum providers have a chance to do better because the warning has arrived early, before quantum machine learning becomes a routine enterprise workload.
That is the real story here. Not that one paper has broken quantum AI, and not that QML is doomed. The point is simpler: if you build models on hardware whose physical quirks can be turned against you, security has to start at the qubit layout and scheduler, not at the press release.
Also read: Sam Altman Calls Elon Musk Homeboy in Their Latest Fight Over AI Infrastructure; China's BrainCo Bets Wearable Brain Tech Can Beat Neuralink's Scalpel; What Is Vibe Coding and How AI Turned Anyone Into a Software Founder
