Defender for Cloud: cutting through the noise

Defender for Cloud is two things: a CSPM (posture management — recommendations, secure score) and a CWPP (workload protection — threat detection on running workloads). Both are useful. Both will drown you in noise if you don't impose structure.

Here's how I get value out of Defender without making the security team's life miserable.

Start with secure score, but ignore the percentage

Secure Score is a useful guide for what to fix. It's a terrible KPI for how secure you are. I've seen teams chase 90% by enabling random low-impact controls and gaming the score, while real risks went unaddressed.

Use it as a checklist of recommendations, ranked by impact. Ignore the headline percentage.

Prioritize recommendations using two filters

Defender returns hundreds of recommendations. Two filters narrow the list to what actually matters:

Severity = High AND has-quick-fix = false. These are the real configuration mistakes — public storage, unencrypted DBs, NSGs allowing internet inbound on management ports. They're worth a ticket.
Recommendations that are part of an active attack path. Defender's attack paths feature traces multi-step attacker scenarios across your assets. A medium-severity finding inside a high-severity attack path matters more than a high-severity finding sitting in isolation.

If a recommendation isn't either of these, deprioritize ruthlessly.

Configure exemptions thoughtfully

Some recommendations don't apply to your environment. Don't leave them as red findings forever — they pollute the dashboard and dilute trust.

Use Defender's Exemption feature, which records:

The reason (Mitigated, Risk Accepted, Waiver).
The expiration date — never permanent. Force re-review.
The exemption scope — narrow as possible.

If you accept a risk, accept it explicitly with an expiration. "We'll fix it later" without a date in writing is not risk acceptance.

Tame the alerts (CWPP side)

The Defender for [Servers / Storage / Containers / etc.] plans generate alerts on suspicious activity. The defaults are noisy.

Three steps to make them useful:

1. Suppress alerts you've decided are noise. Don't ignore — actively suppress with a reason. Suppression rules can scope by resource, alert type, IP, etc.

2. Route alerts somewhere appropriate. Don't dump them all in a SOC inbox. I split:

High-severity alerts on production resources → PagerDuty / on-call.
High-severity alerts on non-prod → Slack channel with daily review.
Medium/low → weekly digest report.

3. Tune detection rules where Defender lets you. Some plans allow customization (suppress specific user agents, allowlist known scanners). Use it.

Hook into Sentinel — but think about it first

The "Defender for Cloud + Sentinel" pattern is common: stream all Defender alerts into Sentinel, build incident response there.

Worth doing if:

You already use Sentinel for other sources.
You have a SOC team that lives in Sentinel.
You want to correlate Defender findings with Entra ID risk events, sign-ins, etc.

Skip if:

You don't have a SOC and Defender's native alerts go to email anyway.
You're early-stage and just trying to get the basics right.

What I always enable

Even on small subscriptions:

Defender for Cloud (free CSPM tier) — $0, just turn it on.
Defender for Servers if you have any VMs.
Defender for Storage for any storage accounts holding sensitive data.
Defender for Key Vault — cheap, catches malicious secret enumeration.
Defender for Resource Manager — catches anomalous control plane activity.

What I usually skip

Defender for App Service unless you have many App Service plans handling sensitive data — it duplicates what App Service's own monitoring catches.
Defender for SQL if you've already got Azure SQL's built-in security features (Advanced Threat Protection) covering the same cases.

Closing thought

Defender's value isn't in seeing the long list of recommendations. It's in actively maintaining a tight, prioritized list and closing the loop — fixing or formally accepting each finding. A team that closes 5 high-severity findings per week is in much better shape than a team with 200 findings sitting open.

Treat Defender like a backlog, not a dashboard.