Azure Policy vs Microsoft Defender for Cloud: Which Enforces What?

TL;DR: Azure Policy vs Defender for Cloud

When to reach for which:

• Use Azure Policy when you need enforcement — a bad configuration must never be deployable.
• Use Defender for Cloud when you need visibility — what is already misconfigured, and what is the blast radius?
• Use both: Policy closes the front door; Defender tells you who already got in.

---

When Both Tools Flag the Same Resource

Three months into their first Azure deployment, a team I was reviewing had a problem they couldn't articulate clearly. "Both things keep flagging our storage accounts," the engineer told me. "Azure Policy says our storage accounts aren't compliant. Defender for Cloud says our storage accounts have a recommendation to enable secure transfer. Are they the same thing? Why are we seeing it in two places?"

This is one of the most common points of confusion for engineers moving from on-premises environments to Azure. Both tools surface security and compliance issues. Both have dashboards. Both generate something that looks like a to-do list. But they exist for fundamentally different reasons, work at different layers, and respond to failures differently.

The short version: Azure Policy is governance and compliance enforcement: it defines rules for what your resources are allowed to do or be. Microsoft Defender for Cloud is security posture management and threat detection: it continuously evaluates whether your resources are configured securely and whether active threats are present.

One enforces. The other observes, recommends, and sometimes detects.

What Azure Policy Actually Does

Azure Policy is Azure's built-in governance engine. It operates at the control plane level, on top of Azure Resource Manager, meaning it intercepts every create, update, and read operation on Azure resources and evaluates it against a set of rules.

Initiatives, Policies, and Assignments

The building blocks are:

A Policy definition is a single rule. "Storage accounts must use HTTPS only." "Virtual machines must use approved VM sizes." "Resource groups must have a specific tag." Each definition specifies a condition and an effect.

An Initiative (also called a Policy Set) is a collection of related policies grouped together. Microsoft provides built-in initiatives for common compliance frameworks: CIS Microsoft Azure Foundations Benchmark, NIST SP 800-53, PCI DSS, SOC 2, ISO 27001. When you assign an initiative, all its constituent policies are evaluated together.

An Assignment is the act of applying a policy or initiative to a specific scope: a management group, subscription, or resource group. The same policy can be assigned to different scopes with different parameters.

The Effects That Actually Matter

The effect is what happens when a resource fails the policy condition. This is where Azure Policy's real power and real complexity live.

Audit - The resource is allowed to exist. A compliance violation is recorded. Nothing is blocked. This is useful for discovering violations without disrupting existing workloads, and for policies where denial would break too many things.

Deny - The resource creation or modification is rejected at the API level. If someone tries to create a storage account without HTTPS-only enabled, the ARM API returns a 403 with the policy details in the error. Nothing gets deployed. This is the effect you want for hard security requirements.

DeployIfNotExists (DINE) - When a resource is created or updated and doesn't have a specific configuration (like diagnostic settings or a specific extension), Azure Policy automatically deploys the missing configuration. This is powerful for ensuring things like Log Analytics agents, disk encryption, or monitoring settings are always present. It requires a Managed Identity with appropriate permissions to execute the remediation deployment.

Modify - Similar to DINE, but adds or removes tags or properties on existing resources. Useful for automatic tagging enforcement.

There's also AuditIfNotExists, which is like DINE without the automatic deployment; it audits resources that are missing a related resource.

Built-in vs Custom Policies

Microsoft ships hundreds of built-in policy definitions covering nearly every Azure service. Before writing a custom policy, search the built-in library; there's a good chance what you need already exists. Custom policies are written in JSON and use Azure Resource Manager condition expressions.

Remediation tasks are how you bring existing non-compliant resources into compliance. For Audit policies, you can create a remediation task manually or schedule it. For DINE policies, the remediation task triggers the deployment automatically. Note that Deny only prevents future violations; it doesn't remediate existing ones, so you'll need a separate remediation approach for resources that already exist.

What Microsoft Defender for Cloud Actually Does

Microsoft Defender for Cloud (formerly Azure Security Center) is a Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) platform. It operates at a higher level of abstraction than Azure Policy; it looks at your cloud environment holistically and tells you how secure your posture is, and optionally, whether active threats are present.

Secure Score and Recommendations

The Secure Score is Defender for Cloud's headline metric: a percentage representing how well your subscription follows Microsoft's security best practices. Every recommendation has a score impact, and fixing recommendations improves your score.

Recommendations are actionable findings. "Enable MFA for accounts with owner permissions on your subscription." "Storage accounts should restrict network access." "Virtual machines should encrypt temp disks, data disks, and cache." Each recommendation shows which resources are affected, what the risk is, and how to fix it. Some recommendations have a Quick Fix button that applies the remediation directly from the portal.

