Microsoft Defender for Cloud: Fix Setup & Config Errors
Why Microsoft Defender for Cloud Setup Goes Wrong
I've seen this exact situation play out dozens of times: a security team enables Microsoft Defender for Cloud on their Azure subscription, expects a clean security posture dashboard, and instead gets a wall of red alerts, missing data, or a plan that silently isn't protecting anything. Nobody warned them that enabling the service is only step one.
Microsoft Defender for Cloud is a Cloud Native Application Protection Platform , what the industry calls a CNAPP. That means it's not a single product. It's a unified umbrella covering three distinct protection areas: Cloud Security Posture Management (CSPM) that audits and scores your configurations, Cloud Workload Protection Platform (CWPP) that actively defends your VMs, containers, databases, and serverless workloads, and Development Security Operations (DevSecOps) that hooks into your CI/CD pipelines to catch misconfigurations before code ships. When something breaks, the failure could live in any one of those layers.
The most common issues I see fall into four buckets:
- Plans not enabled or only partially enabled. The foundational CSPM tier is free, but real workload protection , Defender for Servers, Defender for Containers, Defender for Databases, requires each plan to be individually toggled on at the subscription level. Many organizations turn on the service and never touch the plan toggle, then wonder why Defender for Servers isn't generating alerts.
- Missing agents and connectors. Defender for Cloud needs data. For on-premises machines and non-Azure clouds, that means the Microsoft Defender for Endpoint agent or the Azure Arc onboarding. Skip that, and your coverage map looks healthy while half your estate is invisible.
- Multicloud connector misconfiguration. Connecting AWS accounts and GCP projects requires specific IAM role assignments on the cloud provider side. One missing permission and the connector fails silently, no error banner, just missing data.
- Portal confusion after the Defender portal migration. Microsoft is actively moving Defender for Cloud features into the unified Microsoft Defender portal. Some settings now live in the Azure portal, some in the Defender portal, and documentation is still catching up. If you're looking for a feature in the wrong portal, you'll waste an hour.
I know this is frustrating, especially when the security posture score drops and your CISO wants answers. The good news is that almost every Defender for Cloud problem has a specific, fixable root cause. Let's walk through them. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before going deep, run this audit. It resolves around 60% of the Defender for Cloud problems I encounter in the field.
Open the Azure portal at portal.azure.com and search for Microsoft Defender for Cloud in the top search bar. In the left sidebar, click Environment settings. You'll see a list of your subscriptions and any connected AWS or GCP environments.
Click your subscription name. You'll land on a page called Defender plans. This is the most important screen in the entire product. Scan every row. Each workload category, Servers, Containers, Databases, Storage, App Service, Key Vault, Resource Manager, APIs, has its own on/off toggle. Check the status column for each one.
If any plan you expected to be active shows as Off, click the toggle. Each plan activates independently and has its own pricing tier (Plan 1 vs Plan 2 for Servers, for example). Enable the plans that match your workloads, then click Save at the top of the page. This single action fixes the most common complaint: "Defender isn't generating alerts for my VMs."
While you're on that page, also check the Monitoring coverage column. A plan can be "On" but have gaps, for instance, Defender for Servers might be enabled but the Defender for Endpoint sensor isn't deployed to all machines. The monitoring coverage indicator shows you exactly which resources are unprotected within an enabled plan.
After saving, give the system about 15 minutes to propagate. Then check the Recommendations blade. If new recommendations appear, your plan activation worked. If the coverage map still shows gaps, proceed to the step-by-step section below.
Defender for Cloud works at the subscription level. If your subscription isn't properly connected, nothing downstream will work, not the secure score, not the recommendations, not the alerts.
In the Azure portal, go to Microsoft Defender for Cloud > Environment settings. Your Azure subscriptions should appear automatically here. If a subscription is missing, it typically means the account you're logged in with doesn't have the Security Admin or Contributor role on that subscription. Open Azure Active Directory > Role assignments and verify your permissions.
For non-Azure machines, physical servers, VMs in your own data center, or machines running in other clouds, onboarding requires either the Azure Arc agent or the Microsoft Defender for Endpoint sensor. The official docs are clear on this: non-Azure machines must be onboarded via one of these paths to appear in Defender for Cloud's inventory. Go to Defender for Cloud > Inventory and check whether your on-premises machines appear. If they don't:
# Verify Azure Arc agent status on a Windows machine
Get-Service -Name himds
# Expected output: Status: Running
# Check connectivity to Azure Arc endpoints
Test-NetConnection -ComputerName "management.azure.com" -Port 443If the himds service is stopped, start it with Start-Service himds. If the connectivity test fails, you have a firewall issue blocking the Arc agent from reaching Azure endpoints, work with your network team to open outbound HTTPS to Azure Arc URLs.
When the subscription and machines show up correctly in Environment settings and Inventory, you'll see a resource count next to each subscription. That confirms onboarding is healthy.
Here's where most setups fall apart. The foundational CSPM tier gives you basic security recommendations and the secure score, it's free and it's on by default once you open Defender for Cloud. But it does not protect your workloads. For that, you need the individual workload protection plans.
Go to Defender for Cloud > Environment settings > [Your Subscription] > Defender plans. Walk through each plan category based on what you're actually running:
- Running Azure VMs, AWS EC2, or GCP Compute? Enable Defender for Servers. Plan 1 covers Defender for Endpoint integration. Plan 2 adds agentless vulnerability scanning, file integrity monitoring, and network map features. For most production environments, Plan 2 is what you want.
- Running Kubernetes (AKS, EKS, GKE) or container workloads? Enable Defender for Containers. This handles environment hardening, vulnerability assessment for container images, and runtime threat detection at the Kubernetes node and cluster level.
- Running Azure SQL, Cosmos DB, or open-source databases (PostgreSQL, MySQL, MariaDB)? Enable Defender for Databases. It detects unusual database access patterns and anomalous query behavior.
- Using Azure Blob Storage, File Shares, or Data Lake? Enable Defender for Storage. This covers malware scanning on uploaded files, sensitive data leakage detection, and Shared Access Signature (SAS) token misuse, a vector that catches a lot of teams off guard.
- Hosting APIs in Azure API Management? Enable Defender for APIs to get visibility into your business-critical API surface and real-time threat detection.
After toggling on each plan, click Save. Defender for Cloud will begin collecting telemetry within minutes, but full recommendation generation can take up to 24 hours for some plans, particularly for the first-time container vulnerability scan.
If your organization runs workloads in AWS or GCP alongside Azure, you'll want those environments showing up in Defender for Cloud's unified dashboard. The connection process is specific, and one wrong IAM permission breaks the whole connector.
For AWS, go to Defender for Cloud > Environment settings > Add environment > Amazon Web Services. The wizard walks you through creating a CloudFormation stack in your AWS account. That stack provisions an IAM role that grants Defender for Cloud read access to your AWS environment. The most common failure here is deploying the CloudFormation stack in the wrong AWS region or with an account that lacks iam:CreateRole permissions. Make sure you're running the stack in the same region where your workloads live and that the AWS user executing the stack has sufficient permissions.
For GCP, go to Defender for Cloud > Environment settings > Add environment > Google Cloud Platform. You'll need to run a set of gcloud commands to create a service account and grant it the required viewer roles on your GCP project. The exact commands are provided in the wizard, copy them directly rather than typing them manually to avoid syntax errors.
# Verify AWS connector is working, check this in Azure CLI
az security connector list --resource-group "YourRG" --query "[].{Name:name, State:properties.environmentData.operationalStatus}"If the operational status shows Failed rather than Active, open the connector in the portal and look at the Health tab. It usually identifies the exact missing permission. Fix it on the cloud provider side, then click Update on the connector to retry the connection.
Your secure score is Defender for Cloud's way of telling you how well your environment aligns with security best practices. A low score doesn't mean you've been breached, it means there are configuration gaps. Here's how to read and act on it without getting overwhelmed.
Go to Defender for Cloud > Secure score. You'll see your overall percentage score broken down by security control category (such as "Protect your resources with network security," "Apply system updates," "Remediate vulnerabilities"). Each control is worth a specific number of points.
Click any control to expand it. You'll see the individual recommendations underneath, each with a severity label (High, Medium, Low) and an "Affected resources" count. Sort by severity and tackle the High ones first.
For each recommendation, click into it for the detail view. Defender for Cloud provides a Remediation steps section, this is your action plan. For some recommendations, there's a Fix button that applies the remediation automatically. Use it. For others, like enabling MFA on privileged accounts or rotating exposed secrets, you need to act manually.
One thing that trips people up: some recommendations appear under the free CSPM tier but the detailed fix guidance or the auto-remediation button requires the paid Defender CSPM plan to be enabled. If you're seeing "Upgrade to Defender CSPM to view full details," that's expected behavior, the foundational tier shows you what's wrong but the advanced tier gives you the cloud security graph and agentless scanning that power deeper context.
After fixing a recommendation, it may take up to 12 hours for the secure score to update. Don't expect instant gratification, remediation processing runs on a schedule.
Security alerts are where Defender for Cloud earns its keep. When a threat is detected, unusual login behavior, a suspicious process on a VM, an attempt to access Key Vault from an anomalous IP, Defender generates a security alert. But if your alerts aren't flowing to the right place, they're worthless.
Go to Defender for Cloud > Security alerts. If this page is empty after 24+ hours with active plans, check two things. First, confirm the relevant plans are enabled (go back to Step 2). Second, check whether an alert suppression rule is accidentally swallowing your alerts, go to Alert suppression rules in the sidebar.
To route alerts to your SIEM or ticketing system, go to Defender for Cloud > Environment settings > [Subscription] > Integrations. From here you can connect to Microsoft Sentinel, export to an Event Hub, or push alerts to a Log Analytics workspace. For Microsoft Sentinel integration, the setup is a single toggle, enable the connector in Sentinel's data connectors page and select your Defender for Cloud subscription.
Just-in-time VM access is a specific feature under Defender for Servers that locks down management ports (RDP on 3389, SSH on 22) by default and opens them on request for a defined time window. To enable it:
# Enable JIT via Azure CLI for a specific VM
az security jit-policy create \
--resource-group "MyRG" \
--location "eastus" \
--name "default" \
--virtual-machines '[{"id":"/subscriptions/SUB_ID/resourceGroups/MyRG/providers/Microsoft.Compute/virtualMachines/MyVM","ports":[{"number":22,"protocol":"*","allowedSourceAddressPrefix":"*","maxRequestAccessDuration":"PT3H"}]}]'Once JIT is active, open Defender for Cloud > Workload protections > Just-in-time VM access to see all protected VMs and approve access requests. If the JIT blade says "No VMs are protected," it means Defender for Servers is either not enabled or not deployed to those VMs.
Advanced Troubleshooting
If the standard steps haven't resolved your issue, these deeper approaches cover the edge cases I see in enterprise environments with complex policies, domain-joined machines, or strict network controls.
Diagnosing Defender for Cloud Agent Deployment Failures at Scale
In large environments, Defender for Cloud deploys agents using Azure Policy auto-provisioning. If machines aren't getting the Defender for Endpoint or MMA/AMA sensor, go to Defender for Cloud > Environment settings > [Subscription] > Auto provisioning. Verify that the relevant extensions are set to On. If they are but machines still don't have the agent, check whether an Azure Policy deny assignment is blocking the extension deployment. Open Azure Policy > Compliance and filter for policies in the "Microsoft Defender for Cloud" initiative. Any non-compliant policy with a "deny" effect is your culprit.
Log Analytics Workspace Conflicts
Defender for Cloud needs a Log Analytics workspace to store agent data. If your organization has an existing workspace configuration enforced by policy, Defender's auto-provisioning might try to create a new workspace and fail. Resolve this by going to Auto provisioning > Log Analytics agent for Azure VMs and selecting Connect Azure VMs to a different workspace, then point it to your existing workspace. Run this query in Log Analytics to confirm data is flowing:
// Verify Defender for Cloud heartbeat data is arriving
Heartbeat
| where TimeGenerated > ago(1h)
| where Category == "Direct Agent"
| summarize count() by Computer, OSType
| order by count_ descIf this query returns no results but machines are online, the agent isn't communicating. Check that outbound TCP 443 is open to *.ods.opinsights.azure.com and *.oms.opinsights.azure.com.
DevSecOps Connector Issues
Defender for DevOps connects to GitHub, Azure DevOps, and GitLab to scan code for misconfigurations and exposed secrets. If your DevOps connector shows as unhealthy, go to Defender for Cloud > DevOps security and check the connector status. GitHub connectors fail most often because the GitHub App wasn't granted permissions to all repositories, only the ones selected at install time. Re-open the GitHub App configuration and grant access to the missing repos.
Regulatory Compliance Dashboard Not Showing My Standard
The compliance dashboard in Defender for Cloud maps your environment against frameworks like PCI-DSS, ISO 27001, NIST SP 800-53, and SOC 2. If your required standard isn't showing, go to Defender for Cloud > Regulatory compliance > Manage compliance policies. Select your subscription and enable the standard you need. Note that some standards only appear with Defender CSPM enabled, the foundational tier supports a limited set.
If you've completed all steps above and Defender for Cloud still isn't ingesting data from a connected environment, or if you're seeing a persistent error code in the connector health blade that doesn't match any known issue in the documentation, open a support ticket. Go to Azure portal > Help + support > New support request and select Microsoft Defender for Cloud as the service. Include your subscription ID, the connector resource ID, and a screenshot of the health status. Microsoft Support has access to backend telemetry you won't see in the portal, and connector-level issues often require them to look at the service-side logs.
Prevention & Best Practices
Getting Defender for Cloud working is one thing. Keeping it healthy over time, especially as your environment grows, is a different challenge. Here are the practices that separate teams who get value from Defender for Cloud from teams who have it enabled but mostly ignore it.
Assign a Dedicated Security Admin Role
Defender for Cloud's recommendations and alerts are only useful if someone acts on them. Assign the Security Admin role in Azure RBAC to at least one person on your team whose job it is to review the secure score weekly. The Security Reader role is fine for visibility, but only Security Admin can dismiss alerts, create suppression rules, and adjust plan configurations. Don't give everyone Security Admin, that's how suppression rules get created that accidentally hide real threats.
Use Azure Policy to Enforce Defender Plans Across New Subscriptions
If your organization creates new Azure subscriptions regularly (common in enterprise landing zone designs), Defender for Cloud plans won't automatically be enabled on them. Create an Azure Policy assignment with the effect DeployIfNotExists targeting the Microsoft.Security/pricings resource type to automatically enable specific plans on any new subscription. This prevents coverage gaps as your environment scales.
Review the Workload Protections Dashboard Monthly
Go to Defender for Cloud > Workload protections. This dashboard shows you aggregate coverage across all your active plans, how many VMs are covered by Defender for Servers, how many container registries are scanned, how many databases are monitored. If the covered resources count drops, it usually means new resources were deployed without the agent or that a plan was accidentally disabled. Monthly reviews catch these gaps before they become incidents.
Integrate with Microsoft Sentinel Early
Defender for Cloud generates rich security alerts, but they're most powerful when correlated with signals from across your environment. Connecting Defender for Cloud to Microsoft Sentinel via the native data connector takes about five minutes. Once connected, Sentinel can correlate a Defender for Cloud VM alert with an Azure AD sign-in event and an unusual outbound connection to give you a complete attack story. Do this integration at day one, not after your first incident.
- Enable just-in-time VM access on all internet-facing VMs immediately, it blocks the most common brute-force attack vector against Azure VMs at zero additional cost beyond Defender for Servers.
- Turn on Defender for Storage's malware scanning feature for any storage account that accepts uploads from external users, it prevents malicious files from entering your environment through what looks like a routine upload.
- Export your secure score history to a Log Analytics workspace so you can track posture improvement over time and build a dashboard your CISO can see without logging into the Azure portal.
- Set a recurring monthly calendar block to review and resolve the top five High-severity recommendations, consistent incremental improvement beats sporadic large efforts every time.
Frequently Asked Questions
What is Microsoft Defender for Cloud and what does it actually do?
Microsoft Defender for Cloud is what's called a Cloud Native Application Protection Platform (CNAPP), it's a unified security product that covers three areas at once. It manages your cloud security posture by checking configurations and giving you a score (CSPM), it protects specific workloads like VMs, containers, and databases from active threats (CWPP), and it integrates security checks directly into your DevOps pipelines so misconfigurations get caught before code ships (DevSecOps). Think of it as a security control plane that works across Azure, AWS, GCP, and your on-premises machines from a single dashboard. It also includes AI security capabilities to protect generative AI workloads, which is a newer addition to the product.
Is Microsoft Defender for Cloud free or does it cost money?
There are two tiers. The foundational CSPM tier is genuinely free, you get basic security recommendations, a secure score, and regulatory compliance tracking at no charge once you open Defender for Cloud on your subscription. The paid tiers kick in when you enable individual workload protection plans: Defender for Servers, Defender for Containers, Defender for Databases, Defender for Storage, and so on. Each plan is priced per resource per hour, and costs vary based on which plan tier you select (Plan 1 vs Plan 2 for Servers, for example). Microsoft provides a Defender for Cloud cost calculator on the pricing page so you can estimate your bill before committing, I'd strongly recommend running through it before enabling plans on a large subscription.
Why is my Defender for Cloud secure score so low even though I just set it up?
A low secure score right after setup is completely normal, it's not an alarm, it's a baseline. Defender for Cloud is doing exactly what it should: scanning your existing environment against security best practices and surfacing every gap. The score reflects your current configuration state, not your effort level. What you should do is go to Secure score > Security controls, sort by "Potential score increase," and start with the control at the top of the list. Most environments see significant score improvement just by enabling MFA on admin accounts, applying missing system updates, and enabling disk encryption, actions that are often already on your roadmap but haven't been tracked in one place before.
Where do I find Defender for Cloud now, is it in the Azure portal or the Defender portal?
This is genuinely confusing right now, and Microsoft has acknowledged it. The core configuration experience, enabling plans, connecting subscriptions, viewing recommendations, still lives in the Azure portal at portal.azure.com. However, Microsoft is actively expanding Defender for Cloud into the unified Microsoft Defender portal, and some newer features and experiences are starting to appear there first. When you're following documentation, look for a portal selector toggle at the top of the article that tells you whether the steps apply to the Azure portal or the Defender portal. If you can't find a feature in one portal, try the other, and check back as Microsoft continues the migration because this is an evolving situation.
My Defender for Cloud isn't showing my AWS or GCP resources, how do I fix that?
The multicloud connectors for AWS and GCP need to be explicitly created, they don't discover other cloud accounts automatically. Go to Defender for Cloud > Environment settings > Add environment and follow the wizard for AWS or GCP. For AWS, you'll deploy a CloudFormation stack that creates the IAM role Defender needs. For GCP, you'll run gcloud commands to create a service account with viewer permissions. The most common failure is a missing IAM permission on the cloud provider side, after setup, check the connector's Health tab in the portal. It will list exactly which permission is missing so you know what to grant. Once the connector is active, give it up to 24 hours to fully populate the inventory.
What's the difference between Defender CSPM and the free foundational CSPM?
The free foundational CSPM gives you security recommendations, a secure score, and basic regulatory compliance mapping, it's genuinely useful and worth having enabled on every subscription. The paid Defender CSPM plan adds a significant layer on top: agentless vulnerability scanning across VMs and containers without needing to install anything, a cloud security graph that maps attack paths through your environment, data-aware security posture that identifies sensitive data exposure risks, and advanced threat hunting capabilities. If you're managing a production environment with real compliance requirements or want to visualize how an attacker could chain vulnerabilities together to reach your crown jewels, the paid CSPM plan is worth the investment. The cloud security graph feature alone has helped teams identify lateral movement risks that would have been invisible with basic scanning.