Marin Ivezic
Sovereignty stopped being a slogan in 2024
In an interim final rule published in the Federal Register on September 6, 2024, the U.S. Bureau of Industry and Security added quantum computing systems, their components, and related software and technology to the Commerce Control List, the schedule that decides which exports need a licence and for which destinations. Two years earlier, the same word would have appeared in a keynote and nowhere else.
For most security teams, none of this looked like their problem. Nobody in the enterprise buys a dilution refrigerator. But the rules did something quieter and more durable: they established that quantum technology is now a thing governments will restrict by nationality of buyer, and once that is true of the hardware, the same logic starts arriving at the layers you do own. Which algorithms you are permitted to deploy. Which certification a regulator will accept. Which vendor can legally ship you a firmware update. Who is allowed to sit in the room while your team discusses the design.
That is what quantum sovereignty means in practice: six questions, stacked, with different owners and very different levels of urgency. This piece separates them, because the single word does more harm than good when a board asks a CISO to report on it.
Two definitions, and only one is available to you
Marin Ivezic’s framing in the Quantum Sovereignty series treats sovereignty as a spectrum rather than a state you achieve. We use the same split when we teach it.
At one end sits hard sovereignty: full-stack domestic control, from the cryogenics and the control electronics up through the compilers, the algorithms, and the certification bodies that bless them. Perhaps three or four states can credibly aim at this, and even they cannot reach it in every layer. No company can. A bank headquartered in Frankfurt is not going to fabricate its own superconducting chips, and it shouldn’t try.
At the other end sits sovereign optionality: staying connected to whatever the global market produces, while engineering the ability to verify what you depend on, pivot away from it, and swap it out when the politics turn a supplier into a liability. Optionality is a property of your architecture and your contracts. It is measurable. It has a cost, and the cost is mostly paid in design discipline rather than in capital.
Every recommendation below sits on the optionality end. If you take one structural idea from this piece, take that one: sovereignty is a set of exits you build before you need them, not a place you move your servers to.
The six layers
Layer 1: algorithms and standards
This is where sovereignty first touched enterprise security, and most teams still haven’t registered it as a sovereignty question at all.
On August 13, 2024, NIST published three final post-quantum standards: FIPS 203 for ML-KEM (formerly Kyber), a key-encapsulation mechanism used to establish shared secrets; FIPS 204 for ML-DSA (formerly Dilithium), a digital signature scheme; and FIPS 205 for SLH-DSA (formerly SPHINCS+), a hash-based signature alternative. A fourth signature scheme, FN-DSA, was announced for standardisation and had not been finalised at the time of writing.
Now compare what the other authorities say. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) selects a narrow subset of that set for U.S. national security systems, with specific parameter sizes and a published transition timeline. Germany’s Federal Office for Information Security (BSI), in its technical guideline for cryptographic mechanisms (BSI TR-02102-1), recommends Classic McEliece and FrodoKEM, two conservative schemes that sit outside the NIST selections, on the reasoning that older and better-studied mathematics is worth the larger keys. France’s National Cybersecurity Agency (ANSSI), in its position paper on the post-quantum transition, has been consistent that post-quantum algorithms should be deployed in hybrid mode, meaning a classical algorithm and a post-quantum one combined so that the connection stays secure if either one fails, and has treated hybridisation as a requirement for a transition period rather than a nice-to-have. China maintains its own approved commercial cryptography standards, the SM series, through a national approval process, and is running its own post-quantum selection.
So an algorithm choice is a jurisdiction choice. A single global TLS profile that satisfies NIST, BSI, ANSSI and Chinese regulators simultaneously does not exist today, and we should stop expecting one to appear. If you operate in three of those jurisdictions, you will run three configurations. That is a crypto-agility requirement, not a political statement, and it is the cheapest sovereignty investment available to you because you were going to need agility anyway.
The practical test: can your TLS termination points, your code-signing pipeline and your VPN concentrators be moved to a different algorithm profile per region, by configuration, without a re-architecture? If the answer is no, that’s your first finding and it has nothing to do with geopolitics.
Layer 2: implementations and certification
An algorithm is a specification. What you deploy is somebody’s code, running on somebody’s silicon, validated by somebody’s scheme.
FIPS 140-3 validation, awarded through the Cryptographic Module Validation Program, tells a U.S. federal buyer that a module was tested. Common Criteria evaluation, and the national schemes that sit on top of it, tell European buyers something related but not identical. A module validated under one is not automatically acceptable under the other, and the queue for re-validation after a firmware change is measured in quarters.
Here the sovereignty question becomes contractual rather than geographic. Three things determine whether you have any real control:
- Can you inspect the implementation, or is it a signed binary blob?
- Can you rebuild it, or at minimum, can an independent party you choose evaluate it?
- Can you get a re-certified build within a defined window when a standard changes or a flaw is published?
Open-source implementations answer the first two by construction, and answer the third badly. Vendor firmware answers the third with a contract, if you negotiated one, and refuses the first two. Most enterprises hold a mix and have never written down which is which. We would treat that inventory as a higher-value exercise than any of the geopolitical analysis, because it is the layer where an actual decision gets made every procurement cycle.
Layer 3: roots of trust and key material
Your root of trust is whatever component the rest of your security depends on and cannot itself verify: the hardware security module (HSM) holding your signing keys, the certificate authority anchoring your PKI, the secure element in a shipped device.
Ask three questions of each one.
Who signs the firmware? An HSM you own outright, sitting in your own rack, that will not accept a firmware image unless the vendor signs it, is a dependency wearing a padlock. If that vendor’s government restricts exports to your jurisdiction, or the vendor exits the market, the box does not stop working. It stops changing, which in a migration is the same thing.
Where does key generation and ceremony happen? Sovereignty at this layer is largely a question of witnesses and location, and it is one of the few places where the physical answer genuinely matters.
Can the surrounding tooling issue what you need? A great many certificate lifecycle platforms cannot yet issue or manage ML-DSA certificates, and a great many device management systems cannot handle the larger key and signature sizes without hitting a message-size limit somewhere. That’s not a sovereignty problem in itself, but it determines whether your exit is real or theoretical.
Layer 4: the quantum hardware supply chain
This is the layer the export controls actually targeted, and the one that reaches least far into a typical enterprise.
Building a quantum computer requires an unusually narrow set of suppliers. Dilution refrigerators, which cool superconducting processors to a few thousandths of a degree above absolute zero, come from a small number of specialist manufacturers, with Finland’s Bluefors and the UK’s Oxford Instruments prominent among them. Those systems consume helium-3, an isotope produced mainly as a byproduct of tritium decay, with national stockpiles as the principal source. Cryogenic amplifiers, arbitrary waveform generators, specialised lasers and photonic components each have a handful of credible vendors. Chokepoints like these are why export controls at this layer bite: you do not need to control everything if you control one input that has no substitute.
For a CISO, this matters at exactly two touchpoints. The first is quantum random number generators, if you deploy them, since they are physical devices with a real supply chain and a certification question attached. The second is quantum key distribution, or QKD, which uses quantum physics to establish keys over a dedicated optical link. QKD is the one place where quantum hardware enters an enterprise network directly, and it is also where sovereignty marketing is thickest.
We would be cautious. The NSA has stated that it does not support QKD for national security systems and recommends post-quantum cryptography instead, and the UK’s National Cyber Security Centre (NCSC) has published similar advice. The objections are about implementation security, key authentication, and the cost of dedicated fibre, not about the physics. Post-quantum cryptography protects data you already have, over networks you already own. That is a stronger sovereignty position than a point-to-point link between two buildings.
Layer 5: compute access and jurisdiction
Access to quantum computers today runs almost entirely through cloud services operated by a small number of providers. If your research team is exploring quantum algorithms, they are submitting circuits to somebody else’s machine, over somebody else’s control plane, under somebody else’s national law.
Two consequences follow. The first is disclosure: the structure of the problems you submit reveals what you are working on, in the same way that query patterns always have. The second is jurisdiction. U.S. legal process can reach data held by U.S. providers regardless of where the servers sit, and European financial entities operating under the EU’s Digital Operational Resilience Act (DORA) carry documentation and concentration-risk obligations for critical ICT third-party providers, which increasingly includes anything experimental that touches production.
Some of you will disagree with what follows, but on current evidence this is the least urgent of the six layers for almost every enterprise. Nobody is running production workloads on quantum hardware. The exposure is a research programme and a contract, both of which can be moved in a quarter. Register the service, keep cryptographic material out of it, and spend the attention you save on layers 1 through 3.
Layer 6: people and knowledge
The layer people forget, and the one with the sharpest legal edges.
Under U.S. export control rules, releasing controlled technology or source code to a foreign national, including inside the United States, counts as an export to that person’s country of nationality. This is the deemed export rule, and it has governed defence and semiconductor work for decades. Once quantum technology entered the Commerce Control List, the same rule started reaching quantum teams. A research group with mixed nationalities is now, at least potentially, an export-control matter, which means it involves HR, legal and security together rather than legal alone.
Knowledge sovereignty has a second and more mundane form. If the only people in the organisation who understand your post-quantum migration are three consultants on a statement of work, you do not control that layer either. It’s the same dependency question as the firmware blob, applied to expertise. We see this failure far more often than we see the export-control one, and it costs more.
A worked example: one bank, four decisions
Take a European insurer with a Frankfurt entity, a Paris entity, a U.S. broker-dealer, and an HSM estate coming up for refresh in eighteen months. The board has asked for a position on quantum sovereignty. Here is what a defensible answer looks like, layer by layer.
Decision one, algorithm profile. Standardise on hybrid key establishment, classical plus ML-KEM, as the group default, because it satisfies ANSSI’s transition guidance and is acceptable to the U.S. side. Build the profile so that a second post-quantum KEM can be added for the German entity by configuration, without touching the application layer, in case BSI guidance stays where it is. One architecture, three profiles.
Decision two, the HSM contract. Write the sovereignty requirements into the refresh, not into a policy document. Firmware supporting a newly standardised algorithm within a defined number of months of publication. A named window for a re-certified build after a published flaw. Escape terms if the vendor cannot ship to one of your jurisdictions. This is the single most important moment in the whole programme, and it comes round once every five to seven years.
Decision three, the cloud position. Enter the quantum cloud service in the register of information, keep production key material out of it entirely, and set a written condition for when a research workload becomes a production dependency. Then leave it alone.
Decision four, the inventory. Most cryptographic inventories record algorithm, key length, and location. A cryptographic bill of materials, or CBOM, is the structured version of that inventory: a machine-readable record of every cryptographic asset in a system and what depends on it. For sovereignty purposes, extend it by two columns that almost nobody currently populates: the jurisdiction of the implementation’s vendor, and the certification scheme under which it was validated. With those two fields present, the question “what breaks if country X restricts exports to us” becomes a query. Without them, it stays an essay.
Four decisions. Three of them are contract and configuration work you were going to do anyway. That’s the honest scope of enterprise quantum sovereignty in 2026.
What sovereignty is not
It is not buying local. A domestic vendor reselling a foreign module under a national label has moved the invoice, not the dependency. The test is the same three questions from layer 2: inspect, rebuild, re-certify.
It is not QKD. See layer 4. A quantum link between two of your own buildings is an impressive demonstration and does nothing for the ten thousand TLS endpoints that carry your actual business.
It is not a badge on a datasheet. A large share of what is currently sold as sovereign quantum capability is a label applied to a supply chain that no buyer has audited. The word has commercial value right now precisely because so few procurement teams know what to ask.
And it is not an argument for delay. The harvest-now-decrypt-later problem, where an adversary records encrypted traffic today and decrypts it once a capable quantum computer exists, is indifferent to which jurisdiction your vendors sit in. Migration timelines are set by how long your data has to stay confidential and by regulatory deadlines already published. Sovereignty tells you which supplier to pick and what to write in the contract. It does not tell you to wait.
Where this shows up in your programme
Every layer above resolves into ordinary programme work: an inventory with two more columns, a procurement clause, an agility test, and a team that understands why the German profile differs from the American one. None of it requires a physicist. All of it requires people who can hold the technical detail and the regulatory detail in the same head, which is a rarer combination than it should be.
For the migration methodology itself, including how to build and maintain a cryptographic bill of materials, the PQC Framework is the reference we point learners to. For the geopolitical background in full, including the national strategies this piece deliberately skipped, the Quantum Sovereignty series on PostQuantum.com goes considerably deeper.
And if the gap you’re looking at is capability rather than method, that’s what our certification programs are built for: structured, assessed training that takes security professionals from the standards through to a defensible migration plan. You can review the current programs and their entry requirements at Quantum Academy.