Sovereignty in Azure: What's New in the Cloud Adoption Framework
For a long time, sovereignty in an Azure design conversation came down to one question: which region are we deploying to? Pick West Europe or Belgium Central, tick the data residency box, move on.
That hasn’t been enough for a while. The questions I get now are about who can access the platform and who holds the keys, and auditors want evidence rather than a diagram.
In September 2026 Microsoft added a proper answer to the Cloud Adoption Framework (CAF): a sovereignty section under /cloud-adoption-framework/sovereignty/ with four articles.
- Digital sovereignty adoption: the executive overview. What sovereignty is, whether you need it, which deployment model to pick, what it costs.
- Planning and organizational readiness: requirements, classifications, controls, operating model, roles, skilling and FinOps.
- Architecture and governance: how sovereignty changes your Azure landing zone.
- Operational standards: how you stay sovereign after go-live.
Thomas Maurer (EMEA Global Black Belt for Sovereign Cloud at Microsoft) announced it on 10 September. At the time of writing, the CAF “What’s new” page still lists sovereignty guidance under roadmap, so this is very fresh.
Sovereignty as a subset of compliance
The executive article defines sovereignty as a subset of compliance: control, jurisdiction, data residency, administrative access and operational governance. It also says you don’t get there through isolation alone. The aim is proportionate controls that keep availability and resilience intact, without creating new single points of failure.
The most useful point is that most organisations already have some sovereignty requirements. “Are we sovereign?” can’t really be answered. “Which workloads need which controls?” can, and you can put the answer in a backlog.
Three deployment models
Everything now sits under the name Microsoft Sovereign Cloud, with three deployment models.
Sovereign Public Cloud is normal Azure with sovereignty controls and operational assurances applied. CAF is clear that this is where most organisations should start, and that a workload should only move elsewhere when its requirements can’t be met here. It costs standard Azure pricing plus whatever the controls cost: confidential computing SKUs, customer-managed keys, restricted regions.
Sovereign Private Cloud is Azure Local in facilities you control. It runs either connected, with Azure-connected management, or disconnected, up to fully air-gapped. Microsoft 365, Foundry AI models and GitHub Enterprise can run on it. You pay for hardware, licensing, facilities and staff on top.
National Partner Clouds are operated by a local partner under national governance, independently of Microsoft. They’re only available to eligible customers in a few countries, such as Germany and France, and they set their own prices and service catalogues.
A decision tree in the executive article maps requirements to a model. If standard Azure is enough, stay there. If you need sovereignty controls but not your own hardware, use Sovereign Public Cloud. If you need infrastructure you control, go Private, connected or disconnected. If you need national jurisdiction and an operator independent of Microsoft, you’re looking at a Partner Cloud.
Planning
The planning article is where sovereignty becomes something you can work with. It defines nine requirement categories:
- Cloud governance, security and management
- Data residency
- Data confidentiality at rest
- Data confidentiality in transit
- Data confidentiality in use
- Data confidentiality with key control
- Operator access control
- Operator auditing
- Infrastructure control
You group these into a handful of sovereignty classifications, typically three to five. Its example runs from Classification A (data residency only) to E (residency, confidentiality at rest, in transit and in use, key control, and operator access and auditing). CAF points out that these aren’t maturity levels, which is a mistake I’d expect a lot of people to make on first read. They’re reusable bundles of requirements. Each workload gets a classification and inherits its control baseline, so teams don’t reinterpret the organisation’s risk appetite every time.
The whole model runs on traceability: driver, requirement, risk, control, evidence. If you can’t name the requirement a control satisfies, you probably don’t need that control.
Each requirement maps to Azure capabilities. Data residency maps to region selection, Azure Policy and, in Europe, the EU Data Boundary. Confidentiality in use maps to confidential computing, enforced through Policy. Key control means customer-managed keys, Managed HSM and External Key Management. The docs still link EKM under a preview anchor, so check its status before you design around it. Operator access covers Customer Lockbox, plus Data Guardian for the EU and EFTA, where EU residents oversee Microsoft’s production access. Operator auditing gets an immutable ledger of what operators did, and policy management goes through the Sovereign Control Panel and Azure Policy.
The rest of the article covers the organisational side: an executive sponsor, a cross-functional team (legal, risk, compliance, security, architecture, platform), skilling per deployment model, and FinOps. One rule I’d like to see more often: prioritise workloads by sovereignty risk first and business criticality second. A low-impact workload with a big compliance exposure goes before a critical one that’s already covered.
Architecture and governance
This article builds on the standard Azure landing zone and only covers what’s different. For Sovereign Public Cloud the idea is simple. You create a management group per classification, assign the policies that enforce that classification’s controls there, and put each workload’s subscriptions under the right one.
The Sovereign Landing Zone accelerator is the ready-made version. On top of the platform landing zone it adds three management groups (Public, Confidential Online and Confidential Corp) and a set of policy assignments:
- Data residency:
Enforce-Sov-L1-Regions - Managed HSM and customer-managed keys:
Enforce-Sov-L2-CMKM,Enforce-Sov-L2-CMKP - Encryption in transit (HTTPS, latest TLS):
Enforce-Sov-L2-HTTPS,Enforce-Sov-L2-TLS - Encryption in use:
Enforce-Sov-L3-Conf
The L1/L2/L3 naming follows the same order as CAF’s example classifications: residency first, then encryption and key control, then confidential computing.
Private Cloud doesn’t get new management groups. The landing zone already has a Local management group for Azure Local subscriptions, and you tighten its policy assignments. In disconnected mode you still need Azure subscriptions for billing and licensing, but the workloads run entirely on-premises.
The section I’d point Belgian readers to is the one on reliability. Data residency and resilience pull against each other, and CAF says to settle the rule now rather than during an incident. If your sovereign boundary contains several approved regions, allow multi-region designs and keep the DR region inside the boundary. If it contains only one, say so, require availability zones and backup-based recovery, and accept that cross-region recovery is off the table. If “stays in Belgium” is a hard requirement, you’re in that single-region case.
The article also covers portability. Regulations and geopolitics change, so if a workload might need to move between deployment models later, build on common pieces like Entra ID, Azure RBAC, Azure Policy, VMs, containers and Kubernetes. Check that the target platform supports each service before you adopt it, because availability differs between Sovereign Public, Azure Local (connected and disconnected) and Partner Clouds.
Operational standards
I think this is the most useful of the four articles, because it covers what most designs skip. It opens with the point that a workload that was sovereign at launch can drift out of alignment as regulations, services, people and configurations change. It sorts that drift into three types:
| Drift | Examples | Preventative standard |
|---|---|---|
| Deployment drift | Unapproved region, unapproved service | Service catalog |
| Configuration drift | Encryption setting changed, control removed, classification mismatch | Change management |
| Operational drift | Missed access review, expired exception, missing evidence | Exception management, control ownership, risk integration |
Six operational standards follow. Monitoring uses the Sovereign Control Panel, Azure Policy and the Defender for Cloud regulatory compliance dashboard, with Azure Arc for connected Azure Local and local tooling for disconnected. Evidence management has my favourite line in the whole set: “A sovereignty control that you can’t demonstrate is effectively unenforceable.” Define your evidence sources up front and review them regularly, not just before the audit.
Access goes further than RBAC. It can involve citizenship, residency and personnel screening, with Entra PIM, Customer Lockbox and Data Guardian as the tooling. Data security covers operational data too: logs, telemetry, audit records, backups, forensic evidence and keys can all fall under residency requirements. I suspect a lot of existing “sovereign” designs miss this. Put your Azure Monitor and Log Analytics workspaces in approved regions and turn off geo-redundant export.
For disaster recovery, decide in advance where a workload may recover, agree emergency exceptions before you need them, and test the sovereignty side of a DR exercise, not only the failover. Workload onboarding becomes a formal gate before production: a classification assigned, controls validated, baseline evidence captured, and every exception approved with an owner, an expiry date and a remediation plan.
Where the Regional Catalog fits
In my post on the Azure Regional Catalog, the tracker’s sovereignty view groups things into four areas: residency and autonomy, confidential computing, encryption and key management, and compliance and policy. CAF now has nine requirement categories and a whole operating model around them, so it goes much deeper.
The architecture article describes exactly the gap the tracker covers. For Sovereign Public Cloud, “the only major constraint is service availability. Confirm that each service you depend on runs in your approved regions and supports the sovereignty controls that classification requires.” When a classification’s approved region list is one region long, that check is the first thing to run.
Classifications, policy enforcement, evidence and operator access are still your own governance work. The tracker doesn’t handle those.
Caveat
This guidance is brand new. Microsoft’s roadmap still mentions further landing zone changes, including renaming application landing zones to workload landing zones, and some of the capabilities it references, like External Key Management, are still in preview. Expect it to change, and check the status of any control before you rely on it.