Digital Sovereignty: From Policy Slogan to Testable Architecture

The board reads a headline about a foreign jurisdiction reaching into a cloud, and the question lands on the CTO's desk by Monday: are we sovereign? It is a bad question, because "digital sovereignty" has become a word that means whatever the person saying it needs it to mean — a procurement checkbox, a data-centre postcode, a national-industrial-policy talking point. This article is an attempt to make it an engineering word instead. Sovereignty is not a property of a contract or a region label; it is a property of an architecture, and like any architectural property it decomposes into layers, each of which you can own, prioritise, and — the part almost everyone skips — test. What follows is the decomposition we use, in order of how load-bearing each layer actually is, and the concrete control that turns each one from an assertion into evidence.

Sovereignty is not residency, and the difference is the whole game

The most expensive mistake in this space is treating digital sovereignty and data residency as synonyms. Data residency is a statement about geography: your bytes are stored on servers in Frankfurt. It is verifiable, it is often contractually guaranteed, and it is almost worthless on its own. Sovereignty is a statement about control and jurisdiction: who can compel disclosure of those bytes, who holds the keys that decrypt them, who can push a change to the machine that serves them. A dataset can reside entirely within the EU and remain fully reachable by a foreign authority, because reach follows corporate structure, not latitude.

The mechanism is not hypothetical. The US CLOUD Act of 2018 lets US authorities compel any provider with a US legal nexus to produce data it controls, regardless of where that data physically lives — which means a German subsidiary of a US parent, serving data from a Frankfurt region, is inside the reach of a US warrant. Two rounds of transatlantic transfer frameworks have already died on this rock: the Court of Justice invalidated Privacy Shield in Schrems II in 2020, and the 2023 EU–US Data Privacy Framework that replaced it is under active legal challenge. The lesson for an engineer is not to track the litigation. It is to notice that residency guarantees ride on political weather, and to build the layers underneath residency so that the weather stops mattering. That same jurisdictional gap is why NIS2, DORA, and the EU AI Act converge on self-hosting rather than on a residency clause.

The five control layers you must own

Decompose sovereignty into layers that fail independently, and a vague board question becomes a concrete engineering backlog. There are five, and they stack: compute at the base, then data, then keys, then identity, then the supply chain that produces everything above. Each layer answers a different question, each has a mature open-source answer, and — critically — each has a control you can assert in a pipeline rather than a promise you file in a folder.

• Compute — who runs the machine? Control-plane custody on an immutable OS, optionally on hardware you own. Test: no vendor has a shell into the node, and remote attestation proves the boot state.
• Data — where does it live and who governs it? Residency plus portable, encrypted-at-rest storage you can physically move. Test: the object store is S3-compatible and re-hydrates on a second implementation.
• Keys — who can decrypt? Key custody in an HSM or a key store you operate. Test: no cloud KMS holds a root key; the provider only ever handles ciphertext.
• Identity — who is calling, and as what? A self-hosted identity provider plus attested workload identity. Test: no foreign SaaS sits in any authentication path.
• Supply chain — what am I actually running? Signed provenance, SBOMs, and admission-time verification. Test: an unsigned or unattested image is rejected before it schedules.

Click to zoom

The stacking order matters because the layers are not equally load-bearing, and they do not fail gracefully. If you lose key custody, residency and control-plane custody buy you nothing — the party holding the keys can read the plaintext wherever it sits. If you lose the supply-chain layer, every guarantee below it is undermined by the possibility that the binary running in production is not the one you audited. Sovereignty is only as strong as its weakest owned layer, which is exactly why you have to know which layer that is before you spend a euro hardening the others.

Compute and data: the ground your workloads stand on

The compute layer asks who can touch the machine. In a hyperscaler, the honest answer is that the operator can — their staff, their hypervisor, their maintenance tooling all sit inside your trust boundary by construction. Owning the layer means running your own control plane on an operating system whose attack surface you can enumerate. An immutable, API-driven node OS with no shell and no SSH is the sharp end of this: the security case for Talos Linux is precisely that removing interactive access turns the control plane's attack surface from emergent into finite. Where the threat model includes the host itself, hardware TEEs with remote attestation make "the operator cannot read your memory" a statement a machine can verify rather than a clause a lawyer can draft. And when the compute has to leave someone else's estate entirely, a disciplined repatriation to owned infrastructure is the exercise that proves the layer is actually yours.

