Compliance

Harden Azure SQL Database

One capability across Azure SQL Database and SQL Managed Instance: make sure every advanced threat protection type is switched on, so anomalous and malicious database activity, SQL injection, brute force, access from an unfamiliar principal, is detected and alerted rather than discovered after the fact.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-sql-mi-advanced-threat-protection-all-types azure-sql-server-advanced-threat-protection-all-types

Hardening Azure SQL: the basics

What does a SQL database with no threat detection actually look like?

An Azure SQL logical server and a SQL Managed Instance both hold some of the most sensitive data in a subscription, and both ship with Advanced Threat Protection switched off until someone turns it on. Advanced Threat Protection is the detection layer of Microsoft Defender for SQL: when it is enabled, the platform watches for a defined set of threat types, potential SQL injection, access from an unusual location or data centre, access from an unfamiliar principal or potentially harmful application, and brute force on SQL credentials, and raises a security alert when it sees one. When it is off, those same events happen silently. The data is still reachable, the credentials are still brute-forceable, the injection attempt still lands, but nothing tells you.

Microsoft Defender for Cloud turns this into a recommendation, 'All advanced threat protection types should be enabled in SQL server advanced data security settings', and a parallel one for SQL Managed Instance. The two read as separate findings because a logical server and a Managed Instance are different resource types, but they are the same job: make sure the threat detection is on, and on for every type, across every SQL resource in the estate. There is no partial-credit position here. A server with detection half-configured is a server where a real attack can slip through the gap.

Most of this is omission, not intent. A logical server provisioned before the team standardised on Defender for SQL, a Managed Instance spun up by a module that never set the plan, a subscription where the Defender for Azure SQL plan was simply never switched on. The work is to find every SQL server and Managed Instance where Advanced Threat Protection is not fully enabled, switch it on, and then enable the Defender for Azure SQL plan at the subscription level so that every database created from now on is covered automatically.

In this lesson you will learn what Advanced Threat Protection detects on Azure SQL Database and SQL Managed Instance, how to find every SQL resource where it is not fully enabled, and how to switch it on per resource and then guarantee coverage for the whole subscription with the Defender for Azure SQL plan. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The injection that announced itself

SQL injection has topped the list of web application risks for the better part of two decades, and the reason it persists is that a single unparameterised query can hand an attacker the contents of a database. Advanced Threat Protection on Azure SQL was built precisely to catch this class of attack as it happens: when it spots a query that carries the signature of an injection attempt, it raises an alert with the suspicious SQL statement and the source, often the first signal a team gets that an application has a hole in it. The detection is only useful, though, if it is switched on. On a server where Advanced Threat Protection was never enabled, that same injection attempt produces no alert at all.

Finding SQL servers with threat detection off

Priya is the security lead at a fintech preparing for a SOC 2 audit. Defender for Cloud shows advanced-threat-protection findings across several Azure SQL logical servers and a couple of Managed Instances that pre-date the team's current Defender baseline.

Rather than open each resource in the portal, Priya starts by querying which logical servers still have Advanced Threat Protection disabled, so the gap is a concrete list before anything is changed.

List every Azure SQL logical server and read back its Advanced Threat Protection state. Anything not 'Enabled' is running blind.

$ for s in $(az sql server list --query "[].{n:name,g:resourceGroup}" -o tsv); do n=$(echo $s | cut -f1); g=$(echo $s | cut -f2); st=$(az sql server advanced-threat-protection-setting show -g $g -n $n --query state -o tsv); echo "$n: $st"; done

sql-payments-prod: Disabled

sql-reporting-prod: Enabled

sql-legacy-eu: Disabled

# sql-payments-prod holds card data and has NO threat detection. Enable it first.

The state value is one of Enabled, Disabled or New. Any logical server or Managed Instance showing anything other than Enabled is a server where an injection or brute force attempt would raise no alert. Prioritise the ones holding sensitive data.

How Defender for Cloud decides SQL threat protection is missingdeep dive

The recommendation reads the Advanced Threat Protection setting on the resource. On a logical server this is the 'Microsoft.Sql/servers/advancedThreatProtectionSettings' resource named 'Default', and on a Managed Instance the equivalent under 'Microsoft.Sql/managedInstances'. Its 'state' property is one of three values: 'Enabled', 'Disabled', or 'New' for a resource where a state has never been applied. The recommendation is satisfied only when state is 'Enabled'; both 'Disabled' and the unset 'New' state count as a failure. The phrase 'all advanced threat protection types' is historical: earlier versions let you select a subset of threat types, so the control checks that detection is on for every type, not a chosen few. In the current model enabling Advanced Threat Protection enables the full set, which is why the modern goal is simply state 'Enabled'.

