Soveryne company logoSoveryne
All articles
ArchitectureSovereignty

A Reference Architecture for Sovereign-by-Default Platforms

Eight posts in, from the dependence map to the region lock, here's the synthesis: the minimum architecture that honestly earns the word "sovereign." Not a product pitch: a blueprint you can hold your own stack against.

Ilke Tosunoğlu
Ilke TosunoğluJune 25, 20267 min readUpdated July 20, 2026
A layered reference-architecture shield inside an EU boundary, listing the seven pillars in order (jurisdiction/ownership, region-locked data, key custody, regional inference, cell isolation, tamper-evident audit, enforcement + test) with side notes on sovereign-by-design, privacy-by-default, resilience, and auditability.

Part of the pillar series Sovereignty You Can Actually Operate.

"Sovereign" has become the most over-claimed word in enterprise infrastructure, which is a shame, because it names something precise and buildable. This capstone lays out a vendor-neutral reference architecture for sovereign-by-default platforms: the seven pillars that, together, make sovereignty an enforced and testable property rather than a label. Each pillar comes with an authoritative anchor and a plain "what good looks like." Use it as a checklist against whatever you're evaluating, including us.

The organizing idea, drawn from recent research on "sovereign-by-design" systems, is that sovereignty should be an enforceable, verifiable system property, something the architecture guarantees and a test can confirm, not something an operator promises to uphold.

The seven pillars

# Pillar What good looks like
1 Jurisdiction & ownership EU-governed operating entity, demonstrably immune to extraterritorial compulsion, not just an "EU region"
2 Residency by construction Data confined to region by default-deny replication; it can't leave, not shouldn't
3 Key custody Customer/EU-held keys outside the provider boundary; confidential computing as defence-in-depth
4 Regional AI inference Inference and embeddings run in the data's jurisdiction: the prompt is the data
5 Resilience / anti-monoculture Cell isolation; no single provider or shared fate; blast radius capped at 1/N
6 Tamper-evident audit Hash-chained, per-region, fail-closed; append-only is not enough
7 Enforcement & testing Residency enforced at checkpoints, with a standing test that proves a forbidden move is blocked

Let's take them in turn.

1 & 2. Jurisdiction and residency by construction

Sovereignty starts with a legal fact and a physical one. The legal fact is ownership: as we've covered, an "EU region" of a US-parented provider remains reachable under foreign law, so genuine sovereignty needs an EU-governed operating entity, the bar that certifications like SecNumCloud set with explicit protection against extraterritorial demands. The physical fact is residency by construction: data confined to a region by a default-deny replication policy that excludes other regions outright, so it cannot leave rather than merely shouldn't. The EU Cloud Sovereignty Framework's SEAL 0–4 ladder is the yardstick, and notably, in its 2026 tender, no provider reached the top level (EC). Honesty about that ceiling is part of the discipline.

3. Key custody, with an honest caveat

Encryption decides the compulsion question only if the keys sit outside the provider's reach. Customer-held (HYOK) keys mean a legal order yields ciphertext: nothing to hand over. Confidential computing, which processes data inside hardware-isolated enclaves, is a valuable additional layer. But treat it as defence-in-depth, not a guarantee: in 2025, the TEE.Fail research demonstrated that a roughly $1,000 physical interposer could extract keys from mainstream trusted-execution environments and even forge the attestations meant to prove the isolation held (tee.fail). In the sovereignty threat model, where the adversary may have hardware access, that matters. Customer-held keys remain the load-bearing control.

4. Regional inference: the prompt is the data

The newest pillar, and the one most "sovereign" designs forget: AI. A prompt is a data transfer and an embedding is a recoverable fingerprint of its source text, so region-locking your database while sending prompts to a foreign GPU defeats the whole design. Inference and embeddings have to run in the data's jurisdiction. It costs more (you duplicate inference capacity per region) and that's the honest price of keeping the prompt at home.

5. Resilience without monoculture

Sovereignty and resilience share a root cause: concentration. The architectural answer is cell-based isolation (independent replicas of the stack, each serving a slice of tenants) so that, in AWS's own formulation, "a single-cell failure affects at most 1/N of traffic" (AWS). No single provider, no shared fate, no continent-wide blast radius from one bad change.

The seven pillars of a sovereign-by-default architecture as a checklist (jurisdiction/ownership, region-locked data, key custody, regional inference, cell isolation, tamper-evident audit, enforcement + test) beside the SEAL 0–4 assurance ladder and a "cross-region test → blocked" receipt. Caption: if it isn't enforced and tested, it isn't sovereign.

