Microsoft Sovereign Cloud: Pick the Right Model

Most European organisations asking about Microsoft Sovereign Cloud need one of three things, and only one of them requires leaving the public cloud. Pick the deployment model from the control you are legally obliged to hold — data location, operational oversight, or full technological independence — not from how the word "sovereignty" sounds in a board meeting.

That sentence is the whole article. The rest is how to defend it.

I have sat in enough architecture reviews where "we need sovereignty" arrived as a requirement with no owner and no citation. Someone read a headline. Someone else translated it into "everything must be on-premises". Six weeks later the programme has a private cloud business case, a 40% cost increase, and nobody can point to the regulation that demanded it.

Sovereignty is a real constraint. It is also the most over-scoped requirement I encounter.

What is Microsoft Sovereign Cloud, exactly?

Microsoft Sovereign Cloud is a suite of capabilities and deployment models built to help governments and regulated industries meet data residency, compliance, and operational sovereignty requirements without giving up hyperscale cloud economics. It is the evolution of what used to be called Microsoft Cloud for Sovereignty, and it spans Azure, Microsoft 365, Microsoft Security, and Power Platform.

The key detail people miss: it is not a product you buy. It is three delivery models plus a set of controls you switch on.

The three deployment models

Microsoft Sovereign Cloud is delivered through:

• Sovereign Public Cloud — existing Microsoft hyperscale regions, with added controls for residency, operational oversight, and customer-controlled encryption.
• Sovereign Private Cloud — customer-operated infrastructure, built on Azure Local, for regulated or disconnected environments.
• National Partner Clouds — independently operated environments run by an approved domestic partner under national law.

Availability and service coverage for the partner model vary by geography. That matters more than it sounds, and I come back to it below.

What actually changed from Cloud for Sovereignty

The rename was not cosmetic. The old offering was largely a policy-and-guardrails story on top of standard Azure. The current one adds capabilities that did not exist before as customer-visible controls: supervised Microsoft engineer access, a tamper-evident access ledger, external key custody, and a control panel to see it. Microsoft's own framing is that the foundation targets European datacentre regions, while the technical capabilities to enforce data sovereignty are available worldwide.

If your last assessment of this area is more than a year old, it is out of date.

Which sovereignty problem are you actually solving?

There are three, they are independent, and conflating them is what produces the over-scoped private cloud business case. Microsoft's digital sovereignty overview separates them the same way.

Data sovereignty

Where data is stored and processed, and which law governs it. This is the one most organisations mean. It is also the one the public cloud already answers well in Europe through the EU Data Boundary and in-region storage. If your requirement stops here, you almost certainly do not need to leave the hyperscale model. I wrote about the specific boundaries and what still leaves the tenant in EU Data Boundary and Copilot.

Operational sovereignty

Who can touch the running system, under what supervision, and whether you can prove it afterwards. This is where the interesting new capability sits, and where most 2024-era assessments are wrong, because the controls did not exist yet.

Technological independence

Whether you can keep operating if the provider relationship changes. This is a genuine national-security and critical-infrastructure concern. It is very rarely a mid-market enterprise concern, however loudly it gets raised.

My rule in workshops: write down the specific regulation, article, and supervisory expectation that drives the requirement before anyone draws architecture. If nobody can produce it, the requirement is data sovereignty wearing a costume.

When is Sovereign Public Cloud enough?

For most regulated European enterprises, and a good share of public sector, it is enough. Sovereign Public Cloud layers sovereignty controls onto standard Azure and Microsoft 365 Advanced Data Residency rather than moving you off the platform. You keep the innovation cadence, the security investment, and the resilience.

Two capabilities do most of the work.

Data Guardian, and why it changes old assessments

Data Guardian means remote access by Microsoft personnel to systems in defined regions such as the EU and EFTA is monitored in real time by authorised European-resident personnel, and every session is written to a tamper-evident ledger built on Azure confidential ledger.

Read that again if your objection to public cloud has ever been "a foreign engineer could access our production system unsupervised". That objection now has a documented, auditable answer. It is not a promise in a contract, it is a logged human-in-the-loop control.