There is a layer above the per-resource setting. Microsoft Defender for SQL is a Defender for Cloud plan billed per protected resource. When you enable the Defender for Azure SQL plan at the subscription level, it automatically turns on Advanced Threat Protection and vulnerability assessment for every Azure SQL database in that subscription, including ones created later. The per-resource setting and the subscription plan are two views of the same capability: you can switch detection on one resource at a time, but the plan is what makes coverage automatic and durable.

One trap to avoid: there was a built-in Azure Policy, 'Advanced Threat Protection types should be set to All in SQL server Advanced Data Security settings', that audited this. It is deprecated and should not be assigned. The supported way to enforce the capability at scale is the Defender for Cloud plan, assigned through the built-in 'Configure Azure Defender to be enabled on SQL servers and SQL Managed Instances' policy or simply by enabling the plan on the subscription. Reaching for the old deprecated policy is a common and avoidable mistake. Note too that Defender for Cloud assesses against the Microsoft Cloud Security Benchmark on a periodic cycle, so the recommendation does not flip to Healthy the instant you enable detection; the control-plane change is immediate but the posture catches up on the next assessment, which matters when you are gathering audit evidence to a deadline.

What is the impact of leaving SQL threat protection off?

The direct impact is blindness to attacks aimed squarely at your data. With Advanced Threat Protection off, a SQL injection probe against an application, a brute force run against database credentials, access from an unfamiliar principal or an unusual data centre, and access patterns that look like exfiltration all happen without raising an alert. The events still occur; what is missing is the signal. The whole value of detection is shrinking the window between when an attack starts and when someone notices, and that window is effectively unbounded on a database where detection was never switched on.

The second-order impact is incident response that starts cold. When a breach is eventually discovered through some other channel, a customer report, a credential found for sale, the team has no alert trail to reconstruct what happened or when it began. Advanced Threat Protection alerts give an investigation a starting point: the suspicious statement, the source, the timestamp. Without them, scoping the breach is slower, more expensive, and far less certain, which directly increases the cost and duration of every notification and forensics obligation that follows.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that threats to data stores are actively monitored and detected, not just that access is controlled. A passing set of SQL advanced-threat-protection recommendations, backed by the Defender for Azure SQL plan across every subscription, is a clean and defensible artefact that detection is genuinely in place.

How do you enable SQL threat protection safely?

Work the capability as one loop rather than chasing individual findings. Enabling Advanced Threat Protection is a detection-only change: it adds monitoring and alerting and does not block, throttle or alter any query, so there is no risk of breaking a live application. The order is about coverage and cost, not safety.

1. Inventory every SQL resource by detection state

List every Azure SQL logical server and SQL Managed Instance and read back the Advanced Threat Protection state on each. Treat this inventory as the source of truth, not the Defender finding count, because logical servers and Managed Instances surface as separate recommendations even though they are the same capability.

2. Enable detection on the highest-value databases first

Set Advanced Threat Protection to Enabled on each resource, prioritising the servers and Managed Instances that hold the most sensitive data, payments, customer records, anything regulated. This is purely additive: detection switches on, nothing about the database's behaviour or availability changes.

3. Turn on the Defender for Azure SQL plan for the subscription

Enable the Defender for Azure SQL plan at the subscription level. This automatically enables Advanced Threat Protection and vulnerability assessment for every Azure SQL database in the subscription, including ones created later, so coverage becomes the default rather than a per-resource chore. It is also what carries the per-resource billing, so scope it deliberately.

4. Enforce it with policy, not the deprecated one

Assign the supported built-in policy that configures Defender for SQL on servers and Managed Instances so new subscriptions and resources inherit the plan. Do not assign the old 'Advanced Threat Protection types should be set to All' policy: it is deprecated. Configure the alert contact email and severity in Defender for Cloud so detections actually reach someone.

# 1. Enable Advanced Threat Protection on every logical server (detection only, no blocking).
for row in $(az sql server list --query "[].{n:name,g:resourceGroup}" -o tsv | tr '\t' ','); do
  n=$(echo "$row" | cut -d',' -f1); g=$(echo "$row" | cut -d',' -f2)
  az sql server advanced-threat-protection-setting update -g "$g" -n "$n" --state Enabled
  echo "$n: advanced threat protection enabled"
done

