Running a Sovereignty Stress Test That Can Fail

Most sovereignty exercises are designed to be survived. Six scenarios go up on a wall, a dozen senior people talk for three hours, and the write-up records that the organisation would cope. Nobody defined coping before the session opened, so nothing said in the room could contradict that conclusion.

A tabletop exercise is a discussion-based simulation: a team works through a crisis on paper, without touching production systems. It earns its cost only when the result is genuinely uncertain when the session starts, and that uncertainty has to be engineered. It comes from writing failure criteria in advance, in numbers, and having them signed off before anyone sees the scenario.

The objective under test is sovereign optionality. That means staying integrated in global supply chains, standards bodies and cloud markets while keeping the ability to swap any single dependency inside a period the organisation can survive. Self-sufficiency is a different and mostly unaffordable goal. Optionality asks one question of every dependency, and the question has a numeric answer: how many days would a swap take?

What follows is a design guide for the exercise itself, with six scenarios as the raw material.

Design the exercise before you choose the scenario

Failure criteria, in numbers, signed off in advance

Each scenario gets three to five criteria, written as claims the exercise will try to break. Not aspirations, and not lists of things to consider. Thresholds:

• We can issue a valid signed firmware update within 21 days without the incumbent hardware security module (HSM) vendor.
• Customer-facing services run at 40% of normal capacity from an alternative provider or an owned data centre within 14 days.
• A shipping build using the alternative cryptographic suite exists within one release cycle.

The sponsor signs the list before the scenario is written, and the right sponsor is whoever owns the budget that would fund the remediation. Signing afterwards invites the threshold to move, and it will move, because a room full of competent people who have just watched their own systems fail will find reasons why 21 days was always unrealistic. Set the number when nobody knows which way it cuts.

A control cell that stays out of the discussion

Two or three people own the scenario. They hold the injects, which are the timed pieces of new information released during the session, and they answer questions about what the outside world is doing. They don’t defend the organisation, propose mitigations, or soften a trigger because the room found it uncomfortable. Without that separation, participants end up writing the news as well as reacting to it, and the exercise becomes a meeting.

Participants chosen by dependency, not by seniority

Invite the procurement lead who signs the supplier contracts, the export compliance counsel, the platform engineer with administrative rights on the cloud accounts, whoever holds the HSM keys, the product owner for the affected line, and someone from communications. Senior attendance helps when a decision has to be made in the room. It doesn’t help with the facts, and most of the facts live two or three levels below the people who usually get invited.

One scenario per session

Half a day, one scenario. Running all six in a day produces six shallow conversations and a single flat finding. Sequence them across a year, starting with whichever one sits closest to your actual exposure.

Six scenarios, and what each one is testing

Supplier cutoff

Trigger. Your cryogenics supplier cancels the two dilution refrigerators on order and declines to renew the service contract. A dilution refrigerator is the cryogenic system that holds superconducting processors near 10 millikelvin, so the installed units keep running for now. Spares and service stop.

Leading indicators. Single-source entries on the bill of materials. A supplier market concentrated in one or two countries. Export-control discussion around the category. An incumbent acquired by a firm in a jurisdiction that is tightening its rules.

What breaks. Research stops when a unit goes down and no spare part is available. Procurement substitutes an unqualified vendor, and the qualification effort consumes every week the substitution was meant to save. The incumbent reprices the renewal, because nobody in the room can name an alternative.

Facilitation note. Bring the actual bill of materials and the purchase order history into the room. Most teams can’t name their single-source items from memory, and without documents the session drifts into speculation within twenty minutes.

Optionality. Qualify a second supplier before you need one, and record the qualification lead time as a number rather than an impression. Specify open, documented interfaces so a substitute integrates without a redesign. Hold spares for the items with the longest lead times. Co-develop with an allied institution where the component is genuinely irreplaceable.

Export licence denial

This one differs from a supplier cutoff in a way that changes every response: the supplier wants to sell, and its government will not permit the shipment. On September 6, 2024 the US Bureau of Industry and Security (BIS) issued an interim final rule bringing a set of quantum computing items onto the Commerce Control List (CCL), with licence exceptions for countries that adopt equivalent controls. The structural point for an exercise is that access to a component can now change by regulation, with no commercial dispute anywhere in the chain.

