Azure Security Checklist: Subscription and Identity Controls Verified

Most Azure estates fail a security review on the same few points: too many standing Owners, a break-glass account nobody has tested, PaaS services left on public endpoints and Activity Log data that never reached a workspace. This checklist is a working template for [Organisation] to verify an Azure tenant and its subscriptions against the Microsoft Cloud Security Benchmark (MCSB) and the CIS Microsoft Azure benchmarks. Each section names the MCSB control family it tests, so findings can be traced back to the benchmark and to Defender for Cloud recommendations. It is written for cloud security engineers, platform teams and auditors running a periodic Azure security review or preparing a new landing zone for production.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

How to use this template

• Replace text in square brackets, such as [Organisation], [Tenant], [Subscription], [Control owner] and [Date], with your own values.
• Run the review per tenant, then per management group and subscription. Record each check as Met, Partly met or Not met, with the evidence location (Defender for Cloud export, Azure Policy compliance report, screenshot, KQL result) and an owner and due date for every gap.
• Control IDs (IM-1, PA-5, NS-2 and so on) refer to MCSB v2, which Microsoft marks as preview and which supersedes v1. If your Defender for Cloud regulatory compliance dashboard still shows v1, the families are the same in name but the numbering and guidance may differ, so record which version you assessed.
• For a CIS assessment, use the current CIS Microsoft Azure Foundations Benchmark (version 7.0.0 when checked) plus the separate CIS Compute, Database and Storage Services benchmarks (version 2.0.0 each) for the services you run. Microsoft states that MCSB mappings show where Azure features can help meet a requirement; they do not imply compliance.
• Entra ID tenant hardening is covered here only where it controls Azure resource access. For the full tenant review see the Entra ID Security Guide.

1. Governance, scope and posture management

• A management group hierarchy exists below the tenant root, separating platform (identity, connectivity, management) from workload landing zones, sandbox and decommissioned subscriptions. See the Azure Landing Zones Security Guide.
• Every subscription in [Tenant] is listed with a business owner, a technical owner, an environment tag and a data classification. Subscriptions with no named owner are escalated to [Control owner].
• Production and non-production workloads sit in separate subscriptions, not separate resource groups in one subscription.
• Azure Policy assignments at management group scope enforce the baseline: allowed regions, required tags, deny public network access where private endpoints are mandatory, and deploy diagnostic settings. Policies start in Audit, then move to Deny or DeployIfNotExists. See the Azure Policy and Management Groups Guide.
• Defender for Cloud is enabled on every subscription, and the MCSB standard is assigned and visible in the regulatory compliance dashboard. Secure score is reviewed monthly and the top recommendations by affected resource count have owners. See the Microsoft Defender for Cloud Guide.
• Policy exemptions are recorded with a reason, an approver and an expiry date, and are reviewed at each assessment.

2. Identity and authentication (IM)

• Microsoft Entra ID is the single identity provider for Azure management, and Azure services that support it have local authentication disabled (for example storage account shared key, SQL authentication, Cosmos DB keys) where workloads allow it (IM-1).
• The number of Global Administrators is small: MCSB IM-2 guidance gives two to four. Admin roles require MFA and legacy authentication is blocked by Conditional Access (IM-2, IM-7).
• User consent to applications is restricted, so users cannot grant unmanaged apps access to tenant data (IM-2). See the Entra ID Applications and Consent Guide.
• Conditional Access requires MFA for all users signing in to Azure management, using authentication strengths, with phishing-resistant methods (FIDO2 security keys, passkeys, Windows Hello for Business or certificate-based authentication) required for administrators (IM-6, IM-7).
• Microsoft's mandatory MFA for Azure sign-ins is confirmed in force for the tenant, and any user-based automation that broke has been moved to a workload identity. See the Azure Mandatory MFA guide.
• Risk-based Conditional Access policies (sign-in risk and user risk) are enabled where licences allow, and Continuous Access Evaluation is not disabled (IM-7).
• Guest accounts with Azure RBAC roles are listed and justified. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.

3. Privileged access (PA)

