Why this matters
Azure workloads change without much warning. A pipeline rebuilds a container image, a developer opens a public IP, and a VM picks up an old package from a base image. Microsoft Defender for Cloud puts those changes in one view, pairing misconfiguration checks with software vulnerability findings. Most real incidents start with a known weakness that nobody owned.
Defender for Cloud has two layers. Foundational CSPM is the free posture layer. It flags public storage, weak network rules, and identity problems. Paid Defender plans add workload protection: vulnerability assessment for servers, container image scanning, SQL assessment, and threat detection for App Service and storage. With only the free layer, you see recommendations but not package level findings on machines.
Noise is the main failure mode. A new subscription can produce hundreds of findings, many on test resources or duplicate paths. Rank by reachability and privilege. An old library on an internet facing VM with a contributor role matters more than a medium finding on an isolated lab box.
Before you start
Get the role right. You need Security Admin or Owner at the scope where you enable plans, and Reader on the subscriptions you review. At a management group, confirm inherited permissions cover every subscription. Remove standing access when the rollout ends.
Pick a Log Analytics workspace before you turn on auto provisioning. Defender for Servers can write findings and alerts to a central workspace, and changing that later loses history. Choose a region near the workloads, set retention, and decide who can read the workspace. Reuse your Azure Monitor workspace instead of letting Defender create a default one per subscription.
List subscriptions by environment, tag each resource with an owner, and set a severity threshold for tickets. Set the security contact email so high severity alerts reach a real inbox. Plan the webhook or Logic Apps flow to your tracker now. Scanning without a route to a fix is just a report.
How to do it
In Microsoft Defender for Cloud, open Environment settings and select the management group or subscription. Turn on Defender CSPM for posture and attack path analysis. Turn on Defender for Servers Plan 2 if you need agentless scanning and file integrity monitoring. Add Defender for Containers, SQL, App Service, or Storage only where you run those services. A pilot on one subscription beats a broad switch.
Open Auto provisioning and connect your workspace. Turn on the Azure Monitor Agent and the Microsoft Defender for Endpoint extension for servers. With Plan 2, enable agentless scanning so snapshots cover VMs that cannot take an agent. For containers, let Defender read Azure Container Registry and deploy the Kubernetes sensor to AKS. Check that auto provisioning shows healthy, not just enabled.
Triage with attack path analysis and cloud security explorer. Filter to internet exposed resources and high privilege identities. Use Quick fix for policy backed items such as public blob access or minimum TLS. For package findings, patch the VM or rebuild the image from a clean base. Export recommendations and alerts through continuous export to Log Analytics or Event Hub so ticketing sees the same data.
- Choose the pilot scope. Pick one management group or a small set of subscriptions. Confirm you have Security Admin or Owner at that scope and Reader on each subscription. Write down the resource owners before you enable anything.
- Turn on the right Defender plans. In Environment settings, enable Defender CSPM and Defender for Servers Plan 2 for the pilot. Add Containers, SQL, App Service, or Storage only where those workloads run.
- Connect a workspace. Open Auto provisioning and point Defender for Servers at your central Log Analytics workspace. Set retention and access before the first agent registers.
- Cover machines with both scan types. Enable the Azure Monitor Agent and Defender for Endpoint extension. Turn on agentless scanning for machines so snapshots cover VMs that cannot take an agent.
- Scan containers and data services. Let Defender for Containers read Azure Container Registry and deploy the sensor to AKS clusters. Run SQL vulnerability assessment and review storage public access settings.
- Triage by attack path. Open Recommendations and filter to internet exposed resources with high privilege identities. Clear those first, then move to medium findings in production.
- Export and review coverage. Turn on continuous export to Log Analytics or Event Hub. Connect high severity alerts to email and your ticketing tool, then check agent status and scan freshness each week.
How to check it worked
Open Environment settings and confirm each plan is on for the right scope. In Inventory, filter by machine and check agent status. A machine with no agent and no agentless scan is not covered. In Recommendations, confirm vulnerability findings have a fresh scan time. For containers, check registry images for a scan date. An image with no result is unscanned, not clean.
Run a small test in a nonproduction subscription. Create a VM from an old image or remove a required patch, wait for the scan cycle, and confirm the finding appears. Apply the fix, wait again, and confirm it clears. Do the same for one container image with an outdated base layer. This shows how long each stage takes.
Check the flow outside the portal. Confirm high severity alerts reach the security contact. Create a ticket from one finding and follow it to closure. Query Log Analytics for recent recommendations and alerts grouped by severity and resource group. If the query returns nothing, the export or workspace link is wrong. A subscription with zero findings often has no coverage.
Mistakes to avoid
Turning on every plan across every subscription on day one creates cost and noise before owners exist. Pilot one subscription or management group, learn the findings, then expand with Azure Policy. Use policy to enforce auto provisioning and approved regions, but exempt legacy subscriptions with a named owner and expiry. Broad rollouts fail when nobody knows who fixes the storage account.
Treating agentless scanning as real time is a common error. Agentless scanning reads disk snapshots on a schedule, often daily, so a patch deployed at noon may not clear until the next cycle. Agent based assessment gives faster and deeper software inventory. Use agentless for machines you cannot touch and the agent where you need current data. A clean dashboard is not proof of a clean machine.
Chasing secure score without reading findings is another trap. Score is an aggregate, and exemptions can raise it while risk stays put. Review attack paths, internet exposure, and privileged identities first. When you suppress a finding, record why, set an expiry, and name the owner. A permanent suppression with no note is a hidden vulnerability.
Forgetting identity and network exposure leaves gaps. Many Azure problems are over broad role assignments, public endpoints, open management ports, and anonymous storage access. Review those recommendations next to software findings. Patch management and vulnerability scanning are related, not the same job. If you want an outside read before a customer security review, the Cloud security review package from Cloudverg is $6,500/month and covers up to five cloud accounts or subscriptions.
Frequently asked questions
Does Microsoft Defender for Cloud scan Azure VMs without an agent?
Yes, with agentless scanning in Defender for Servers Plan 2. It reads disk snapshots on a schedule and finds installed software and vulnerabilities. Agent based assessment gives faster updates and deeper inventory, so many teams run both.
What is the difference between secure score and vulnerability findings?
Secure score summarizes how well resources follow recommendations. Vulnerability findings name specific software flaws on a machine or image. Fixing a flaw can raise the score, but a high score does not prove that no exploitable package is present. Use attack path analysis to judge reachability.
Can Defender for Cloud scan container images in Azure Container Registry?
Yes, Defender for Containers scans images in Azure Container Registry when they are pushed and on a schedule. It also checks running AKS clusters for image and configuration issues. Confirm the registry connection and scan dates before you trust an empty result.