Compliance

Enable Microsoft Defender for Cloud plans

One capability across Servers, Storage and Azure SQL: make sure the workloads that hold or run your data are actually being watched for threats, rather than left with the free posture tier that only scores configuration and never raises an alert.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Enabling Defender plans: the basics

What is actually switched off when a Defender plan is disabled?

Microsoft Defender for Cloud has two layers, and they are easy to confuse. The free layer is the posture tier, the secure score and the configuration recommendations that everyone sees the moment they open the portal. The paid layer is the set of Defender plans, one per resource type, and these are what actually detect threats and raise alerts at runtime. With the plans off, Defender will happily tell you a storage account allows anonymous access, but it will never tell you that someone is currently exfiltrating data from it. The recommendation 'Microsoft Defender for Servers should be enabled', and its siblings for Storage and Azure SQL, are Defender pointing at itself to say a whole class of workload has no active threat detection.

Each plan covers a different blast radius. Defender for Servers brings endpoint detection and response to your VMs through Microsoft Defender for Endpoint, plus agentless vulnerability scanning and, on the higher tier, just-in-time access and file integrity monitoring. Defender for Storage watches the data plane and control plane of every storage account for the signatures of a compromised account: a suspicious access pattern, an abused or leaked shared access signature token, or anomalous data access. Defender for Azure SQL adds vulnerability assessment and Advanced Threat Protection, surfacing SQL injection attempts and anomalous database access. Three plans, three of the highest-value targets in any subscription: the machines, the data stores and the databases.

Most of the time a plan is off because nobody turned it on. Defender plans are configured per subscription, and a subscription created outside the landing-zone blueprint, or one that pre-dates the team's current guardrails, simply never had them enabled. The work is to find every subscription where Servers, Storage or SQL is still on the free tier, decide the right plan and sub-plan for each, turn them on, and then enforce that any new subscription inherits the same coverage rather than relying on whoever creates it to remember.

In this lesson you will learn the difference between Defender for Cloud's free posture tier and its paid Defender plans, why three of those plans, Servers, Storage and Azure SQL, matter most, how to find every subscription where they are still off, and how to enable them at the right tier without an unexpected bill. The Controls this lesson covers section lists every Defender plan recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The free tier that watches nothing

A common and expensive misunderstanding is that opening Microsoft Defender for Cloud and seeing a secure score means the estate is being defended. It is not. The free tier scores configuration and nothing more: it has no agents on your VMs, watches no storage data plane, and inspects no SQL queries. Every active threat detection, every alert that says an attack is happening right now rather than that one could, lives behind a paid Defender plan. Plenty of organisations have discovered after an incident that the dashboard they trusted was only ever grading their homework, never standing guard.

Finding subscriptions with no active threat detection

Priya is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows 'Defender for X should be enabled' findings across several subscriptions that were created before the team adopted a landing-zone blueprint.

Rather than click into each subscription in the portal, Priya starts by listing the Defender plans per subscription, so she can see at a glance which workload types are still on the free tier and have no threat detection at all.

List the Defender plans for the current subscription. 'Free' means the posture tier only: no active threat detection on that resource type.

$ az security pricing list --query "value[?name=='VirtualMachines' || name=='StorageAccounts' || name=='SqlServers'].{plan:name, tier:pricingTier}" -o table

Plan Tier

--------------- --------

VirtualMachines Free

StorageAccounts Free

SqlServers Standard

# Servers and Storage have NO active threat detection here. SQL is covered.

'Free' is not a safe default: it means that resource type is unwatched. A subscription holding production VMs and data on the free tier is the highest-value target in this group.

How Defender for Cloud decides a plan is missingdeep dive

Defender plans are not a property of any individual VM, storage account or database. They are configured per subscription through the 'Microsoft.Security/pricings' resource, one entry per plan name: 'VirtualMachines' for Servers, 'StorageAccounts' for Storage, 'SqlServers' for Azure SQL. Each entry has a 'pricingTier' of either 'Free', the posture tier with no threat detection, or 'Standard', the paid plan that turns detection on for every supported resource of that type in the subscription, including ones created later. The recommendation fires whenever that tier is 'Free'. Because the setting is subscription-wide, one toggle protects every matching resource at once, which is why enablement scales so cleanly.

