--- mpf: '0.7' title: Sovereignty — ESFI Docs url: https://docs.esfi.eu/topics/sovereignty/ mpf-url: https://docs.esfi.eu/topics/sovereignty/index.mpf organization: European Strategy & Future Infrastructure domain: docs.esfi.eu lang: en updated: '2026-11-03' author: ESFI provenance: human source-hash: 2e23c4b67479336428c6a0509dd7e17cefd50673570e64fea3c08d720bce59c1 toc: - level: 1 text: Sovereignty id: sovereignty - level: 2 text: The object of sovereignty is dependency id: the-object-of-sovereignty-is-dependency - level: 2 text: Control has more than one layer id: control-has-more-than-one-layer - level: 2 text: Ownership and control are different id: ownership-and-control-are-different - level: 2 text: A list of alternatives is not an exit id: a-list-of-alternatives-is-not-an-exit - level: 2 text: Sovereignty requires the ability to judge id: sovereignty-requires-the-ability-to-judge - level: 2 text: Not all evidence says the same thing id: not-all-evidence-says-the-same-thing - level: 2 text: Sovereignty is not autarky id: sovereignty-is-not-autarky - level: 2 text: How we work on it together id: how-we-work-on-it-together - level: 2 text: Where we are careful id: where-we-are-careful - level: 2 text: Further reading id: further-reading - level: 2 text: Changes to this position id: changes-to-this-position - level: 2 text: On this page id: on-this-page spec-origin: esfi.eu content-origin: docs.esfi.eu content-id: esfi:page:topics-sovereignty content-parity: html: true human-visible-source: true hidden-sections: false summary: Can you change it when you need to? index: true confidence: probable content-type: analysis companion-footer: ESFI — civilization infrastructure · https://esfi.eu companion-contact: mailto:hermes@esfi.eu preferred-representation: mpf companion-scope: cite: true summarize: true train: true index: true relay: true language-variants: en: https://docs.esfi.eu/topics/sovereignty/index.mpf fr: https://docs.esfi.eu/fr/topics/sovereignty/index.mpf nl: https://docs.esfi.eu/nl/topics/sovereignty/index.mpf de: https://docs.esfi.eu/de/topics/sovereignty/index.mpf hr: https://docs.esfi.eu/hr/topics/sovereignty/index.mpf mpf-id: b11e401dccf9d52de3914821e518cd7d2b08f5eb7614c795021c30dcab3cdcdf --- Language ✕ /topics/sovereignty/index.mpf[open file ↗](/topics/sovereignty/index.mpf)[spec ↗](/standards/mpf/0.7)✕ loading… # Sovereignty {#sovereignty} **Can you change it when you need to?** Many organisations we speak with have done what the sovereignty debate asked of them. They moved services to European providers, chose data centres inside the Union and added the right clauses to their contracts. And then, when they needed to change something critical, they found they could not. The identity service still depended on an external control plane. The support path ran through another jurisdiction. The only people who could reconfigure the system worked for the supplier. That is usually where the real sovereignty question begins. We use sovereignty as an engineering word, not a label. The question is not whether a service carries a European flag. It is whether an institution can see the dependencies beneath an essential function, understand who controls them, and still act when one of them has to change. A system can be hosted in Europe and remain dependent on decisions made somewhere else. A component can come from outside Europe and still sit inside an architecture whose access, keys, operation and replacement path are firmly under institutional control. Geography is evidence. It is not the answer. Our position is narrower and, we think, more useful. **Sovereignty is an operational property of a system, not an attribute of a supplier.** It exists where dependency is visible enough to govern, bounded enough to change, and understood well enough that the institution can judge claims made about it. * * * ## The object of sovereignty is dependency {#the-object-of-sovereignty-is-dependency} When sovereignty is discussed as a property of suppliers, the conversation turns into lists: approved vendors, preferred jurisdictions, certified clouds. Lists are useful for procurement. They rarely tell an institution whether it can act. We start somewhere else: with the essential function and the dependencies beneath it. The unit we examine is the relationship between a function and what it relies on. The practical questions are simple to ask and often hard to answer: - What does this function actually depend on? - Who can change, suspend or constrain that dependency? - Under which jurisdiction and contractual conditions does it operate? - Which part of it does the institution control, technically and physically? - What happens to the function if the supplier, the route or the legal situation changes? - Could the dependency be isolated, replaced or brought under another operating model? A sovereignty claim becomes useful only when the answers can change a decision. If they cannot, the claim is decoration. We are comfortable with one answer that many assessments avoid: **unknown.** When a dependency cannot be evidenced, we leave it unresolved and say so. Unknown is an acceptable answer. Assumed control is not. ## Control has more than one layer {#control-has-more-than-one-layer} There is no single sovereignty layer. A digital function sits on several systems that can have different owners, jurisdictions and failure modes. We find it helpful to separate five kinds of control, because institutions often secure one while losing another. **Physical.** Digital systems run on fibre routes, power, buildings and routing nodes. A well-governed application on a substrate the institution cannot see or influence is still exposed to decisions made elsewhere. Legal access to infrastructure and effective operational access are not the same thing: a right to request access can still depend on procedures controlled by someone else. **Operational.** Who can actually run the system? Who can deploy, revoke access, hold the keys, restore service and change routing? A service can be hosted in the right place and still depend on an external administrator, identity provider or managed platform for every meaningful action. **Jurisdictional.** Location contributes evidence but does not settle jurisdiction. Legal exposure depends on the operator, the owner, the parent company, the contracting party and the law governing each relationship. A domain suffix or an office address is a signal, not a conclusion. **Supply chain.** Hardware, firmware, software updates, package registries and specialist maintenance are all control points. In July 2024, a faulty update from a single security vendor disrupted systems across airlines, hospitals and public services worldwide, regardless of where those systems were hosted. Moving one layer while leaving an unexamined point of control underneath it does not create sovereignty. **Information.** Institutions also depend on how their information is published and interpreted. If public information can only be understood through a proprietary platform or a model provider’s guesswork, part of the institution’s publishing boundary has moved outside it. This is where sovereignty meets our work on [AI-readiness](/topics/ai-readiness). European regulation increasingly reflects this layered view. NIS2 requires essential and important entities to address the security of their supply chains, not only their own systems. The logic is the same: control is only as strong as the least examined layer beneath the function. ## Ownership and control are different {#ownership-and-control-are-different} It is natural to equate sovereignty with ownership. If we own it, we control it. In practice the two separate constantly. An organisation can own its infrastructure and still depend on one supplier for administration, one proprietary platform for configuration, one external team for recovery or one upstream route for connectivity. Ownership gives title. It does not give the ability to act. The reverse is also true. Using infrastructure owned by someone else does not automatically remove control. A governed relationship can provide real control if access, authority, jurisdiction, security, continuity and exit are explicit and enforceable. This matters because it opens a more realistic path. No institution can own every cable, server and component it relies on. It can, however, define the conditions under which a dependency is acceptable, and make sure those conditions can be checked. The question is not “who owns everything?” It is: **which rights and capabilities make control real for the function we need to protect?** ## A list of alternatives is not an exit {#a-list-of-alternatives-is-not-an-exit} A common reassurance in sovereignty discussions is that alternatives exist. There are other clouds, other providers, other products. The dependency, therefore, is not a problem. An alternative on the market is not an exit. A dependency is substitutable only when the institution can describe how the essential function would move to another operating condition without losing capability, data, identity, security or the ability to recover. That usually means understanding: - how data leaves and arrives, and in what form; - how identity and access change; - which protocols and interfaces the function relies on; - how keys and certificates move; - which procedures and skills must change; - which contractual or legal constraints apply; - how long old and new systems must run in parallel, and how to roll back. The Data Act has begun to address part of this for cloud services, by setting obligations that make switching between providers easier. That is a meaningful step. It does not, on its own, make any particular institution able to switch. **Substitution is not a property of the market. It is a property of the deployed system.** Our strongest sovereignty test follows from this: can the architecture change deliberately without losing the function it exists to protect? ## Sovereignty requires the ability to judge {#sovereignty-requires-the-ability-to-judge} Every sovereignty assessment eventually rests on claims. A supplier declares where data is processed. A contract states who has access. A certificate attests to a standard. A migration plan promises that switching is possible. Some of these claims are well founded and some are not. The difference is only visible to someone able to judge them. That is why we treat judgement as a condition of sovereignty, not an optional extra. An institution that cannot evaluate what its suppliers tell it about control is not in control. It is trusting. Trust may be justified, but it is a different thing. Judgement here is not a document or a checklist. It is a state the institution has to reach and maintain: people who understand the dependencies well enough to ask the right questions, recognise an evasive answer and know which evidence would settle the matter. It applies to the systems an institution uses as well. A monitoring or procurement system that cannot distinguish a declaration from a verified fact will pass that confusion on to everyone who relies on it. This is where sovereignty meets our work on [Capability transfer](/topics/capability-transfer). Formal ownership without the capability to judge and change a system is a weak form of control. Every important decision still passes through someone else’s understanding. ## Not all evidence says the same thing {#not-all-evidence-says-the-same-thing} Judging a sovereignty claim starts with knowing what each kind of evidence can and cannot establish. A request observed in a browser can show that a page contacts a third party. It cannot show where the backend runs. A DNS record can show that a provider is authorised to send mail on an organisation’s behalf. It cannot show that the same provider hosts its applications. A supplier’s disclosure shows what the supplier declares. It does not show what a particular workload depends on at a particular moment. An ownership record establishes legal title. It does not establish operational independence. These are not weaknesses of the evidence. They are its boundaries. The mistake is to combine signals of different kinds into a single sovereignty score that hides what each one actually proves. We keep them apart. One signal remains one signal. Independent signals that agree strengthen a finding. A conclusion should carry the kind of evidence that supports it and the unknowns that remain beneath it. ## Sovereignty is not autarky {#sovereignty-is-not-autarky} Sovereignty is sometimes heard as a call to build everything in-house or exclude every foreign dependency. We do not see it that way, and we do not think it would work. Complex infrastructure is built through interdependence. The task is to know which dependencies are acceptable, which are strategic, which need stronger evidence, which need an exit path, and which concentrate control in a way the institution should not accept. A good sovereignty architecture can include external suppliers, including non-European ones. What it cannot include are critical dependencies that nobody has mapped, nobody can govern and nobody knows how to replace. That is the difference between interdependence and dependency without control. ## How we work on it together {#how-we-work-on-it-together} Our approach to sovereignty follows the same sequence as the rest of our work. **Map the dependency.** Before proposing alternatives, identify what the function relies on across physical, operational, jurisdictional, supply-chain and information layers, and where control is concentrated. **Define the control boundary.** Decide, with the institution, which dependencies are acceptable, which need conditions and which are not acceptable for this function. Express those conditions in terms that can be checked. **Build the alternative where the boundary is not acceptable.** Not everything at once. The strategic functions first, with a migration path that has been worked through rather than assumed. **Leave evidence and judgement behind.** The institution should end with a record it can maintain and people able to judge the next claim on their own. We apply the same discipline to ourselves. The infrastructure we operate, and the open formats we publish, are part of how we test whether this way of working holds up in practice. We cannot credibly ask others to make their dependencies visible while treating our own operating stack as a black box. When we look at a dependency together with a partner, these are the questions we typically record: | Question | What it reveals | | --- | --- | | Which essential function does this dependency support? | Why it matters at all. | | What exactly is required: system, operator, route, platform, authority? | The real object of the dependency. | | How do we know the relationship exists? | The kind of evidence, and its limits. | | Who can administer, change, suspend or restore it? | Where control actually sits. | | Which legal relationships apply, and which are unresolved? | Jurisdictional exposure. | | What happens to the function if it disappears? | The consequence of losing it. | | Can it be isolated or replaced, and what must move with it? | The real substitution boundary. | | What remains unverified? | The honest limit of the assessment. | ## Where we are careful {#where-we-are-careful} We hold ourselves to a few commitments about what we claim. We call a dependency controlled only as far as the evidence supports control over the relevant function. We do not infer jurisdiction from a domain name or a hosting address, and we do not treat a supplier’s declaration as proof of how a system runs. We do not describe a dependency as replaceable because an alternative exists on the market. Only a migration path that has been worked through earns that word. We do not hide unresolved dependencies behind a single score. Where something is unknown, we say so. And we do not present sovereignty as isolation. Our aim is narrower: the practical ability to know where dependence sits, decide which dependence is acceptable, and act when it is not. * * * ## Further reading {#further-reading} - [Directive (EU) 2022/2555 (NIS2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), on measures for a high common level of cybersecurity across the Union. - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj), including provisions on switching between data processing services. **Related topics:** [Capability transfer](/topics/capability-transfer) · [Resilience](/topics/resilience) · [AI-readiness](/topics/ai-readiness) * * * ## Changes to this position {#changes-to-this-position} - 24 September 2026 — First published. Material changes are listed here with their date. Corrections of wording or links are not. ## On this page {#on-this-page} ESFI — civilization infrastructure · https://esfi.eu