• Owner, Contributor and User Access Administrator assignments at subscription and management group scope are exported and justified. Standing assignments at these scopes are the exception, and most are converted to resource group scope or removed (PA-1, PA-7).
• Privileged Identity Management (PIM) is used for Entra roles and Azure resource roles: eligible rather than active assignments, activation requires MFA and a justification, approval is required for Owner and User Access Administrator, and activation lasts hours, not days (MCSB PA-2 gives 1 to 8 hours as typical).
• At least two cloud-only emergency access (break-glass) accounts exist, not federated, with long random passwords held under dual control. At least one is excluded from Conditional Access. Every sign-in raises a critical alert, and the accounts are tested quarterly (PA-5).
• Access reviews cover Entra roles, Azure resource roles at subscription scope, privileged groups and enterprise apps, at least quarterly (PA-4).
• Administrators use dedicated admin accounts from managed, hardened privileged access workstations, with device compliance required by Conditional Access (PA-6).
• VM management ports are reached through Azure Bastion or just-in-time VM access, never through public IPs (PA-2, PA-6).
• Customer Lockbox is enabled where the support plan allows, and Azure Lighthouse delegations to service providers are listed with their roles and an internal owner (PA-8). See the Azure Lighthouse Security Guide.

4. Workload identities and secrets (IM-3, IM-8)

• Managed identities are used wherever the service supports them. Service principals are used only where managed identities are not available, with certificate credentials or workload identity federation instead of client secrets (IM-3). See the Azure Managed Identities Security Guide.
• Every service principal and managed identity with a role at subscription or management group scope is listed with an owner and the narrowest workable role. Contributor or Owner on a pipeline identity is treated as a privileged account. See the Azure RBAC and Service Principals Guide.
• Client secrets and certificates on app registrations are reported by expiry date, and secrets older than [90] days or with no owner are rotated or removed. See How to find expiring app secrets and certificates in Entra ID.
• CI/CD pipelines authenticate to Azure with workload identity federation rather than stored secrets. See How to replace Azure app secrets with federated credentials.
• Secrets, keys and certificates live in Key Vault, accessed by managed identity. Vaults use the Azure RBAC permission model, have purge protection on, public network access disabled with private endpoints, and resource logs sent to the central workspace. See the Azure Key Vault Security Guide.
• Code repositories are scanned for secrets with push protection or an equivalent scanner, and Defender for Cloud agentless secret scanning findings have owners (IM-8).
• Storage SAS tokens are short-lived and user delegation SAS is preferred over account key SAS. See the Azure SAS Tokens Security Guide.

5. Network security (NS)

• Virtual networks are separated by environment and trust zone, and NSGs deny by default with explicit allows. No NSG rule allows RDP (TCP 3389) or SSH (TCP 22) from Internet or 0.0.0.0/0; management ports accept traffic only from the bastion subnet (NS-1).
• PaaS services holding sensitive data (Storage, SQL, Key Vault, Cosmos DB) use Private Link private endpoints with Private DNS zones, and public network access is disabled once private endpoints work (NS-2).
• VMs do not have public IP addresses unless an approved exception exists; internet-facing web apps sit behind Application Gateway or Front Door (NS-2).
• Egress is forced through Azure Firewall or an equivalent network virtual appliance using a 0.0.0.0/0 user-defined route, with FQDN application rules and threat intelligence filtering on (NS-3). Where Azure Firewall Premium is used, IDPS has moved from Alert to Alert and Deny after tuning (NS-4).
• Internet-facing applications have a WAF on Application Gateway or Front Door in Prevention mode, after a period in Detection mode, and DDoS Network Protection or IP Protection covers critical public IPs (NS-5, NS-6).
• Legacy protocols (TLS 1.0 and 1.1, SMBv1, NTLMv1, unsigned LDAP) are identified and disabled, or isolated by deny rules where they cannot be removed (NS-8).
• VNet flow logs and Traffic Analytics are enabled for production networks (NS-7, LT-4). See the Azure Virtual Network Security Guide.

6. Data protection (DP)

• Storage accounts disallow anonymous blob access, require secure transfer and set a minimum TLS version of 1.2. See the Azure Storage Security Guide.
• Databases use Entra authentication, auditing is enabled and sent to the central workspace, and public network access is off where private endpoints exist. See the Azure SQL and Cosmos DB Security Guide.
• Data classified as [Confidential] or above uses customer-managed keys in Key Vault where policy or regulation requires it, with key rotation configured and the dependency documented (disabling a key takes dependent services offline).
• Sensitive data stores are tagged with their classification, and Defender for Storage and Defender for SQL plans cover them.