CSPM vs CWP

Defender for Cloud operates in two modes:

CSPM (Cloud Security Posture Management) is available in a free tier and continuously evaluates your Azure resources against security best practices. This is the part that generates recommendations and a Secure Score. The free tier covers Azure, and with the paid Defender CSPM plan, it extends to multi-cloud (AWS, GCP) and adds attack path analysis, cloud security explorer, and agentless scanning.

CWP (Cloud Workload Protection) is the paid, threat-detection layer. The Defender plans cover individual resource types: Defender for Servers, Defender for SQL, Defender for Storage, Defender for Containers, Defender for Key Vault, Defender for App Service, and others. These plans go beyond posture and add real-time threat detection, anomaly detection, and security alerts for active attacks.

The Regulatory Compliance Dashboard

Defender for Cloud's Regulatory Compliance dashboard maps your environment against specific compliance frameworks (the same ones Azure Policy uses: CIS, NIST, PCI DSS, etc.). This is where the overlap with Azure Policy becomes visible: the compliance status you see here is driven by Policy evaluations running under the hood.

The Overlap: Where They Work Together

The thing that makes this confusing is that Defender for Cloud and Azure Policy are deeply integrated. Defender for Cloud uses Azure Policy as its enforcement mechanism for recommendations. When you see a recommendation in Defender for Cloud like "Storage accounts should use private link," there is an Azure Policy definition running in the background that evaluates the same condition.

Here's a concrete example: the recommendation "Storage accounts should restrict network access using virtual network rules" appears in Defender for Cloud's Secure Score. If you navigate to Azure Policy and search for storage account policies, you'll find "Storage accounts should restrict network access" as a built-in policy definition. They're evaluating the same thing from different vantage points.

This means:

• Viewing the issue in Defender for Cloud shows you the security risk framing and what remediation looks like.
• Using Azure Policy gives you the ability to *enforce* it - to Deny non-compliant configurations from being created.

Defender for Cloud shows you the recommendation and scores your posture. Azure Policy enforces the requirement and blocks violations. You often need both.

The architecture looks like this:

Azure Resources
       |
       ▼
Azure Resource Manager (ARM)
       |
       ├──► Azure Policy Engine
       │         │
       │         ├── Evaluate conditions
       │         ├── Apply effects (Audit, Deny, DeployIfNotExists)
       │         └── Write compliance state to ARM
       │
       └──► Microsoft Defender for Cloud
                 │
                 ├── Read policy compliance state from ARM
                 ├── Run additional security assessments (agent-based + agentless)
                 ├── Generate Secure Score and recommendations
                 ├── Map to regulatory frameworks
                 └── (With paid plans) Detect active threats

The 2025–2026 Microsoft Security Portal Consolidation

Microsoft is actively converging its security products into the unified portal at security.microsoft.com, where Defender for Cloud posture recommendations, Microsoft Sentinel incidents, and Defender XDR alerts now appear side-by-side. This creates a real operational risk: a Defender recommendation about a misconfigured storage account can visually appear equivalent to an active credential-theft alert from Sentinel, when the two require completely different owners, timelines, and urgency levels. Azure Policy compliance violations live in the Azure portal governance blade and belong to platform engineering; Defender recommendations are posture debt for security engineers to address over days or weeks; Sentinel incidents are active threats requiring SOC response within minutes. As portals continue to merge, explicitly defining which team owns each category of finding — and ensuring those distinctions survive runbook updates — becomes more important, not less.

Decision Framework: Which Tool for Which Scenario?

The table reveals the core distinction: Azure Policy is proactive and preventive. Defender for Cloud is reactive and observational (with threat detection as an active layer on top).

Practical Example: Enforcing Tagging With Azure Policy and Terraform

One of the most common governance requirements is mandatory resource tagging. Here's how to enforce it properly with Terraform:

# Define the policy assignment for required tags
resource "azurerm_policy_assignment" "require_tags" {
  name                 = "require-env-owner-tags"
  scope                = data.azurerm_subscription.current.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/96670d01-0a4d-4649-9c89-2d3abc0a5025"
  # Built-in: "Require a tag and its value on resources"
  display_name         = "Require environment and owner tags on all resources"
  description          = "Denies creation of resources missing required env or owner tags"
  enforcement_mode     = "Default"  # "Default" = enforce, "DoNotEnforce" = audit only

  parameters = jsonencode({
    tagName = {
      value = "environment"
    }
    tagValue = {
      value = "production"
    }
  })

  identity {
    type = "SystemAssigned"
  }

  location = "westeurope"
}