Trigger. The licence application for an item your programme has already budgeted and scheduled is returned with a request for further end-use information, and then denied.

Leading indicators. Additions to control lists in your category. Approval times lengthening. A supplier’s counsel asking end-use questions they didn’t ask last year.

What breaks. The programme stalls at one item. A workaround through a third country costs a premium and leaves you a technology generation behind. The organisation launches a reactive indigenous effort with no budget line and no schedule, which is the most expensive of the three outcomes and the easiest to talk yourself into on the day.

Optionality. Name the three items whose denial would halt the programme, and licence or stock them while it remains legal. Secure an allied alternative for each. Brief counsel early, because a licence application that documents end-use controls is a stronger application than one assembled under pressure. If an indigenous effort is warranted, scope it to the single component rather than the whole stack.

Cloud access revoked

Trigger. Your provider suspends the organisation’s accounts in one region with 30 days’ notice, citing a sanctions determination.

Leading indicators. Data residency legislation in markets where you operate. National cloud programmes such as GAIA-X in Europe. Precedent, since providers have suspended services in sanctioned markets before, and that history is what makes the trigger arguable rather than fictional.

What breaks. Services go dark wherever no fallback exists. Data is legally retrievable and practically unreachable inside the notice window. A migration that would take a planned quarter gets attempted in three weeks, by the people already handling the incident.

Facilitation note. Ask for the date of the last tested cutover. If the answer is that it’s never been tested, the criterion has already failed, and the rest of the session can go to the plan instead of the argument.

Optionality. Maintain at least one alternative under a different jurisdiction. Define infrastructure as code, so redeployment is a pipeline run rather than a project. Negotiate escrow and self-hosting clauses at contract renewal, which is the only moment you have bargaining power. Rehearse a cutover and record how long it took.

Standards bifurcation

NIST published three Federal Information Processing Standards (FIPS) on August 13, 2024. FIPS 203 standardises ML-KEM (Kyber) for key encapsulation, which is the mechanism two parties use to agree a shared secret, and FIPS 204 and FIPS 205 standardise ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) for digital signatures. A fourth signature standard, FN-DSA (Falcon), was still in draft. China’s commercial cryptography regime centres on the SM family: SM2, SM3 and SM4. In 2025 its standards body opened a call for next-generation commercial algorithms, post-quantum candidates among them. Two standard sets, two assurance regimes, and no mutual recognition on the horizon.

Trigger. A major market’s procurement rules begin naming a national algorithm suite for your product category.

Leading indicators. National calls for indigenous algorithms. Duplication of, or withdrawal from, international working groups. Certification schemes that reference only one suite.

What breaks. Duplicate stacks, duplicate testing, duplicate certification, all funded from one engineering budget. A product that is compliant in one market and non-compliant in another. Smaller suppliers exit a market rather than maintain two builds, which changes your own supply chain even if you stay.

Optionality. Build crypto-agility, meaning a system where the algorithm can be replaced without rewriting the application, usually by routing every cryptographic call through one library or service. Inventory where cryptography is actually used, and expect the answer to be hundreds of places rather than the dozen on the architecture diagram. Engage with the second standard while it is still a draft, when adaptation is cheap and influence is possible.

Crypto mandate divergence

The previous scenario is drift. This one is a regulatory deadline, and the date is set outside the organisation.

Trigger. A regulator in your largest market sets an 18-month deadline for post-quantum key exchange in your product category. A regulator in your second market names a different suite and a different date.

What breaks. Compliance conflicts that no single build resolves. Hasty deployment during the transition, and misconfiguration is the most common failure in any rushed cryptographic migration. Two certification programmes drawing on the same small team of people who understand the code.

Optionality. One crypto abstraction layer, owned and versioned. Hybrid deployments where the mandate permits them, with the costs stated openly: larger keys, bigger handshakes, longer certificate chains, and measurable latency in some protocols. One named owner for cryptographic compliance across jurisdictions, rather than a distributed responsibility that resolves to nobody. Automated scanning that reports which algorithm is running where, because the inventory goes stale within a quarter. The migration methodology at pqcframework.org covers the inventory and sequencing work in more depth than an exercise can.

Talent mobility shock

Trigger. Two of your four specialists in a niche area are foreign nationals whose visa renewals are refused. A third accepts a position abroad in the same month.