6 & 7. Audit and the test that proves it

The last two pillars are what separate a claim from a guarantee. Audit must be tamper-evident: hash-chained and integrity-keyed, per region, and fail-closed so that an action which can't be provably logged simply doesn't happen. ("Append-only" storage is not the same as tamper-evident; it can still be rewritten by whoever controls the store.) And enforcement must be backed by a standing test: enforce residency at the data, dispatch, and audit layers, then run an automated check that attempts a forbidden cross-region access and asserts it's blocked. That test is the receipt. Without it, every refactor is a chance to silently lose the property you claimed. If it isn't enforced and tested, it isn't sovereign.

The Soveryne Cloud Foundation as a worked example

We didn't derive these pillars in the abstract. They're the specification we built the Soveryne Cloud Foundation against, and every earlier post in this series is really one pillar examined up close: jurisdiction and keys, region-locked residency, regional inference, anti-monoculture resilience, and portability. The Foundation is EU-governed and EU-operated, with data confined by design, keys in your jurisdiction, AI inference that stays home, distributed cell-isolated compute, a tamper-evident audit trail, and enforcement you can test. Command and Counsel run on it because sovereignty that stops at the application layer isn't sovereignty.

If you're evaluating your own stack, or ours, hold it against these seven pillars. Where it can't answer "yes, and here's the test," that's where the word "sovereign" is doing more work than the architecture. To pressure-test your architecture with us, get in touch.

FAQ

What makes a cloud architecture genuinely "sovereign by default"? Sovereignty enforced by the architecture and provable by a test (across jurisdiction, residency, key custody, regional AI inference, cell-based resilience, tamper-evident audit, and standing enforcement checks) rather than promised by an operator or implied by an "EU region" label.

Is confidential computing enough for sovereign data? No. It's a useful defence-in-depth layer, but 2025 research (TEE.Fail) showed mainstream trusted-execution environments can be defeated with physical access and their attestations forged. Customer-held keys remain the primary control.

How do you prove a system is sovereign rather than just claim it? Enforce residency at multiple checkpoints and run a standing automated test that attempts a forbidden cross-region access and asserts it fails. That test is the evidence; without it, the property can silently regress.

What is the SEAL framework? The EU Cloud Sovereignty Framework's assurance levels (0–4) for scoring how sovereign a service actually is: a practical maturity model to hold any architecture, including your own, against.

That's the blueprint: seven pillars, enforced and tested. Hold your stack against it, and if you want to hold ours against it too, get in touch or explore the Soveryne Cloud Foundation.

Sources

A 12-month roadmap arc with six milestones (map, tier, fix sensitive, design exit, open standards, skills) under the line "Start on Monday. No rip-and-replace."
Companion piece
A Pragmatic Sovereignty Playbook for the Next 12 Months

Seven posts of problem. This one is all solution. Here is what a European organization can actually do in the next year to reduce its dependence on foreign technology, without a rip-and-replace, without autarky, and without waiting for Brussels to build the alternatives.

Read the companion piece

More articles

A map of Europe's dependence on US technology: cloud, software, AI and chips, alongside the leverage points Europe still holds in lithography and telecom.
SovereigntyCloud

Europe's Digital Dependence, Explained

This is the stakes, in one place. How deep does Europe's reliance on US technology run, why does concentration turn ordinary tools into systemic risk, and why is passing an audit not the same as being sovereign? This cornerstone ties the argument together and links to the detail behind each claim.

July 20, 20264 min read
A dial set between "open / dependent" and "sovereign / isolated", marked at a pragmatic middle labelled selective autonomy: control where it matters, open everywhere else.
SovereigntyGovernance

Sovereignty You Can Actually Operate

This is the method. Once you accept that dependence is real and compliance alone won't fix it, the question becomes operational: what do you actually control, how do you prove it, and how do you leave if you have to? This cornerstone turns the point of view into a how-to and links to the article behind each move.

July 20, 20264 min read
A prompt and its retrieved context flowing into a model, splitting one path to a foreign GPU outside the jurisdiction, the other to in-region EU inference that keeps the data home.
AISovereignty

Sovereign AI, Explained

This is our whitespace. Cloud dependence is a known story; AI is repeating it one layer up, faster and deeper. This cornerstone explains why "sovereign AI" is a real category and not a marketing label, and links to the article behind each claim.

July 20, 20263 min read