Beyond Data Residency: Achieving Digital Sovereignty with Multi-Plane Cloud Native Architectures

For years, the gold standard for international cloud compliance was “data residency.” If a company could prove their databases were physically located within a specific country’s borders, they checked the box for regulators. However, in an era of globalized cloud control planes and extraterritorial data access laws, residency has become a fragile legal fiction. True digital sovereignty is no longer about where the bits are stored; it is about the jurisdiction of control and state.

As we navigate a landscape shaped by the EU Data Act, NIS-2 (Network and Information Security Directive), and DORA (Digital Operational Resilience Act), the technical requirements for “sovereign” platforms have shifted. It is no longer enough to trust a cloud provider’s contractual promise. Platform engineers must now build architectures that technically enforce jurisdictional boundaries, ensuring that even if a global administrator’s credentials are compromised, the localized data and execution environments remain unreachable and autonomous.

The Sovereignty Crisis: Why Data Residency is No Longer Enough

The fundamental problem with traditional data residency is the “Control Plane Paradox.” You may have a Kubernetes cluster running in a Frankfurt data center, but if the API server for that cluster is managed by a control plane located in the United States, the data is technically subject to foreign subpoenas and administrative override. Under regulations like NIS-2 and the UK Data Use and Access Act, this “remote control” creates a compliance vacuum.

Digital sovereignty requires a shift from location-based compliance to jurisdictional autonomy. This means:

1. Administrative Sovereignty: Ensuring that only authorized personnel within a specific jurisdiction can access the management interfaces of the infrastructure.
2. Operational Sovereignty: The ability to keep systems running even if the connection to the global central management is severed.
3. Data Sovereignty: Technical guarantees that data cannot be egressed to a different jurisdiction without explicit, auditable, and automated triggers.

The catalyst for this shift is the realization that “the cloud” is not a monolithic entity but a series of interconnected planes. To achieve sovereignty, we must decouple these planes, ensuring that while management may be global, the “state” and “control” remain local.

The Multi-Plane Topology: A Structural Blueprint

To build a sovereign platform, we must move away from the “single cluster” mindset and adopt a multi-plane topology. This architecture separates the platform into distinct functional layers, each with its own jurisdictional rules.

1. The Control Plane

The Control Plane acts as the “brain” of the platform. In a sovereign architecture, the global control plane handles high-level orchestration—such as defining what an application should look like—but it does not have direct access to the underlying data or the ability to “push” changes into a sovereign environment. Instead, it serves as a repository for desired state.

2. The Data Plane

The Data Plane is where the actual workloads reside. In a sovereign model, the Data Plane is localized within a specific jurisdiction. It is responsible for the execution of containers, the storage of persistent volumes, and the processing of user requests. Crucially, the Data Plane operates on a “pull” basis, fetching instructions from the control plane rather than allowing the control plane to reach into its network.

3. The Observability and Workflow Planes

One of the biggest challenges in sovereign architectures is maintaining visibility. If logs and metrics are exported to a central global dashboard, you have effectively leaked sovereign data.

• The Observability Plane uses local collectors (like OpenTelemetry and Prometheus) that aggregate data locally. Only anonymized or high-level “health” signals are permitted to cross jurisdictional boundaries.
• The Workflow Plane (often powered by Argo Workflows) manages the lifecycle of applications. It ensures that deployment pipelines respect “jurisdictional gates”—for example, preventing a deployment to a German cluster unless it has passed a specific compliance scan required by local law.

4. The Experience Plane

The Experience Plane is the Internal Developer Platform (IDP). It provides a unified interface for developers to interact with the platform, regardless of where the underlying infrastructure sits. This is critical for maintaining developer velocity; a developer shouldn’t need to know the intricacies of NIS-2 to deploy a microservice. They interact with the Experience Plane, which then routes the request through the appropriate sovereign channels.

This routing logic is increasingly complex, mirroring the challenges seen in scaling AI agents across global regions, where the choice of “where” to run a workload is determined by a mix of latency, cost, and strict compliance constraints.

Technical Enforcement: The Outbound-only mTLS Model

The most significant technical hurdle in sovereign architectures is the “Inbound Problem.” Traditionally, a central management server connects to a remote cluster’s API via a public or VPN-protected endpoint. However, having an open port for an API server—even one protected by a firewall—is a liability in highly regulated environments.

The “Dial-Out” Mechanism

To solve this, sovereign architectures utilize an outbound-only mTLS (Mutual TLS) model. In this pattern:

1. The sovereign Data Plane cluster does not expose any inbound ports to the internet or the global control plane.
2. An agent within the Data Plane initiates an outbound connection to the Control Plane.
3. This connection is secured via mTLS, where both the agent and the control plane must present valid, short-lived certificates issued by a trusted local Certificate Authority (CA).
4. Once the “tunnel” is established, the Data Plane pulls the desired state and reports back status.

Implementation with Cilium and cert-manager

Using Cilium as the Container Network Interface (CNI) allows for transparent encryption of all traffic between these planes. When combined with cert-manager, the rotation of these mTLS certificates can be automated, ensuring that even if a certificate is compromised, its window of utility is negligible.

# Example: Cilium Network Policy for Sovereign Egress
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "sovereign-egress-only"
  namespace: "platform-system"
spec:
  endpointSelector:
    matchLabels:
      app: "sovereign-agent"
  egress:
    - toEndpoints:
        - matchLabels:
            "io.kubernetes.pod.namespace": "kube-system"
    - toFQDNs:
        - matchName: "control-plane.global.mantbyte.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP
  # Note: No ingress rules are defined, defaulting to a "deny-all" inbound posture.