The data layer is where residency finally earns its keep — as a floor, not a ceiling. Storing regulated data in-region is table stakes; the sovereignty question is whether you can move it without asking permission. That means an object layer you can lift and re-lay elsewhere, which in practice means an S3-compatible store on software you can run yourself. The design constraint is portability: pick a data plane you could migrate between MinIO successors without rewriting an application, and encrypt at rest with keys that belong to the next layer down, not to the storage vendor. Residency answers where; the layers below answer who — and who is the question that decides a compelled-disclosure order.

Keys: the layer that makes the other four real

If you harden exactly one layer this quarter, harden this one. Key custody is the linchpin because it is the only control that holds even after every other layer is breached. A provider that operates your control plane, stores your data, and runs your identity system still cannot produce plaintext to an authority if it has never held the decryption key — it can hand over ciphertext, and ciphertext under a key it does not possess is noise. This is the single technical fact that converts sovereignty from a contractual aspiration into a mathematical one.

Owning the keys means an internal PKI and a key store you operate — Vault, or a hardware security module, with the root of trust anchored inside your perimeter. The anti-pattern to hunt down and kill is the silent dependency: a cloud KMS holding the key-encryption key, an envelope-encryption scheme whose outermost wrap lives in someone else's account, a "customer-managed key" that is customer-named but provider-held. Kubernetes secrets management with External Secrets and Vault is the pattern that keeps the material inside the boundary while still delivering it to workloads at runtime.

Identity and supply chain: proving who, and proving what

The identity layer is the one teams most often leave foreign by accident. You can repatriate compute, data, and keys and still route every login through an external SaaS identity provider — at which point the ability to authenticate into your own sovereign estate depends on a vendor outside your jurisdiction. Owning the layer means a self-hosted identity provider such as Keycloak, Authentik, or Zitadel for human access, and SPIFFE/SPIRE for workload identity so that services authenticate to each other with short-lived, attested credentials and no vendor in the trust path.

The supply-chain layer closes the loop by answering what is actually running. Every guarantee below it assumes the binary in production is the one you built and audited; SBOMs, Sigstore signatures, and SLSA provenance are how you make that assumption checkable rather than hopeful. The enforcement point is admission: a policy that refuses to schedule anything it cannot verify. The two controls — an internal identity issuer and a signed supply chain — are testable with a single policy that rejects both an external OIDC issuer and an image from a registry you do not control:

package sovereignty.controls

import future.keywords.contains
import future.keywords.if

# Identity: reject any workload that authenticates against an
# OIDC issuer outside the perimeter you operate.
deny contains msg if {
  input.kind == "Deployment"
  issuer := input.spec.template.metadata.annotations["oidc.issuer"]
  not startswith(issuer, "https://sso.internal.")
  msg := sprintf("identity leak: OIDC issuer %q is not self-hosted", [issuer])
}

# Supply chain: reject images from a registry you do not control.
deny contains msg if {
  some c
  img := input.spec.template.spec.containers[c].image
  not startswith(img, "registry.internal.")
  msg := sprintf("supply-chain leak: %q is not from your sovereign registry", [img])
}

From principle to a test you can run

The move that separates a sovereignty practice from a sovereignty slide is this: every principle becomes an ownable layer, every layer becomes an open-source mechanism, and every mechanism becomes a control that runs in your pipeline and emits evidence when it fires. A claim you cannot test is a claim you cannot defend — to an auditor, to a regulator, or to yourself at three in the morning during an incident. This is where policy-as-code with Kyverno earns its place: it converts "we are sovereign over our supply chain" from a sentence in a deck into an admission decision the cluster makes on every pod.

Click to zoom

Concretely, the whole decomposition can live as a single build target that fails the pipeline the moment any layer leaks. It does not have to be elegant to be decisive — it has to run on every change and produce a log line you can hand to an auditor:

#!/usr/bin/env bash
# Fails the build if any control layer leaks. Fail closed, always.
set -euo pipefail
fail() { echo "SOVEREIGNTY VIOLATION: $1" >&2; exit 1; }

# Layer 3 (keys): no cloud KMS may hold a root key.
grep -rqE 'arn:aws:kms|cloudkms\.googleapis' manifests/ \
  && fail "a cloud KMS key reference is present in manifests/"

# Layer 1 (compute): the node OS must expose no interactive shell.
talosctl -n "$NODE" get services -o json | jq -e \
  'select(.spec.id=="sshd")' >/dev/null 2>&1 \
  && fail "sshd is running on a node that must be immutable"