# 2. Same for every SQL Managed Instance.
for row in $(az sql mi list --query "[].{n:name,g:resourceGroup}" -o tsv | tr '\t' ','); do
  n=$(echo "$row" | cut -d',' -f1); g=$(echo "$row" | cut -d',' -f2)
  az sql mi advanced-threat-protection-setting update -g "$g" -n "$n" --state Enabled
done

# 3. Turn on the Defender for Azure SQL plan for the whole subscription so new
#    databases are covered automatically (this is what carries the per-resource cost).
az security pricing create -n SqlServers --tier Standard

# 4. Enforce at scale via the supported built-in policy (looked up by display name,
#    never a hardcoded GUID). Do NOT assign the deprecated 'set to All' policy.
pid=$(az policy definition list \
  --query "[?displayName=='Configure Azure Defender to be enabled on SQL servers and SQL Managed Instances'].name" -o tsv)
az policy assignment create \
  --name enable-defender-sql \
  --policy "$pid" \
  --scope "/subscriptions/<subscription-id>"

Quick quiz

Question 1 of 5

Defender for Cloud shows 'All advanced threat protection types should be enabled' on several Azure SQL servers and a Managed Instance. What is the most efficient way to think about them?

Keep learning

Go deeper on what Advanced Threat Protection detects on Azure SQL and how the Defender for SQL plan delivers it across the estate.

You can now treat Azure SQL threat detection as one capability rather than a scatter of findings: inventory every logical server and Managed Instance by detection state, enable Advanced Threat Protection on the highest-value databases first, turn on the Defender for Azure SQL plan so coverage is automatic for current and future databases, and enforce it with the supported policy rather than the deprecated one. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening Azure SQL: the cost and risk view

A small, predictable per-resource charge that buys detection of the attacks that hit databases hardest

Unlike most hardening controls, this one does carry a real and recurring Azure cost, and that is worth being honest about. Advanced Threat Protection is part of the Microsoft Defender for SQL plan, which is billed per protected resource, per node or vCore depending on the deployment, so enabling it across the estate adds a line to the bill that scales with the number of SQL servers and Managed Instances. It is not free in the way that disabling anonymous storage access is free.

What that spend buys is detection of the threats that target databases most directly: SQL injection, credential brute force, and exfiltration-shaped access patterns. Frame each failing recommendation as a database that is currently running blind, and weight it by the sensitivity of what it holds. A Managed Instance behind the customer-facing application carries a far higher expected loss when undetected than an internal reporting database, even though both surface as a single red finding.

The arithmetic still comes out one-sided, because the Defender for SQL charge is small and bounded against the documented cost of an undetected database breach: regulatory fines, breach notification, forensics, legal fees and customer churn. The finance job is to scope the spend honestly, prioritise the high-value databases first, and treat the plan cost as cheap insurance rather than an open-ended commitment.

This lesson is for the finance partner who sees SQL threat-protection findings on the security report and wants to know what enabling them costs and whether the spend is worth it. It covers why this control, unlike most hardening, carries a real per-resource Defender for SQL charge, how to scope that spend, and how to prioritise by the sensitivity of the data each database holds.

Fun fact

The injection that announced itself

How a finance partner frames the SQL threat-detection decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with seven SQL findings: five logical servers and two Managed Instances with Advanced Threat Protection off. Unlike the storage findings the team cleared last month, this one is not free. Advanced Threat Protection is part of the Defender for SQL plan, billed per protected resource, so enabling it across seven resources adds a real, recurring line to the bill. The question is not whether to spend, it is how to scope the spend so it lands where the risk is.

Priya asks the team to map each failing resource to the data behind it. The payments logical server and one Managed Instance hold cardholder data; two more servers hold customer records; the rest are internal reporting and staging. The list is reframed: the card-data and customer-data resources are enabled today, because an undetected attack on those is the highest expected loss in the estate and the per-resource Defender charge is trivial against it; the reporting and staging resources are enabled as part of the same plan because turning the plan on at the subscription level covers them automatically and the marginal cost is small. The finance pack reads: 'Defender for SQL is a bounded per-resource charge; we are scoping it across every SQL resource because the highest-value databases cannot be left without detection, and the subscription-level plan is the cheapest way to guarantee new databases are covered too.'

Why missing SQL threat detection belongs on the risk register

