Azure Landing Zones in 2026 and What Actually Matters Now

In this article

• The Hierarchy Problem Is Still the Same, Just Older
• Policy Hygiene Is the Governance Challenge
• Subscription Vending Is the Scaling Pattern
• Identity Changed More Than Anything Else
• Networking Still Comes Down to Two Choices, With a DNS Twist
• Where FinOps Meets Landing Zones
• The Day-2 Problem Nobody Talks About Enough
• Your Landing Zone Health Checklist

Six years ago, when we first wrote about Enterprise-Scale Landing Zones, the challenge was getting them deployed at all. The tooling was raw. The reference implementations were new. Organisations were debating whether to adopt the hierarchy or build their own.

That debate is settled. The ALZ accelerator, the Terraform modules, and the Bicep modules are mature. Most Azure enterprises we work with have landing zones in production. Some have had them running for four or five years.

The challenge has shifted. It is no longer “how do we set this up?” It is “how do we keep it healthy, evolve it, and avoid governance rot?” The day-2 problems are where organisations actually struggle, and they get far less attention than the initial deployment.

The Hierarchy Problem Is Still the Same, Just Older

We said it in 2020, and it still holds: most enterprises over-engineer their management group hierarchy. The reference architecture suggests three to four levels. That is enough for virtually every organisation.

Tenant Root Group
└── Organisation
    ├── Platform
    │   ├── Identity
    │   ├── Management
    │   └── Connectivity
    ├── Landing Zones
    │   ├── Corp
    │   └── Online
    ├── Sandbox
    └── Decommissioned

Yet we regularly walk into environments with six or seven levels. Extra tiers for business units, regions, environments, regulatory classifications. Every additional level makes policy inheritance harder to reason about and RBAC conflicts more likely. When something breaks, the debugging path runs through every parent group, and nobody remembers why the “Europe-Regulated-Production” management group exists.

If you have more than four levels today, ask yourself: which concrete policy or RBAC requirement forced each extra tier? If the answer is “it seemed like a good idea” or “our org chart has that many divisions,” that tier is governance overhead, not governance value.

Policy Hygiene Is the Governance Challenge

Azure Policy is the backbone of landing zone governance, but not the whole operating model. Policy is strong at preventing bad states, enforcing required metadata, and deploying baseline configuration. It is weak at business-system reconciliation, stale exception cleanup, and replacing IaC drift detection. The day-2 reality of policy management is messy, and most organisations underestimate it.

Here is what happens over time: assignments accumulate. The initial set from the ALZ accelerator gets augmented with custom policies for naming conventions, region restrictions, specific resource configurations. Each new compliance requirement adds another assignment. Exemptions start piling up as teams request exceptions for legitimate use cases. Custom policy definitions get created for edge cases, sometimes duplicating built-in policies that were added later.

After two or three years, a mature landing zone can have hundreds of policy assignments across the hierarchy, dozens of exemptions (some with expiry dates that nobody tracked), and custom definitions that overlap with Azure’s expanding built-in library.

Nobody reviews this. That is the problem. Policy hygiene requires the same discipline as code hygiene: regular review, deduplication, removal of policies that no longer apply, and validation that exemptions still have a business justification.

We recommend a quarterly policy review cadence:

• Audit all exemptions. Are they still needed? Have the underlying workloads changed?
• Compare custom definitions against the built-in library. Azure adds new built-in policies regularly. That custom “enforce TLS 1.2” policy you wrote in 2022 might have a built-in equivalent now.
• Check compliance scores at each management group level. If a management group shows 60% compliance and nobody is investigating, you have governance decay.
• Remove assignments for policies that no longer match your organisational requirements.

Without this hygiene, your policy environment drifts from what you intended and nobody catches it until an audit.

Subscription Vending Is the Scaling Pattern

The original landing zone guidance said “one subscription per workload.” That guidance is still correct, but the operational question it raises is: how do application teams get subscriptions without filing tickets and waiting days?

Subscription vending is the answer, and the tooling is production-ready now. The ALZ subscription vending module handles the core automation: create a subscription, place it in the right management group, assign a budget, configure networking, set up initial RBAC, and wire diagnostic settings to the central Log Analytics workspace.

The mature pattern we see in well-run environments looks like this: a team submits a request (YAML file in a repo, ServiceNow form, or an internal portal). A pipeline validates the request against organisational rules (approved regions, budget limits, required metadata). If validation passes, the pipeline provisions the subscription and returns access details within minutes.

The same “paved path” concept applies here, as we wrote about in developers needing guardrails, not more tools. The landing zone provides the governance boundary. Subscription vending provides the self-service interface. Together, they remove the bottleneck of manual provisioning while keeping every subscription compliant from creation.

The organisations that still rely on manual subscription creation in 2026 have a scaling problem. Every new project requires platform team involvement. The platform team becomes the bottleneck. Teams start sharing subscriptions to avoid the wait, which undermines the isolation model that landing zones are designed to provide.

Identity Changed More Than Anything Else

The identity story in Azure landing zones looks different from 2020. Three changes matter most.

Entra ID Privileged Identity Management (PIM) replaced permanent role assignments as the default pattern for administrative access. Instead of granting standing Contributor access to a subscription, you grant eligible access that requires just-in-time activation with justification and optional approval. Most mature organisations we work with have moved to PIM-eligible assignments for anything above Reader. Standing administrative access is treated as a finding in security reviews.

Conditional Access policies have become much more granular. Device compliance, sign-in risk, location, and authentication context all feed into access decisions. Landing zones that were designed with simple RBAC in mind now need to account for Conditional Access policies that might block access based on device state or network location, even when RBAC says the user has permission.