# Layer 5 (supply chain): every image needs verifiable provenance.
for img in $(yq '.. | .image? // empty' manifests/*.yaml | sort -u); do
  cosign verify-attestation --type slsaprovenance \
    --certificate-identity-regexp '^https://forgejo\.internal\.' \
    "$img" >/dev/null || fail "no verifiable provenance for $img"
done
echo "All sovereignty controls passed."

The point is not this exact script; it is that sovereignty becomes a green or red check on a commit. Once a control is a test, it stops decaying. Residency drifts when someone spins up a region for latency; a signed-provenance gate does not, because the next unsigned image simply fails to deploy. Audit-grade rigour is not a heavier document — it is the discipline of making every claim continuously falsifiable.

Which layer first: a sequencing model

You cannot own all five layers at once, and pretending otherwise is how sovereignty programmes stall. Sequence by leverage — how much sovereignty each layer buys per unit of effort — and by blast radius if you get it wrong. A defensible order for most teams:

1. Keys first. Highest leverage, smallest surface. Moving the root of trust in-house protects the data you already have and is a precondition for every claim above it. A team can do this without re-platforming anything else.
2. Compute second. Control-plane custody on an immutable OS is the layer with the largest attack surface, so it returns the most risk reduction once keys are secured.
3. Data third. With keys and compute owned, portable encrypted storage is mostly a migration exercise — real work, low conceptual risk.
4. Identity fourth. Often the highest-friction to move because it touches every human and service, so schedule it once the layers it protects are worth protecting.
5. Supply chain last, and forever. It is never "done": it becomes a permanent gate in CI that hardens continuously as your provenance coverage grows.

This ordering is a default, not a law. A team facing an acute jurisdictional deadline may pull data residency forward; a team with a mature key story may start at compute. What does not change is the principle: prioritise the load-bearing layers, do one at a time, and make each one testable before you move on — because a half-owned layer that nobody checks is indistinguishable, on the day it matters, from one you never touched.

The regulation is catching up — don't wait for it

The policy layer is finally converging on the architecture, which is both validating and a trap. On 3 June 2026 the European Commission presented its Technological Sovereignty Package, whose centrepiece — the Cloud and AI Development Act — defines, per Lawfare's analysis, four ascending levels of sovereignty assurance for public-sector cloud procurement, from basic data-location requirements at Level 1 up to full transparency and control over the entire software supply chain at Level 4. The framing from the Commission is unusually blunt for a regulator: Executive Vice-President Henna Virkkunen told reporters the goal is to ensure that providers of critical workloads do not hold a "kill switch", and conceded that US firms would struggle to reach the highest levels precisely because of the CLOUD Act.

Read that Level 4 definition again: transparency and control over the entire software supply chain. It is the supply-chain layer of this article, written into procurement law. The regulation is describing the same architecture an engineer would build from first principles — which tells you the architecture is right, and also that waiting for the statute is unnecessary. Regulatory definitions of sovereign cloud have been drafted, deadlocked, and re-drafted across Europe for half a decade; the Gaia-X trust framework and its label levels are a parallel, still-maturing attempt at the same target. A team that has already made its five layers testable will map to whatever assurance level a tender asks for, because it has the evidence on hand. A team waiting for the final text will still be reading it when the deadline arrives.

The exit ramp, and the long game

Sovereignty framed as control has a property that sovereignty framed as compliance does not: it is the same discipline as anti-lock-in. Every layer you own is a layer you can move, and every testable control is a rehearsal of the exit. The organisations that have executed a real repatriation report, without exception, that the exit was constrained by architectural coupling and never by paperwork — the contract was easy to terminate and the data was hard to move. Designing each layer for portability is not a separate optionality project bolted on afterward; it is what owning the layer means. An object store you can re-lay elsewhere, a control plane that runs on hardware you can buy from three vendors, an identity system with a documented export — these are sovereignty and exit strategy at the same time.

This is ultimately a decade-scale posture, and that is the case for building it now rather than buying a label later. Frameworks, adequacy decisions, and sovereign-cloud tiers are political artifacts with political failure modes: they can be litigated away, renegotiated, or deadlocked for years. A control plane you operate, on hardware you own, with keys you hold and a supply chain you verify, is an engineering artifact with engineering failure modes — and engineering failure modes are the kind you can fix on a Tuesday. Digital sovereignty stops being a slogan the moment it becomes five layers, a priority order, and a pipeline that goes red when a claim stops being true. Build it that way, and the next headline about a foreign jurisdiction reaching into a cloud is, for you, simply not a question about your architecture.