The cost model here is different from most hardening work, and finance should be the one to name the difference honestly. Enabling Advanced Threat Protection is not free: the Defender for SQL plan is billed per protected resource, so estate-wide coverage is a real recurring charge. But that charge is small and predictable, and what it offsets is the documented and unbounded cost of an undetected database breach. Each database without detection is a place where an attack could run for an unknown length of time before anyone notices, and the longer that window, the larger the eventual bill.

The documented cost of a database breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, regulatory penalties, and customer churn, and undetected breaches cost markedly more than ones caught early because the dwell time is longer. Against that, the Defender for SQL charge is cheap insurance. The finance role is to attach expected loss to each undetected database, weighted by the sensitivity of what it holds, so the plan is scoped to cover the highest-value data first and the spend is justified by risk rather than waved through or blocked wholesale.

What finance can do about the SQL detection gap

Finance cannot flip a detection setting, but it owns the framing that turns a row of red findings into a scoped, justified spend rather than either a blanket rejection or an unexamined approval. Three levers.

1. Name the cost honestly, then bound it

Unlike most hardening, this one is not free: the Defender for SQL plan is billed per protected resource. Make that explicit so nobody is surprised by the bill, but also bound it: the charge is per resource and predictable, not open-ended, and the subscription-level plan is the most efficient way to cover everything including future databases. Present it as a known recurring line item, scoped to the number of SQL resources, not as an unknown.

2. Order coverage by the sensitivity of the data, not by finding count

A logical server holding cardholder data and an internal reporting server both show as a single red finding, but the expected loss from an undetected attack differs by orders of magnitude. Ask the team to map each failing resource to the data behind it and to enable the highest-value databases first. The metric that belongs on the cost-and-security review is the count of undetected SQL resources weighted by data sensitivity, not the raw total.

3. Treat the plan cost as insurance against dwell time

The case for the spend is that undetected breaches cost far more than detected ones, because dwell time drives forensics, notification scope and regulatory exposure. Frame the Defender for SQL charge as buying down that dwell time on the assets that matter most. That reframes the conversation from 'can we avoid this cost?' to 'which databases can we afford to leave undetected?', which answers itself.

Quick quiz

Question 1 of 5

A security report shows seven SQL threat-protection findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on what Advanced Threat Protection detects on Azure SQL and how the Defender for SQL plan delivers it across the estate.

You have finished the finance view of hardening Azure SQL. You know this control, unlike most hardening, carries a real per-resource Defender for SQL charge, that the charge is bounded and predictable, and that it is cheap insurance against the far larger cost of an undetected database breach. Next time SQL threat-protection findings land, you will scope the plan honestly, order coverage by the sensitivity of the data each database holds, and frame the spend as buying down dwell time on the assets that matter most.

Back to the library

Hardening Azure SQL: the headline

Whether an attack on a database would be detected, or only discovered later

Databases are where the data the business actually cares about lives, and they are a primary target. The leadership question is simple: if someone attacked one of our databases tonight, a SQL injection probe, a brute force run against credentials, an access pattern that looks like exfiltration, would we know? With Advanced Threat Protection off, the answer is no, and the report shows that gap as a scatter of separate findings across SQL servers and Managed Instances.

The defensible end state is that Advanced Threat Protection is enabled for every type on every SQL resource, and that the Defender for Azure SQL plan is on at the subscription level so new databases are covered by default. That turns detection from something each team has to remember to switch on into something the platform guarantees.

This one is a cost decision as well as a governance one. The Defender for SQL plan is billed per resource, so enabling it estate-wide is a real, if modest, recurring spend. The trade is straightforward: a bounded, predictable charge against the unbounded cost of an attack on a database that nobody saw coming.

A short read for the leader who needs to know what Advanced Threat Protection actually detects, why running databases without it means an attack would go unseen, and what a defensible, plan-backed end state looks like across every SQL server and Managed Instance in the estate.

Fun fact

The injection that announced itself

What it looks like when an attack on a database is seen, not missed

After an industry peer disclosed a breach that began with a SQL injection nobody noticed for weeks, the CEO asked the obvious question at the next review: if that happened to one of our databases, would we see it? The honest answer at the time was that it depended on the database, because Advanced Threat Protection had been switched on by whichever team happened to remember, and several production servers had it off.

The team's response was to stop treating threat detection as a per-server afterthought and start treating it as a platform guarantee. They listed every logical server and Managed Instance, enabled Advanced Threat Protection on each, and then switched on the Defender for Azure SQL plan at the subscription level so that every database created from then on was covered by default, with no one having to remember. The next time the CEO asked, the answer had changed from 'on the important ones, we think' to 'yes, every SQL resource has detection on, and the plan guarantees new ones do too.' That shift, from detection-if-someone-remembered to detection-by-default, is the confidence signal this capability delivers, and it costs a modest, predictable Defender for SQL charge to reach.

