Microsoft Defender for Azure SQL Database servers should be enabled

What does the recommendation "Microsoft Defender for Azure SQL Database servers should be enabled" check?

Flags any Azure SQL logical server where the Microsoft Defender for Azure SQL Databases plan is not enabled. With it on, the server gets threat detection alerts (for example SQL injection, brute-force and anomalous logins, and suspicious bulk data exfiltration) plus a recurring vulnerability assessment scan that compares the database configuration against a security baseline. This single plan (the 'SqlServers' pricing tier) protects Azure SQL Database single databases and elastic pools, Azure SQL Managed Instance, and Azure Synapse Analytics dedicated SQL pools together: enabling it once at the subscription level covers all of them, so SQL Managed Instance and Synapse are not separate recommendations you must enable independently. What it does not cover is SQL Server running on Azure VMs or Azure Arc (the separate 'SQL servers on machines' plan) and open-source database services such as PostgreSQL or MySQL, each of which has its own plan.

Why does "Microsoft Defender for Azure SQL Database servers should be enabled" matter?

An Azure SQL server usually holds the records that matter most: customer identities, orders, financials. Without Defender, a credential-stuffing attack, an injection payload smuggled through your application, or a bulk export by a compromised account all happen silently, and you typically only learn of the breach when the data surfaces somewhere else. Enabling the plan turns those events into actionable alerts and surfaces exploitable weaknesses, stale permissions and missing baselines before an attacker finds them. In practice that is often the difference between a contained incident closed in an afternoon and a reportable breach that triggers customer notifications, regulatory fines and lasting reputational damage.

How do I fix "Microsoft Defender for Azure SQL Database servers should be enabled"?

1. Enable the Defender for Azure SQL Databases plan: in Defender for Cloud open Environment settings, select the subscription, and switch the Azure SQL Databases plan on (this single toggle covers every Azure SQL Database server, SQL Managed Instance, and Synapse dedicated SQL pool in the subscription), or scope it to one server from the server's Microsoft Defender for Cloud blade. Via CLI run 'az security pricing create -n SqlServers --tier standard'.
2. Configure the vulnerability assessment so its scans have somewhere to run. Prefer the express configuration, which needs no storage account; if you must use the classic mode, set a storage account in the server's Defender settings so the periodic baseline scans can run and results can be compared over time.
3. Confirm alerts actually reach a person: under Defender for Cloud email notifications, set security contact addresses and enable notifications to subscription owners, so a high-severity detection at 2am does not sit unread in the portal. Decide who triages SQL alerts before you turn the plan on, not after the first one fires.

# 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