How to Use This Checklist
Work through each section and click the checkboxes as you verify each item. Your progress is tracked at the top of the sidebar. Each item is marked with a priority level — focus on Critical items first, then High, then Medium.
This checklist is designed for quarterly security reviews of existing Azure environments, pre-production readiness checks, and onboarding audits when you inherit an Azure environment someone else built. It covers the most common misconfigurations we see in real Azure deployments.
Pro Tip
Run this checklist against one subscription at a time. For large environments with multiple subscriptions, use Microsoft Defender for Cloud's secure score alongside this checklist — it automates detection of many of these items at scale.
1. VNet & Subnet Design
VNet & Subnet Design
Network architecture and segmentation
Workloads are separated into dedicated subnets by tier
Web, app, and data tiers each have their own subnet. No flat /16 with everything mixed together.
No production and dev/test workloads share the same VNet
Mixing environments in one VNet creates lateral movement risk. Separate VNets or strict NSG rules required.
No backend VMs have public IP addresses
Public IPs on app/data tier VMs bypass all perimeter controls. Use Azure Bastion or Firewall DNAT for admin access.
VNet peering is documented and intentional
All peerings have a documented business reason. No forgotten dev-to-prod peerings with AllowForwardedTraffic enabled.
Azure Bastion deployed for VM administrative access
RDP/SSH access via Azure Bastion over HTTPS rather than exposing management ports directly. No public IPs on jump boxes.
Private Endpoints used for PaaS services (Storage, SQL, Key Vault)
PaaS services accessed via private IP within the VNet. Public endpoint access disabled after Private Endpoint creation.
Subnet address spaces are appropriately sized
Subnets have room for growth. No subnets at 90%+ IP utilisation that would require downtime to resize.
2. Network Security Groups
Network Security Groups
NSG rules, priorities, and coverage
NSGs applied to every subnet — no subnet left unprotected
Every subnet has an associated NSG. Confirm in Network Watcher → Topology or via Azure Policy.
No Allow Any Any rules at low priority numbers
Check all NSGs for broad inbound/outbound Allow rules at priority 100–500. These override more specific deny rules placed later.
Explicit Deny-All rules at the end of each NSG
Final rule at priority 4000 or 4096 denying all remaining inbound and outbound traffic. Don't rely on Azure's implicit deny alone.
Service Tags used instead of hardcoded IP ranges where possible
AzureLoadBalancer, Storage, AzureMonitor etc. Auto-updated by Microsoft. Hardcoded IPs break silently when Microsoft updates infrastructure.
Management ports (22, 3389) not open to the internet
SSH and RDP should never be exposed via public IP or NSG rule from Any source. Use Azure Bastion or Just-in-Time VM access.
Application Security Groups used for multi-VM workloads
Environments with 3+ VMs of the same role use ASGs rather than individual IP-based NSG rules.
3. Azure Firewall
Azure Firewall
Firewall deployment and rule hygiene
Azure Firewall deployed in hub VNet with UDRs forcing spoke traffic through it
All spoke VNets have UDRs with 0.0.0.0/0 next-hop pointing to the Azure Firewall private IP. Verify routes are active.
Threat Intelligence mode set to Alert and Deny
Default is Alert only. Set to Alert and Deny in Firewall Policy to actively block traffic to/from Microsoft's known malicious IP/domain feed.
Outbound internet traffic filtered by FQDN application rules
Explicit allow list of required FQDNs for outbound internet. Default deny for all other outbound destinations.
Azure Firewall logs sent to Log Analytics workspace
AzureFirewallApplicationRule, AzureFirewallNetworkRule, and AzureFirewallDnsProxy diagnostic categories all enabled.
Firewall Policy used rather than classic Firewall rules
Firewall Policy enables centralised management across multiple Firewall instances, IDPS (Premium), and rule inheritance.
Azure Firewall Premium with IDPS enabled for regulated workloads
Environments requiring PCI-DSS, HIPAA, or NIST compliance should have Premium tier with IDPS in Alert and Deny mode.
4. Identity & Access
Identity & Access
MFA, Conditional Access, and RBAC
MFA enforced for all users via Conditional Access policy
Not just Security Defaults — a Conditional Access policy explicitly requiring MFA for all users and all cloud apps.
Legacy authentication protocols blocked via Conditional Access
CA policy targeting all users blocking all legacy auth client apps. Verify no service accounts depend on legacy auth before enabling.
No standing Owner or Contributor role assignments at subscription scope
Use Entra PIM (Privileged Identity Management) for just-in-time privileged access. Permanent broad role assignments are a high risk.
Break-glass emergency access accounts exist and are tested
Two break-glass accounts excluded from all CA policies, credentials stored securely offline. Tested quarterly to confirm they work.
Managed Identities used for workload authentication — no service account passwords
VMs, App Services, and Functions authenticate to Azure services via Managed Identity. No credentials stored in code or config files.
Conditional Access device compliance policy enforced for Azure portal access
Accessing the Azure portal, CLI, and ARM APIs requires a compliant, Intune-managed device.
5. Logging & Monitoring
Logging & Monitoring
Visibility into network traffic and events
NSG Flow Logs enabled on all NSGs and sent to Log Analytics
Version 2 flow logs enabled. Retention set to at least 30 days. Traffic Analytics enabled for visualisation if budget allows.
Azure Activity Log exported to Log Analytics
All subscription-level operations (who changed what, when) are captured and queryable. Retention minimum 90 days.
Microsoft Defender for Cloud enabled at Standard tier
Defender for Servers and Defender for DNS enabled. Secure score reviewed monthly. High-severity recommendations actioned.
Entra sign-in and audit logs ingested into SIEM
Sign-in logs (including risky sign-ins) and audit logs sent to Microsoft Sentinel or equivalent SIEM. Alerts configured for anomalous activity.
Alerts configured for critical network security events
Alerts for: NSG rule changes, Firewall policy changes, new public IP assignments, new peering connections, and role assignment changes.
Network Watcher enabled in all regions with deployed resources
Network Watcher required for NSG Flow Logs, Connection Monitor, and packet capture capabilities.
6. DDoS Protection & Resilience
DDoS Protection & Resilience
Protection against volumetric and protocol attacks
Azure DDoS Network Protection enabled on production VNets with public IPs
Basic DDoS protection is included but limited. Network Protection adds adaptive tuning, attack analytics, and rapid response support.
Web Application Firewall (WAF) deployed on Application Gateway or Front Door
Any internet-facing web application has a WAF in Prevention mode with OWASP ruleset enabled and regularly reviewed.
No resources exposed directly to internet without a load balancer or App Gateway
All internet-facing workloads sit behind an Application Gateway, Azure Front Door, or at minimum an Azure Load Balancer.
DDoS Protection alerts configured and tested
Azure Monitor alerts set up for DDoS attack detection metrics. Incident response runbook exists for DDoS events.
Rate limiting configured on API endpoints
Azure API Management or Application Gateway policies implement request rate limiting to mitigate layer 7 attacks.
Geo-filtering configured to block regions with no business presence
Azure Front Door or Application Gateway WAF geo-filtering blocks traffic from countries your organisation never serves.
Using This Checklist
Getting the most from your audit
- →Start with Critical items — these represent the highest risk and most commonly exploited gaps
- →Run quarterly — Azure environments drift over time as teams add resources and rules accumulate
- →Use alongside Defender for Cloud — automates detection of many of these items at scale across multiple subscriptions
- →Document exceptions — any item you can't remediate should have a documented risk acceptance and compensating control
- →Assign owners — each failed item should have a named owner and remediation deadline