1
Sovereign 2.0: Control-Plane Sovereignty for Cloud Systems Under Disruption
arXiv:2604.14242v1 [cs.CR] 15 Apr 2026
Justin Stark University of Technology Sydney Sydney, NSW, Australia Accenture, Australia [email protected] [email protected]
Scott Wilkie University of Technology Sydney Sydney, NSW, Australia Accenture, Australia [email protected] [email protected]
result, systems can satisfy residency requirements while still lacking sovereign control over how they are governed, operated, and recovered. These conditions invalidate a purely location-centric model of sovereignty. The relevant question is no longer where data resides, but whether control over the service—including governance authority, privileged access, cryptographic trust, data lifecycle, observability, and incident response—remains enforceable within a sovereign boundary under both steadystate and disruption conditions. This paper defines Sovereign 2.0, a control-plane-centric model that reframes sovereignty as an enforceable property of system control rather than infrastructure location. In this model, sovereignty is evaluated in terms of control retention: the extent to which governance authority, operational capability, evidence, and trust remain within the sovereign boundary under conditions of disruption. We introduce management sovereignty as the core operating construct of Sovereign 2.0: the sovereign ability to govern, Index Terms—cloud sovereignty, digital sovereignty, sovereign approve, operate, evidence, and recover digital services across cloud, risk assurance, operational resilience, data residency, cloud their full service boundary, even when underlying infrastructure guardrails, post-quantum cryptography, TLS 1.3, hybrid key and dependencies remain federated. This shifts sovereignty exchange from a static compliance property to a dynamic, evidencebacked control system. I. I NTRODUCTION To operationalise this model, we propose a three-layer loud sovereignty has traditionally been framed as a ques- risk-assurance framework spanning governance, operational, tion of location: where data is stored, where infrastructure and technical domains. This framework provides a structured resides, and which jurisdiction governs the provider. This mechanism to specify, implement, and continuously evidence framing—here termed Sovereign 1.0—has shaped regulatory sovereign outcomes, bridging the gap between policy intent and policy, procurement requirements, and cloud architecture design enforceable control in both steady-state and crisis conditions. for over a decade. However, it is no longer sufficient to describe The significance of this shift is both practical and systemic. or assure sovereign control in modern cloud systems. As cloud systems become more distributed, interdependent, Three developments expose a structural gap between and long-lived, sovereignty must be engineered as a control residency-based sovereignty and contemporary service delivery. problem rather than a location property. This paper establishes First, geopolitical and kinetic disruptions demonstrate that that reframing and defines the foundation for an emerging cloud infrastructure remains physically vulnerable, and that discipline of sovereign service delivery. regional concentration can produce correlated service degradation. Second, extraterritorial legal regimes challenge the A. Contributions assumption that data location alone determines control. Third, This paper makes four contributions. the effective service boundary has expanded beyond the data centre to include identity systems, observability pipelines, SaaS • We redefine cloud sovereignty for contemporary disdependencies, AI services, and remote support pathways. As a tributed systems by showing that residency- and Abstract—Cloud sovereignty can no longer be defined by data residency or infrastructure location alone. Under conditions of geopolitical disruption, legal exposure, and expanding service boundaries, sovereignty must be understood as enforceable control over how digital services are governed, operated, and recovered. This paper introduces Sovereign 2.0, a control-plane-centric model that extends sovereignty beyond localisation to include governance authority, privileged access, cryptographic trust, data lifecycle control, observability, and incident response across federated environments. We define management sovereignty as the sovereign ability to govern, operate, evidence, and recover services regardless of underlying infrastructure dependencies. To operationalise this model, we propose a three-layer riskassurance framework spanning governance, operational, and technical controls, enabling sovereign outcomes to be specified and continuously evidenced under both steady-state and crisis conditions. We further position post-quantum-ready cryptographic control, particularly TLS and key custody, as foundational to long-term sovereign trust. These contributions reframe sovereignty as an evidence-backed control system rather than a property of location, with implications for cloud architecture, procurement, and resilience design.
C
2
localisation-based models are insufficient under conditions compromise, or unavailability of these dependencies can impair of geopolitical disruption, legal exposure, and service- the ability to govern or recover the system. 4) Cryptographic Degradation and Trust Erosion. Longboundary expansion. lived services rely on public-key cryptography for identity, • We introduce Sovereign 2.0, a control-plane-centric model that reframes sovereignty as an enforceable property of confidentiality, and integrity. Emerging threats, including postquantum adversaries and “harvest now, decrypt later” strategies, service delivery rather than infrastructure location. may undermine existing cryptographic mechanisms over time, • We define management sovereignty as the operating construct of Sovereign 2.0 and identify the control weakening trust relationships across the service boundary. domains—governance, identity and privileged access, cryptographic trust, data lifecycle, observability, and C. Sovereignty Failure Modes incident authority—that must remain under sovereign Under this threat model, a system fails to achieve sovereignty control. if any of the following conditions occur: • We propose a three-layer risk-assurance framework span• Loss of governance authority: the inability to define or ning governance, operational, and technical controls, enforce policy, approve actions, or exercise decision rights providing a structured mechanism to specify, implement, within the sovereign boundary. and continuously evidence sovereign outcomes across • Loss of operational control: the inability to administer federated environments. systems, execute recovery actions, or maintain service continuity without external or non-sovereign intervention. II. T HREAT M ODEL AND P ROBLEM C ONTEXT • Loss of evidentiary control: the inability to access, verify, Sovereign service delivery must be evaluated under condior retain logs, traces, and audit artefacts required to tions where control over digital systems is contested, degraded, demonstrate compliance and accountability. or disrupted. This paper considers a threat model that extends • Loss of trust control: the inability to govern cryptographic beyond conventional cybersecurity concerns to include geopomechanisms, key material, or trust anchors that underpin litical, legal, operational, and cryptographic stressors that affect system identity and secure communication. the control plane of cloud-based services. These failure modes highlight that sovereignty is not solely a property of data location, but of sustained control over the mechanisms that govern, operate, and verify the service. A. System Model We consider a distributed service S composed of infrastructure, platform, and application components deployed across one or more cloud environments. The effective service boundary of S includes not only compute and storage resources, but also identity systems, observability pipelines, software delivery infrastructure, external SaaS dependencies, and provider-operated support pathways. As a result, S is inherently federated, with control functions distributed across multiple administrative and jurisdictional domains. B. Adversarial and Disruption Model We define four classes of threats that directly impact sovereign control: 1) Kinetic and Infrastructure Disruption. Cloud infrastructure is physically instantiated and therefore subject to damage, degradation, or denial of service due to conflict, natural disasters, or targeted attacks. Such events may cause partial or complete loss of regional capacity, requiring rapid migration or failover under constrained conditions. 2) Jurisdictional and Legal Compulsion. Data and control planes may be subject to foreign legal regimes, including lawful access requests, disclosure obligations, or administrative control exerted through providers operating under different jurisdictions. These mechanisms can bypass or override local governance assumptions. 3) Control-Plane Dependency and Supplier Failure. Critical control functions—such as identity, logging, key management, and administrative access—may depend on external providers or cross-border support arrangements. Loss,
D. Problem Statement Given a federated service S operating under the threat conditions described above, the problem addressed in this paper is as follows: How can sovereign authority over governance, operation, evidence, and trust be maintained and demonstrably enforced across the full service boundary of S, even when underlying infrastructure and dependencies are distributed across multiple jurisdictions and subject to disruption? This problem definition motivates the transition from location-centric sovereignty models to the control-plane-centric approach developed in the remainder of this paper. III. W HY THE P ROBLEM I S N OW T IME -C RITICAL A. Cloud Is Physical, Concentrated, and Therefore Disruptable The 2026 AWS Middle East incident converted an abstract policy concern into an operational one. AWS publicly reported direct and nearby drone-strike impacts on facilities in the UAE and Bahrain, significant impairment in two UAE Availability Zones, and degraded availability across foundational and dependent services [1]. AP’s reporting highlighted the same point from a different angle: cloud infrastructure remains a set of real physical facilities that can be damaged by conflict and cannot be made invisible simply because the service model is abstracted [2]. The implications are broader than a single outage. First, critical workloads are often concentrated into a small number of preferred regions for latency, ecosystem, and regulatory reasons.
3
Second, resilience architectures are frequently optimised for failures within a region or a single Availability Zone, not for regional instability combined with evacuation, migration, and cross-border legal complexity. Third, recovery becomes a governance problem as much as a technical one: who has the authority to reroute traffic, relax policy constraints, activate alternate-region capacity, approve privileged changes, or invoke emergency supplier support? B. Residency Does Not Settle the Sovereignty Question A second reason for urgency is that residence and sovereignty are not the same. The Government of Canada has long distinguished data residency from data sovereignty, warning that data stored in cloud environments may still be subject to foreign laws regardless of where the infrastructure is physically located [3]. Canada’s newer digital sovereignty framework extends the discussion further, defining digital sovereignty in terms of autonomy over digital assets and services, with explicit attention to operational resilience, system integrity, supply-chain factors, and institutional control [3]. France’s ANSSI makes a similar move through SecNumCloud. ANSSI states that SecNumCloud is intended to recognise trusted cloud offers suitable for sensitive data and notes that the qualification aims in particular to protect sensitive data and processing against cybercriminal threat and the application of extraterritorial laws [4], [5]. This is conceptually important: the target is not merely local hosting, but legally and operationally meaningful control. C. The Service Boundary Has Expanded Beyond the Data Centre The final reason the issue is time-critical is that sovereign exposure increasingly appears outside traditional hosting scopes. Telemetry pipelines may export logs and metadata to foreignmanaged observability platforms. Identity federation may rely on external trust anchors. Managed support channels may create privileged administrative paths across jurisdictions. AI and analytics services may move sensitive prompts, embeddings, or intermediate data into external processing chains. Each of these can become a sovereignty leakage path unless it is explicitly governed. For this reason, sovereign service delivery must be evaluated at the service boundary rather than only at the hosting boundary. The question is not just whether data starts inside the jurisdiction, but whether governance, identity, keys, evidence, and incident response remain under sovereign authority throughout the full operating lifecycle. IV. F ROM S OVEREIGN 1.0 TO S OVEREIGN 2.0 A useful way to structure the sovereignty discussion is to begin with the now-common progression from sovereignty by localisation, to sovereignty by control, to sovereignty by design. This paper groups these into two eras. Sovereign 1.0 is the location-centric model. It maps most closely to sovereignty by localisation and the traditional emphasis on in-country hosting, local facilities, and geographic
data containment. It remains important, but on its own it mainly answers where workloads sit. Sovereign 2.0 is the management- and design-centric model. It incorporates sovereignty by control and sovereignty by design, shifting attention to who can administer, access, approve, evidence, and recover services, and to whether architecture embeds sovereignty constraints such as strong segmentation, dedicated trust anchors, independent key control, and minimised dependence on foreign-operated control planes. This distinction matters because real systems are inherently federated and layered. A platform can be localised at the data plane yet dependent on a foreign support path. It can be well controlled operationally yet lack sovereign recovery authority during crisis. It can be well designed cryptographically yet fail to provide locally governed evidence or supplier transparency. What is needed is a construct that focuses on the control outcomes that must remain sovereign across a mixed environment. A. Management Sovereignty This paper calls that construct management sovereignty, defined as: A system satisfies management sovereignty if governance, operational execution, evidence generation, and trust control remain enforceable within the sovereign boundary under both steady-state and disruption conditions. Management sovereignty is not the negation of Sovereign 1.0; rather, it operationalises Sovereign 2.0 by subsuming control and design questions into a single enforceable model. This emphasis resonates with recent policy language around “Sovereignty 2.0,” which rejects geographic abstractions in favour of measurable operational autonomy under selective interdependence [6]. A sovereign architecture need not eliminate all external dependencies; it must ensure that no single provider, jurisdiction, or support chain can unilaterally dictate outcomes during stress. Under this definition, a service is more sovereign when the following remain under sovereign authority: • Governance and decision rights: who can set policy, grant exceptions, and authorise emergency actions; • Identity and privileged access: who can administer systems, from where, under which approval chain, and with which evidence; • Cryptographic trust: who controls keys, certificate authorities, hardware security module (HSM) policies, and protocol transition decisions; • Data lifecycle and egress: how data is classified, tokenised, exported, replicated, and deleted; • Observability and evidence: where logs, traces, and alerts reside and who can inspect them; and • Incident and continuity authority: who commands recovery when the normal operating posture collapses. This lens aligns with the Government of Canada’s move from data sovereignty to digital sovereignty [3] while remaining compatible with more stringent national frameworks such as SecNumCloud [4], [5]. It also better reflects the operational
4
lessons of the Middle East cloud disruption, where the hardest questions were not only about storage location, but about migration, control, recovery, and authority. This control-plane perspective also extends to cryptographic trust. As long-lived services depend on public-key infrastructure and transport security, the ability to govern cryptographic transitions—particularly toward post-quantum-safe mechanisms—becomes part of sovereign control rather than a purely technical upgrade.
Despite this progress, most existing frameworks remain incomplete when evaluated against crisis conditions. Certification schemes and policy baselines tend to emphasise steady-state compliance, but provide limited guidance on sovereign authority during cross-border disruption, provider unavailability, or emergency migration. In particular, few frameworks explicitly define who retains decision rights over failover, privileged access, or recovery execution when normal jurisdictional and operational assumptions no longer hold. This gap reinforces the need for a control-plane-centric model of sovereignty that treats governance, operational authorV. C OMPARATIVE S TANDARDS AND P OLICY L ANDSCAPE ity, and evidence generation as first-class design requirements. No single global sovereign-cloud standard exists. Instead, Without explicit control over these elements, organisations the policy landscape is evolving through a combination of cannot reliably execute recovery or maintain sovereign authority certification schemes, security baselines, trusted-cloud qualifica- under disruption conditions. tions, and operational control frameworks. Table I summarises Sovereignty in this paper is evaluated in terms of control selected instruments relevant to management sovereignty. retention: the extent to which governance authority, operational The list is illustrative rather than exhaustive, but it shows capability, evidence, and trust remain enforceable within the a striking convergence around governance, legal exposure, sovereign boundary under both steady-state and disruption identity, cryptography, auditability, and continuity. conditions. Several observations follow from this landscape. Existing sovereignty frameworks have significantly advanced First, mature sovereignty-oriented frameworks rarely stop beyond pure residency requirements, particularly in areas such at residency. Canada explicitly extends the concept into as auditability, governance, and supply-chain control. However, operational resilience and institutional control [3]. France binds when evaluated against the threat model defined in Section trusted cloud qualification to technical, operational, and legal II, these frameworks remain primarily optimised for steadyconditions [4]. The UK NCSC principles ask evaluators to state compliance rather than sovereign control under disruption. inspect governance, administration, supply chain, and audit Table II summarises this distinction. evidence [16]. Dubai and Saudi Arabia both translate national cyber policy into concrete CSP obligations [17], [18]. VI. A T HREE -L AYER R ISK -A SSURANCE M ODEL Second, the European landscape is bifurcated between formal certification and ecosystem trust. The EU Cybersecurity The principal weakness of many sovereignty programmes Certification Framework provides EU-wide scheme machinery is that they stop at policy intent rather than demonstrable and assurance levels, while the EUCS cloud scheme remains control outcomes. Risk registers and procurement clauses state a candidate scheme under development [7], [8]. In parallel, what should happen, but they do not reliably prove what is Gaia-X has evolved a trust and labelling framework aimed at happening under steady-state or crisis conditions. To close that interoperable, federated, and policy-aware ecosystems, includ- gap, this paper proposes a three-layer risk-assurance model: ing criteria linked to transparency, portability, and “European governance assurance, operational assurance, and technical Control” [11], [13]. This combination matters because many assurance, illustrated in Fig. 1. sovereign services will operate through federated ecosystems rather than purely national stacks. Third, Europe is now using procurement as a sovereignty A. Governance Assurance Governance assurance defines the rules of the game. It lever rather than relying only on certification discourse. The Commission’s Cloud Sovereignty Framework defines eight answers what must be sovereign, why it must be sovereign, who sovereignty objectives spanning strategic, legal and jurisdic- decides, and how exceptions are governed. Relevant artefacts tional, data and AI, operational, supply chain, technology, include data-classification rules, sovereignty profiles by service security and compliance, and environmental dimensions [10]. It class, supplier policies, foreign-law exposure assessments, then applies minimum SEAL levels and a separate sovereignty exception approvals, and continuity thresholds. score that contributes to tender quality evaluation [9], [10]. This layer should establish at least four outcomes. First, This is one of the clearest current examples of Sovereign 2.0 the organisation should be able to identify which data classes, being quantified, audited, and commercialised as an award keys, identity functions, logs, and operational roles require criterion. sovereign treatment. Second, it should know which jurisdictions, Fourth, continuity and outage handling are becoming providers, and support pathways are acceptable for each service sovereignty concerns in their own right. Singapore’s MTCS class. Third, it should define emergency decision rights so that is a cloud-security standard, but IMDA’s associated technical crisis actions are pre-authorised rather than improvised. Fourth, reference on cloud outage incident response recognises that it should create contractual and policy hooks that obligate cloud assurance must be paired with disciplined outage response external providers to support evidence generation, incident and disaster recovery expectations [21]. The 2026 Middle East notification, lawful-access transparency where permitted, and incident strongly reinforces that point. service-continuity cooperation.
5
TABLE I S ELECTED S OVEREIGNTY-R ELEVANT F RAMEWORKS AND C ONTROL BASELINES (I LLUSTRATIVE , N OT E XHAUSTIVE ) Jurisdiction / Ecosystem
Instrument
Primary Emphasis
Relevance to Management Sovereignty
European Union
EU Cybersecurity Certification Framework; EUCS candidate scheme [7], [8] Cloud Sovereignty Framework v1.2.1; EUR 180M sovereign-cloud tender [9], [10] Gaia-X Trust Framework and Label [11]–[13]
EU-wide certification language, scheme governance, assurance levels (basic, substantial, high)
Creates a common assurance vocabulary across member states; useful for procurement and comparability, but EUCS remains a candidate rather than a finalised sovereign-cloud scheme.
Eight sovereignty objectives; minimum SEAL thresholds; sovereignty scoring as tender award input
Turns sovereignty from declarative policy into measurable procurement and assurance criteria, closely matching a Sovereign 2.0 and management-sovereignty approach.
Transparency, portability, interoperability, compliance, “European Control,” federated trust High technical, operational, and legal requirements for trusted cloud; sensitivity to extraterritorial-law exposure Minimum cloud controls, independent audit, jurisdiction and disclosure transparency, logging, key management, continuity Data in transit, asset protection, governance, operational security, personnel, supply chain, administration, audit Mandatory requirements for CSPs serving Dubai government and semi-government entities Minimum cloud cybersecurity requirements for providers and tenants, updated for data-localisation requirements Operational resilience, institutional control, legal and supply-chain risk, mandatory baseline controls
Important for multi-party ecosystem governance where sovereignty depends on verifiable policy and trust assertions across federated participants.
Tiered cloud assurance and explicit outage-response guidance for cloud environments
Combines certification with outage-preparedness, reinforcing that sovereignty and resilience must be treated together.
European Commission procurement
Gaia-X ecosystem
France
ANSSI SecNumCloud v3.2 [4], [5]
Germany
BSI C5 [14], [15]
United Kingdom
NCSC Cloud Security Principles [16]
Dubai (UAE)
DESC CSP Security Standard [17]
Saudi Arabia
NCA Cloud Cybersecurity Controls (CCC–2:2024) [18]
Canada
GC Digital Sovereignty Framework; GC Cloud Guardrails; data sovereignty white paper [3], [19], [20] MTCS SS 584:2020 and TR 62 cloud outage incident response [21]
Singapore
B. Operational Assurance
One of the clearest examples of sovereignty extending beyond hosting to legal and operational conditions of trust.
Strong evidence-oriented baseline for enterprise cloud assurance; especially useful for proving operational and technical control maturity.
Explicitly links cloud suitability to evidence, governance, and administrative control rather than geography alone.
Shows a jurisdictional model where government cloud supply is conditioned on a local certification and surveillance regime.
Demonstrates how sovereignty concerns are being translated into national cloud-control obligations, including localisation-sensitive updates. Directly supports the move from location-centric sovereignty to control, assurance, and resilience across government operations.
to-recover metrics, alternate-region readiness, and supplier participation in continuity tests.
Operational assurance is where sovereignty either succeeds or fails. It covers how systems are actually run: privileged access workflows, just-in-time elevation, segregation of duties, C. Technical Assurance software release approvals, configuration baselines, incident Technical assurance provides the mechanisms that make command, crisis communications, break-glass procedures, governance and operations enforceable. It includes sovereign backup restoration, and cross-region failover exercises. identity boundaries, transport and storage encryption, key manThe 2026 AWS Middle East disruptions make the need agement, tokenisation, egress controls, observability pipelines, for operational assurance concrete. A sovereign claim has policy enforcement points, continuous control monitoring, limited value if an organisation cannot execute an approved tamper-evident logging, and crypto agility. migration, recover from remote backups, reroute traffic, or Technical assurance is also where post-quantum migration maintain locally governed incident command under pressure. belongs. Sovereign control is partly a matter of how trust is Operational assurance therefore requires evidence such as established and rotated. If an organisation cannot inventory access logs, approval records, rehearsal results, mean-time- where vulnerable public-key cryptography is used or update
6
TABLE II C OMPARISON OF S OVEREIGNTY C APABILITIES ACROSS M ODELS Capability
Existing Frameworks (e.g., SecNumCloud, EUCS, NCSC, C5) Explicitly defined and auditable residency and jurisdictional constraints
Crisis-time decision authority (failover, migration, recovery)
Sovereign 1.0 (Residency / Localisation) Strong emphasis on incountry storage and processing Limited; often implicit or delegated to provider control planes Not addressed; assumes steady-state conditions
Operational independence under disruption
Not considered; assumes provider availability
Addressed indirectly via resilience and continuity controls
Evidentiary control (logs, audit, traceability)
Minimal focus beyond compliance artefacts
Strong emphasis on auditability and logging in steady state
Supplier and sovereignty
Not addressed
Partially addressed through supplychain and personnel controls
Service-boundary coverage (SaaS, identity, telemetry, AI)
Focused on infrastructure and data plane
Expanding coverage, but often scoped to primary cloud services
Cryptographic trust and key control
Implicit managed
Addressed through key management and encryption requirements
Post-quantum readiness
Not addressed
Emerging consideration, not yet systematically integrated
Sovereignty under disruption (combined stress conditions)
Not addressed
Limited treatment; primarily steadystate assurance
Data location control Control-plane authority (governance, admin, policy)
support-path
or
provider-
Partially addressed through governance and administrative requirements Limited guidance; typically unspecified under cross-border disruption
its TLS and PKI dependencies, or cannot ensure sovereign governance of keys and certificate authorities, then its trust boundary remains externally fragile. Together, these three layers provide a structured mechanism for evaluating and enforcing management sovereignty. They translate abstract sovereignty requirements into observable and testable control outcomes across governance, operations, and technical implementation. VII. S OVEREIGN S ERVICE D ELIVERY IN F EDERATED E NVIRONMENTS A realistic sovereignty model must assume that many organisations will continue to depend on global providers, shared infrastructure, and specialised suppliers. For that reason, management sovereignty should not be interpreted as a requirement to build every layer domestically. Rather, it should be treated as an operating model that distinguishes which functions may be federated and which must remain sovereign. In practice, sovereign service delivery requires changes to core operating assumptions. First, privileged access cannot be globally ambient. Administrative access should be jurisdiction-scoped, time-bounded, approved, monitored, and forensically attributable. Second, support pathways must be treated as control boundaries. The ability of an external provider to “help” with a service is itself a sovereignty decision that should be policy-driven and auditable. Third, DevSecOps pipelines, configuration repositories, and production-signing processes should be segmented in proportion to data class and continuity criticality. Fourth,
Sovereign 2.0 (This Paper) Preserved, but treated as necessary rather than sufficient Explicit requirement that governance and privileged control remain under sovereign authority Explicit requirement for sovereign control over recovery, failover, and emergency actions Explicit requirement to operate and recover services without nonsovereign intervention Requirement for sovereign access to tamper-evident evidence under both steady-state and crisis conditions Explicit requirement to govern and constrain external support pathways and dependencies Explicit inclusion of full service boundary, including external dependencies and control-plane components Explicit requirement for sovereign key custody, trust-anchor control, and crypto transition governance Treated as a foundational sovereignty control for longlived services Central design objective: maintaining control, evidence, and trust under disruption
continuity plans should assume not only conventional outages, but also loss of region, loss of provider pathway, or temporary suspension of normal cross-border operations. Fifth, evidence collection should be designed as an operational product, not an afterthought. This federated approach aligns with several of the frameworks surveyed above. Canada’s digital sovereignty framework emphasises legal, supply, and technical controls alongside continuity and resilience [3]. The NCSC principles place strong emphasis on administrative security, personnel trustworthiness, supply-chain security, and customer audit information [16]. Singapore’s outage-response guidance reinforces that cloud assurance is incomplete without disciplined incident and continuity practice [21]. A. Example Implementation Pattern To make management sovereignty concrete, a representative sovereign service architecture should implement control-plane isolation and evidence generation across key domains. Identity and privileged access should be enforced through jurisdiction-scoped privileged access management (PAM), with just-in-time elevation, multi-party approval, and full session recording. Administrative actions must be attributable and governed within the sovereign boundary. Cryptographic trust should be anchored in sovereign key custody, with hardware security modules (HSMs) under local control, sovereign certificate authorities, and policy-governed key lifecycle management. External trust dependencies should be minimised or explicitly governed.
7
Drivers of urgency Kinetic disruption of cloud regions; extraterritorial legal exposure; service-boundary sprawl through APIs, SaaS, telemetry, identity federation, AI services, and remote support dependencies. Layer 1: Governance assurance Sovereignty profiles by data and service class; jurisdictional acceptability; decision rights; exception handling; supplier and contract requirements; continuity thresholds. Layer 2: Operational assurance Privileged access governance; incident command; disaster recovery rehearsals; release and configuration control; evidence production; emergency operating authority. Layer 3: Technical assurance Identity boundaries; encryption and key control; egress and tokenisation; sovereign telemetry; continuous control monitoring; crypto agility and protocol transition readiness. Management sovereignty control domains Governance and decision rights · Identity and PAM · Keys and trust anchors · Data lifecycle and egress · Observability and evidence · Supplier and support control Sovereign service delivery model Jurisdiction-specific teams · Segregated DevSecOps pipelines · Controlled vendor support paths · Federated continuity runbooks · Local incident and crisis authority · Evidenceas-a-service for auditors and regulators Foundational trust layer: post-quantum-ready TLS and PKI Crypto inventory · Hybrid TLS 1.3 transition · Sovereign key custody · Certificate and trust-anchor governance · Protection against harvest-now-decrypt-later exposure. Fig. 1. Management sovereignty as a three-layer assurance problem delivered through sovereign operating controls and anchored by post-quantum-ready trust.
Observability pipelines should retain primary logs, traces, and alerts within the sovereign domain, with export controls applied to downstream analytics or external monitoring services. Logs should be tamper-evident and accessible for regulatory inspection. Data egress should be mediated through policy enforcement points, including API gateways, tokenisation, and allowlisting, ensuring that both bulk data and operational metadata flows are governed. Continuity architecture should include pre-authorised failover patterns, jurisdiction-aware disaster recovery runbooks, and clearly defined incident command authority, enabling rapid migration or recovery without requiring external approval under crisis conditions. Together, these patterns illustrate how management sovereignty can be implemented as an enforceable control system rather than a declarative policy posture. VIII. E XTERNAL S ERVICES AS S OVEREIGNTY L EAKAGE PATHS In many environments, the largest sovereignty exposure is not the primary compute platform but the surrounding
services. SaaS collaboration suites, observability providers, security tooling, code-hosting platforms, AI model endpoints, ticketing systems, and identity brokers all process operationally significant data. Some services process content, while others handle metadata and administrative context. Management sovereignty treats these services as managed dependencies rather than peripheral tools. Four design principles follow. The first is classification-driven service use. Not all service classes should be allowed to handle all data classes, and the rules should extend to telemetry, prompts, model outputs, and administrative metadata. The second is egress discipline. API gateways, data loss prevention, tokenisation, and allowlisting must be applied not only to bulk transfers but also to streaming and support paths. The third is evidence discipline. External services should supply immutable audit evidence, retention controls, and notification pathways. The fourth is recoverability discipline. Organisations should know how to continue operating when a peripheral dependency becomes unavailable, legally inaccessible, or politically unacceptable. This is a primary source of sovereignty leakage in otherwise well-architected platforms. A sovereign hosting enclave is weakened if its logs are exported to a non-sovereign platform, if its identity plane is anchored elsewhere, or if emergency support requires foreign privileged access that cannot be constrained or independently evidenced. IX. P OST-Q UANTUM TLS AS A S OVEREIGNTY C ONTROL A. Why TLS Belongs Inside the Sovereignty Model TLS is commonly treated as transport plumbing. In sovereign service delivery it should be treated as a trust control. APIs, identity federation, administrative consoles, service meshes, data replication links, and inter-agency exchanges all depend on TLS-mediated trust relationships. If those trust relationships cannot be inventoried, updated, and governed under sovereign control, then neither the confidentiality nor the continuity of the service boundary is fully sovereign. B. Why the Timing Is Immediate NIST is explicit that the transition to post-quantum cryptography should begin now. Its plain-language guidance warns that encrypted data is already vulnerable to “harvest now, decrypt later” collection strategies for secrets with long confidentiality lifetimes [22]. The broader NIST PQC programme notes that the first three standards are ready for implementation now [23]. NIST finalised FIPS 203, FIPS 204, and FIPS 205 in August 2024 [24], [25]. NIST’s migration project and draft transition guidance further stress the need to inventory quantumvulnerable public-key dependencies and build roadmaps across hardware, software, services, and protocols [26], [27]. This matters directly for sovereign services because identity and inter-service trust often protect data whose value outlives the current cryptographic era: citizen records, health information, justice data, operational telemetry, and criticalinfrastructure interactions. Where confidentiality lifetimes are long, waiting for a complete post-quantum market transition is itself a sovereignty risk.
8
and resilience [3]. Singapore couples tiered assurance with The IETF’s work on hybrid key exchange in TLS 1.3 outage response [21]. Even highly trust-sensitive frameworks provides a practical transition pattern: combine classical and such as SecNumCloud address how commercial cloud can post-quantum key establishment so that the session remains be made trustworthy under stringent conditions rather than secure unless all component mechanisms are broken [28]. This assuming that only wholly national stacks are acceptable [4]. This paper is a design and governance analysis rather than approach is attractive for sovereign service delivery because it supports staged migration without requiring an instantaneous an empirical evaluation. The AWS Middle East disruptions are used as a contemporary forcing function rather than as replacement of the installed base. A sovereignty-oriented TLS transition should therefore a comprehensive case study. Future work should apply the include at least four workstreams. The first is a cryptographic in- proposed model to real-world deployments to validate its ventory: every externally reachable service, internal API, VPN, effectiveness across different sectors and threat conditions. load balancer, service mesh, HSM, certificate authority, and In addition, some key public schemes are still evolving; identity component that depends on public-key cryptography most notably, the EUCS cloud scheme remains a candidate should be identified. The second is crypto agility: systems scheme rather than a finalised European sovereign-cloud should be able to change key-establishment and signature certification [8]. These limitations do not undercut the central algorithms without wholesale redesign. The third is hybrid argument, but they do mean that management sovereignty transition: organisations should test and phase in hybrid TLS should be refined further through operational field studies, where interoperability and platform support make it feasible. assurance metrics, and sector-specific deployment patterns. Management sovereignty is not without trade-offs. ImThe fourth is sovereign key custody: certificate issuance, revocation, rotation, HSM policy, root and intermediate trust plementing jurisdiction-scoped control-planes, sovereign key anchors, and approval workflows should remain under sovereign custody, and independent observability increases architectural complexity and operational overhead. It may also constrain governance. In this sense, post-quantum TLS is not a cryptographic side the use of globally integrated SaaS platforms and limit certain issue. It is part of the same control problem as privileged economies of scale offered by hyperscale providers. In addition, enforcing sovereign control over support pathaccess, logging, and continuity. It determines whether the service boundary can retain trustworthy communications and ways and administrative access can introduce latency in incident response if not carefully designed. These trade-offs require identity under future cryptanalytic conditions. deliberate balancing between sovereignty, cost, performance, and operational agility. X. D ISCUSSION For this reason, management sovereignty should be applied Three broader implications follow from the argument devel- proportionally, with higher assurance levels reserved for seroped above. vices with greater sensitivity, regulatory exposure, or continuity First, sovereign service delivery should be framed as a criticality. spectrum of control outcomes rather than an all-or-nothing infrastructure attribute. Full autonomy is rarely realistic, and XI. C ONCLUSION the Government of Canada explicitly recognises that complete The sovereign-cloud debate has entered a new and explicitly digital autonomy is impossible in a globally connected environment [3]. A more useful design question is: which functions operational phase. The combination of kinetic stress on must remain sovereign, at which assurance level, under which cloud infrastructure, ongoing extraterritorial legal exposure, expanding service boundaries, and the post-quantum transition disruption assumptions? Second, the most credible sovereignty models are those that means that sovereignty can no longer be reduced to data combine legal, operational, and technical controls. Residency- residency or local hosting claims. The 2026 AWS Middle only models fail under foreign legal compulsion. Operational- East disruptions demonstrated that regional cloud dependency only models fail when evidence is weak or cryptographic trust is is a continuity problem as much as a compliance problem [1], externally anchored. Technical-only models fail when supplier [2], [29]. Contemporary government and standards frameworks contracts, emergency decision rights, or continuity authority are increasingly reflect the same shift, whether through operational vague. Management sovereignty is valuable precisely because resilience and institutional control in Canada, trusted-cloud qualification in France, governance and audit expectations in it compels these dimensions to be designed together. Third, the path forward is likely to be federated rather the UK, or cloud control baselines in Dubai, Saudi Arabia, and than isolationist. That conclusion is consistent with recent Singapore [3], [4], [16]–[18], [21]. descriptions of “Sovereignty 2.0,” which emphasise strategic This paper has argued for management sovereignty as the autonomy through selective interdependence rather than com- appropriate next-step concept. In the terminology proposed plete autarky [6]. The standards landscape already points in here, Sovereign 1.0 remains necessary but insufficient: location this direction. EU certification and Gaia-X emphasise common still matters, but it does not settle the questions of authority, assurance and federation [7], [13]. The European Commission’s evidence, recovery, and trust. Sovereign 2.0 adds those diCloud Sovereignty Framework goes further by embedding mensions by evaluating whether governance, privileged access, sovereignty metrics directly into procurement [9], [10]. Canada cryptographic trust, data lifecycle and egress, observability, stresses interoperability with trusted partners alongside control supplier dependency, and recovery authority remain under C. A Pragmatic Transition Pattern
9
sovereign control and can be continuously evidenced. Under that model, risk assurance is not a supporting activity but the mechanism by which sovereign claims become credible. The European Commission’s Cloud Sovereignty Framework is important precisely because it shows how a jurisdiction can convert those claims into minimum assurance thresholds and procurement scoring rather than leaving them at the level of policy rhetoric [9], [10]. Post-quantum-ready TLS and PKI are likewise not future nice-to-haves, but foundational trust controls that help keep sovereign service boundaries viable over the confidentiality lifetime of the data they protect. The practical implication is clear: sovereign services must be engineered and operated as evidence-backed control systems capable of maintaining authority, trust, and continuity under both jurisdictional pressure and physical disruption. XII. F UTURE W ORK AND R ESEARCH AGENDA The model of Sovereign 2.0 and management sovereignty defined in this paper establishes a foundation for a broader research and implementation programme. Several directions follow directly from this work. First, there is a need for formalised measurement and assessment. Future work should develop sovereignty metrics and maturity models that quantify control retention across governance, operational, technical, and cryptographic domains. Such metrics would enable organisations and regulators to evaluate the degree to which sovereign authority is maintained under both steady-state and disruption conditions, and to compare alternative architectures and provider models. Second, the translation of management sovereignty into enforceable procurement and assurance mechanisms remains an open problem. While emerging frameworks introduce sovereignty objectives and scoring, further work is required to define verifiable control requirements, audit artefacts, and continuous assurance mechanisms that can be embedded in contracts, certification schemes, and regulatory oversight. Third, reference architectures and implementation patterns should be developed and validated across representative environments. This includes formalising sovereign controlplane isolation patterns, evidence pipelines, jurisdiction-scoped identity and access models, and continuity architectures capable of operating under region loss, supplier unavailability, or crossborder constraint. Fourth, sector-specific applications of management sovereignty require further exploration. Critical infrastructure, public-sector systems, and regulated industries exhibit different risk profiles, legal exposures, and continuity requirements. Applying the model across these domains will help refine proportionality, assurance levels, and control prioritisation. Finally, the role of cryptographic sovereignty in long-lived systems warrants deeper investigation. The transition to postquantum cryptography introduces new requirements for crypto agility, key governance, and trust-anchor control. Future work should examine how sovereign control over cryptographic mechanisms can be maintained across heterogeneous platforms and evolving standards over multi-decade service lifecycles. Together, these directions position Sovereign 2.0 not as a static framework, but as the basis for an evolving discipline
of sovereign service delivery, spanning architecture, policy, assurance, and operational practice. R EFERENCES [1] Amazon Web Services, “Amazon web services service status,” [Online]. Available: https://status.aws.amazon.com/rss/all.rss, Apr. 2026, accessed: Apr. 6, 2026. Chan, “Iranian strikes on amazon data centers [2] K. highlight industry vulnerability to physical disasters,” [Online]. Available: https://apnews.com/article/ amazon-aws-data-center-uae-iran-bahrain-71066b0a822c4cfd88b61e3fe79af917, Mar. 2026, accessed: Apr. 6, 2026. of Canada, “Digital sovereignty frame[3] Government work,” [Online]. Available: https://www.canada.ca/.../ digital-sovereignty-framework-improve-digital-readiness.html, 2025, accessed: Apr. 6, 2026. “Cloud,” [Online]. Available: https://cyber.gouv.fr/ [4] ANSSI, enjeux-technologiques/cloud/, 2026, accessed: Apr. 6, 2026. [5] ——, “Secnumcloud requirements v3.2,” [Online]. Available: https: //cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/, 2026, accessed: Apr. 6, 2026. [6] W. Dixon and S. Wilkie, “Sovereignty 2.0: Why europe’s eur 180 million cloud bet matters,” [Online]. Available: https://www.weforum.org/stories/ 2025/11/sovereignty-2-why-europe-180-million-cloud-bet-matters/, Nov. 2025, accessed: Apr. 8, 2026. [7] European Commission, “Eu cybersecurity certification framework,” [Online]. Available: https://digital-strategy.ec.europa.eu/en/policies/ cybersecurity-certification-framework, Jan. 2026, accessed: Apr. 6, 2026. [8] European Union Agency for Cybersecurity (ENISA), “Eucs — cloud services scheme,” [Online]. Available: https://www.enisa.europa.eu/ publications/eucs-cloud-service-scheme, ENISA, Tech. Rep., Dec. 2020, accessed: Apr. 6, 2026. [9] European Commission, “The commission moves forward on cloud sovereignty with a eur 180 million tender,” [Online]. Available: https://commission.europa.eu/news-and-media/news/ commission-moves-forward-cloud-sovereignty-eur-180-million-tender-2025-10-10_ en, Oct. 2025, accessed: Apr. 8, 2026. [10] European Commission, Directorate-General for Digital Services, “Cloud sovereignty framework, version 1.2.1,” [Online]. Available: https://commission.europa.eu/document/download/ 09579818-64a6-4dd5-9577-446ab6219113_en, European Commission, Tech. Rep., Oct. 2025, accessed: Apr. 8, 2026. [11] Gaia-X, “Gaia-x: A federated secure data infrastructure,” [Online]. Available: https://gaia-x.eu/, 2026, accessed: Apr. 6, 2026. [12] ——, “Gaia-x label,” [Online]. Available: https://gaia-x.eu/wp-content/ uploads/2024/03/Labels-Document_2024_FINAL-V2-1.pdf, 2024, accessed: Apr. 6, 2026. [13] ——, “Gaia-x framework,” [Online]. Available: https://gaia-x.eu/ gaia-x-framework/, 2026, accessed: Apr. 6, 2026. [14] BSI, “C5 criteria catalogue,” [Online]. Available: https://www.bsi.bund. de/EN/Themen/.../kriterienkatalog-c5_node.html, 2026, accessed: Apr. 6, 2026. [15] ——, “Cloud computing compliance controls catalogue (c5),” [Online]. Available: https://www.bsi.bund.de/.../ ComplianceControlsCatalogue-Cloud_Computing-C5.pdf, BSI, Tech. Rep., 2020, accessed: Apr. 6, 2026. [16] UK National Cyber Security Centre, “The cloud security principles (v2.1),” [Online]. Available: https://www.ncsc.gov.uk/collection/cloud/ the-cloud-security-principles, Jun. 2023, accessed: Apr. 6, 2026. [17] Dubai Electronic Security Center, “Cloud service provider security standard,” [Online]. Available: https://www.desc.gov.ae/regulations/ certifications/, 2026, accessed: Apr. 6, 2026. [18] National Cybersecurity Authority, “Cloud cybersecurity controls (ccc2:2024),” [Online]. Available: https://nca.gov.sa/en/regulatory-documents/ controls-list/ccc/, Jul. 2025, accessed: Apr. 6, 2026. [19] Treasury Board of Canada Secretariat, “Gc cloud guardrails,” https: //canada-ca.github.io/cloud-guardrails/, 2024, accessed: 2026-04-06. [20] Government of Canada, “Data sovereignty and the cloud: A government of canada perspective,” https://www.canada.ca/ en/treasury-board-secretariat/services/information-technology/ data-sovereignty.html, 2018, accessed: 2026-04-06. [21] Infocomm Media Development Authority, “Cloud computing and services,” [Online]. Available: https://www.imda.gov.sg/.../ cloud-computing-and-services, 2026, accessed: Apr. 6, 2026.
10
[22] NIST, “What is post-quantum cryptography?” [Online]. Available: https://www.nist.gov/cybersecurity-and-privacy/ what-post-quantum-cryptography, 2026, accessed: Apr. 6, 2026. [23] ——, “Post-quantum cryptography,” [Online]. Available: https://www. nist.gov/pqc, 2026, accessed: Apr. 6, 2026. [24] ——, “First finalized post-quantum encryption standards,” [Online]. Available: https://www.nist.gov/news-events/news/2024/08/..., Aug. 2024, accessed: Apr. 6, 2026. [25] National Institute of Standards and Technology (NIST), “Announcing finalized post-quantum cryptography standards (fips 203, fips 204, fips 205),” https://www.nist.gov/news-events/news/2024/08/ nist-releases-first-3-finalized-post-quantum-encryption-standards, 2024, accessed: 2026-04-06.
[26] ——, “Nccoe post-quantum cryptography migration project,” https://www. nccoe.nist.gov/projects/building-blocks/post-quantum-cryptography, 2026, accessed: 2026-04-06. [27] NIST, “Ir 8547: Transition to post-quantum cryptography,” [Online]. Available: https://csrc.nist.gov/pubs/ir/8547/ipd, NIST, Tech. Rep., 2024, accessed: Apr. 6, 2026. [28] IETF, “Hybrid key exchange in tls 1.3,” [Online]. Available: https:// datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/, Sep. 2025, work in progress. Accessed: Apr. 6, 2026. [29] Amazon Web Services, “Service health — apr. 5, 2026,” [Online]. Available: https://health.aws.amazon.com/health/status, Apr. 2026, accessed: Apr. 6, 2026.