Some plans have a sub-plan that materially changes both coverage and cost. Defender for Servers offers Plan 1 and Plan 2: Plan 1 delivers the core Defender for Endpoint integration, while Plan 2 adds just-in-time VM access, file integrity monitoring, agentless vulnerability scanning and a free daily data ingestion allowance into Log Analytics. In Bicep or ARM this is the 'subPlan' property ('P1' or 'P2') on the 'VirtualMachines' pricing. Defender for Storage's current plan is per storage account and carries optional add-ons for malware scanning and sensitive-data threat detection. Choosing the tier and add-ons is the real decision; the recommendation only checks that you are above 'Free'.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so enabling a plan does not flip the recommendation to Healthy instantly. The control-plane change is immediate and protection begins right away, but the posture catches up on the next assessment. The strongest position pairs the per-subscription enablement with an Azure Policy 'DeployIfNotExists' or a landing-zone blueprint, so a newly created subscription has the plans turned on automatically rather than waiting for the next person to notice the finding. That is the difference between covering the subscriptions you have today and guaranteeing coverage on every subscription you will ever have.

What is the impact of leaving Defender plans off?

The direct impact is blindness on your highest-value workloads. With Defender for Servers off, a VM compromised through a stolen credential or an unpatched service has no endpoint detection watching it, so lateral movement, persistence and data staging happen unseen. With Defender for Storage off, an abused or leaked shared access signature token can drain a container and nothing flags the anomalous access pattern. With Defender for Azure SQL off, a SQL injection attempt or an anomalous query against a customer database raises no alert. The free tier will have told you these resources existed and scored their configuration; it will not tell you any of them is under attack.

The second-order impact is dwell time. Undetected intrusions are expensive precisely because they run for weeks. Active threat detection is what collapses the window between compromise and response from months to hours, and that window is the single biggest driver of breach cost. Every subscription left on the free tier is a place where an attacker can operate without tripping anything, and the cost of that scales with how long they go unnoticed.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA and PCI DSS, expects evidence not just of good configuration but of active monitoring and threat detection on systems handling sensitive data. 'We score our configuration' does not satisfy a control that asks for detection and response capability. A passing set of Defender plan recommendations across every subscription is the artefact that shows an auditor the estate is actually watched, not merely graded.

How do you enable the plans safely and predictably?

Treat this as one capability across every subscription, not a plan-by-plan scramble. The order matters: forecast the cost and choose the right tier before you enable, so the bill holds no surprises and the coverage is the one you intended.

1. Inventory which plans are off, per subscription

List the Defender plan tier for Servers, Storage and SQL across every subscription. Treat 'Free' as 'unwatched'. This inventory, not the raw finding count, is the source of truth, because one disabled plan on a busy subscription protects many resources once enabled.

2. Forecast the cost from a resource count

Count the protectable resources behind each off plan: VMs for Servers, storage accounts for Storage, SQL servers for Azure SQL. Multiply by the published per-resource rate to get a defensible monthly forecast before you enable anything. This is the step that turns a metered charge from a surprise into a budgeted line.

3. Choose the right tier and add-ons, then enable

Decide Servers Plan 1 versus Plan 2 (Plan 2 adds just-in-time access, file integrity monitoring and vulnerability scanning), and whether Storage needs the malware-scanning and sensitive-data add-ons. Then enable the plan per subscription. Enablement is immediate and protects every existing and future resource of that type in the subscription.

4. Make coverage the default for new subscriptions

Bake plan enablement into the landing-zone blueprint and assign an Azure Policy 'DeployIfNotExists' so any new subscription gets the plans turned on automatically. This is what stops the estate drifting back to gaps every time someone spins up a subscription outside the standard path.

# 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

Quick quiz

Question 1 of 5

Defender for Cloud shows a healthy secure score but 'Microsoft Defender for Servers should be enabled' is failing. What does that combination actually mean?

Keep learning

Go deeper on what each Defender plan in this capability protects and how to enable it at the right tier.

You can now treat Defender plan enablement as one capability rather than a scatter of findings: inventory which plans are on the free tier per subscription, forecast the metered cost from a resource count, enable Servers, Storage and SQL at the right tier, and make coverage the default for every new subscription with a blueprint and an Azure Policy. The Controls this lesson covers section below links every Defender plan recommendation in this group to its deep page and fix.

