When Geopolitics Becomes Architecture

On August 13, 2024, NIST published its first three post-quantum cryptography standards. Quantum computing hardware sits under a separate regime, the dual-use export-control lists that already govern advanced semiconductors and cryogenic equipment, and inside those lists a dilution refrigerator has a control classification just as a processor does. Neither set of documents looks like an architecture specification. Both of them constrain one.

For anyone who specifies or buys quantum systems, that has an immediate consequence. Sovereignty used to belong to the policy team and the government affairs function. It now appears in the bill of materials, in the compiler toolchain, and in the termination clause of a supply contract. What follows is a walk through the places it shows up in a design, and what an architect can do about each one. For the geopolitical picture underneath these rules, PostQuantum.com covers the strategic argument in depth.

Hard sovereignty and practical sovereignty

The word gets used two ways, and only one of them is a design goal.

Hard sovereignty means full-stack domestic control. Design, manufacture, and operation of a quantum system with no critical foreign dependency anywhere in it. Two or three states might attempt it. For everyone else it stays a budget line with no completion date.

Practical sovereignty is narrower and buildable. It means keeping access to the capability, keeping the ability to verify what the system is doing, and keeping the ability to change suppliers without rebuilding the program. Nothing in that definition requires a domestic fab. All of it requires decisions taken early, because every one of them gets expensive once the architecture has set.

We spend most of our time with architects on the second definition, because it’s the one that turns into work orders.

Why the classical substitution playbook doesn’t transfer

Most of us learned sovereignty thinking in the cloud era, where there’s always a fallback. If a foreign provider became unavailable tomorrow, a competent team could stand up a domestic substitute covering 80 or 90 percent of what they had. It would cost more and run slower. It would work.

Quantum doesn’t offer that trade. A 50-qubit processor isn’t a degraded version of a 1,000-qubit processor; it’s a machine that cannot run the workload at all. The useful application range moves with qubit count, gate fidelity, and coherence time together, so falling short of the frontier usually means falling out of the problem. Partial capability still buys you experience and a training environment, which is worth having on its own terms. It doesn’t buy you the answer you were procuring.

Physical inputs are the harder constraint. A superconducting quantum computer needs a dilution refrigerator, the cryogenic plant that holds the chip near 10 millikelvin, and those are built by a small number of firms concentrated in Finland, the United Kingdom, and the Netherlands. They run on helium-3, a scarce isotope produced mainly as a decay product of tritium held in national nuclear stockpiles. Below the fridge sit cryogenic coaxial cables, low-noise amplifiers, and arbitrary waveform generators. Ion-trap and neutral-atom systems bring their own chokepoints, including narrow-linewidth lasers, acousto-optic modulators, and single-photon detectors. Spin-qubit work needs isotopically enriched silicon. There is no open-source qubit, and no substitute you can compile from a repository over a weekend.

Talent is scarcer still. A classical sovereignty program can draw on a deep pool of software engineers. A quantum program needs physicists and engineers with years of hands-on device experience, and there are few of them in any country. That constraint doesn’t respond to funding on a one-year timescale.

The four questions that turn policy into design

Nearly every sovereignty conversation we have with architects reduces to four questions. Answer them at design time and most of the rest follows.

Which jurisdiction does each part answer to? Build the bill of materials with a control-classification column beside the part number, and fill it in for every jurisdiction you operate in, not only the one you buy from. Controls follow the item and its re-export history, so a component bought from a domestic distributor can still carry a foreign license condition.

What breaks if a supplier stops shipping on Tuesday? Write the answer as a duration. Time-to-swap for a cryostat, a control rack, or a processor is measured in months, and the number moves depending on how tightly the rest of your stack is bound to that specific device. A risk-register sentence that says “alternative suppliers exist” is not an answer.

Where does the control plane sit? If your operators reach the machine over a network, the circuits cross a border and so does the structure of the problem you’re solving. Remote access can itself be a controlled transfer, depending on who is at the keyboard and where they hold citizenship. That belongs in the design review, not in a legal review six months later.

What do you keep when the contract ends? Interface documentation, pulse-level access, calibration and characterization data, and trained staff are the assets that survive a vendor change. If none of them is a contractual deliverable, you are renting a capability rather than building one.

Designing for the swap

Open architecture, in this context, means published interfaces between the four layers of a quantum system: the processor, the cryogenic plant, the control electronics, and the software stack. Where those interfaces are documented and stable, a part from one supplier can be replaced by a part from another without redesigning everything around it.

Where the swap is real

