Security guide

Secure Azure Architecture: Landing Zone Reference Guide

A secure Azure architecture is a landing zone: a platform that holds governance, identity, networking and logging, and workload subscriptions that inherit its guardrails. Microsoft's Cloud Adoption Framework describes the pattern, its Well-Architected security pillar judges each workload, and the Microsoft cloud security benchmark lists the controls.

This guide draws the reference architecture, walks the management group hierarchy, and covers identity, network, logging and data protection in turn. Every claim is tied to a Microsoft Learn page read on 4 November 2026. It ends with a decision checklist you can take to an architecture review.

The benchmark page we read is v2, which is in preview and supersedes v1, so we name its domains and avoid control numbers. This is a design guide, not a compliance statement.

Updated 4 November 2026 (last reviewed)

TL;DR

The short version

5 points

Treat Azure as a platform landing zone (governance, security, shared services) plus workload landing zones, as Microsoft's Cloud Adoption Framework describes.
Keep management groups shallow (three to four levels), assign Azure Policy at group scope, and separate prod, test and dev by subscription.
Identity first: limit user consent, prefer managed identities over secrets, keep emergency access accounts, and make powerful roles time-bound.
Send logs to a central Log Analytics workspace by policy and run Microsoft Sentinel from the security subscription.
Protect data by disallowing anonymous blob access, preferring Entra authorization over Shared Key, using Key Vault with Azure RBAC, and reaching services over private endpoints.

The reference architecture

The diagram shows the management group layout from Microsoft's Azure landing zone reference architecture, with the controls that cut across every group underneath. Start here, then tailor it: Microsoft says the default Corp, Online and Local groups are an ideal starting point for many organisations, and some need more.

Group names follow Microsoft's Azure landing zone reference architecture. Source: Cloud Adoption Framework, Management groups (accessed 4 November 2026).

Azure landing zones have two parts: the platform landing zone, the centralised foundation for governance, security and shared resources, and workload landing zones, where workload teams deploy within those guardrails. Microsoft lists design areas for the tenant and billing, identity and access management, resource organisation, and network topology and connectivity, with security, governance and management around them.

Sources (accessed 4 November 2026): Azure landing zones; Landing zone design areas; CAF management groups.

Landing zone and management group hierarchy

Management groups exist to attach policy and initiative assignments to a class of workload. The groups below are those in Microsoft's reference architecture. A tree can be six levels deep below the root; Microsoft recommends staying at three to four.

Group	What Microsoft says it is for	Design note
Intermediate root	Sits directly under the tenant root with your prefix, so you do not use the root group. Parent of every group the reference architecture creates.	Keep policy assignments here few.
Platform: Security	Dedicated subscription for security and SIEM team tooling, including Microsoft Sentinel and syslog collectors.	SOC-owned; separate from workload teams.
Platform: Management	Dedicated subscription for management, monitoring and security; hosts an Azure Monitor Logs workspace.	The default log destination.
Platform: Connectivity	Dedicated subscription for networking such as Virtual WAN, Azure Firewall and Azure DNS private zones.	The shared hub.
Platform: Identity	Placeholder subscription for AD DS virtual machines or Microsoft Entra Domain Services; enables authentication and authorization for workloads.	Harden with specific policies.
Landing zones: Corp, Online	Corp is for workloads needing connectivity to the corporate network through the hub; Online for workloads that may need direct internet connectivity or no virtual network.	Workload-agnostic policies sit on the parent.
Sandboxes	Testing and exploration, securely isolated from corporate and online landing zones, with a less restrictive policy set.	Good default group for new subscriptions.
Decommissioned	Cancelled landing zones; Azure deletes them after 30 to 60 days.	Move, do not delete in place.

Rules that prevent the common mistakes

Do not duplicate the org structure into a deep tree, and do not create management groups for production, testing and development.
Do not give workload teams RBAC at management group scope; assign at subscription or resource group. Platform teams may hold it, controlled through privileged identity management.
By default any principal in the tenant can create management groups and new subscriptions land under the root. Enable RBAC authorization for management group operations and set a dedicated default group.
Limit the number of Azure Policy assignments at the root so inherited policy stays debuggable.
Do not create management groups just to model Azure regions, unless you have location-based regulatory requirements such as data residency.

Azure Policy enforces standards and assesses compliance at scale: allowed regions, consistent tags, requiring diagnostic logs to a Log Analytics workspace, and blocking actions. Effects include audit, deny, modify, deployIfNotExists and others; audit reports without blocking, deny prevents the change. Roll out with audit first, then enforce.

