Microsoft Defender for Resource Manager should be enabled

What does the recommendation "Microsoft Defender for Resource Manager should be enabled" check?

Flags any subscription where the Defender for Resource Manager plan is not set to Standard. The plan watches the Azure control plane: management operations that flow through Azure Resource Manager, whether they arrive from the portal, the REST API, the az CLI, PowerShell or any other programmatic client. It checks only that the plan is on at the subscription level. It does not inspect activity inside a resource's data plane, such as reads against blobs, queries against a SQL database or traffic to a VM, and it is not a substitute for the per-resource Defender plans that cover those surfaces.

Why does "Microsoft Defender for Resource Manager should be enabled" matter?

The management plane is where an attacker who has captured a credential or token turns access into control: enumerating your estate, granting themselves roles, disabling antimalware, running scripts through VM extensions or exfiltrating secrets. Without this plan those moves leave no alert, and reconnaissance toolkits such as MicroBurst and PowerZure are built precisely to exercise them at speed. With the plan on, Defender applies behavioural analytics to Resource Manager operations and raises alerts on suspicious patterns, for example management calls from a known malicious IP or from a risky toolkit, so you can intervene before a compromised identity escalates into estate-wide damage and the breach-notification and recovery costs that follow.

How do I fix "Microsoft Defender for Resource Manager should be enabled"?

1. Enable the plan on the subscription: az security pricing create --name Arm --tier Standard. The 'Arm' identifier is the Resource Manager plan; confirm with az security pricing show --name Arm that the pricingTier reads 'Standard'.
2. Route the alerts to a human by setting email notifications in Defender for Cloud: az security contact create with an email address and high-severity alert notifications turned on, so a suspicious control-plane operation reaches your responders rather than sitting in the portal.
3. Make it durable across every subscription by assigning the built-in audit policy so drift is caught automatically. Look the definition up by its exact display name rather than hardcoding a GUID: pid=$(az policy definition list --query "[?displayName=='Azure Defender for Resource Manager should be enabled'].name" -o tsv); az policy assignment create --name defender-arm --policy "$pid" --scope /providers/Microsoft.Management/managementGroups/<mg-id>.

# Enable the three high-value Defender plans on the current subscription.
# Servers on Plan 2 (adds JIT access, FIM and vulnerability scanning).
az security pricing create --name VirtualMachines \
  --tier Standard --subplan P2

# Storage on the current per-account plan.
az security pricing create --name StorageAccounts --tier Standard

# Azure SQL Database servers (VA + Advanced Threat Protection).
az security pricing create --name SqlServers --tier Standard

# Verify what is now active on this subscription.
az security pricing list \
  --query "value[?pricingTier=='Standard'].name" -o tsv

# Ratchet it shut for the estate: assign the built-in DeployIfNotExists
# policies that turn each plan on for any subscription where it is missing.
# Servers (built-in 'Configure Azure Defender for servers to be enabled').
az policy assignment create \
  --name enable-defender-servers \
  --policy 8e86a5b6-b9bd-49d1-8e21-4bb8a0862222 \
  --scope "/providers/Microsoft.Management/managementGroups/contoso-root"

# Look up the matching Storage and SQL policies by display name rather than
# hard-coding a GUID, then assign each the same way at the same scope.
az policy definition list \
  --query "[?contains(displayName, 'Configure Microsoft Defender for Storage') || contains(displayName, 'Configure Azure Defender to be enabled on SQL servers')].{name:name, displayName:displayName}" \
  -o table