Secure Score went up six points. Leadership celebrated. The hub still had three standing Owners, and a storage account in prod accepted key access from the Internet. The score did not lie. It measured something else.

Microsoft Defender for Cloud is useful when you treat recommendations as a backlog owned by platform and workload. It is not a trophy.

This is article two of Series 3. Article one threat modeled the control plane. Policy already decided what Deny means in your landing zone. Defender is residual signal: misconfigurations that escaped the module, drifted after a portal click, or need a human judgment call.

What Defender actually is in a landing zone

Defender for Cloud is two jobs sharing a portal blade.

Cloud security posture management (CSPM) watches configuration. Recommendations, Secure Score, regulatory compliance dashboards that map to frameworks like the Microsoft Cloud Security Benchmark (MCSB) and CIS Azure Foundations. Much of that posture work is powered by Azure Policy under the covers.

Cloud workload protection (CWPP) is the paid Defender plans on resource types: Servers, Storage, Key Vault, App Service, Containers, Databases, Resource Manager, DNS, and others as your estate grows. Those plans add threat detection, malware scanning where applicable, and deeper signals. They also add invoice lines and alert volume.

If you enable every plan on day one and ignore the queue, you train the whole org to dismiss alerts. If you enable nothing and claim “we use Defender” because the free CSPM blade is open, the auditor will notice.

Turn on what you will operate

Start from the subscriptions you vend and the resource types your spoke module creates.

Platform subscriptions and the hub usually need:

• Defender for Resource Manager if you want control-plane operation anomalies on management plane activity
• Defender CSPM (foundational posture) on by default for recommendations
• Plans that match hub resources you actually run: Key Vault if the platform vault sits here, Storage if the state account does, Servers only if you still run jump boxes you admit to

Workload subscriptions get plans tied to the reference spoke:

• App Service / Functions patterns → Defender for App Service
• SQL / open-source DB → corresponding database plans when you will triage findings
• Storage accounts with data worth protecting → Defender for Storage
• Key Vault per app → Defender for Key Vault
• AKS arrives in Series 4 → Containers plan when the cluster is a platform product, not a science project

Write the enablement in Terraform or policy so a newly vended subscription does not wait for a portal click. Cost already taught you that optional platform features become surprise invoices. Defender plans are the same shape: decide per management group, not per enthusiastic engineer.

Platform-owned vs workload-owned recommendations

Split ownership the same way Series 2 split the spoke contract.

Platform owns recommendations that span many subscriptions or live on shared assets:

• Missing diagnostic settings on hub firewall, DNS, or the central workspace path
• Management group policy gaps that MCSB expects and your initiative never assigned
• Insecure defaults in the spoke module (public network access left optional, key access on by default)
• Identity recommendations that point at standing privileged roles or over-permissioned service principals on the platform identity
• Defender pricing tier not enabled on subscriptions the landing zone creates, when that was a standard

Workload owns recommendations inside their subscription that the app team can fix without hub rights:

• Unhealthy resources they deployed
• SQL or storage settings they requested as exemptions
• Open management ports on VMs they still run
• Code and container image issues once Containers is in scope
• Missing encryption or TLS settings on PaaS they chose

If platform tries to remediate every workload recommendation, you become the app team with a security badge. If platform ignores hub recommendations because Secure Score “looks fine,” the score is cosplay.

Secure Score is a trend, not a bonus KPI

Secure Score is a weighted rollup of unresolved recommendations. It is good for spotting direction. It is a bad employee scorecard.

Problems with binding bonuses to a single tenant-wide number:

• One busy app team can tank the score while platform hygiene is excellent
• Disabling a plan or exempting resources can inflate the score without reducing risk
• Quick wins (easy recommendations) get chased while hard control-plane items sit

Track these instead on a weekly platform ritual:

1. Open Critical and High recommendations on platform subscriptions and the hub resource groups
2. Age of the oldest platform Critical item
3. Time-to-remediate for platform-owned items closed that week
4. New recommendations introduced by the last spoke module change

Publish the workload Critical list to Owner tags the same way budgets page owners. Do not paste a tenant Secure Score screenshot into the QBR and call it governance.

Governance with Policy first, Defender second

Many Defender recommendations map directly to Azure Policy definitions. MCSB is available as a built-in initiative. CIS Azure Foundations is available as a built-in initiative. Your landing zone should already assign a curated initiative at the management group, not wait for someone to click “Assign” inside the Defender regulatory compliance blade for every subscription.

Preferred order:

1. Decide the control in architecture (no public blob access in prod, purge protection on Key Vault, diagnostics on hub)
2. Encode it in the spoke/hub module so new resources are born compliant
3. Assign Deny or DeployIfNotExists at the management group for the controls you will defend
4. Use Defender recommendations for residual drift, preview controls, and threat detections Policy cannot express