Sources (accessed 4 November 2026): CAF management groups; Azure Policy overview; Azure Policy effects.

Identity

Microsoft's landing zone guidance calls identity and access management a primary security boundary in the public cloud. In practice that means five decisions:

Consent. Allow user consent only for apps from verified publishers and low-impact permissions, or disable it, and enable the admin consent workflow. A settings change does not touch existing grants, so review those too.
Workload identities. Applications, service principals and managed identities are the workload identities in Entra. Use a managed identity as the credential whenever possible, a certificate if not, and avoid password secrets; use application management policies to limit secret lifetimes.
Risk signals. Entra ID Protection detections such as password spray, anomalous token and suspicious credential addition need Entra ID P2 for full detail. Wire them to alerts.
Break glass. Create two or more emergency access accounts and use them only in emergencies.
Privilege over time. Replace standing permissions with just-in-time, just-enough and time-based access.

Practise the response side in the Azure Identity Compromise Lab.

Sources (accessed 4 November 2026): Landing zone design areas; User consent settings; App registration best practices; Workload identities; Entra ID Protection risk detections; Emergency access accounts; WAF security principles.

Network

Central connectivity. In the reference architecture the Connectivity subscription hosts shared networking such as Virtual WAN, Azure Firewall and Azure DNS private zones.
Network security groups. Rules carry a priority from 100 to 4096; lower numbers are processed first and processing stops at the first match. A broad allow at a low number defeats any deny placed after it.
Private endpoints. A private endpoint gives a service such as Azure Storage, Azure Cosmos DB or Azure SQL Database a private IP address in your virtual network. Only endpoints in an approved state carry traffic, so approval is a control. Closing the public path afterwards is our recommendation, not a quote from Microsoft.

Sources (accessed 4 November 2026): CAF management groups; Network security groups; Private endpoint.

Logging and detection with Log Analytics and Sentinel

A Log Analytics workspace is the data store that Azure Monitor, Microsoft Defender for Cloud and Microsoft Sentinel build on. Microsoft Sentinel is a cloud-native SIEM that supports threat detection, investigation, response and hunting. In the reference architecture the Management subscription hosts the Azure Monitor Logs workspace and the Security subscription hosts Sentinel.

Use Azure Policy to require resources to send diagnostic logs to the workspace, so logging is default, not remembered.
Entra sign-in logs record who, how and what, including activity by managed identities and service principals; they cannot be changed or deleted. Send them, with the audit log, to the same place as your Azure logs.
Alert on persistence paths: new consent grants, new credentials on app registrations and newly registered authentication methods (our selection, based on the detections Microsoft documents).

Sources (accessed 4 November 2026): Log Analytics workspace; Microsoft Sentinel; CAF management groups; Azure Policy overview; Sign-in logs; Entra ID Protection risk detections.

Data protection

Classify first. The Well-Architected security pillar asks you to classify data by sensitivity, assign confidentiality levels and base encryption at rest, in transit and during processing on them.
Anonymous blob access. Disallow it at the storage account; the account setting overrides every container setting. Content that must be public belongs in a separate account. A static website's $web container is always public.
Shared Key. Microsoft recommends Microsoft Entra ID over account keys. The AllowSharedKeyAccess property is unset by default and unset still permits Shared Key, so set it explicitly after moving applications.
Key Vault. Use Azure RBAC for the data plane, a vault per application per environment, roles at vault scope. A Contributor on the control plane can grant themselves data access under the older access policy model, so switch deliberately: setting the RBAC model invalidates access policies.
Posture. Defender for Cloud applies the Microsoft cloud security benchmark by default. Only built-in benchmark recommendations affect the secure score, and risk prioritization does not, so order work by exposure.

Sources (accessed 4 November 2026): WAF security principles; Anonymous blob access; Shared Key authorization; Key Vault Azure RBAC; Secure score; Security recommendations.

Mapping to CAF, Well-Architected and the benchmark

Three Microsoft frameworks answer different questions. The Cloud Adoption Framework (CAF) designs the landing zone, the Well-Architected Framework (WAF) security pillar judges each workload, and the Microsoft cloud security benchmark (MCSB) lists the controls and their Azure Policy mappings. The mapping below is our reading, not a Microsoft table; Microsoft cautions that mappings show you can use Azure features to meet a requirement, not that you comply.