Note the distinction from Customer Lockbox, because auditors ask: Lockbox requires your explicit approval before a Microsoft engineer accesses customer content. Data Guardian records and supervises production touches. Different controls, different questions, both listed under operational controls. You will likely be asked to evidence both.

Sovereign Landing Zone

The Sovereign Landing Zone is an opinionated variant of the Azure Landing Zone, shipped with Bicep and Terraform implementations, that encodes sovereignty guardrails as policy-as-code.

Use it. Not because the policies are magic, but because "we enforce region restrictions" is a claim, and a policy assignment with a compliance dashboard is evidence. Auditors accept evidence.

Do you need External Key Management? Probably not

Here is the part where I disagree with most sovereignty proposals I review.

Teams hear "sovereignty" and jump to holding their own keys outside Microsoft infrastructure. It feels like the strongest possible control. It is also, in the overwhelming majority of cases, the wrong trade.

What Managed HSM already gives you

Azure Key Vault Managed HSM delivers key sovereignty through FIPS 140-3 Level 3 validated hardware, single-tenant isolation, and a customer-controlled security domain. Microsoft's own external key management guidance states plainly that for most organisations, Managed HSM key sovereignty satisfies even stringent regulatory requirements.

You hold the security domain. Without it, the keys are unusable. That is real custody, with an SLA attached.

What External Key Management costs you

With EKM, the key encryption key lives in a customer-operated HSM outside Azure, and Managed HSM delegates wrap and unwrap operations to it through a proxy you run. Two things follow.

First, it is a preview feature at the time of writing, so it carries supplemental preview terms and may change before general availability. Second, and more important, Microsoft's documentation describes it as trading availability, performance, and operational simplicity for physical key control, and calls it a last-resort option for organisations with a hard legal or contractual mandate rather than a general-purpose upgrade.

That is the vendor telling you not to over-buy. I would take the hint.

The failure mode is predictable and I have watched it play out: you now run an HSM cluster and a proxy on the critical path of every encrypted service. Your availability is capped by the least reliable component you operate. When the proxy has a bad afternoon, storage and databases stop, and the incident review asks which regulation required this.

If you have that mandate in writing, EKM is the right answer and the complexity is justified. If what you have is a preference for control, take Managed HSM and spend the engineering budget on oversharing remediation, which is where actual data exposure happens. That is the argument I make in Purview DSPM for AI.

When does Sovereign Private Cloud make sense?

When you genuinely cannot be connected, or when national rules require infrastructure you own and operate.

Sovereign Private Cloud runs on Azure Local as the infrastructure foundation, supporting workloads as virtual machines or on Arc-enabled AKS clusters. On top sit Foundry Local for AI, Microsoft 365 Local for Exchange, SharePoint and Skype for Business Server, and GitHub Local.

Be clear-eyed about the trade. Microsoft's own documentation says private and local environments provide the strongest sovereignty controls, with full control over hardware, software, data, location and management, and in the same breath says they do not deliver the full cloud value in cost-effectiveness, scalability, speed of innovation, security, and reliability.

You are buying control with innovation velocity. For a disconnected defence workload that is obviously correct. For a bank's HR analytics, it is not.

Foundry Local is the piece worth knowing about if AI is the driver: it runs models entirely inside your Azure Local environment, integrates with Arc-enabled Kubernetes, and supports a model-as-a-service approach so you are not operating the full model lifecycle yourself. If your blocker is "inference cannot leave our walls", this is the answer, and it is a narrower blocker than most people assume.

What about National Partner Clouds?

National Partner Clouds are independently operated environments delivering Azure and Microsoft 365 under local ownership, physically and logically isolated, run by local personnel under national compliance frameworks. Bleu in France, a joint venture of Orange and Capgemini built for SecNumCloud, and Delos Cloud in Germany, operated by an SAP subsidiary, are the named examples.

They exist for national security, public sector regulation, and geopolitical risk mitigation. If you are not in one of those categories, this is not your model.

The practical constraint is coverage. Service availability and scope vary by geography and follow national frameworks, which means the newest Azure and Copilot capabilities are not there on day one. Committing a Copilot programme to a partner cloud without checking the service list first is a mistake I would rather you learn about here.

How do AI workloads change the picture?

They raise the stakes on classification, and they add asset types your existing data governance probably does not name. Microsoft's AI workloads and sovereignty guidance is the most useful page in the set.