Back to the library

Enabling Defender plans: the cost and risk view

The one compliance capability in this category that genuinely does add to the Azure bill, and why it is still cheap insurance

Most Azure compliance fixes cost nothing in spend; this one is the exception, and it is worth being precise about why. Turning on a Defender plan is a metered Azure charge, billed per subscription against the resources it protects. Defender for Servers is charged per server per hour, with two plans at roughly 0.007 and 0.02 US dollars per server per hour. Defender for Storage on the current plan is charged per storage account, around 10 US dollars per account per month including a generous transaction allowance, with malware scanning and sensitive-data detection as paid add-ons. Defender for Azure SQL is charged per protected server, on the order of 15 US dollars per server per month. These are real, forecastable line items, not a rounding error and not a budget shock.

The right frame is insurance, priced against expected loss. A handful of dollars per server, per storage account and per SQL server buys active threat detection on exactly the resources where an undetected intrusion is most expensive. The plans surface as a single red finding each, so the spend question is narrow and answerable: count the protectable resources in each subscription, multiply by the published rate, and you have the annual cost to forecast before you switch anything on.

The arithmetic is the familiar security one but with a non-zero left-hand side. The cost is bounded and predictable. The downside of leaving the plans off is an intrusion that runs for weeks because nothing was watching, with the documented breach costs: regulatory fines, breach notification, forensics, legal fees and reputational damage. The finance role is to forecast the bounded cost honestly and weigh it against the unbounded one, not to treat a small recurring charge as a reason to leave the highest-value workloads unwatched.

This lesson is for the finance partner who sees 'Defender should be enabled' findings on the security report and, unlike most compliance fixes, needs to budget for the answer. It covers how each plan is metered, how to forecast the cost from a resource count before switching anything on, and why a small, predictable recurring charge is the right insurance against an unbounded breach cost.

Fun fact

The free tier that watches nothing

How a finance partner frames the Defender-plan decision

Priya is the finance partner supporting the platform team's ISO 27001 push. The security report lands with 'Defender for Servers, Storage and SQL should be enabled' across four older subscriptions. Unlike the storage-hardening findings on the same report, this one is not free to close, so the instinct is right: before approving anything, ask what enabling the plans will actually cost. Each plan is metered, so the answer comes from a resource count, not a guess. The team pulls the numbers: 60 production VMs across the four subscriptions, 25 storage accounts and 8 Azure SQL servers.

Priya turns that into a forecast in one pass. Defender for Servers at roughly 15 US dollars per server per month on the higher plan is about 900 US dollars a month for the VMs; Storage at roughly 10 US dollars per account is about 250; SQL at roughly 15 US dollars per server is about 120. Call it around 1,300 US dollars a month, a touch over 15,000 a year, to bring active threat detection to every production workload across the estate. The finance pack reads: 'This is the one compliance capability that adds to the bill. The number is bounded and forecastable at about 15k a year, it scales with the estate, and it is the price of having anything at all watch our most valuable workloads. The alternative is not a saving; it is running blind on the resources where a breach is most expensive.'

Why enabling Defender plans is the insurance line, not a discretionary spend

Unlike most security remediation in this category, this one has a real and recurring cost, so the temptation is to treat it as optional. The honest cost model says otherwise. The plans are metered per resource: per server per hour, per storage account per month, per SQL server per month. That makes the spend bounded and forecastable from a simple resource count, and it makes it scale sensibly with the estate rather than arriving as a surprise.

Against that bounded cost sits an unbounded one. The documented cost of a breach that ran undetected includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, regulatory penalties and customer churn, all amplified by dwell time, the very thing these plans exist to cut. The finance role is to forecast the plan cost precisely, present it as the insurance premium it is, and resist the framing that a small recurring charge is a reason to leave the most valuable workloads unwatched. Where budget pressure is real, the lever is choosing the right sub-plan, Servers Plan 1 versus Plan 2, and the optional Storage add-ons, not switching detection off entirely.

What finance can do about the Defender-plan gap

Finance cannot enable a plan, but it owns the framing that turns a metered charge from a budget objection into a forecasted insurance line. Three levers.

1. Forecast the cost before the decision, not after