# Assign a built-in initiative for CIS benchmark
resource "azurerm_policy_set_definition" "cis_assignment" {}

resource "azurerm_subscription_policy_assignment" "cis_benchmark" {
  name                 = "cis-benchmark-v2"
  subscription_id      = data.azurerm_subscription.current.id
  policy_definition_id = "/providers/Microsoft.Authorization/policySetDefinitions/06f19060-9e68-4070-92ca-f15cc126059e"
  # Built-in: CIS Microsoft Azure Foundations Benchmark v2.0.0
  display_name         = "CIS Microsoft Azure Foundations Benchmark v2.0.0"
  enforcement_mode     = "DoNotEnforce"  # Audit first, then switch to Default
}

A few notes on this pattern: Start new policy assignments with enforcement_mode = "DoNotEnforce" to audit violations without blocking anything. Once you've reviewed the findings and are confident in the policy logic, switch to "Default" to enforce. Switching a Deny policy from audit to enforce on an active subscription with existing violations will not affect those resources retroactively, but it will block any new non-compliant resources.

For more complex governance patterns, see the [Azure auto-tag event-driven governance](/blog/azure-auto-tag-event-driven-governance) article, which covers DINE policies and Event Grid-based tagging approaches. For securing the Azure Storage accounts used as Terraform remote backends for these Policy assignments, see [Secure Terraform Remote State in Azure Storage](/blog/terraform-remote-state-azure-storage-security).

Deny Policy JSON and Bicep: Concrete Examples

The Terraform example above uses built-in policy definitions. Here is how to write a custom Deny policy from scratch, plus a Bicep snippet to assign the Microsoft Cloud Security Benchmark (MCSB) initiative.

Custom Deny Policy Definition (JSON)

This policy blocks storage accounts from being deployed with allowBlobPublicAccess: true. Save as policy.json and deploy with az policy definition create --name 'deny-public-blob' --rules policy.json:

{
  "properties": {
    "displayName": "Deny storage accounts with public blob access",
    "description": "Blocks storage accounts that allow public blob access at the ARM level.",
    "mode": "Indexed",
    "policyType": "Custom",
    "parameters": {},
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
            "equals": "true"
          }
        ]
      },
      "then": {
        "effect": "Deny"
      }
    }
  }
}

This intercepts at the ARM layer. Any Terraform apply, Bicep deployment, portal click, or direct API call that creates a storage account with public blob access will fail with a policy error before the resource is created. Defender for Cloud will also stop recommending "Disable public blob access" on this subscription — because the misconfiguration can no longer exist.

MCSB Initiative Assignment (Bicep)

The Microsoft Cloud Security Benchmark (MCSB) v1 is the successor to the Azure Security Benchmark and maps directly to Defender for Cloud's Secure Score. Assigning it with DoNotEnforce gives you an immediate compliance baseline with zero enforcement risk:

targetScope = 'subscription'

resource mcsbAssignment 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
  name: 'mcsb-audit-baseline'
  location: deployment().location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    displayName: 'Microsoft Cloud Security Benchmark — Audit baseline'
    // MCSB v1 initiative ID
    policyDefinitionId: '/providers/Microsoft.Authorization/policySetDefinitions/1f3afdf9-d0c9-4c3d-847f-89da613e70a8'
    enforcementMode: 'DoNotEnforce'  // audit first; switch to Default once findings are reviewed
    description: 'Assigns MCSB in audit mode to establish a compliance baseline'
  }
}

output assignmentId string = mcsbAssignment.id

Once deployed, Defender for Cloud's Regulatory Compliance dashboard automatically reflects your MCSB compliance posture. Switch enforcementMode to Default after reviewing and remediating findings. If your team uses [Azure DevOps Pipelines](/blog/azure-devops-pipelines-beginners-guide) for infrastructure deployments, consider adding a Policy compliance evaluation step before terraform apply or az deployment so non-compliant resource configurations are caught in the pipeline rather than flagged weeks later in a security review.

Pricing Reality Check

Azure Policy is free. You can create as many policy definitions, initiatives, and assignments as you need. Policy evaluations run continuously at no charge. This makes it a no-brainer for governance; there's no financial reason not to use it.

Microsoft Defender for Cloud has two tiers:

The free CSPM tier is included with every Azure subscription. It gives you Secure Score, basic recommendations, and the Regulatory Compliance dashboard. For most organizations starting out, this provides significant value at no cost.