Modularity is what makes a first build possible for a program that cannot manufacture every layer, and what makes the second build cheaper than the first. A processor from one supplier, a cryostat from another, control electronics integrated locally, and an open-source software layer above all of it – that composition needs published interfaces at three boundaries, and it fails at whichever boundary is undocumented.

It also changes what a single export restriction does to a program. A controlled component can stall a closed-stack build entirely, because there is nowhere to put a substitute. In a modular build it stalls one layer while the rest continues, and the procurement question becomes which alternative part clears the interface rather than which alternative program to start.

Where the swap stops

Modular on a datasheet is not the same as swappable in your program. A processor swap is only real if the layers above it can move with it. Circuits compile to a device’s native gate set, and a two-qubit operation that costs one gate on one architecture can cost three on another. On a noisy device, that extra depth can cost more fidelity than the swap saved. Calibration routines, error-mitigation parameters, and scheduling logic are usually tuned to one machine’s noise profile and won’t transfer unchanged.

So we tell architects to test portability rather than declare it. Keep at least one representative workload that runs on a second device on a regular cadence, compile it through a vendor-neutral intermediate representation such as OpenQASM or QIR (Quantum Intermediate Representation), and record what the move costs in gate count, runtime, and result quality. A swap plan that has never been executed is an assumption with a document number.

Two crypto stacks instead of one

The August 2024 NIST standards cover ML-KEM (formerly Kyber) for key establishment and ML-DSA (formerly Dilithium) and SLH-DSA (formerly SPHINCS+) for signatures. Other jurisdictions are running their own selection processes and will mandate their own suites for national and regulated systems.

For anyone shipping a product into more than one market, that has a design consequence today. Crypto-agility, meaning the ability to present a different algorithm suite depending on where the system is deployed and who regulates the buyer, stops being a desirable property and becomes a requirement. The migration methodology for that work sits at pqcframework.org, and the sequencing is easier to establish before the second mandated suite arrives than after.

Contract language that carries the requirement

Architecture decisions only survive if the contract keeps them enforceable. These are the clauses we see doing that job.

• Export-control representation and notice. The supplier states the classification of each item and commits to notifying you when a classification or license condition changes.
• Interface documentation as a deliverable. Named documents with version numbers, delivered on a schedule, rather than a promise that documentation will be made available.
• Data portability. Calibration data, characterization results, and device logs delivered in a documented format you can read without the vendor’s own tooling.
• Source escrow for control software. Release triggered by discontinuation, insolvency, or an export denial that stops delivery.
• Second-source and end-of-life terms. Notice periods, last-time-buy rights, and an obligation to support a published interface rather than only the vendor’s own part.
• Access jurisdiction. For cloud-delivered capacity, the physical location of the machine, the location of the support staff, and the law governing both.
• Sublicensing and re-export. Whether you can relocate the system, run it for a subsidiary in another country, or resell the output as a service.

None of these is exotic. Most of them exist already in mature hardware procurement, and the work is adapting them to a supply base where the alternative part may not exist yet.

The dependency that isn’t in the bill of materials

Hardware can be bought under conditions. Expertise can’t be bought the same way, and the arrangements that work best treat that as the design goal rather than a side effect.

One pattern is a hosted machine with local staff attached to it. When IBM installed a Quantum System One at the Fraunhofer institute in Ehningen in 2021, the hardware remained the vendor’s and the operational experience became local. Engineers who run a real device for three years learn what drifts, what a calibration cycle actually costs, and which vendor claims don’t match the logs. No procurement document transfers any of that.

The same logic applies inside an enterprise. A sovereignty program that funds hardware and not people produces a machine nobody can operate independently, which is the dependency you were trying to avoid, relocated. Roles in this field are still forming, and QuantumCareers.com maps where they currently sit.

What a sovereignty review should produce

We’re asked regularly what the output of this work looks like. Four artifacts, all of them short.

A component inventory with control classifications recorded per jurisdiction. A swap plan for each layer with a measured time-to-swap rather than an estimated one. A workload split naming which computations must run on infrastructure you control and which can run anywhere. And a capability plan for the people, with named roles and a training path attached to each.

Most vendor claims of sovereignty we’ve read amount to a data-residency statement plus a local support desk. That’s hosting. It answers where the machine sits and says nothing about what happens when a license condition changes, which is the question the review exists to answer.

Building the capability in-house

Export-control classification, second-source planning, and interface portability are architecture skills before they are policy skills, and most engineering teams are picking them up mid-project, under deadline, from vendors with an interest in the answer.

Quantum Academy’s architecture and systems-integration programs cover the decisions in this article as practical work, including supply-chain classification, modular system composition, portability testing, and vendor evaluation for teams that will live with the result. Current programs and access details are at quantumacademy.com/.