Darryl van der Peijl
Sovereignty is often used as a catch-all term in cloud conversations. However, the word describes multiple, distinct forms of control. Without separating these layers, discussions about “sovereign cloud” quickly become misleading and unhelpful for architectural decisions. In this blog, Darryl van der Peijl, CTO at Splitbrain, breaks down each sovereignty layer and shows what Azure Local actually delivers.
Sovereignty is not something you enable with a setting or buy as a product. It emerges from how different layers of control are designed, owned, and operated. Each layer answers a different question about risk, authority, and dependency. How can Azure Local help with each of them?
Location sovereignty is about where workloads physically run and who controls the site and hardware. Azure Local runs on customer-owned hardware in customer-controlled locations.
This gives you direct control over physical access, facility security, and network boundaries. You remove reliance on hyperscaler-owned datacenters. Your servers sit where you decide they sit.
Data sovereignty focuses on who can access and read data. With Azure Local, data remains on local storage. You protect it with customer-managed encryption and keys.
This protection works in multiple layers. At the platform level, BitLocker encrypts all storage volumes. You control the encryption keys, which means Microsoft cannot decrypt your data even if they wanted to. Without your keys, the data on those drives is unreadable.
Inside your virtual environments, you can apply additional encryption. Virtual machines can run their own BitLocker instances. Applications can implement their own encryption layers. This creates defense in depth, where compromising one layer does not expose everything.
Design this correctly, and neither the cloud provider nor external parties can technically access or decrypt your workload data.
Jurisdictional sovereignty is determined by which legal systems can impose obligations on the parties involved. This is where nuance matters.
Azure Local runs on-premises. But the platform is supplied and supported by Microsoft, a US-based legal entity. Jurisdiction does not require technical access to systems. It applies to the legal obligations of the vendor itself.
Here is the core tension: US legislation like the Cloud Act and FISA allows American authorities to compel US-based companies to hand over data, regardless of where that data physically sits. An Amsterdam datacenter operated by an American company still falls under US jurisdiction. At the same time, GDPR prohibits transferring personal data to countries without adequate protection. Complying with a US data request could mean violating European privacy law.
Azure Local changes part of this equation. Because the hardware sits on your premises and you control the encryption keys, Microsoft cannot technically access your data. They cannot hand over what they cannot reach. This addresses the technical access concern, but not the legal relationship with a US vendor.
For organizations where jurisdictional purity is a hard requirement, this distinction matters. Azure Local removes technical access to customer data. It does not remove Microsoft from the legal chain.
There is also a broader reality to consider: most enterprise software comes from American companies. Salesforce, Adobe, Oracle, ServiceNow, VMware, and countless others are US-based. If jurisdictional sovereignty means avoiding all US vendors, almost nothing qualifies. Even European alternatives often rely on American components, libraries, or infrastructure.
Software sovereignty concerns who controls the software stack and its evolution. Azure Local provides more autonomy than public cloud services. But the core platform, updates, and lifecycle remain vendor-driven.
This reflects a fundamental reality: building your own software is not a realistic option for most organizations. Microsoft invests billions annually in security research, feature development, and platform maintenance. They employ thousands of engineers working on problems that most companies cannot justify solving themselves. Replicating that capability requires resources that simply do not exist outside the largest technology companies.
The alternative, open-source software, shifts rather than eliminates dependency. Open-source communities can change direction, lose momentum, or fragment. Maintainers can disappear. Security vulnerabilities may go unpatched for longer. You trade vendor dependency for community dependency, with different risk profiles but not necessarily lower risk.
You trade deeper software independence for faster innovation and reduced operational complexity. For most organizations, this trade-off makes practical sense. The question is not whether to accept some dependency, but which dependencies offer the best balance of capability, security, and risk.
A clear distinction exists between control plane and data plane. Azure Local localizes the data plane entirely. Your workloads and data stay on your hardware.
The control plane supports lifecycle management and integration. It enables Azure Arc management, updates, and hybrid scenarios. The control plane does not process your workload data. It manages infrastructure, applies policies, and coordinates operations.
No cloud or on-premises solution delivers absolute sovereignty across all layers. Azure Local shifts the balance by increasing local control over infrastructure and data, while retaining some dependency at the software and vendor level.
Evaluate these trade-offs deliberately rather than assuming them away. A practical approach: map your requirements against each sovereignty layer. For each layer, ask what level of control you actually need, what risks you are trying to mitigate, and what you are willing to invest or sacrifice to achieve that control.
Location sovereignty is usually straightforward. If you need data in your building, Azure Local delivers that. Data sovereignty comes down to encryption and key management. If you control the keys, you control the data. Jurisdictional sovereignty requires legal analysis specific to your industry and geography. Software sovereignty requires honest assessment of your build-versus-buy capabilities.
Frameworks like the Cloud Security Alliance’s CCM or national guidelines from organizations like BSI can help structure this analysis. But the real work is internal: understanding which risks matter most for your organization and accepting that perfect sovereignty in all dimensions does not exist.
Azure Local does not make an environment sovereign by default. It provides architectural building blocks that allow you to increase control over location and data when used consciously.
What Azure Local does not deliver: independence from Microsoft as a vendor. You remain dependent on their software updates, their product roadmap, and their continued support for the platform. If Microsoft decides to discontinue Azure Local or change its direction, that affects your environment.
What you get in return: access to Microsoft’s security investment of over 1.5 billion dollars annually, continuous platform innovation, integration with Azure services, and operational tooling that would take years to build independently. Your infrastructure benefits from the same security research and feature development as Azure’s largest enterprise customers.
Sovereignty is achieved through informed design choices, not through labels or marketing terms.
Darryl
Gerelateerde blogs