Why this is a board-level risk

The breaches that do the most damage are rarely the ones caught quickly; they are the ones that ran undetected for weeks or months. Databases are the prize, and Advanced Threat Protection is the control that turns an attack on a database from something discovered later into something detected as it happens. Leaving it off on production databases is choosing not to look, on exactly the assets an attacker most wants to reach.

This is a cost decision as well as a governance one, and that is the honest framing for the board. The Defender for SQL plan is a modest, predictable recurring charge billed per resource. The trade is that bounded cost against the well-documented, far larger and far less predictable cost of a database breach that nobody saw coming. For the assets that hold the data the business depends on, that is a trade leadership should be quick to approve.

The leadership move on SQL threat detection

The executive handle is not to approve each server individually; it is to require that detection is on for every SQL resource and guaranteed for future ones by the subscription plan, and to accept the bounded cost that comes with it.

1. Approve the plan as scoped, recurring insurance

This control costs money, and that is the right call to make explicitly. Ask for the Defender for SQL plan scoped across the SQL estate as a bounded, recurring charge, and approve it on the basis that it buys detection on the assets an attacker most wants. The decision to make is not whether to spend but to confirm that no production database holding sensitive data is left without detection to save a small per-resource fee.

2. Require detection by default, not by memory

Ask for the Defender for Azure SQL plan enabled at the subscription level so every database, including ones created next quarter, is covered automatically. A plan that no individual team has to remember to switch on is the difference between detection on the databases someone thought of and detection on all of them. That is the governance outcome, not a one-time clean-up.

3. Ask for proof, and make sure alerts reach someone

The proof that this is closed is a passing set of SQL advanced-threat-protection recommendations across every subscription plus evidence the Defender for SQL plan is on, requested with lead time because Defender assesses on a cycle. Equally important: confirm the alert contact and severity are configured, because detection that fires into an inbox nobody watches is not detection at all.

Quick quiz

Question 1 of 5

At a board review you ask whether an attack on one of your databases would be detected. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on what Advanced Threat Protection detects on Azure SQL and how the Defender for SQL plan delivers it across the estate.

Two takeaways. This is one of the rare hardening controls that genuinely costs money, the Defender for SQL plan is billed per resource, but it is a modest, predictable charge against the unbounded cost of a database breach nobody detected. And the defensible end state is not 'detection on the databases we thought of'; it is Advanced Threat Protection on every SQL resource plus the Defender for Azure SQL plan enabled at the subscription level, so detection is guaranteed by default and proven by a passing posture, not by memory.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Azure SQL Database

All advanced threat protection types should be enabled in SQL server advanced data security settings Medium Disabling threat protection types leaves SQL injection and anomalous activity undetected on your servers

Azure SQL Managed Instance

All advanced threat protection types should be enabled in SQL managed instance advanced data security settings Medium Disabling threat protection types leaves SQL injection and anomalous activity undetected on managed instances

Part of the learning path Harden Azure workloads

Harden Azure SQL Database

Hardening Azure SQL: the basics

The injection that announced itself

Finding SQL servers with threat detection off

How Defender for Cloud decides SQL threat protection is missingdeep dive

What is the impact of leaving SQL threat protection off?

How do you enable SQL threat protection safely?

1. Inventory every SQL resource by detection state

2. Enable detection on the highest-value databases first

3. Turn on the Defender for Azure SQL plan for the subscription

4. Enforce it with policy, not the deprecated one

Quick quiz

Keep learning

Hardening Azure SQL: the cost and risk view

The injection that announced itself

How a finance partner frames the SQL threat-detection decision

Why missing SQL threat detection belongs on the risk register

What finance can do about the SQL detection gap

1. Name the cost honestly, then bound it

2. Order coverage by the sensitivity of the data, not by finding count

3. Treat the plan cost as insurance against dwell time

Quick quiz

Keep learning

Hardening Azure SQL: the headline

The injection that announced itself

What it looks like when an attack on a database is seen, not missed

Why this is a board-level risk

The leadership move on SQL threat detection

1. Approve the plan as scoped, recurring insurance

2. Require detection by default, not by memory

3. Ask for proof, and make sure alerts reach someone

Quick quiz

Keep learning

Controls this lesson covers

Azure SQL Database

Azure SQL Managed Instance

Related compliance lessons