Insist the team produces a per-subscription resource count, VMs, storage accounts and SQL servers, and multiplies it by the published rates before anything is switched on. A defensible annual forecast removes the single biggest objection to enablement, which is fear of an unknown bill. Once the number is on the page, the conversation moves from 'can we afford this?' to 'this is the premium, is it worth it?', which it almost always is.

2. Use the sub-plan and add-ons as the cost lever, not the off switch

When budget is genuinely tight, the right lever is tiering, not leaving detection off. Servers Plan 1 costs materially less than Plan 2 and still delivers core endpoint detection; Storage malware scanning and sensitive-data detection are optional add-ons that can be scoped to the accounts that warrant them. Make explicit that scaling the tier is a legitimate cost control, while disabling a plan entirely is accepting an unmonitored workload, which is a risk decision, not a cost one.

3. Track coverage as a metric, weighted by what is behind it

The number that belongs on the cost-and-security review is the percentage of high-value resources covered by an active Defender plan, weighted by sensitivity, not the raw finding count. A production database subscription on the free tier is a far bigger gap than an empty sandbox. Ask for coverage to be reported and trending towards complete, so the recurring spend is visibly buying down a measured risk rather than vanishing into the bill.

Quick quiz

Question 1 of 5

Unlike most compliance fixes on the report, enabling Defender plans is not free. As the finance partner, what is the right first step before approving it?

Keep learning

Go deeper on what each Defender plan in this capability protects and how to enable it at the right tier.

You have finished the finance view of enabling Defender plans. You know this is the one compliance capability that genuinely adds to the bill, that the cost is bounded and forecastable from a simple resource count, and that the lever for budget pressure is the sub-plan and add-ons, not the off switch. Next time the 'Defender should be enabled' findings land, you will produce the forecast first, present the spend as the insurance premium it is, and track coverage weighted by sensitivity rather than asking whether detection is worth paying for at all.

Back to the library

Enabling Defender plans: the headline

Whether anyone, or anything, is actually watching the estate for an attack in progress

Free configuration scoring tells you whether a door is unlocked. A Defender plan tells you whether someone is walking through it right now. With the plans off, the estate has the first and not the second: a tidy secure score and no active threat detection on the servers, data stores and databases that an attacker would actually target.

The leadership question is simple. If a workload is compromised tonight, does anything raise an alert, or does the intrusion run unseen until a customer or a regulator notices? The defensible end state is that Defender for Servers, Storage and SQL is enabled across every subscription, so detection follows every workload automatically rather than depending on whoever created the subscription remembering to turn it on.

This is the one capability in the compliance set that does cost money, and the number is small and predictable: dollars per server, per storage account and per database server, per month. The decision is not really a budget one. It is whether the organisation is prepared to run its most valuable workloads with no one watching them, to save a sum that is trivial next to the cost of a single undetected breach.

A short read for the leader who needs to know what is switched off when a Defender plan is disabled, why this is the one compliance capability that costs real money, and why the number is small enough that the decision is about whether the estate is watched at all, not about the budget.

Fun fact

The free tier that watches nothing

What it looks like when detection follows every workload, not just the ones someone remembered

After a peer company spent six weeks discovering that an intrusion had been quietly running in an Azure subscription that had no threat detection enabled, the CEO asked the obvious question at the next review: if that happened to us, would anything catch it? The honest answer at the time was that it depended on the subscription, because Defender plans had been turned on by whoever set each one up, and the older subscriptions had simply never had them.

The team's response was to stop treating Defender plans as a per-subscription afterthought and start treating them as a baseline. They listed every subscription where Servers, Storage or SQL was still on the free tier, enabled the right plan on each, and then set the enablement into the landing-zone blueprint and an Azure Policy so that any new subscription inherits full coverage automatically. The next time the CEO asked the question, the answer had changed from 'it depends which subscription' to 'yes, every server, data store and database in the estate has active threat detection, and any new subscription gets it by default.' That shift, from detection being something someone had to remember to switch on to something the platform guarantees, is the confidence signal this capability delivers. It is the one in the compliance set that costs real money, and the number is small and predictable next to what it protects against.

Why this is a board-level risk

Nearly every breach that became a prolonged, headline event shares a root cause: the intrusion ran for a long time because nothing was watching. Enabling Defender plans is the capability that puts active detection on the servers, data stores and databases where that scenario plays out, collapsing the dwell time that turns an incident into a catastrophe. It is the difference between finding out from your own alerts in hours and finding out from a regulator in months.

