Home Insights

Sovereignty in Azure

3 myths about sovereignty in Microsoft Azure | Lume

Sovereign cloud in Azure: 3 common misconceptions, and what to do instead

The geopolitical climate is shifting. Regulations are tightening. And boards are asking questions about digital sovereignty that nobody had clear answers to 12 months ago. The pressure is real, coming from NIS2, DORA, the EU AI Act, and an increasingly unpredictable geopolitical environment all at once. The reaction for many organizations is to move away from public cloud altogether. That reaction is understandable. But it's driven more by anxiety than by facts. In reality, sovereign cloud is not about leaving Azure. It's about understanding how to use it in a way that aligns with your legal, operational and security requirements, and knowing when a different architecture is the right answer.

  • Understand what sovereign cloud is really all about
  • Learn what actually matters from control and flexibility
  • Discover how to avoid overengineering, driven by misconceptions
Michael Kelarou - Cloud Expert

What makes a cloud "sovereign"?

Sovereign cloud is often reduced to a single question: where is my data stored? While location plays a role, it is only one piece of the puzzle. True sovereignty comes from how your environment is designed and governed, how access is controlled, how data is encrypted at every layer, how operational responsibilities are divided, and who is accountable when something goes wrong.

If those elements are not in place, storing data in Belgium does not guarantee compliance or protection. A poorly governed environment in-country can still introduce more risk than a well-designed multi-region Azure setup. Sovereignty, in that sense, is architectural before it is geographical.

The European Commission now formalizes this through a Cloud Sovereignty Framework that evaluates providers across eight dimensions. From legal jurisdiction and data control, to supply chain transparency, operational independence, and technology portability. Cloud infrastructure is one part of that picture. Governance, architecture, and partner accountability are equally weighted.

Learn more

3 common misconceptions about cloud sovereignty

Some organizations overcorrect, moving entirely away from hyperscalers, accepting higher costs, more complexity, and slower innovation in the process.

Others underestimate the challenge and assume their current setup is already sufficient. Both reactions are fueled by misconceptions about what sovereignty actually requires. Here are the three we hear most often.

1. "Sovereign cloud means no public cloud"

The assumption that sovereignty and Azure are somehow at odds is the most common and the most costly misconception. Walking away from public cloud often creates more problems than it solves: higher infrastructure costs, loss of innovation velocity, reduced access to AI capabilities, and operational complexity that most internal teams are not equipped to manage long-term.

The reality is that Azure already provides a full spectrum of sovereignty options, by design. At one end: sovereign public cloud with EU Data Boundary, regional data residency controls, and confidential computing built in. Further along: Azure Local, which lets organizations run Azure-native services in their own infrastructure, connected or fully disconnected. At the far end: national partner clouds for the most sensitive scenarios.

Most organizations don't belong at either extreme. The right architecture sits somewhere between sovereign public cloud and fully private cloud, and identifying exactly where, is the strategic question, not whether to use the platform at all.

2. "Storing your data in Belgium means you're protected"

This is the misconception that creates the most false confidence. Location and protection are not the same thing. Storing data in Belgium, or in any EU region, does not automatically shield it from non-EU legal access. The US CLOUD Act is the most commonly cited concern, and while its scope is narrower than most organizations assume, the underlying principle holds: where data sits and who can read it are two entirely different questions.

What actually protects you is encryption architecture. Azure Confidential Computing keeps data encrypted at rest, in transit, and in use, including during processing. Customer-managed keys with External Key Management mean that decryption authority sits entirely with the customer. Customer Lockbox ensures that any operator access to your environment requires your explicit approval. In a properly configured setup, even a legally compelled disclosure yields nothing readable.

The practical implication: sovereignty is not about geography. It is about who holds the keys, under what legal conditions, and whether your architecture ensures that the answer is always you.

3. "This only applies to regulated industries"

That framing is outdated. If your organization processes data from EU citizens, operates across borders, depends on cloud connectivity for business continuity, or supplies organizations that do, you already have sovereignty exposure. The question is not whether sovereignty applies to you. It is whether you are managing it deliberately or not.

There is also a dimension that is easy to overlook: the sovereignty model extends beyond your infrastructure to the people and organizations that interact with it. Your cloud partner plays a direct role in your overall control and compliance posture. A partner operating under Belgian law, with EU-based operations and local accountability, is structurally different from one where operational responsibility sits with a non-EU entity, regardless of what the contract says.

The partner is not an add-on to the sovereignty model, it’s an integral part of it.

We make sovereignty in Azure practical

Sovereign cloud is often framed as a trade-off between control and flexibility. Ready to discover what sovereignty really means for your Azure environment? Let’s map it together.

Want more? Read on!