Classify before you pick a model

Apply classification labels early, before model selection. Distinguish training corpora, evaluation sets, embeddings, vector indexes, model weights, inference logs, and derived analytics as separate things with separate residency requirements.

Embeddings and vector indexes are the ones that catch teams out. They are derived from regulated source data, they can leak information about it, and they frequently end up in a service nobody put in scope. Ask where your vector index lives. The pause before the answer tells you what you need to know.

The guidance also warns against commingling high-risk data with generic contextual sources unless justified. In practice that means one index with everything in it is a sovereignty problem as well as a quality problem, which is the same conclusion I reached from the retrieval side in Microsoft Foundry after the rebrand.

Tie key rotation to model versions

Use customer-managed keys by default for persistent storage of sensitive training datasets, model weights, and vector databases. Then rotate keys in alignment with model version release cycles, and revoke unused keys promptly when decommissioning models.

That second half is the part everyone skips. Models get retired, their artefacts stay in storage, and the keys stay live. Two years later you have a decommissioned model's weights sitting encrypted under an active key with no owner. Build revocation into the retirement runbook or it will not happen.

Confidential computing covers data in use, and attestation can gate pipeline orchestration so that decryption keys or dataset access tokens are only provisioned after enclave measurement validation. That is a strong pattern for high-sensitivity training, and it is more accessible than it was.

A decision sequence that holds up in an audit

Run it in this order. The order is the point.

1. Name the obligation. Regulation, article, supervisory expectation. In writing, with an owner. No citation, no sovereignty programme.
2. Classify the axis. Data, operational, or technological. Most requirements are data.
3. Test Sovereign Public Cloud first. EU Data Boundary, in-region storage, Data Guardian, Managed HSM, Sovereign Landing Zone. Document specifically which obligation it fails to meet.
4. Only then escalate. Private cloud for disconnected or owned-infrastructure mandates. Partner cloud for national security and critical infrastructure. EKM only for a hard written mandate on physical key custody.
5. Check service coverage before committing. Especially for AI and Copilot capabilities in private and partner models.
6. Capture evidence as you go. Region assignments, key usage, attestation results, policy compliance state. Retrofitting audit evidence costs several times what capturing it costs.

Step 3 is the one that gets skipped, and skipping it is what turns a residency requirement into a three-year infrastructure programme.

The honest summary: sovereignty in 2026 is mostly a controls and evidence problem, not a location problem. The location answer was correct in 2022. It has been overtaken, and a lot of architecture decisions are still running on the old assessment.

Go and re-read the requirement. Then check when it was written.

Frequently asked questions

Is Microsoft Sovereign Cloud the same as the EU Data Boundary?

No. The EU Data Boundary is a data residency commitment about where customer data is stored and processed. Microsoft Sovereign Cloud is the broader set of deployment models and controls, which includes the EU Data Boundary as one component alongside operational oversight, key management, and confidential computing.

What is the difference between a sovereign cloud and a private cloud?

A private cloud is defined by who owns and operates the infrastructure. A sovereign cloud is defined by which jurisdiction's law and oversight apply to it. Sovereign Public Cloud is sovereign without being private. Sovereign Private Cloud is both, and costs accordingly.

Do I need External Key Management to claim key sovereignty?

Generally no. Azure Key Vault Managed HSM provides key sovereignty through FIPS 140-3 Level 3 hardware, single-tenant isolation, and a customer-controlled security domain, and Microsoft's guidance states this satisfies even stringent regulatory requirements for most organisations. EKM is positioned as a last-resort option for a hard legal or contractual mandate.

Can I run Copilot and AI workloads in a sovereign environment?

Yes, with different models. In Sovereign Public Cloud you apply sovereign controls across the AI lifecycle using customer-managed keys, confidential computing, and Data Guardian. For disconnected requirements, Foundry Local on Azure Local runs models inside your own environment. Check service coverage first in partner clouds.

Where do the European Digital Commitments fit in?

They are the policy commitments underpinning the sovereignty controls, and Sovereign Landing Zone policy sets align to them. Reviewing the European digital commitments is worthwhile before a supervisory conversation, because it is what your regulator will have read.