By eliminating public IP addresses for sensitive API servers, we move from a “perimeter-based” security model to a “zero-trust” model where the identity of the cluster itself is the primary gatekeeper.

The Reference Stack: Implementing Sovereignty with OpenChoreo

To move these concepts from theory to production, many organizations are looking toward the OpenChoreo project as a reference implementation. OpenChoreo provides an orchestrator specifically designed for these sovereign patterns, allowing for the declarative definition of “jurisdictions.”

Declarative Promotion Paths

In a sovereign platform, you cannot simply kubectl apply to a production environment. You need a promotion path that is aware of jurisdictional boundaries. Using Argo Workflows and Flux CD, OpenChoreo allows you to define a “Sovereign Promotion Path.”

For example, a developer pushes code to a Git repository. Flux detects the change and triggers an Argo Workflow. This workflow doesn’t just run tests; it checks the “Jurisdiction” metadata of the target cluster. If the target is “EU-Germany,” the workflow ensures that the container image was built using Cloud Native Buildpacks on a local, trusted builder to ensure provenance, and that all secrets are sourced from a local instance of the External Secrets Operator.

Managing Secrets Across Borders

Secrets management is often the “achilles heel” of sovereignty. If your secrets are stored in a global vault, you’ve lost sovereignty. The sovereign pattern requires a local secret store (like HashiCorp Vault or a cloud-native KMS) that the global control plane cannot access. The External Secrets Operator acts as the bridge, allowing the Data Plane to pull secrets from its local provider based on a reference provided by the Control Plane, without the Control Plane ever seeing the actual sensitive value.

Standardizing Builds with Provenance

Sovereignty also extends to the software supply chain. Using Cloud Native Buildpacks (CNB) ensures that every layer of a container image is accounted for. In a sovereign context, this means you can guarantee that a workload running in a specific jurisdiction was built using approved, audited base images that have not been tampered with by external actors.

Declarative Sovereignty: Auditing via GitOps

The true power of this architecture lies in making sovereignty a technical property rather than a legal one. By using GitOps, the entire jurisdictional state of the platform is defined in code.

Jurisdiction as a CRD

We can define a Custom Resource Definition (CRD) in Kubernetes called a Jurisdiction. This resource maps a cluster or a namespace to a specific set of legal and technical constraints.

apiVersion: sovereignty.mantbyte.com/v1alpha1
kind: Jurisdiction
metadata:
  name: eu-germany-prod
spec:
  region: "eu-central-1"
  complianceFrameworks:
    - "NIS-2"
    - "DORA"
  dataResidency:
    storageClass: "local-ssd-encrypted"
    backupPolicy: "local-only"
  accessControl:
    adminGroup: "de-ops-team"
    emergencyAccess: "break-glass-local"
  egressPolicy: "restricted-to-eu"

Automated Compliance Reporting

Because the entire state is in Git, auditing for NIS-2 or DORA becomes a matter of running a diff between the desired sovereign state and the actual state. If a cluster in the “EU-Germany” jurisdiction is suddenly found to be sending logs to a US-based S3 bucket, the GitOps controller can automatically trigger a reconciliation or raise a high-priority alert. This moves compliance from a manual, quarterly checklist to a continuous, automated process.

Geopolitical Resilience: Lessons from the Compute Ban

The push for sovereignty is not just about regulation; it is about resilience in a volatile geopolitical climate. We have seen how hardware constraints and compute bans can suddenly disrupt global platforms. Architects are increasingly forced to design for “compute autonomy”—the ability for a local region to survive and operate even if it is cut off from global supply chains or management software.

In our analysis of architectures designed to bypass compute bans, we observed that the most resilient systems are those that decouple the “intelligence” of the system from the “raw compute.” By applying this to platform engineering, we can create sovereign “cells” that are functionally independent.

This is particularly relevant for AI infrastructure. As organizations deploy large language models (LLMs) within sovereign boundaries, they must ensure that the model weights and the inference data never leave the jurisdiction. This requires a level of architectural rigor similar to the “Constitutional AI” frameworks used to govern model behavior at a foundational level. In both cases, the goal is to bake the “rules of the road” directly into the technical architecture so they cannot be bypassed by operational error.

The Future: Jurisdiction as a First-Class Citizen

As we look toward the next decade of cloud-native computing, digital sovereignty will evolve from a specialized requirement for banks and governments into a standard feature of all platform engineering.

We are already seeing the early signs of “Jurisdiction” becoming a first-class citizen in the CNCF ecosystem. Imagine a future where:

• Kubernetes Schedulers automatically account for jurisdictional metadata when placing pods, much like they account for CPU and memory today.
• Service Meshes provide “jurisdictional mTLS,” where traffic is automatically blocked if it attempts to cross a defined geographic boundary without a “compliance token.”
• Automated Promotion Pipelines that enforce “Sovereignty-by-Design,” where a developer can’t even trigger a build if the target environment’s jurisdictional requirements aren’t met.

The shift from data residency to digital sovereignty is a shift from where data sits to who can control it. By adopting a multi-plane architecture and leveraging outbound-only mTLS, platform engineers can build systems that are not only compliant with today’s regulations but are resilient to tomorrow’s geopolitical shifts. The future of the cloud is not a single global fabric, but a federation of sovereign, autonomous cells, unified by a common experience plane but governed by local law.