Defender for Azure SQL Not Enabled: Why It Matters and How to Fix It

Most teams put a lot of effort into hardening the network around their databases, locking down firewall rules, enforcing private endpoints, rotating credentials. Then they leave the database itself blind to attacks that get through anyway. Microsoft Defender for Azure SQL exists to close that gap, and this Lensix check tells you when it has been left off.

If you run any production data in Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure VMs, this is one of those low-effort, high-value protections worth turning on early.

---

What this check detects

The defender_azuresql check inspects the Microsoft Defender for Cloud pricing configuration on your subscription and reports whether the SqlServers plan is set to the Standard tier. When the plan sits at Free (the default), Defender for Azure SQL is effectively disabled and the check fails.

Defender for Azure SQL bundles two capabilities:

• Advanced Threat Protection (ATP) — detects anomalous activity such as SQL injection attempts, access from unusual locations, and brute force login patterns.
• Vulnerability Assessment — runs scans against your databases to surface misconfigurations, excessive permissions, and exposed sensitive data.

---

Why it matters

Network controls reduce the attack surface, but they do not catch what happens once a request reaches the database. Defender for Azure SQL is the layer that watches actual query behavior and login patterns.

SQL injection is still everywhere

SQL injection has been a known class of vulnerability for over two decades, and it still shows up in penetration tests and breach reports constantly. An attacker who finds an injectable parameter in your application can read, modify, or dump entire tables, and your firewall rules will happily let those queries through because they arrive over a legitimate, allowed connection. Defender's threat protection flags the abnormal query patterns that injection produces, giving you an alert instead of a silent breach.

Credential abuse and lateral movement

If an application connection string or SQL login leaks (through a compromised CI pipeline, an exposed config file, or a phished developer), an attacker can authenticate as a trusted user. Defender notices access from unfamiliar IP ranges, unusual data extraction volumes, and login attempts that do not match historical patterns. Without it, that access looks like business as usual.

The vulnerability assessment angle

Beyond live threats, the included vulnerability assessment scans surface things you might not know about: a database where Transparent Data Encryption was disabled, a login with excessive permissions, or a column holding what looks like personal data without the right controls. These findings are exactly the kind of slow-burning misconfiguration that turns a minor incident into a major one.

---

How to fix it

You can enable the plan through the Azure portal, the CLI, PowerShell, or infrastructure as code. Pick the one that fits how you manage Azure today.

Option 1: Azure CLI

Set the SqlServers plan to the Standard tier for the current subscription:

# Confirm which subscription you are targeting
az account show --query "{name:name, id:id}" -o table

# Enable Defender for Azure SQL (SqlServers plan)
az security pricing create -n SqlServers --tier Standard

There is also a related plan for SQL Server running on machines (VMs and Arc-enabled servers). If you run SQL Server on VMs, enable that one too:

az security pricing create -n SqlServerVirtualMachines --tier Standard

Verify the change:

az security pricing show -n SqlServers --query "pricingTier" -o tsv
# Expected output: Standard

Option 2: Azure portal

1. Open Microsoft Defender for Cloud in the Azure portal.
2. Go to Environment settings and select your subscription.
3. In the Defender plans list, find Databases.
4. Toggle the status to On, then expand it to confirm Azure SQL Databases and SQL servers on machines are enabled.
5. Click Save.

Option 3: PowerShell

Set-AzSecurityPricing -Name "SqlServers" -PricingTier "Standard"

Option 4: Terraform

If you manage Defender for Cloud as code, this is the cleanest place to set it so it never drifts back to Free:

resource "azurerm_security_center_subscription_pricing" "sql_servers" {
  tier          = "Standard"
  resource_type = "SqlServers"
}

resource "azurerm_security_center_subscription_pricing" "sql_vms" {
  tier          = "Standard"
  resource_type = "SqlServerVirtualMachines"
}

Configure where alerts go

Enabling the plan is only useful if someone sees the alerts. Make sure email notifications are configured so security contacts get notified:

az security contact create \
  --name default \
  --email "[email protected]" \
  --alert-notifications On \
  --alerts-admins On

---

How to prevent it from coming back

Enabling the plan manually fixes one subscription today. New subscriptions, and people clicking toggles, will undo it tomorrow. Treat the configuration as something you enforce, not something you set once.

Use Azure Policy to enforce it

Azure has a built-in policy that configures Defender for SQL automatically. Assign it at the management group level so it applies to every subscription, including ones created in the future:

# Built-in policy: Configure Azure Defender for SQL servers to be enabled
az policy assignment create \
  --name "enable-defender-sql" \
  --display-name "Enable Defender for Azure SQL" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/b99b73e7-074b-4089-9395-b7236f094491" \
  --scope "/providers/Microsoft.Management/managementGroups/your-mg-id" \
  --location eastus \
  --mi-system-assigned \
  --role Contributor

With a DeployIfNotExists policy in place, any subscription that drifts back to Free gets remediated by a policy assignment instead of waiting for a human to notice.

Gate it in CI/CD

If your subscriptions are provisioned through Terraform or Bicep, add the Defender pricing resource to your baseline module so every new environment ships with it enabled. Then run a check in your pipeline that fails the build if the plan is missing. A quick CLI assertion works as a guardrail:

tier=$(az security pricing show -n SqlServers --query "pricingTier" -o tsv)
if [ "$tier" != "Standard" ]; then
  echo "Defender for Azure SQL is not enabled. Failing build."
  exit 1
fi

Keep it monitored

Continuous scanning is the real safety net. Lensix re-runs the defender_azuresql check on a schedule, so if someone disables the plan during a cost-cutting exercise or a misfired script, you get told before an auditor or an attacker finds it first.

---

Best practices

• Enable it across all subscriptions, not just production. Dev and test databases often hold copies of real data and are softer targets. Apply the policy at the management group level.
• Act on vulnerability assessment findings. The scans only help if you triage the results. Set a baseline so expected findings are suppressed and new ones stand out.
• Pair it with auditing. Enable SQL auditing to a Log Analytics workspace so you have the query-level forensic trail to investigate a Defender alert.
• Confirm alert routing during onboarding. A new subscription with Defender enabled but no security contact configured produces alerts that go nowhere.
• Layer your defenses. Defender for SQL complements, it does not replace, private endpoints, least-privilege logins, TDE, and Microsoft Entra authentication. Each layer catches what the others miss.

The cheapest breach to handle is the one your monitoring caught at the alert stage. Defender for Azure SQL turns silent database compromise into a notification, and that difference is usually measured in days of dwell time.

Turning on this plan takes one command. The payoff is visibility into a part of your stack that network controls cannot see. Run the fix, enforce it with policy, and let continuous scanning keep it that way.