New Local Management Group for ALZ & Updated Sovereign Policies for SLZ

Following on from months of working alongside customers, partners, and our internal product groups, we have now made two updates to the Azure landing zone (ALZ) and the Sovereign landing zone (SLZ), that I’d like to walk you through in this post:

1. A new dedicated ‘Local’ Management Group added beneath the Landing Zones Management Group – applies to both ALZ & SLZ
2. A refresh of the sovereign policy initiatives assigned in the SLZ, replacing the previous Sovereignty Baseline initiatives with new built-in initiatives that align directly to sovereign control levels 1, 2, and 3 – applies to SLZ only

A new ‘Local’ Management Group

What’s changing?

We have added a new dedicated ‘Local’ Management Group beneath the Landing Zones Management Group in the ALZ conceptual architecture, sitting alongside the existing Corp and Online Management Groups. And because the SLZ extends and takes a dependency on ALZ, this Management Group is inherited by the SLZ hierarchy too in the same hierarchy location, beneath the Landing Zones Management Group.

Azure landing zone conceptual architecture's Management Group hierarchy only. Download a Visio file or PDF file of this architecture.

Why have we added it?

We have been working closely with the Azure Local product group, customers, and partners on what good governance looks like for Azure Local within the ALZ architecture, and we kept hearing two consistent asks:

• A clear, opinionated home in the Management Group hierarchy for Azure Local clusters and the workloads that sit on top of them.
• A way to help customers — particularly those with sovereignty or resiliency requirements — design and run workloads in the Azure public cloud today that are ready to "exit" to Azure Local disconnected operations (ALDO) if they ever need to.

The new Local Management Group gives us a single, consistent scope to address both scenarios with the same governance and policy guardrails. It is therefore intended to be used both for:

• Workloads running directly on Azure Local clusters — to apply consistent best practices, governance, and security guardrails for Azure Local deployments.
• Workloads running in the Azure public cloud today that may one day need to be moved to run on Azure Local in disconnected operations mode — to make sure they are exit-ready by construction, rather than at the point you find out you need them to be.

How exit planning is supported

To make exit planning straightforward, the new ‘Local’ Management Group leverages the following new built-in Azure Policy:

• [Preview]: Restrict resource types to Azure services supported in Azure Local disconnected operations — Definition ID dabf7c7f-5354-42de-a92a-8367f538dd71. Category: Azure Local, Version: 1.0.0-preview.

This policy can be used in a couple of ways depending on where a customer is on their journey:

• In Audit mode, the policy gives you an at-a-glance view of which resource types currently deployed in subscriptions under the ‘Local’ Management Group are not available on Azure Local disconnected operations clusters. This is great for understanding the current state of an exit plan without changing developer behavior.
• In Deny mode, the policy prevents deployment of any resource type that is not available on Azure Local disconnected operations clusters. Workloads can carry on running happily in Azure public, but they are exit-ready by construction — there is no scenario where someone "accidentally" introduces a service that breaks the exit story.

The important thing to call out here is that workloads do not have to run on Azure Local today to benefit from this. Customers with sovereignty or business continuity requirements that need a credible exit story to Azure Local disconnected operations can keep their workloads running in the Azure public cloud and use this new ‘Local’ Management Group, with the new built-in policy to Deny, to guarantee portability when they need it. The platform enforces it, rather than someone tracking it in a spreadsheet or other manual methods

Further policies from the Azure local product group over time. These additional policies will focus on Azure Local cluster and workload best practices and other scenarios that can be assigned to the new ‘Local’ Management Group.

New sovereign policy built-in initiatives aligned to sovereign control levels 1, 2 & 3

What’s changing?

In the SLZ we have replaced the previous Sovereignty Baseline initiatives with a set of new built-in sovereign policy initiatives, assigned at the appropriate Management Group scopes in the Sovereign landing zone (SLZ), that align to the three sovereign control levels:

• Level 1 — Data residency
• Level 2 — Encryption-at-Rest / in-Transit
• Level 3 — Encryption in use (Confidential Computing)

You can read more about each of these levels and the principles behind them on Microsoft Learn:

• Controls and principles in Sovereign Public Cloud
• Implement controls and principles in SLZ

What was assigned before?

Up until this update, the SLZ assigned two existing Sovereignty Baseline built-in initiatives:

• Sovereignty Baseline – Global Policies (c1cbff38-87c0-4b9f-9f70-035c7a3b5523) — 5 policies covering location restrictions and Trusted Launch.
• Sovereignty Baseline – Confidential Policies (03de05a4-c324-4ccd-882f-a814ea8ab9ea) — 19 policies covering customer-managed keys, confidential compute, and resource type / location restrictions.

These were broad baselines, not purpose-built per sovereign control level. They did the job, but they didn’t map cleanly to the L1/L2/L3 model that customers, partners, and our own documentation use to talk about sovereign controls.

What’s assigned now?

Working with the Sovereign Public product group, we have moved the SLZ over to a set of new built-in initiatives that we have built and published recently, each aligned to a specific sovereign control level. These are now assigned by default in the SLZ in place of the two Sovereignty Baseline initiatives above:

Sovereign landing zone conceptual architecture's Management Group hierarchy with the associated controls and principles applied. Download a Visio file or PDF file of this architecture.

Why have we done this?

Aligning the SLZ to these new built-in policy initiatives gives customers, partners, and our internal teams several benefits:

• Single source of truth — the policies assigned by the SLZ now match exactly what is documented in the sovereign controls and principles guidance on Microsoft Learn. No translation, no mapping exercise.
• Per-level alignment — each initiative aligns to a specific level (L1, L2, L3), so customers can map their data classifications (Public, Internal, Confidential, Secret) to the right scope in the hierarchy and apply only what is required for that classification.
• Lower maintenance overhead — by moving from broad baselines to per-control built-ins owned by the Sovereign Public product group, customers benefit from updates made by the product group automatically, without us having to ship and version our own copies in the SLZ.
• Easier auditing and reporting — built-in initiatives are first-class citizens in tools such as Microsoft Defender for Cloud and Azure Policy compliance reporting, which makes evidencing compliance against the sovereign controls easier for those that need to.

What if we have already deployed ALZ or the SLZ?

These changes are now live in the following releases in the Azure Landing Zones library.

• platform/alz/2026.04.2
• platform/slz/2026.04.2

We have also updated the ALZ Accelerator and our AVM-based Terraform & Bicep deployment options to use these latest releases for new deployments. And for those of you who already have an active deployment you can upgrade your library version following the guidance here:

• Terraform - Updating the module and library version | Azure landing zone Documentation.
• Bicep - Updating the ALZ Library Version | Azure landing zone Documentation

The ALZ Portal accelerator is also being updated this week so stay tuned for those if you use that, although we highly recommend the ALZ IaC Accelerator.