Workload identity federation replaced service principal secrets for CI/CD pipelines. If your landing zone pipelines still authenticate using client secrets stored in a key vault, you are carrying unnecessary risk. Federated credentials tied to specific repositories and branches provide the same access without long-lived secrets to rotate and protect.

These three shifts together mean that the identity section of your landing zone design needs a revisit if it was written before 2023. The patterns from the original Enterprise-Scale guidance were correct for their time, but the tooling has caught up.

Networking Still Comes Down to Two Choices, With a DNS Twist

Hub-spoke remains the dominant topology, and Virtual WAN continues to grow for organisations with multi-region, multi-branch requirements. That decision hasn’t changed much, though Virtual WAN routing intent has made the configuration less painful than it was three years ago.

What did change is the DNS story. Private endpoints are everywhere now. Every PaaS service your workloads consume (storage accounts, key vaults, databases, container registries) likely uses private endpoints. Each private endpoint requires a DNS record in the appropriate private DNS zone.

Managing those DNS zones at scale is a real operational challenge. The recommended pattern is centralised private DNS zones in the connectivity subscription, linked to spoke VNets, with Azure Policy deploying DNS records automatically when private endpoints are created. This works, but it requires careful zone management, especially when you have hundreds of private endpoints across dozens of subscriptions.

Organisations that let teams manage their own private DNS zones end up with fragmentation: duplicate zones, inconsistent records, and resolution failures that are painful to debug. Centralise DNS zone management early. Retrofitting centralised DNS into a fragmented setup is painful.

Where FinOps Meets Landing Zones

Cost governance lives inside landing zones, whether you plan for it or not. The intersection point is tags.

Every landing zone deployment enforces some set of required tags: cost centre, environment, owner, application. These tags flow into Cost Management and become the basis for cost allocation, showback, and chargeback. When tags are inconsistent or missing, cost reporting breaks down and finance teams lose trust in the numbers.

The operational reality: tag enforcement via policy catches resources at creation time, but it doesn’t handle tag values changing or tags becoming stale. An application tagged to cost centre “CC-1234” might move to a different business unit. The tag stays. Multiply that by thousands of resources and you end up with cost allocation that drifts from reality.

Mature organisations pair policy-based tag enforcement with a periodic reconciliation process. Export resources and tags, compare against the source of truth (usually a CMDB or project portfolio tool), and flag mismatches. Automate corrections where possible. Treat tag accuracy as a metric that gets reviewed alongside cost reports.

Budget alerts at the subscription level also deserve attention. Subscription vending should set a default budget based on the requested workload tier. If a team requests a development subscription, the budget should reflect development-tier spend, not production-tier. When spend exceeds the budget, the alert should reach the team, not just the platform team. Cost accountability starts at the team level.

The Day-2 Problem Nobody Talks About Enough

Deploying a landing zone is a project. Operating one is a product. That distinction matters because most organisations fund landing zones as a project: budget is allocated, the deployment happens, the project closes, and the team moves on.

Then drift starts. Someone modifies a policy assignment through the portal. A network peering gets added manually. An exemption gets granted without documentation. The Terraform state no longer matches reality. Six months later, the next terraform plan shows 40 unexpected changes, and nobody knows which ones are intentional.

Drift detection needs to be continuous. Run your IaC pipeline on a schedule (not just on pull requests) and alert when the plan shows changes that weren’t committed. Azure Policy compliance reports help, but they only catch what policies are configured to detect. Configuration drift in resources that policies don’t cover (RBAC assignments, network configurations, diagnostic settings) requires IaC drift detection as a separate mechanism.

Compliance reporting is the other half. Your security team, your auditors, and your leadership all want to know: “Are we compliant?” That question requires a reporting pipeline that aggregates policy compliance, drift status, and remediation progress into something readable. Azure’s built-in compliance dashboard is a start, but most organisations need to export that data into their GRC tooling or a central dashboard.

The platform team that operates the landing zone needs to be funded and staffed as a permanent team, not a project team that disbands after deployment. Landing zones are living infrastructure. They need ownership, a backlog, and regular investment.

Your Landing Zone Health Checklist

If you already have landing zones running, here is what to review.

Governance and structure:

• Count your management group levels. If you have more than four, justify each extra tier or flatten it.
• When was the last full policy review? Audit exemptions, remove stale assignments, check for overlap with newer built-in policies.
• Check compliance scores at every management group. Anything below 90% deserves investigation.

Operations and identity:

• How long does it take a team to get a new subscription? If the answer is “days” or involves tickets, automate it.
• Are you using PIM for eligible access? Are CI/CD pipelines using workload identity federation instead of client secrets?
• Are private DNS zones centralised or fragmented across subscriptions? Is DNS record creation automated via policy?

Cost and sustainability:

• When was the last reconciliation of tags against your cost centre source of truth?
• Is your IaC running on a schedule with alerts for unplanned changes?
• Is the platform team permanent with a product backlog, or was it a project team that disbanded?

These items are not glamorous and they do not make for exciting architecture diagrams. They are, however, the difference between a landing zone that works on paper and one that keeps working eighteen months after deployment. If your landing zones have been running for a year or more without a structured review, an Azure architecture assessment usually surfaces actionable findings within the first week.

Related: What an Azure Landing Zone Audit Actually Finds common findings across enterprise environments · Azure Policy Guardrails That Developers Don’t Hate enforcement without friction · Azure Private Link: How It Changed the Enterprise PaaS Playbook private endpoint architecture at scale