In nearly every article, briefing, and conference talk about the quantum threat to cryptography, one claim shows up with the regularity of a metronome: “Criminals won’t need to build their own quantum computer. They’ll just rent time on a quantum cloud service.”
The implication is that the moment a cryptographically relevant quantum computer (CRQC) becomes available commercially, the barrier to entry for breaking encryption drops to the price of an API call. A teenager with a credit card could factor RSA-2048. A ransomware gang could harvest encrypted traffic and decrypt it the same afternoon.
I’ve seen this claim repeated in threat briefings from major consulting firms, in vendor pitch decks selling post-quantum migration services, and in media coverage that should know better. And every time, I find myself asking the same question: has anyone actually looked at how quantum cloud services work?
I have. The answer is that this scenario unravels the moment you examine how quantum cloud services actually operate. The barriers to running Shor’s algorithm on rented quantum hardware are not just technical (the hardware doesn’t exist yet). They are contractual, regulatory, architectural, and, increasingly, subject to active monitoring. And the emerging research on both detecting and obfuscating cryptanalytic circuits suggests that when CRQC-grade hardware eventually reaches the cloud, a well-developed cat-and-mouse game will already be in progress.
None of this changes the need for PQC migration. The threat from quantum computing is real. But the specific scenario of criminals casually renting Shor’s on demand has been repeated so often that it has calcified into conventional wisdom without anyone checking the foundations.
Start with the basics. Walk through the process of accessing a quantum processor on any major Western cloud platform, and you’ll find that “just renting one” requires clearing several gates that the popular narrative ignores.
IBM Quantum’s Acceptable Use Policy prohibits using its systems for any activity that is “unlawful or improper,” that interferes with “the integrity or security of a network or system,” or that violates third-party rights. IBM has stated publicly that it has “implemented contractual language barring the use of our products for certain potentially harmful applications”. Running Shor’s algorithm against someone else’s cryptographic keys would constitute unauthorized access under the Computer Fraud and Abuse Act and equivalent laws in most jurisdictions. IBM doesn’t need a Shor-specific clause; the existing legal framework already covers it.
Access to IBM’s most capable systems is additionally gated by pricing tiers. The open plan gives you 10 free minutes per month on entry-level hardware. The Flex Plan starts at $30,000 for 400 minutes per year. Access to premium systems through the IBM Quantum Network requires contracts of $250,000 or more. At that level, IBM knows who you are, where you work, and what you’re doing.
Amazon Braket inherits the AWS Acceptable Use Policy, which prohibits use “for any illegal or fraudulent activity” or to “violate the security, integrity, or availability of any user, network, computer or communications system.” Braket requires users to sign third-party device agreements before submitting jobs to partner hardware (IonQ, Rigetti, IQM, QuEra). AWS retains the right to suspend access for violations.
Microsoft Azure Quantum goes further in one important respect. Its Preview Supplemental Terms state that Microsoft will “process and store your inputs to the service as well as output from the service, for purposes of monitoring for and preventing abusive or harmful uses or outputs of the service.” That language explicitly asserts the right to inspect submitted quantum circuits.
And then there’s Google Quantum AI, which is the most restrictive of all. Google’s Quantum Computing Service is not publicly available. Every user must be individually approved and added to an allow-list by a Google sponsor. There is no self-service signup.
The picture that emerges is a long way from “anyone can rent Shor’s.” Every major Western QaaS provider requires verified identity, contractual agreement, and, in several cases, institutional affiliation or a purchase commitment of $30,000 or more. The anonymous credit-card-and-go scenario that threat briefings imply simply doesn’t exist.
The “they’ll just rent it” argument implicitly assumes that cloud providers would treat quantum circuits the way they treat generic compute: submit whatever you want, no questions asked. But classical cloud providers abandoned that posture years ago.
The most direct precedent is cryptocurrency mining detection. AWS GuardDuty uses machine learning to identify unauthorized crypto mining across customer environments, analyzing CPU and GPU usage patterns, network behavior, and container activity. Azure and Google Cloud run similar detection systems. This is workload classification at scale, deployed in production, against a specific prohibited use case.
The parallels to quantum are instructive. Crypto mining has a distinctive computational fingerprint. So does Shor’s algorithm: a modular exponentiation circuit followed by an inverse Quantum Fourier Transform on the period register. If cloud providers can train classifiers to detect mining patterns across millions of heterogeneous VMs, the technical challenge of detecting a structurally distinctive quantum circuit on a controlled quantum processor with full telemetry is, if anything, simpler.
The GPU export-control regime provides a second and even more relevant precedent. The January 2025 AI Diffusion Rule and the September 2024 BIS quantum export controls (89 Fed. Reg. 72926) have forced data center operators to monitor not just who is using their hardware, but what they are using it for. As policy researchers at AI Frontiers argued in December 2025, U.S. cloud providers “could monitor how chips in their data centers are being used, identifying and preventing prohibited activities (such as large training runs that could produce models at the frontier of capabilities).” The conceptual leap from “detecting large AI training runs on rented GPUs” to “detecting Shor’s algorithm on rented QPUs” is small.
A third precedent is ITAR workload segregation. Google Cloud’s Assured Workloads enforces US-person-only access, US-only data residency, and dedicated support routing for defense-related compute. Cloud providers already segment access based on the classification of what is being computed.
The foundation for monitoring quantum workloads, in other words, already exists in the classical cloud ecosystem. Legal precedent, operational tooling, and regulatory expectations are all in place. The quantum-specific detection layer hasn’t been built yet, but that’s because no one is running CRQC-grade circuits today. The infrastructure to support it is ready.
A sophisticated adversary might object: even if providers monitor for Shor’s, circuits can be obfuscated to evade detection. This is true, and the academic community has been working on both sides of this problem for several years.
On the detection side, Wu, Hu, and Li (William & Mary, ICCAD 2024) demonstrated a dynamic fingerprinting method that captures the unique error characteristics of quantum devices through probing circuits. Their focus was detecting provider fraud (whether a cloud provider secretly substitutes a lower-quality machine), but the underlying capability runs both ways: if you can fingerprint device behavior from circuit outputs, you can fingerprint circuit behavior from device telemetry. The provider, after all, has full access to the hardware.
On the obfuscation side, Bartusek, Kitagawa, Nishimaki, and Yamakawa (UC Berkeley + NTT, STOC 2023) published the first provably secure obfuscation scheme for a circuit class powerful enough to encompass Shor’s algorithm. Their approach encrypts the circuit using quantum fully-homomorphic encryption (building on Mahadev’s QFHE), so the server processes an encrypted circuit description without seeing the underlying structure. The security reduces to the quantum hardness of Learning With Errors (LWE). An NTT press release confirmed the result was selected for ACM STOC 2023, the premier theoretical computer science venue.
The catch: the Bartusek construction outputs an obfuscated program that includes a quantum state, not a purely classical circuit description. Current QaaS platforms accept classical circuit descriptions (OpenQASM, transpiled Qiskit circuits). Running the Bartusek obfuscator would require a fundamentally different submission architecture than anything that exists today. The theoretical guarantee is real; the practical deployability is not.
A more practical tool exists. ObfusQate (Bartake et al., Singapore Institute of Technology + Fraunhofer Singapore, ACM MATE Workshop 2025) implements eight circuit-level and code-level obfuscation techniques that work on existing quantum programs. The team demonstrated embedding a keylogger into Shor’s algorithm and showed that GPT-4o, GPT-o3-mini, and Grok-3 could identify the payload in the original code but failed after ObfusQate processing. This is a weaker guarantee than Bartusek’s cryptographic construction, but it runs on current infrastructure.
And Zhang et al. (IEEE Transactions on Quantum Engineering, 2026) published an “encrypted-state quantum compilation scheme based on quantum circuit obfuscation for quantum cloud platforms,” directly addressing the threat model of a user hiding malicious intent from a cloud provider.
What does this cat-and-mouse picture tell us? Two things. First, the detection-versus-obfuscation arms race for quantum circuits is already a recognized research problem, with papers on both sides appearing at top venues. Second, the adversary who wants to hide Shor’s from a provider’s classifier needs access to cutting-edge cryptographic techniques that, as of today, either require non-standard submission architectures (Bartusek) or offer only heuristic rather than provable security (ObfusQate). This is not the profile of a casual criminal renting cloud time. This is the profile of a well-resourced research team, which brings us to the real question.
Here is the part of the argument that rarely gets articulated. The level of quantum computing expertise required to successfully obfuscate a Shor’s circuit against a provider’s detection system, submit it through an authenticated and monitored pipeline, extract meaningful cryptanalytic results, and avoid detection after the fact is extraordinarily high.
An adversary operating at that level of sophistication is, almost by definition, operating at the level of a nation-state program. And nation-state programs don’t need to rent quantum compute. They build their own.
The alternative path for a criminal actor, waiting for a less governance-minded government to build a CRQC and provide access, faces its own obstacles. The supply chain for building a quantum computer is carefully monitored and geographically concentrated. Dilution refrigerators come from Bluefors (Finland) or Oxford Instruments (UK). Control electronics come from Qblox (Netherlands), Quantum Machines (Israel), or Zurich Instruments (Switzerland, now Rohde & Schwarz). QPUs come from a handful of vendors, most in Western-aligned nations. The September 2024 BIS export controls added specific ECCNs for quantum computers, cryogenic amplifiers, and cooling systems, and the Treasury’s Outbound Investment Rule (effective January 2, 2025) bars U.S.-person investment in PRC quantum computing entities. IonQ’s export compliance page confirms its systems are classified under EAR, though the company argues that cloud access itself is not currently a controlled export.
As I’ve written in my China’s Quantum Ambition series, export controls are accelerating Chinese self-sufficiency rather than preventing it. But even a domestically sourced Chinese CRQC would be a state asset, not a tool rented to freelance criminals through an unmonitored API. China’s own quantum cloud platforms (China Telecom’s Tianyan, Origin Quantum’s Wukong) are state-operated. There is no reason to believe that a CRQC-grade system would be offered with less governance, not more.
If “criminals rent Shor’s on the cloud” is the wrong threat model, what is the right one?
The answer has three components, and none of them are new to readers of this site.
First, Harvest Now, Decrypt Later (HNDL) remains the dominant near-term quantum threat. State intelligence agencies are almost certainly collecting encrypted traffic today for future decryption once they have access to a CRQC. This threat doesn’t require renting anything. It requires patience.
Second, Trust Now, Forge Later (TNFL), the digital signature analog of HNDL, is arguably less discussed but equally serious. Signatures created with classical algorithms today can potentially be forged once a CRQC exists, undermining the integrity of software updates, legal documents, and certificate chains retroactively.
Third, when a CRQC does arrive, the first entities with access will be governments. The cryptanalytic applications will be intelligence operations, not commercial crime. The history of every dual-use computing capability, from mainframes to GPUs to AI, follows this pattern: state actors get access first, criminal adoption follows years later, and by the time criminals have access, defenses have adapted.
The practical implication for CISOs is that the timeline to act is set by regulatory deadlines and data shelf-life, not by the hypothetical date when a criminal can rent Shor’s. As I’ve argued in Forget Q-Day Predictions: Regulators, Insurers, Investors, Clients Are Your New Quantum Clock, the ecosystem-driven deadlines already in force (CNSA 2.0’s 2030 mandate, the EU’s Recommendation 2024/1101, the NIST deprecation timeline for classical algorithms) are more operationally relevant than any CRQC prediction.
The “criminals will rent quantum” narrative is seductive because it’s simple. It converts the quantum threat into something that feels immediate and democratized, like ransomware-as-a-service. That makes it useful for selling PQC products and for generating urgency in boardroom presentations.
But it’s wrong in its specifics, and getting the specifics wrong leads to misallocated resources. If you’re planning your PQC migration around the assumption that CRQC access will be democratized the moment it exists, you’re overweighting a low-probability scenario and underweighting the threats that are active today.
The correct prioritization is:
Inventory your cryptographic assets now. Identify long-lived secrets, root-of-trust signing keys, and any data with a confidentiality requirement exceeding 10 years. These are your HNDL-vulnerable assets, and they are at risk today, not in some future where criminals rent Shor’s.
Deploy hybrid PQC for high-risk traffic. ML-KEM (FIPS 203) hybrid key exchange (X25519MLKEM768) is already in production at AWS, Cloudflare, Chrome, and OpenSSH. Follow their lead for VPN, mTLS, and code-signing paths.
Stop worrying about democratized CRQC access and start meeting the deadlines that are already set. CNSA 2.0 requires full PQC migration for national security systems by 2030. The EU’s coordinated roadmap targets high-risk systems by end of 2030 and full transition by 2035. These dates are not predictions. They are commitments.
And if you’re giving boardroom briefings on quantum risk, please stop repeating the “criminals will just rent one” line. The evidence doesn’t support it, and we have enough real quantum threats to worry about without manufacturing fictional ones.
My company - Applied Quantum - helps governments, enterprises, and investors prepare for both the upside and the risk of quantum technologies. We deliver concise board and investor briefings; demystify quantum computing, sensing, and communications; craft national and corporate strategies to capture advantage; and turn plans into delivery. We help you mitigate the quantum risk by executing crypto‑inventory, crypto‑agility implementation, PQC migration, and broader defenses against the quantum threat. We run vendor due diligence, proof‑of‑value pilots, standards and policy alignment, workforce training, and procurement support, then oversee implementation across your organization. Contact me if you want help.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。