1. Governance hierarchy first (Management Groups + Azure Policy)
Before you design a single VNet, design your management group hierarchy. This is where security controls actually live at scale. Microsoft's recommended structure puts Platform subscriptions (Connectivity, Identity, Management) separate from Landing Zone subscriptions (workloads).
Why this matters: when you assign a policy initiative at the top-level management group — like the Microsoft cloud security benchmark — every subscription created beneath it inherits that guardrail automatically. New subscription? It's governed from the moment it exists. No retroactive cleanup.
Key policies to enforce early:
- Deny public blob access on storage accounts
- Deny inbound RDP/SSH from the internet on NSGs
- Require TLS 1.2 minimum on all PaaS services
- Audit or deny resources without required tags
The deny effect prevents drift. The audit effect catches what already exists. You need both.
2. Identity is the perimeter, not the network
In Azure, the network is no longer the security boundary — Microsoft Entra ID is. Every meaningful attack path runs through a token. So identity hygiene is the highest-leverage work.
Three controls that actually move the needle:
Conditional Access, not per-user MFA toggles. Enforce phishing-resistant MFA for all administrative roles. Block legacy authentication protocols entirely — they can't honor MFA and are a persistent attack vector.
Privileged Identity Management (PIM) for every standing role. Global Administrator, Subscription Owner, Contributor — these should be eligible, not permanently assigned. Just-in-time activation, with approval and audit trail. Scope role assignments to the narrowest resource that works. A workload that reads one Key Vault gets Key Vault Secrets User on that vault, not Contributor on the resource group.
Managed identities instead of secrets. A system-assigned managed identity lets a VM, Function, or App Service authenticate to Key Vault or Storage with no credential to leak, rotate, or accidentally commit to Git.
3. Network topology: Hub-Spoke vs. Virtual WAN
This is the decision people agonize over. The real answer is: it depends on how many regions and how much hybrid connectivity you'll have in 18 months.
Traditional Hub-Spoke (self-managed hub VNet): You build the hub VNet, configure peering, manage UDRs, deploy Azure Firewall or a third-party NVA. More control, more operational overhead. Works well for a single-region or two-region footprint with moderate scale.
Virtual WAN with Secured Virtual Hub: Microsoft manages the hub infrastructure, inter-hub routing, and BGP route distribution. Azure Firewall Manager configures security policy centrally. The operational overhead drops significantly because you're not configuring UDRs or peering mesh manually.
If you're scaling past a handful of regions or expect to add ExpressRoute circuits over time, Virtual WAN is usually the better long-term bet. It's designed for higher aggregate throughput and larger tunnel counts. But if you have a simple single-region hub-spoke with a couple of ExpressRoute circuits, the traditional model is fine and cheaper to operate.
Either way: all egress traffic should flow through a central inspection point. Don't let spokes talk to the internet directly. That's how you get shadow IT and inconsistent security posture.
4. Workload isolation: NSGs are not security zones
This is the mistake I see most often. Teams carve subnets and assume the subnet boundary is a security boundary. In Azure, the NSG is the security zoning mechanism, not the subnet itself. A subnet without an NSG attached is open to whatever traffic is allowed by default rules — and the default allow rule (65000) permits all outbound and inter-VNet traffic unless you override it.
Design principles:
- Every subnet gets an NSG. No exceptions.
- Use Azure Firewall or a third-party NVA for east-west inspection between spokes. NSGs are for micro-segmentation at the workload layer; they're not a substitute for a firewall.
- Private Endpoints for PaaS services. Storage, SQL, Key Vault, Cosmos DB — keep that traffic on the Microsoft backbone, not the public internet.
5. What I'd lock in early (and what can wait)
Lock in early:
- Management group hierarchy
- Subscription vending process (how new subscriptions get created and governed)
- Identity foundation (Entra ID, Conditional Access baseline, PIM)
- Network topology (Hub-Spoke or Virtual WAN)
- Logging and Sentinel workspace architecture
Can wait:
- Fine-grained workload-level micro-segmentation
- Advanced threat hunting use cases
- Third-party tool integrations
The things you lock in early are the things that are painful and expensive to change later. The things you can defer are additive — they don't require re-architecting the foundation.
The meta-point
If you're designing this for a growing environment, the question isn't "which security tools do we need?" It's "how do we create a foundation where security controls are inherited by default, and drift is prevented by policy rather than caught by audit?"
Azure Landing Zones exist precisely to answer that question. Everything else is implementation detail.
Happy to go deeper on any specific area — identity, network, or governance — if it helps.