7. Logging, detection and response (LT, IR)

• Activity Log for every subscription is sent to a central Log Analytics workspace through diagnostic settings, enforced by Azure Policy at management group scope (LT-3). See the Azure Monitor, Activity Log and Diagnostic Settings Guide.
• Entra sign-in and audit logs, including service principal and managed identity sign-ins, are exported to the workspace, because the default retention is 30 days (LT-2, LT-3).
• Resource logs are on for Key Vault, Storage, SQL, AKS (kube-audit), Container Registry, App Service, API Management and Functions where those services are used (LT-3).
• Defender for Cloud plans are enabled for servers, storage, databases, containers and Key Vault in production (LT-1).
• Logs are retained for [1 to 2] years in the workspace for investigation, with longer-term archive where regulation requires it, and Defender for Cloud alerts use continuous export because native retention is limited (LT-6).
• Alerts exist for: any break-glass sign-in; new Owner or User Access Administrator assignments; diagnostic setting deletion; policy assignment deletion; new credentials added to service principals; and Key Vault purge or access policy change. Alerts route to [SOC queue] with a named responder.
• An incident response runbook covers Azure scenarios: compromised admin, compromised service principal, exposed storage account and crypto-mining deployment (IR).

8. Backup and recovery (BR)

• Azure Backup or the native equivalent protects every production VM, database and file share, with coverage enforced or audited by Azure Policy (BR-1).
• Recovery Services vaults have soft delete on, immutability enabled and locked for critical workloads, and multi-user authorisation protecting changes to security settings (BR-2). See the Azure Backup and Recovery Services Vault Security Guide.
• Backup operators cannot also delete backups, and vault administration uses PIM.
• Alerts fire on backup job failures, retention reductions and soft delete being disabled (BR-3).
• Restores are tested on a schedule (MCSB BR-4 suggests quarterly for critical systems) and results are recorded against RTO and RPO.

Implementation guidance

Order of work: fix identity first, because almost every serious Azure compromise runs through it. In the first two weeks, confirm break-glass accounts, remove standing subscription Owners, block legacy authentication and confirm Activity Log export. Then close internet-exposed management ports and public PaaS endpoints, then move to workload identities and secrets, then data protection, backup immutability and detection tuning. Scope matters: include test and sandbox tenants in the review, and confirm every account in them uses MFA.

Rolling out policy safely: assign new Azure Policy definitions in Audit effect, review the non-compliant list with resource owners, fix or exempt, then switch to Deny or DeployIfNotExists. Roll back by changing the effect or the assignment's enforcement mode rather than deleting the assignment, so compliance history is kept.

Small and large estates: a single-subscription organisation can complete this in a day using Defender for Cloud recommendations and an export of role assignments. A large enterprise should automate sections 1, 3, 5 and 7 through Azure Policy compliance and Azure Resource Graph queries, run the review per landing zone, and keep the manual checks (break-glass test, access review evidence, restore test) on a quarterly calendar.

Metrics to track: standing Owner and User Access Administrator assignments at subscription scope; percentage of subscriptions with Activity Log export; PaaS resources with public network access enabled; service principals using client secrets rather than certificates or federation; MCSB compliance percentage in Defender for Cloud; and days since the last successful restore test.

References: Microsoft Learn: Microsoft Cloud Security Benchmark overview · Microsoft Learn: MCSB v2 Identity Management · Microsoft Learn: MCSB v2 Privileged Access · Microsoft Learn: MCSB v2 Network Security · Microsoft Learn: MCSB v2 Logging and Threat Detection · Microsoft Learn: MCSB v2 Backup and Recovery · CIS: Microsoft Azure Benchmarks · Microsoft Learn: Mandatory multifactor authentication for Azure

Related NHI Mgmt Group resources: Microsoft Azure Security Guide · Microsoft Cloud Security Benchmark Guide · CIS Cloud Foundations Benchmarks Guide · Cloud Security Policy Template