Digital Sovereignty Is a Stack, Not a Layer
Enterprise Architecture • Digital Strategy • Part 1 of 5
Digital Sovereignty Is a Stack, Not a Layer
Why enterprise architects need to rethink digital sovereignty as an architectural property — and how a seven-layer framework called The Sovereignty Stack provides a systematic way to assess where strategic dependency actually lives.
- Most organisations have a cloud decision, not a sovereignty strategy. The gap between them is where strategic exposure quietly accumulates across layers that have never been formally assessed.
- Digital sovereignty is an architectural property, not a technology choice. Like security, resilience, or interoperability, it emerges from the interaction of multiple layers — and cannot be addressed by a decision in a single one.
- The Sovereignty Stack has seven layers. Data, Identity, Platform, Infrastructure, AI, Standards, and Supply Chain. Sovereignty is constrained by the weakest dependency, not defined by the strongest layer.
- France's April 2026 programme addressed all six relevant domains simultaneously. The architectural lesson is not the Linux choice — it is that a government formally recognised sovereignty cannot be achieved at a single layer.
- Most organisations sit at Level 2 maturity — Cloud Aware. They have assessed infrastructure hosting but have not evaluated the other six layers. Levels 3 and 4 require systematic stack-wide analysis.
- 00Why this conversation has changed
- 01The question EA hasn't been asking
- 02Introducing The Sovereignty Stack
- 03The seven layers in depth
- 04Why the layers interact
- 05France's programme: the architectural lesson
- 06Sovereignty as an architectural quality
- 07A maturity model for digital sovereignty
- 08What this series covers
Why this conversation has changed in 2026
Three events between 2024 and 2026 converted digital sovereignty from a policy discussion into a strategic imperative.
Digital sovereignty has appeared in technology strategy documents for most of the past decade. It has generated policy papers, conference panels, and vendor marketing. What changed between 2024 and 2026 is that it started generating implementation mandates — and the reasons why illuminate what the concept actually means as an architectural concern.
Broadcom's acquisition of VMware (2024) produced licensing price increases of 300–500% for some enterprise customers and eliminated perpetual licences — making the "vendor can change the terms unilaterally" risk concrete and quantified for organisations that had treated it as theoretical. The CrowdStrike incident (July 2024) crashed 8.5 million Windows endpoints simultaneously via a single vendor update — demonstrating that software supply chain concentration risk operates at civilisational scale. The geopolitical context of 2025 — US tariff policy, CLOUD Act enforcement activity, and explicit European government statements about technology dependency as strategic vulnerability — elevated sovereignty from a compliance consideration to a board-level strategic concern.
Against that backdrop, France's April 8, 2026 declaration from DINUM — requiring every ministry to file technology independence plans by autumn 2026 across six domains — is not a symbolic political gesture. It is a concrete architecture mandate reflecting lessons that are equally applicable to enterprises.
The most important of those lessons is structural: France did not address a single technology domain. It addressed six simultaneously. That scope is the architectural signal the rest of this series builds from.
The question enterprise architecture hasn't been asking
EA has always managed technical dependency. Digital sovereignty extends that discipline to legal, geopolitical, and strategic dependency.
Enterprise Architecture has always been about understanding dependencies. Applications depend on platforms. Platforms depend on infrastructure. Infrastructure depends on networks. Identity governs access. Data flows through every layer. Every architectural decision either reduces or increases dependency somewhere within the technology estate.
That analytical discipline is well established. The question it has not traditionally included is one that is now becoming unavoidable:
Who ultimately controls those dependencies — and what happens if that control changes?
A technically excellent architecture can carry substantial strategic risk if the entities controlling its critical dependencies have interests that diverge from the organisation's, operate under different legal jurisdictions, or can change their terms unilaterally. The Broadcom/VMware situation is the clearest recent illustration: an architecture that was technically sound, widely adopted, and well-governed became strategically exposed when the vendor changed the commercial relationship. The technical quality of the architecture did not protect against that exposure. The strategic dependency did.
Viewed through that lens, digital sovereignty is not a procurement exercise or a compliance checkbox. It is an extension of the dependency analysis enterprise architects already perform — expanded to include legal control (which jurisdiction governs this dependency), operational control (can we operate if this vendor changes terms or fails), and strategic control (does this dependency compound or constrain our future choices).
That expansion produces a different set of architectural questions — and a different framework for evaluating technology decisions.
Introducing The Sovereignty Stack
A seven-layer architectural model for understanding where sovereign control exists — and where strategic dependency has accumulated unexamined.
The Sovereignty Stack emerged from a simple architectural question that recurs in any digital sovereignty conversation: which dependency are we actually talking about? Sometimes the answer is cloud hosting. Sometimes identity. Increasingly, artificial intelligence. Sometimes software supply chains. Each conversation tends to treat its own layer as the sovereignty question — which means each one is incomplete.
The framework maps seven interconnected architectural layers, each introducing distinct forms of dependency and control. Together they define an organisation's sovereign posture — not any single layer in isolation.
| Layer | Sovereignty question & hidden exposure |
|---|---|
| 1 — DataInformation and legal jurisdiction | Who controls your information, and under which legal jurisdiction can it ultimately be accessed?Assuming European data centres equal European jurisdiction. They don’t if the operator is US-incorporated. |
| 2 — IdentityTrust, authentication, access | Who authenticates your users, governs trust, and controls access across your digital estate?US-incorporated SSO providers control authentication infrastructure for the entire estate and are rarely assessed as a sovereignty risk. |
| 3 — PlatformOS, productivity, collaboration | Can your software platforms be independently audited, governed, or replaced when required?Proprietary software security claims cannot be independently verified. No audit path exists regardless of vendor documentation. |
| 4 — InfrastructureCompute, network, CDN, DNS | Who operates the compute, storage, networking, and cloud services your organisation depends upon?CDN and DNS providers are almost never assessed alongside cloud hosting, despite equal CLOUD Act exposure. |
| 5 — AIModels, inference, decision support | Who controls the intelligence embedded in your business processes, and how transparent are those models?AI API dependency replicates cloud lock-in with data exposure, zero model auditability, and export control risk — almost absent from enterprise risk registers. |
| 6 — StandardsFormats, protocols, interoperability | Are your systems built on open standards that preserve interoperability, or proprietary ecosystems that quietly increase dependency?File format dependency determines whether historical data is portable or vendor-locked — across decades of records. |
| 7 — Supply ChainHardware, software components | How resilient and transparent are the hardware, software, and open-source components underpinning everything above?Most organisations have no complete open-source dependency map and no defined response process for upstream maintainer vulnerabilities. |
The subsequent sections of this article explore each layer and its interactions. Parts 2 through 5 in this series will examine each group of layers in practical depth.
What each layer means in practice
Each layer has a distinct risk profile, a distinct set of decision-makers, and a distinct regulatory context. They share one property: strategic dependency accumulates in each of them silently until it becomes a constraint.
Layer 1 Data Sovereignty
Data sovereignty addresses who controls your information and under which legal jurisdiction it can be accessed. This is the most widely discussed layer — and the one most organisations have the most incomplete understanding of. The critical distinction is between data residency (where data is physically stored) and data sovereignty (who can legally compel its disclosure). These are independent variables.
The US CLOUD Act (2018) requires US-incorporated companies to produce data held on any server worldwide on valid government demand. A Microsoft facility in Frankfurt, an AWS zone in Dublin, a Google datacentre in Stockholm — all remain subject to US jurisdiction because the operator is US-headquartered. The server's address is legally irrelevant. This creates a structural conflict with GDPR Article 48 that Standard Contractual Clauses cannot resolve — a fact Microsoft acknowledged explicitly in 2025 when it confirmed it cannot guarantee data sovereignty for EU customers.
Layer 2 Identity Sovereignty
Identity sovereignty is the forgotten layer. Most enterprise single sign-on runs through Microsoft Entra, Google Workspace, or Okta — all US-incorporated, all subject to CLOUD Act jurisdiction. The authentication infrastructure controlling who can access everything your organisation operates is, for most enterprises, hosted by an entity whose obligations to foreign legal demands you cannot govern. Authentication logs reveal who accessed what, when, from where — often more sensitive than the data in the systems they protect. Few organisations have formally assessed their SSO provider as a sovereignty risk.
Layer 3 Platform Sovereignty
Platform sovereignty asks whether the software platforms your people depend on daily can be independently audited, governed, or replaced. Proprietary operating systems, productivity suites, and collaboration tools make security claims that cannot be independently verified — there is no audit path regardless of what vendor documentation states. Only open-source software provides the technical possibility of independent verification. The French Gendarmerie's GendBuntu — a custom Ubuntu-based OS running on 103,164 workstations for 17 consecutive years — demonstrates that platform sovereignty at scale is achievable. France's LaSuite, a sovereign M365 alternative co-developed with the Netherlands and Germany, is now deployed to 600,000 civil servants and illustrates that platform sovereignty extends beyond OS to the full collaboration stack.
Layer 4 Infrastructure Sovereignty
Infrastructure sovereignty covers compute, storage, networking, and cloud services. European cloud providers (OVHcloud, Hetzner, Deutsche Telekom Open Telekom Cloud) operate under European legal jurisdiction — a meaningful distinction from hyperscaler regional zones, regardless of physical location. The assessment needs to extend further than most architecture reviews reach: Content Delivery Networks (Akamai, Cloudflare, Fastly) and DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) are almost universally US-headquartered and almost never included in infrastructure sovereignty assessments.
Layer 5 AI Sovereignty
AI sovereignty is the domain that will define the next five years of this conversation — and it barely appears on current enterprise risk registers. Proprietary AI API dependency replicates cloud lock-in with additional exposure: your data may be used in training, you cannot audit what the model was trained on, you have no control over capability changes or service discontinuation, and advanced models are increasingly subject to export controls. DINUM explicitly named AI as one of its six sovereignty domains at the same priority level as operating systems — a signal about where the strategic risk is moving, not where it already is.
Layer 6 Standards Sovereignty
Standards sovereignty asks whether your digital assets are built on open standards that preserve interoperability or proprietary ecosystems that quietly increase dependency. File formats are the most visible battleground — OpenDocument Format versus OOXML determined whether decades of government documents would be portable or vendor-locked. The deeper argument: if you build on open standards, you preserve the choice of implementation across the lifespan of those assets. If you depend on proprietary formats, the vendor controls your data's future accessibility.
Layer 7 Supply Chain Sovereignty
Supply chain sovereignty covers the hardware and software components underpinning everything above. Log4j demonstrated what single-maintainer open-source dependency looks like when a critical flaw is discovered in a widely embedded library. TSMC manufactures the majority of the world's advanced semiconductors regardless of whose designs they fabricate — a hardware concentration risk that the EU Chips Act is beginning to address on a decade timescale. Most organisations have no complete Software Bill of Materials for their critical applications and no defined process for responding to upstream vulnerability disclosures.
Why the layers interact — and why partial solutions are insufficient
Sovereignty is not determined by the strongest layer. It is constrained by the weakest strategic dependency.
The seven layers are not independent. Each one creates conditions that enable or undermine sovereignty at the others. This interaction is why addressing a single layer creates the appearance of progress without materially reducing overall strategic exposure.
- Data sovereignty cannot compensate for weak identity control. If your SSO provider can be compelled under CLOUD Act to disclose authentication logs, your data governance controls are partially circumvented before they even apply — because the attacker knows who accessed what system, when.
- A sovereign cloud deployment does not eliminate AI API dependency. An organisation that hosts its infrastructure on a European cloud provider but calls US-headquartered AI APIs for document processing or decision support has redirected its data sovereignty exposure, not eliminated it.
- An open-source OS cannot resolve supply chain risk alone. The open-source dependencies that OS relies upon may themselves carry single-maintainer vulnerabilities or be maintained by contributors in jurisdictions subject to export controls.
- Standards sovereignty enables all other layers. When systems are built on open standards, every other layer becomes easier to substitute. When they are built on proprietary formats, vendor lock-in compounds across the stack — each layer becomes harder to replace because the data in it is not portable.
A sovereignty assessment that examines only cloud hosting — as most current assessments do — will conclude the organisation is better positioned than it actually is. The unexamined layers carry real risk that the examined layer cannot compensate for. This is the gap between "a cloud decision" and "a sovereignty strategy."
France's programme: what the architectural scope actually tells us
The programme was reported as a Linux story. The significance is architectural — a government formally acknowledged that sovereignty cannot be achieved at a single layer.
On April 8, 2026, France's DINUM issued a formal interministerial declaration — from a seminar chaired by the Prime Minister — requiring each ministry, public operator, and service agency to develop implementation plans by autumn 2026. The six domains explicitly covered: operating systems, collaboration tools, cybersecurity and antivirus software, artificial intelligence, databases, virtualisation, and network infrastructure.
The media coverage focused almost entirely on the OS domain — the Linux headline. What that framing misses is architecturally significant. A national government, advised by its leading technical agencies, concluded that technology independence cannot be achieved by changing a single layer. The programme addresses Layer 3 (platform), Layer 4 (infrastructure), Layer 5 (AI), and elements of Layers 6 and 7 (databases and virtualisation as platform dependencies, network as infrastructure). The explicit inclusion of AI at the same priority level as operating systems is the most forward-looking signal in the declaration.
The April 2026 announcement was not a political impulse. DINUM's Emma Ghariani, Head of Open Source and Digital Commons, noted that beta testing of the Linux transition started before summer 2025 after three years of preparation. LaSuite — France's sovereign collaboration suite, co-developed with the Netherlands and Germany — is deployed to 600,000 civil servants. The National Gendarmerie has run GendBuntu on 103,164 workstations for 17 consecutive years. The Directorate General for Public Finances preceded DINUM in the Linux transition. The April 2026 declaration built on a foundation that already existed across multiple agencies.
The governance lesson from France's programme is as important as the technical one. The Munich LiMux migration — which moved 12,600 government desktops to Linux by 2012, then reversed course under new political leadership by 2020 — failed because it was framed as a cost initiative rather than a sovereignty initiative. A cost-savings argument is vulnerable to vendor lobbying and leadership change. A sovereignty argument embedded in institutional strategic identity is not. The Gendarmerie sustained GendBuntu for 17 years across multiple governments because it was never primarily a cost programme.
"We should not see open source as an end, but rather as a means to gain sovereignty, build transparency, and progressively substitute pieces of our systems."
Emma Ghariani — Head of Open Source and Digital Commons, DINUMThat framing applies directly to enterprise strategy. Sovereignty is not achieved by adopting a specific technology. It is built progressively by understanding dependencies, reducing the ones that introduce unacceptable risk, and ensuring that the ones that remain are deliberate choices rather than inherited constraints.
Sovereignty as an architectural quality
The shift from treating sovereignty as a technology programme to treating it as an architectural property changes how it is assessed, governed, and maintained.
Enterprise Architecture has long treated qualities such as security, resilience, interoperability, scalability, maintainability, and availability as properties that influence every technology decision. These are not initiatives with their own budget lines that compete for funding alongside functional programmes. They are lenses through which every technology decision is evaluated — questions asked during platform selection, supplier assessment, system design, and technology retirement.
Digital sovereignty deserves to be treated in exactly the same way. Not as a programme that competes with digital transformation or cloud migration for resources, but as an architectural quality that shapes how all of those programmes are evaluated and executed.
The practical implication is that it changes the questions architects ask at every decision point. The traditional set:
- Is this solution technically capable of meeting our functional requirements?
- Is this solution secure, resilient, and maintainable?
- Is this solution cost-effective over its operational lifespan?
The additional question sovereignty as an architectural quality introduces:
Who ultimately controls this dependency — and what happens to our architecture if that control changes?
That question applies to every platform evaluation, every supplier selection, every AI service integration, every standards decision, and every supply chain choice. It does not always produce a different decision. But it ensures that strategic dependencies are visible, evaluated, and accepted deliberately rather than accumulated by default.
Treating sovereignty as an architectural quality requires embedding it in existing governance processes — architecture review boards, technology radar processes, supplier assessment frameworks, and technology strategy reviews — rather than creating a separate sovereignty programme. The discipline is new. The governance mechanisms are not. Embedding the question "who controls this dependency?" into existing EA practice is lower overhead and more durable than establishing a standalone programme that competes for attention alongside other strategic initiatives.
A maturity model for digital sovereignty
Most organisations sit at Level 2. Knowing what Levels 3 and 4 require is the starting point for a realistic roadmap.
Digital sovereignty maturity cannot be assessed by auditing a single technology decision. It requires evaluating the organisation's position across all seven layers of the Sovereignty Stack — and understanding which of those layers have been formally assessed, which have been assumed, and which have never been examined.
Four levels describe the progression from no formal sovereignty consideration to deliberate strategic management:
The majority of enterprises that have any formal sovereignty posture sit at Level 2 — Cloud Aware. They have addressed data residency for cloud infrastructure, have a GDPR compliance programme, and may have a DORA ICT risk assessment if they are in scope. They have not assessed identity sovereignty, AI API dependencies, CDN and DNS exposure, file format lock-in, or open-source supply chain risk. The gap between Level 2 and Level 3 is not a technology gap — it is an analytical one. Levels 3 and 4 require applying the stack framework systematically to the existing estate.
The goal is not Level 4 everywhere. Some dependencies are acceptable. Some are unavoidable given current technology landscapes. The goal is informed choice — ensuring that every dependency in the estate is there because it was deliberately evaluated and accepted, not because it was never assessed. That is the difference between a sovereignty strategy and a cloud decision.
This series: what each part covers
Each subsequent part examines a group of layers in practical depth — with regulatory context, enterprise implications, and architecture guidance.
Digital sovereignty is not a cloud strategy. It is not an operating system. It is not a procurement decision. It is an architectural property of the entire technology stack — and managing it deliberately is becoming a core responsibility of enterprise architecture.
The Sovereignty Stack framework gives that responsibility a systematic shape. Parts 2 through 5 give it practical content.
Comments
Post a Comment