The paid Defender CSPM plan adds multi-cloud support (AWS/GCP), attack path analysis, cloud security explorer, and agentless scanning. It's priced per billable resource. For organizations managing complex multi-cloud environments or needing advanced attack path visualization, it's worth it.

The Defender plans (for Servers, SQL, Containers, Storage, Key Vault, etc.) are priced separately, typically per resource per hour. Defender for Servers is often the largest cost because it applies to every VM. For a production environment with regulated workloads, Defender for Servers combined with Defender for SQL typically provides enough detection coverage to justify the cost against the alternative of building detection from scratch in your SIEM.

Where the paid plans are genuinely worth the cost: regulated industries (finance, healthcare, government), environments processing sensitive data, and organizations without dedicated security monitoring tooling. Where they may not be: small environments with homogeneous workloads where a well-tuned Azure Policy baseline + Log Analytics provides equivalent coverage at lower cost.

The Mistake That Costs People the Most

The most expensive mistake teams make is treating Defender for Cloud recommendations as a substitute for Azure Policy enforcement.

Defender for Cloud tells you that your storage accounts should restrict network access. It's right. But if you don't also have an Azure Policy with a Deny effect preventing non-compliant storage accounts from being created, the next engineer who runs a Terraform apply or clicks through the portal to create a storage account will create a public one by default. Defender will flag it. They'll fix it (maybe) when they get around to it. Meanwhile, a public storage account with sensitive data was live for hours or days.

Policy enforcement means the misconfiguration never happens. The deployment fails with a policy error message explaining exactly what's wrong. The engineer fixes their code before it reaches production.

Recommendations without enforcement is like a smoke alarm that tells you there was a fire last week. Useful information, but you'd prefer the fire suppression system that prevented it.

If you're building your cloud security foundation, start with Azure Policy to enforce your hard requirements, and use Defender for Cloud recommendations to find and prioritize everything else. For the identity layer, pair Policy with [Entra ID Conditional Access](/blog/microsoft-entra-id-conditional-access-setup) — together they protect both what gets deployed and who can authenticate to use it. When writing Deny policies, be deliberate about exclusions: [break glass emergency accounts](/blog/entra-id-break-glass-account-setup-monitoring) and service principals used in recovery workflows may need explicit policy exclusions, just as they require Conditional Access exclusions. The [cloud security fundamentals guide](/blog/cloud-security-fundamentals-beginners) walks through how to layer these controls into a coherent baseline for new Azure environments.

Frequently Asked Questions

What is the main difference between Azure Policy and Microsoft Defender for Cloud?

Azure Policy is a governance and compliance enforcement engine. It defines rules for what resources are allowed to be or do, and can block non-compliant deployments before they happen. Microsoft Defender for Cloud is a security posture management (CSPM) and threat detection platform. It evaluates whether your existing resources are configured securely and detects active threats. Azure Policy prevents misconfigurations; Defender for Cloud identifies and responds to them.

Does Microsoft Defender for Cloud use Azure Policy?

Yes. Defender for Cloud uses Azure Policy as its underlying evaluation mechanism for many recommendations. When Defender for Cloud surfaces a recommendation, such as "Storage accounts should restrict network access," there is an Azure Policy definition running in the background evaluating the same condition. Enabling Defender for Cloud automatically assigns several built-in policy initiatives to your subscription.

Is Azure Policy free?

Yes. Azure Policy is entirely free. You can create unlimited policy definitions, initiatives, and assignments, and evaluations run continuously at no cost. This makes it a zero-cost governance layer for any Azure environment.

Can Azure Policy block resource deployments?

Yes. Using the Deny effect, Azure Policy intercepts create and update operations at the Azure Resource Manager (ARM) level and rejects them with a policy error if they do not meet the policy conditions. No deployment succeeds until the resource configuration is compliant. This is the key enforcement capability that Defender for Cloud recommendations alone cannot provide.

What is CSPM in Azure?

Cloud Security Posture Management (CSPM) is the practice of continuously assessing your cloud resources against security best practices and compliance frameworks. In Azure, Defender for Cloud is the primary CSPM tool. It generates a Secure Score, surfaces prioritized recommendations, and maps your environment against standards like CIS, NIST SP 800-53, and PCI DSS. The free tier covers Azure resources; the paid Defender CSPM plan extends coverage to AWS and GCP.

Should I use Azure Policy or Defender for Cloud first?

Use both, but start with Azure Policy. Set up Deny policies for your hard security requirements (public storage accounts, non-HTTPS traffic, missing encryption) so these misconfigurations can never be deployed. Then use Defender for Cloud's Secure Score to identify and prioritize everything else that needs remediation. Azure Policy prevents future problems; Defender for Cloud helps you find and fix current ones.