Microsoft Defender for Cloud: From Licensed to Operational
Every Azure tenant we inherit has Microsoft Defender for Cloud switched on. Almost none of them have it actually doing anything. The plans are toggled, the compliance dashboard is green-ish, and nobody has looked at the Recommendations blade in six months. Meanwhile the Security Score is sitting at 41% and the SOC is triaging alerts from a completely separate tool.
That is the real problem: Defender for Cloud is a platform, not a product you turn on. What follows is how we actually operationalize it.
What You Are Buying When You Enable the Plans
Defender for Cloud runs two distinct surfaces, and conflating them is why most deployments stall.
The first surface is CSPM, Cloud Security Posture Management. This covers your control plane: are your storage accounts publicly accessible, are your VMs missing endpoint protection, does your AKS cluster have the API server locked down. The free tier gives you basic CSPM. Defender CSPM (paid) adds attack path analysis, agentless scanning, and the governance engine that lets you assign remediation owners with SLA timers. Attack path analysis is the one feature that changes the conversation with a CISO because it shows a lateral-movement chain, not just a list of findings.
The second surface is CWP, Cloud Workload Protection. This is your data-plane runtime coverage. Separate plans cover servers, containers, databases, storage, App Service, and Key Vault. Each plan costs money per resource per month. Defender for Servers Plan 2 runs roughly $15 per server per month and includes MDE (Microsoft Defender for Endpoint) auto-provisioning, file integrity monitoring, and the JIT VM access controls. If you only enable one CWP plan, make it that one.
The mistake we see constantly: organizations enable DCSPM and then treat the Recommendations tab as the product. The attack surface alerts, the runtime detections, the MDE integration, none of that fires unless the relevant workload plans are on.
Connecting Defender for Cloud to Defender XDR
The Defender XDR portal (security.microsoft.com) is where you want incidents to land. Defender for Cloud alerts are not automatically there unless you complete two steps that Microsoft's own setup wizard buries.
First, enable the Defender for Cloud integration inside Defender XDR settings. Navigate to Settings, then Microsoft Defender for Cloud, and turn on the connector for each subscription. This pulls cloud security alerts into the unified incident queue.
Second, and this is the one teams miss: make sure the Defender for Cloud data connector in Microsoft Sentinel is set to "Bi-directional sync." Without that, an alert that Defender for Cloud closes because of an auto-remediation will stay open in Sentinel as a phantom incident. We have seen SOCs where 30% of the open incident count is phantom Defender for Cloud ghosts.
After the connector is live, verify it with this query in Sentinel:
SecurityAlert
| where TimeGenerated > ago(24h)
| where ProductName has "Microsoft Defender for Cloud"
| summarize AlertCount = count(), Severities = make_set(AlertSeverity)
by bin(TimeGenerated, 1h), AlertName
| order by AlertCount desc
If AlertCount is zero and you have workload plans running, the connector is broken. If you see alerts but no corresponding incidents in the XDR portal, the bi-directional sync setting is off.
Hunting Privilege Escalation via the Cloud Layer
The attack pattern that shows up in almost every cloud compromise follows a predictable shape: an initial foothold through an overprivileged identity, then escalation via a misconfigured managed identity or a role assignment the attacker creates on the fly. Defender for Cloud's JIT analysis and the MDE telemetry from Defender for Servers give you coverage across both layers, but only if you correlate them.
This hunt queries for role assignment creation events that happen within two hours of an MDE alert firing on the same subscription. It is not a polished detection rule; it is a starting point for building one.
let mde_alerts = SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == "Microsoft Defender for Endpoint"
| where AlertSeverity in ("High", "Medium")
| extend SubscriptionId = tostring(parse_json(ExtendedProperties).SubscriptionId)
| project AlertTime = TimeGenerated, SubscriptionId, AlertName, Entities;
let role_assignments = AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Add member to role"
| extend SubscriptionId = tostring(
parse_json(AdditionalDetails)[0].value)
| project AssignTime = TimeGenerated, SubscriptionId,
Initiator = tostring(InitiatedBy.user.userPrincipalName),
TargetRole = tostring(TargetResources[0].displayName);
mde_alerts
| join kind=inner (
role_assignments
) on SubscriptionId
| where AssignTime between (AlertTime .. (AlertTime + 2h))
| project AlertTime, AssignTime, SubscriptionId, AlertName,
Initiator, TargetRole, Entities
| order by AlertTime desc
Run this over 30 days on any new environment. The first result that comes back is usually either a legitimate IT admin who fired off a Terraform apply during an incident, or it is a real problem. You will know which within five minutes of looking at the Initiator field.
The Huawei driver privilege escalation Microsoft disclosed earlier this year is a good reminder that kernel-level vulnerabilities still land in environments that have strong cloud posture scores. A CSPM score of 90% does not protect you from a driver exploit on a physical or virtualized host. The Defender for Servers plan with MDE integration is what catches the post-exploitation behavior, not the posture score.
Governance Engine Is the Feature Nobody Uses
Defender CSPM includes a governance engine that most teams ignore. It lets you create rules that automatically assign recommendations to owners with a remediation deadline, and it tracks compliance over time. At scale, this is worth more than the attack path analysis.
The setup takes about an hour. You create assignment rules that map recommendation severity and resource tag (for example, environment=production) to an owner group and a deadline. Owners get email notifications. Overdue remediations show up in a governance report you can export for audits.
Without this, the Recommendations blade is a list that nobody owns. With it, you have a lightweight GRC workflow inside the same portal your security team already lives in. We have seen this reduce open critical recommendations by 60% inside 90 days on Azure environments that had accumulated years of drift.
Security Copilot in the SOC Workflow
Microsoft's Security Copilot integration with Defender for Cloud is genuinely useful for one specific task: summarizing attack paths. An attack path finding that normally takes an analyst 20 minutes to trace through the graph, across managed identities, network exposure, and vulnerable software versions, gets summarized in about 30 seconds. The analyst still has to verify it, but the reading time drops significantly.
What it does not replace: triage judgment, alert fatigue management, and the institutional knowledge of which findings are false positives in a specific environment. We tell clients to treat Copilot as a fast junior analyst who reads documentation well but has never met your environment before.
The practical setup is to enable the Copilot integration inside Defender for Cloud under the AI features blade, then pin the "Explain this recommendation" prompt to your SOC runbook. Have analysts use it before escalating a Defender for Cloud finding to a full incident. The reduction in escalations from analysts who would otherwise write up a finding they do not fully understand is measurable inside the first month.
The Baseline We Deploy on Every New Azure Engagement
When we onboard a net-new Azure environment to our detection engineering practice, the Defender for Cloud baseline looks like this:
- Defender CSPM on all subscriptions, attack path analysis confirmed firing
- Defender for Servers Plan 2 on all production VMs, MDE auto-provisioning verified in the MDE portal
- Defender for Key Vault on any subscription holding customer secrets
- Bi-directional Sentinel connector confirmed with the
SecurityAlertquery above - Governance engine rules covering all High and Critical recommendations with a 30-day deadline
- Weekly attack path review scheduled on the SOC calendar
From there, the detection work starts: building analytics rules on top of the SecurityAlert and AuditLogs tables, tuning the noise from expected automation accounts, and wiring Defender XDR incidents into whatever ticketing system the client runs.
The posture score goes up as a side effect. We never optimize for the score directly.
When to Call Us
If your Defender for Cloud deployment is producing a posture score but no actionable incidents, or if you are trying to connect its output to a Sentinel-based SOC without creating alert storms, reach out at /contact and we will scope a two-week assessment.