Like a precision-engineered espresso machine, a mature Azure environment is all about control — achieving just the right balance between pressure and flow. In our cloud world, that balance exists between security, governance, and operational agility.

The Secure Landing Zone (SLZ) is the mechanism that keeps that balance finely tuned. It’s the dedicated space within your Azure Landing Zone architecture where security, compliance, and trust boundaries converge — the operational embodiment of Sovereign Landing Zone (SoLZ) principles.

As organisations expand beyond their initial Azure foundations, they often need to navigate regulatory compliance, data residency, and strict access separation.
That’s where the SLZ steps in — extending your Azure Landing Zone architecture to deliver sovereign-grade security and control.

What is the Secure Landing Zone?

The Secure Landing Zone (SLZ) builds upon the Azure Cloud Adoption Framework (CAF) design areas to provide a sovereign-ready platform for security operations.

It separates core security capabilities into a distinct management and operational boundary, allowing for strong isolation, independent lifecycle management, and compliance alignment.

The SLZ focuses on:

• Security & Compliance – Centrally managing policies, alerting, and detection
• Identity & Access – Segregated privileged identities via Microsoft Entra ID
• Monitoring & Response – Unified telemetry and automation through Sentinel
• Data Sovereignty – Restricting telemetry and data flow to specific regional boundaries

In short, the SLZ is a Sovereign Control Plane for your Azure estate — enforcing identity, policy, and compliance guardrails without constraining day-to-day innovation.

How It Fits in the Landing Zone Hierarchy

The Secure Landing Zone extends the standard Azure Landing Zone layout by introducing controlled, sovereignty‑aware boundaries that mirror the Sovereign Landing Zone (SoLZ) pattern.

By structuring management groups and subscriptions around trust tiers and regional boundaries, the design ensures that sensitive operations and data remain isolated within trusted Azure regions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Tenant Root
├── Platform
│   ├── Identity
│   ├── Management
│   ├── Connectivity
│   ├── Shared Services
│   └── Secure
└── Workloads
     ├── Corp
     ├── Secure-Corp
     ├── Online
     └── Secure-Online

Platform Secure Layer (Sovereign Core)

The Secure management group represents the sovereign control plane of your Azure platform.
This is where you locate:

• Microsoft Sentinel (SIEM/SOAR) and Log Analytics — centralised but region‑restricted
• Defender for Cloud — managed at scale via policies scoped to this management group
• Azure Policy and Governance Initiatives — enforcing security and compliance baselines
• Automation and Playbooks — contained within a sovereign data region (e.g., Australia East/Central)

This design ensures that both governance and operational intelligence are processed locally within approved regions, addressing data residency and compliance requirements.

Sovereign Secured Workload Zones

Under each workload domain — Corp and Online — the inclusion of secure-corp and secure-online follows the SoLZ pattern for sovereign application zones. These are specialised sub‑zones dedicated to sensitive or compliance‑bound workloads.

Each secure workload zone is:

• Bound to specific sovereign Azure regions via the “Allowed Locations” policy
• Connected only via the Connectivity Platform, using private endpoints and hub-spoke topology
• Subject to delegated Defender for Cloud policies while reporting telemetry back to the Platform Secure workspace
• Compliant by default, using Azure Policy and RBAC definitions inherited from the sovereign control plane

These secure subzones act as sovereign enclaves — maintaining isolation, compliance posture, and audit traceability.

Real‑World Impact

In regulated and defence-grade organisations across Australia, these Secure Landing Zones deliver measurable benefits:

• Data residency assurance. Telemetry and logs never leave sovereign regions.
• Reduced blast radius. Platform and workload security scopes remain strictly separated.
• Centralised compliance. Security policies, audit logs, and Defender alerts flow to a single, sovereign workspace.
• Operational clarity. Security personnel manage the SLZ; application teams focus on workloads.

By adopting an SLZ following Sovereign Landing Zone principles, teams accelerate their security maturity without complicating operational models.

Implementation Examples

Portal Deployment Sequence (High Level)

1. Create a Secure management group under Platform and deploy a dedicated security subscription.
2. Deploy Log Analytics, Microsoft Sentinel, and Azure Automation in a sovereign region.
3. Apply Defender for Cloud standard plans across the Secure management group.
4. Assign sovereign and security policy initiatives targeting compliance (e.g. ISO27001, IRAP, or Essential Eight).
5. Build secure‑corp and secure‑online subscriptions for sovereign application workloads.
6. Configure private connectivity and telemetry flow back into the Secure platform workspace.

Example Bicep Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@description('Prefix for secure landing zone resources')
param prefix string = 'secure'

@description('Region for sovereign deployment')
param location string = 'australiaeast'

resource secureLog 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: '${prefix}-law'
  location: location
  sku: {
    name: 'PerGB2018'
  }
  properties: {
    retentionInDays: 30
  }
}

resource sentinel 'Microsoft.SecurityInsights/onboardingStates@2022-11-01' = {
  name: '${prefix}-sentinel'
  scope: secureLog
  properties: {}
}

resource defender 'Microsoft.Security/pricings@2022-03-01' = {
  name: 'VirtualMachines'
  properties: {
    pricingTier: 'Standard'
  }
}

This configuration ensures sovereignty by constraining deployment to an Australian region and centralising all SIEM and Defender activity within the Secure Platform boundary.

Gotchas & Edge Cases

• Policy overlap across management groups – Validate inheritance to avoid conflicting enforcement when sovereign policies cross scopes.
• Telemetry costs – Data retention and SIEM ingestion in sovereign regions can be higher due to compliance logging. Plan retention carefully.
• Defender plan overuse – Avoid enabling every plan globally; use management group scoping to control coverage.
• Identity segregation – Maintain Entra Privileged Identity Management (PIM) separation between platform and workload identities.

Best Practices

• ✅ Create a dedicated Secure management group under Platform to host all SLZ resources.
• ✅ Deploy Sentinel and Defender for Cloud in compliance-approved Azure regions only.
• ✅ Use “Allowed Locations” and “Audit VNet Peering” policies to guarantee sovereign network boundaries.
• ✅ Follow the Sovereign Landing Zone reference architecture for structured isolation.
• ✅ Keep all automation, alerting, and telemetry private — no Internet dependencies.
• ✅ Apply least privilege (RBAC/PIM) and separate operational lifecycles for Secure, Corp, and Online zones.

Learn More

• Microsoft Cloud Adoption Framework – Landing Zone Design Areas
• Sovereign Landing Zone Design
• Microsoft Sentinel Documentation
• Microsoft Defender for Cloud Overview
• Azure Policy and Initiative Samples
• CAF Secure Landing Zone Reference Implementation (GitHub)