Microsoft Defender for Azure Cosmos DB should be enabled

What does the recommendation "Microsoft Defender for Azure Cosmos DB should be enabled" check?

Flags any subscription where the Defender for Azure Cosmos DB plan is not switched on, so no Cosmos DB account in the subscription is getting threat detection alerts. The plan is a subscription-level toggle inside the Defender for Databases bundle, not a per-account setting, so a single 'Off' covers every existing and future account at once. It checks that the plan is enabled, not that any individual alert has fired or been triaged, and it does not assess network rules, firewall scope, RBAC or encryption: those are covered by separate controls. Note the scope is narrow at the data-plane level, Defender for Azure Cosmos DB currently inspects activity on the NoSQL (Core) API only, so accounts using the MongoDB, Cassandra, Gremlin or Table APIs satisfy the plan toggle but receive no behavioural alerts.

Why does "Microsoft Defender for Azure Cosmos DB should be enabled" matter?

Cosmos DB often holds the application's primary operational data: customer records, sessions, order history. Without the Defender plan there is nothing watching the data plane for the patterns that precede a breach: SQL injection attempts, access from a Tor exit node or an anomalous geography, a spike in document reads that looks like bulk exfiltration, or a key suddenly used from an unfamiliar principal. These are exactly the signals that turn a leaked connection string or stolen key into a quiet, undetected dump of your database. Enabling the plan gives the security team alerts in Defender for Cloud the moment that activity starts, which is the difference between responding in minutes and learning about the loss from a third party weeks later.

How do I fix "Microsoft Defender for Azure Cosmos DB should be enabled"?

1. Enable the plan at the subscription level: 'az security pricing create -n CosmosDbs --tier standard'. This turns on Defender for Azure Cosmos DB for every account in the subscription, including ones created later. In the portal the equivalent is Defender for Cloud, Environment settings, the subscription, Defender plans, Databases, Select types, Azure Cosmos DB set to On.
2. To enforce it across many subscriptions without hand-toggling each one, assign the built-in DeployIfNotExists policy by its exact display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Configure Microsoft Defender for Azure Cosmos DB to be enabled'].name" -o tsv); az policy assignment create --name enable-defender-cosmos --policy "$pid" --scope <management-group-or-subscription-id> --location <region> --identity-scope <scope> --role Contributor.
3. Confirm alerts will actually reach someone: under Defender for Cloud, Environment settings, Email notifications, set the recipients and minimum severity so a high-severity Cosmos DB alert pages the right team instead of sitting unread in the portal.

# 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