CAF design area	WAF security idea	MCSB domain
Resource organisation, management groups	Plan security readiness: segmentation, standards	Asset Management; Posture and Vulnerability Management
Identity and access management	Least privilege; verify explicitly	Identity Management; Privileged Access
Network topology and connectivity	Segmentation; guard against data exfiltration	Network Security
Security (platform security and SIEM tooling)	Detect, respond and recover; keep an audit trail	Logging and Threat Detection; Incident Response
Governance and compliance	Understand compliance requirements; enforce posture	Posture and Vulnerability Management
Management (monitoring and logs)	Maintain an audit trail of access activities	Logging and Threat Detection
Workload landing zones	Protect confidentiality, integrity and availability; supply chain	Data Protection; Backup and Recovery; DevOps Security

The WAF anchors on Zero Trust: verify explicitly, use least-privilege access, and assume breach. For exact control IDs and a second opinion, the CIS Microsoft Azure Benchmark is a separate community-consensus baseline; we cite no CIS numbers here.

Sources (accessed 4 November 2026): Azure landing zones; Landing zone design areas; WAF security principles; MCSB overview.

Decision checklist for an architecture review

Bring these questions to the review. Each one has an owner and an answer you can write down. The interactive version is the Azure Security Checklist.

Is the hierarchy three to four levels, on the landing zone pattern, with prod, test and dev split by subscription?
Is RBAC authorization on for management group operations, and is the default group for new subscriptions not the root?
Which Azure Policy assignments are at the root, why, and which are audit versus deny?
Who can consent to apps, and when were existing grants last reviewed?
Which apps still use client secrets, and what is the plan to replace them with managed identities or certificates?
Where are the two emergency access accounts, and what alerts when they are used?
Which roles are standing, and which are time-bound?
Does every resource send diagnostic logs to the central workspace, enforced by policy?
What does the SOC alert on for identity persistence?
Is anonymous blob access disallowed at the account, and Shared Key disallowed or planned?
Are Key Vaults on Azure RBAC, one per application per environment?
Does any NSG rule allow a management port from the internet, and are priorities reviewed?
Which production data services use private endpoints, and who approves them?
Is data classified, with a confidentiality level driving access and encryption?
Is there a rehearsed incident response plan and an immutable, encrypted backup?

Sources (accessed 4 November 2026): CAF management groups; Azure Policy overview; User consent settings; App registration best practices; Emergency access accounts; WAF security principles; Log Analytics workspace; Anonymous blob access; Shared Key authorization; Key Vault Azure RBAC; Network security groups; Private endpoint.

Frequently asked questions

What is a secure Azure architecture?

In Microsoft's terms, an Azure landing zone: a platform landing zone that holds governance, security and shared resources, plus workload landing zones where teams deploy within those guardrails. Security comes from the structure (management groups and Azure Policy), strong identity, controlled networks, central logging and data protection, applied the same way to every workload.

How many management group levels should I use?

Keep the hierarchy reasonably flat, ideally no more than three to four levels, although Azure supports up to six levels of depth below the tenant root. Microsoft advises against copying your org chart and against creating management groups for production, test and development; separate those by subscription instead.

Should I use Azure RBAC or access policies for Key Vault?

Microsoft documents Azure RBAC as the default access control model for newly created key vaults from API version 2026-02-01, and recommends a vault per application per environment with roles at the vault scope. Switching an existing vault invalidates its access policies, so assign the equivalent roles first to avoid an outage.

What is the Microsoft cloud security benchmark?

Microsoft's set of security controls organised into domains such as Network Security, Identity Management, Privileged Access, Data Protection, Logging and Threat Detection, Incident Response, Posture and Vulnerability Management, Backup and Recovery and DevOps Security. The version we read, v2, is in preview and adds an Artificial Intelligence Security domain. Defender for Cloud applies the benchmark by default.

How do the Cloud Adoption Framework and the Well-Architected Framework differ?

The Cloud Adoption Framework's Ready guidance helps you design the landing zone: tenant, identity, resource organisation, network and the security, governance and management areas around them. The Well-Architected Framework's security pillar guides each workload against a Zero Trust approach: verify explicitly, use least-privilege access and assume breach.

Where should Microsoft Sentinel live?

In the landing zone reference architecture the Security management group holds a dedicated subscription for security and SIEM tooling, including Microsoft Sentinel, while the Management group holds the subscription with the Azure Monitor Logs workspace. Sentinel runs on a Log Analytics workspace, so plan the data flow between them.

Is this guide a compliance checklist?

No. Microsoft notes that benchmark mappings only show that you can use Azure features to meet a requirement, not that you are compliant. Use the guide to design and the checklist to find gaps; for formal compliance work, use the standard itself.