Staffing and export policy are the same policy here, and teams routinely discover it during the exercise rather than before. Under the deemed export rule, releasing controlled technology to a foreign national inside the country counts as an export to that person’s home country. Who can work on what is a licensing question.

Leading indicators. A bus factor of one on any critical subsystem. Recruitment cycles measured in quarters. Rising refusal rates in the visa categories you depend on. Graduates from your own programmes leaving for other markets.

What breaks. The project stops rather than slows, because the knowledge was never written down. The team turns insular, and within a year nobody remaining can evaluate a vendor’s technical claims independently. Documentation debt that was invisible while the expert was present becomes the whole problem the week after they leave.

Optionality. Document each critical subsystem to the level where a competent engineer new to it can operate it, and test that claim by having someone try. Cross-train deliberately, on a schedule, not when someone resigns. Train locally rather than only recruiting, because a hiring strategy is a dependency like any other. Host capability domestically where the option exists. Foreign technology on domestic ground, operated by domestic teams, keeps the operating skills in the country.

Running the day

Build the session on a timeline with injects at fixed points, and start before the crisis.

T minus 90 days. Hand the room the leading indicators only, with no trigger, and ask what was escalated and to whom. Most exercises skip this stage. The signals for the scenario you’re about to run are usually already visible somewhere in the organisation’s own reporting, and the distance between visible and escalated is a finding in its own right.

T zero. The trigger. Ask what breaks first, and hold the room to specifics: which system, which customer, which contractual obligation.

T plus 7, T plus 30, T plus 180. Each inject adds something the control cell wrote in advance, including one piece of good news, because a scenario in which everything worsens teaches the room to stop reasoning and start bracing.

At each stage, everyone writes their answer to a single question on paper before anyone speaks. Then the answers are read out. This costs three minutes and prevents the standard failure of tabletop exercises, where the most senior person answers first and the room converges on that answer within a sentence and a half.

A scribe records decisions, assumptions and unknowns in three separate columns. The unknowns column is usually the longest, and it converts into actions more directly than the other two.

What the exercise has to produce

Three artefacts, or the day was a conversation:

1. A dependency map with swap time against every entry, in days, with the evidence for each estimate recorded next to it. Swap time is the number to carry forward, and re-estimating it quarterly is cheaper than re-running the exercise.
2. The criteria list, marked pass or fail, with the sponsor’s signature and the date they signed it.
3. A risk register entry for every failed criterion, each with a named owner and a date, written before people leave the room.

An exercise that fails most of its criteria on the first run is normal, and the write-up should say so plainly rather than soften it. The organisation that has never failed one of these has never designed one that could.

Where these exercises go wrong

The trigger gets dismissed as fiction. Every trigger described here resembles something that has already happened to someone: control lists changed, providers suspended accounts, visas were refused, regulators named algorithms. Anchor each one to a precedent in the briefing pack and the room argues about the response instead of the premise.

Mitigation cost overwhelms the findings. Prioritise by swap time weighted against exposure, not by which scenario felt most alarming on the day. A 200-day swap on a dependency carrying 3% of revenue ranks below a 40-day swap on a dependency carrying half of it.

Over-correction into isolation. Full decoupling is expensive and usually unnecessary. The target is a swap option with a known cost and a known duration, which is a far smaller commitment than building everything locally.

Static scenarios. Control lists, crypto mandates and cloud regulations change every year. A scenario pack older than twelve months tests last year’s world.

The wrong facilitator. Whoever owns the dependency under test should not run the session. They’ll defend the design without meaning to, and they are the person whose honest assessment the exercise most needs.

Building the capability in-house

Running one of these well is a skill, and it’s closer to facilitation and structured analysis than to technical work. The people best placed to learn it are usually the ones who already understand the dependencies: security architects, procurement leads, programme managers with geopolitical exposure on their risk registers.

Our programs cover the method behind these exercises, from writing failure criteria through to the risk register that comes out the other end, and they are at quantumacademy.com/. The longer analysis these six scenarios draw on sits at PostQuantum.com, and the migration methodology that the cryptographic scenarios depend on is at pqcframework.org.

Whichever scenario you pick first, write down what failure looks like before you write the scenario. Everything else in the method follows from that one decision.