This is the one capability in the compliance set with a genuine recurring cost, and that makes leadership's role clear. The number is small, predictable and scales with the estate, a few dollars per server, per data store and per database per month. The cost of getting it wrong is an undetected breach. This is the rare control where the right move is simply to approve the bounded premium and require that detection follows every workload in the estate, with no subscription left running blind to save a trivial sum.

The leadership move on Defender plans

The executive handle is not to approve each subscription individually; it is to require that active threat detection follows every workload by default and that the bounded cost of doing so is treated as a premium, not a discretionary spend.

1. Approve the premium and set a coverage deadline

Ask for the forecast, approve the bounded cost, and set a date by which Servers, Storage and SQL are enabled across every subscription that holds production workloads. Because this is the one compliance capability that costs money, the leadership decision is to accept a small, predictable premium rather than to debate it line by line. The end state is full coverage, not a negotiated subset of subscriptions.

2. Require coverage to be the default, not a manual step

Enablement on today's subscriptions is necessary but not sufficient. Ask for the plans to be baked into the landing-zone blueprint and enforced by an Azure Policy so any new subscription inherits full coverage automatically. A backstop that turns detection on by default is the difference between watching the estate you have today and guaranteeing every future subscription is watched too.

3. Ask for proof of detection, not just enablement

The proof that this is closed is a passing set of Defender plan recommendations across every subscription plus evidence the enforcement policy is assigned. Because Defender for Cloud assesses on a periodic cycle, request that evidence with lead time before any audit deadline. The question to keep asking is not 'did we turn it on?' but 'if a workload is compromised tonight, would we know?'

Quick quiz

Question 1 of 5

At a board review you ask whether an undetected intrusion like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on what each Defender plan in this capability protects and how to enable it at the right tier.

Two takeaways. This is the rare compliance control with a real recurring cost, and the number is small and predictable next to the undetected breach it guards against, so the move is to approve the premium and require full coverage, not to negotiate it subscription by subscription. And the defensible end state is not 'we turned the plans on once'; it is enablement baked into the landing-zone blueprint and enforced by Azure Policy, so active threat detection follows every workload in the estate, today and on every subscription created tomorrow.

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.

Defender

Key Vault / Defender for Cloud

Microsoft Defender for Key Vault should be enabled High Without Defender for Key Vault, unusual or malicious attempts to access your secrets go undetected.

Microsoft Defender for APIs

Microsoft Defender for APIs should be enabled High Without the APIs plan you miss discovery, threat detection and attack alerts for your published APIs.

Microsoft Defender for Cloud

Part of the learning path Turn on Azure detection

Enable Microsoft Defender for Cloud plans

Enabling Defender plans: the basics

The free tier that watches nothing

Finding subscriptions with no active threat detection

How Defender for Cloud decides a plan is missingdeep dive

What is the impact of leaving Defender plans off?

How do you enable the plans safely and predictably?

1. Inventory which plans are off, per subscription

2. Forecast the cost from a resource count

3. Choose the right tier and add-ons, then enable

4. Make coverage the default for new subscriptions

Quick quiz

Keep learning

Enabling Defender plans: the cost and risk view

The free tier that watches nothing

How a finance partner frames the Defender-plan decision

Why enabling Defender plans is the insurance line, not a discretionary spend

What finance can do about the Defender-plan gap

1. Forecast the cost before the decision, not after

2. Use the sub-plan and add-ons as the cost lever, not the off switch

3. Track coverage as a metric, weighted by what is behind it

Quick quiz

Keep learning

Enabling Defender plans: the headline

The free tier that watches nothing

What it looks like when detection follows every workload, not just the ones someone remembered

Why this is a board-level risk

The leadership move on Defender plans

1. Approve the premium and set a coverage deadline

2. Require coverage to be the default, not a manual step

3. Ask for proof of detection, not just enablement

Quick quiz

Keep learning

Controls this lesson covers

Azure App Service

Azure Arc-enabled Kubernetes

Azure Kubernetes Service

Defender

Key Vault / Defender for Cloud

Microsoft Defender for APIs

Microsoft Defender for Cloud

Related compliance lessons