Defender then becomes the signal for what escaped. Policy is what prevents the next escape. Policy already covered Audit-then-Deny. Defender is not a substitute for that path. It is how you notice when Audit was never flipped.

Recommendations that are really module bugs

When the same High recommendation appears on every new spoke, stop filing fifty tickets. Fix the module.

Examples that keep showing up in real estates:

• Storage accounts created with allowBlobPublicAccess left to the provider default
• Key Vaults without purge protection in prod management groups
• Missing diagnostic settings because the module “will add monitoring later”
• NSGs with overly permissive rules baked into a “temporary” sample

Remediate existing resources once. Change the module. Add a regression check in the secure SDLC article’s PR gates. Defender should go quiet on that finding for new subscriptions. If it does not, your apply path is still losing to the portal.

Alerts are not recommendations

Recommendations are posture. Security alerts are detections: suspicious Resource Manager operations, unusual Key Vault access, malware on a server plan, anomalous storage access when Defender for Storage is on.

Own them differently:

• Recommendations → backlog, SLA by severity, owner by platform vs workload
• Alerts → incident process (article eight), enrichment with logging and identity context, suppression only with expiry and justification

Suppressing alerts to protect Secure Score is backwards. Secure Score barely cares about your alert fatigue. Your on-call does.

Export or lose history

Portal views are not evidence. Subscriptions move. Management groups get renamed. People screenshot the wrong scope.

Turn on continuous export of Defender recommendations and security alerts to Log Analytics or Event Hub. Prefer the same platform workspace design you already fought for in logging, or a dedicated security workspace with clear retention and who pays for ingestion.

You need export for three reasons:

1. Article three’s continuous evidence pack (ARG plus historical recommendation state)
2. Sentinel or custom detections that join Defender alerts with AzureActivity and Sign-in logs
3. Audit season when someone asks what was open last Tuesday

Security teams that live only in the Defender portal will rebuild history from memory. Memory fails audit week.

A weekly operating rhythm that fits on one page

Monday thirty minutes. Same agenda every week.

1. New Critical/High on platform scope since last week
2. Recommendations that repeated across spokes (module fix candidates)
3. Open alerts in investigation or waiting on identity
4. Plans or pricing changes that would affect next month’s invoice
5. One exemption or suppression that should have expired

Assign actions with names. Close the meeting with the oldest Critical item still open and why.

If that meeting keeps getting canceled for “delivery work,” Secure Score will still move. Your control plane will not.

How this connects to MCSB and CIS

Defender’s regulatory compliance experience surfaces MCSB and CIS assessments. Those assessments are useful conversation starters with auditors. They are not a substitute for your control-to-artifact map.

Use Defender to see which MCSB controls are unhealthy in Azure terms. Use your git-hosted map (next article) to say which Azure Policy assignment, ARG query, and log prove each control you claim. When the two disagree, believe the query and the assignment IDs, then fix the dashboard expectations.

MCSB is Microsoft’s native benchmark for Azure and multi-cloud posture. CIS Azure Foundations is often what external auditors bring in their binder. Overlap is large. Maintain one remediation backlog. Tag work items with both IDs when both apply. Do not run two unrelated Secure Score chase programs that fight each other for engineer time.

Remediation that does not thrash the estate

Bulk “fix” from the portal feels productive. It also creates changes nobody can find in git.

Rules for remediation:

1. Prefer fixing the module and letting new resources be born clean
2. For existing platform resources, remediate through a PR when Terraform owns the resource
3. Use Policy remediation tasks for DINE assignments you already trust, and record the task ID on the ticket
4. Avoid clicking Fix on a recommendation that would open network access or weaken encryption “to restore connectivity”
5. Re-run ARG after remediation so continuous evidence shows the before/after

Workload remediations go to the Owner with a due date and a link to the recommendation. Platform does not silently change app SKUs to clear a score.

Cost and coverage conversations with finance

Defender plans show up on the invoice. Finance will ask why. Answer with the resource types you protect and the alerts you actually triage. “We turned everything on” is not a FinOps answer and it is not a security answer.

Pair plan enablement with the Series 5 cost conversation when you get there: which subscriptions carry which plans, which cost center pays, and what you disable when a management group is decommissioned. Orphaned Defender plans on abandoned subscriptions are how security tooling becomes unexplained spend.

Next: Continuous Evidence. MCSB and CIS mapped to Policy, Resource Graph, and exports that survive auditor rotation.

Randy Bordeaux

Azure Trainer | Veteran | Engineer

Helping IT professionals grow through cloud, leadership, and shared knowledge.