SC-500 Defender for Cloud Posture: Defender CSPM, Compliance, Workload Plans, AWS/GCP Connectors and EASM

Defender for Cloud has two posture tiers: Foundational CSPM, free and on by default, and the paid Defender CSPM plan, which adds risk context, governance and data posture on top. Foundational CSPM tells you what is misconfigured; Defender CSPM tells you which of those findings an attacker could actually chain together, who owns the fix and by when.

Two points cause most mistakes. First, the basics of reporting and automation are free: secure score, the compliance dashboard with the MCSB standard, workflow automation and continuous export all work without Defender CSPM. Assessing your resources against any other regulatory standard, and building custom recommendations, are Defender CSPM features. Second, workload protection plans are not posture plans. Defender for Storage, Defender for Resource Manager or Defender for Servers Plan 1 detect threats on their own resource type; none of them builds the cross-resource graph that attack paths come from. If the requirement is to see how an internet attacker could move from an exposed VM to a sensitive data store, the answer is Defender CSPM.

Defender CSPM's features also have their own switches. The plan's Settings page holds components such as Agentless scanning for machines and sensitive data discovery; turning a component off removes the data the dependent features rely on, even though the plan itself still shows as on.

The classic secure score measures the share of built-in MCSB recommendations you have resolved, grouped into security controls, and it is part of free Foundational CSPM. It does not depend on any workload protection plan.

• Only generally available, built-in MCSB recommendations count. Recommendations marked Preview are excluded until they reach GA, so a new preview check can flag many resources without moving the score. Custom recommendations and other standards don't count either.
• Points are awarded per control, not per recommendation. Each control (for example Secure management ports or Enable MFA) has a maximum score. Its current score is the score per resource multiplied by the number of healthy resources, and a resource is healthy for the control only when every recommendation in that control is resolved for it. Fixing three of four recommendations on every VM earns nothing for that control.
• Timing: controls are recalculated roughly every eight hours per subscription or cloud connector, so a counted recommendation shows within a day.
• Assigning an owner (a governance rule) does not change the score; a governance grace period can keep findings that are still inside their deadline from lowering it (see governance rules below).

The Microsoft Defender portal also shows a newer, risk-based Cloud secure score that weights findings by asset risk. The classic, control-based score in the Azure portal is the one whose mechanics are described above.

Attack path analysis shows precomputed chains from an external entry point to a critical target; cloud security explorer lets you write your own graph query over the same cloud security graph. Both need Defender CSPM, and both work across Azure, AWS and GCP.

Attack paths in practice

• No paths despite exposed, vulnerable VMs? Attack paths depend on agentless scanning being on in the Defender CSPM settings. Without it the engine has no software and vulnerability data from VM disks, so it can't identify an exploitable entry point. Viewing paths needs only Security Reader.
• Each path has a Recommendations tab (the steps that break the path) and Additional recommendations (they reduce risk but don't resolve the path).
• Once the path-breaking recommendation is healthy, the path is resolved, but it can take up to 24 hours to disappear from the list. Agentless scanning runs on its own fixed cycle, and an exemption is a way to record accepted risk on a recommendation, not a remediation.

The explorer's plan limit

With Defender for Servers Plan 2 alone (no Defender CSPM), cloud security explorer can only run queries about keys and secrets on machines. Every other query, such as one combining internet exposure with high-severity vulnerabilities, needs the Defender CSPM plan.

A governance rule automatically assigns an owner and a remediation due date to every recommendation that matches its conditions, then tracks and emails about progress; it is a Defender CSPM feature. It is the low-effort way to drive remediation, compared with building Logic Apps that send emails but track nothing.

• Conditions: match recommendations by severity, risk level, category or specific recommendation, within a scope (subscription, management group, AWS account or GCP project).
• Owner: set By resource tag (for example a tag holding the engineer's email address) or By email address.
• Remediation time frame: 7, 14, 30 or 90 days; it sets the due date.
• Apply grace period: MCSB recommendations covered by the rule don't affect the secure score until they become overdue.
• Notifications: weekly emails to owners about open and overdue items, and optionally to the owner's manager.
• Existing recommendations: a new rule acts on recommendations as they match; to cover the backlog, choose to apply it to existing recommendations that lack an owner or due date (or to overwrite existing assignments).
• Conflicts: when several rules match, rules at a management scope apply before single-scope rules, then the rule priority (1 is highest) decides.

Neighbouring features do different jobs. Email notifications deliver security alerts (and attack paths) to roles or addresses; workflow automation runs a Logic App when an event occurs; an Azure Policy modify effect changes resource properties such as tags. Only governance rules give recommendations an owner and a due date and track them.

The Regulatory compliance dashboard in Defender for Cloud maps your resources' assessment results onto the controls of each assigned standard, and it is where you produce evidence for auditors. Assigning and managing standards (including MCSB as the default) is covered in the governance lesson; this section is about reading the results and proving compliance.

• Freshness: automated assessments refresh about every 12 hours, so a fix doesn't show instantly.
• Access: the dashboard reads policy compliance data. The Reader role can see it; Security Reader sees recommendations and alerts but not that compliance data, so Reader is the least-privilege fix for a Security Reader who sees an empty dashboard. Adding or removing standards needs more (Resource Policy Contributor plus Security Admin), and assessing any standard other than MCSB requires Defender CSPM on that subscription, account or project.
• Policy exemptions remove resources from evaluation for accepted risk or a mitigating control. Custom recommendations (a Defender CSPM feature) are your own configuration checks written as queries; they evaluate resource settings, so process controls rely on attestation.

Standards across clouds

MCSB is enabled by default for every Azure subscription, AWS account and GCP project. Connected clouds also get their own default standard: AWS Foundational Security Best Practices for AWS and GCP Default for GCP. Other standards, such as CIS AWS Foundations, CIS Google Cloud Platform Foundation or PCI DSS, need Defender CSPM and appear only after you assign them; cloud-specific benchmarks can only be assigned to their own cloud. A standard with no relevant resources isn't shown. Defender for Cloud compliance data can also feed Microsoft Purview Compliance Manager.

Continuous export streams Defender for Cloud data (recommendations, alerts, secure score, regulatory compliance) to a Log Analytics workspace or Azure Event Hubs; workflow automation runs a Logic App when a specific event occurs. Both are free Foundational CSPM features. The one-time CSV download from a portal list is neither continuous nor automatic.

Workflow automation triggers must match the event

A workflow automation uses one of three Defender for Cloud triggers in Logic Apps: security alerts, recommendations or regulatory compliance assessments. Compliance changes are not alerts, so an alert-triggered Logic App never fires for them. To deploy automations at scale, assign the matching built-in Deploy Workflow Automation for Defender for Cloud DeployIfNotExists policy (there is one per trigger type) to a management group: it covers new subscriptions automatically, and a remediation task covers existing ones.

Workload protection plans (Defender for Servers, Storage, Databases, Containers, App Service, Key Vault, Resource Manager, APIs, AI services and others) are enabled per subscription in Environment settings, and a few can also be enabled on individual resources. They add threat detection and hardening for their resource type, and most start with a 30-day free trial.

• Subscription level: Environment settings, select the subscription (or AWS/GCP connector), then turn plans on individually or with Enable all. Each plan's Settings link holds its components (for example vulnerability assessment or agentless scanning).
• Resource level: only some plans support it.

The Plan 2 asymmetry matters when only a few VMs need Plan 2-only features such as agentless malware scanning or premium Defender Vulnerability Management: Plan 2 goes on at the subscription and is turned off on the servers that don't need it, so they aren't billed for it.

Onboarding many subscriptions

To make sure every current and future subscription in a management group is registered with Defender for Cloud, assign the built-in onboarding policy (Enable Microsoft Defender for Cloud on your subscription) to the management group. Its deployIfNotExists logic handles subscriptions created or updated later; existing subscriptions are only flagged non-compliant until you run a remediation task. The MCSB initiative, by contrast, is an audit initiative: it evaluates resources but doesn't enable plans.

Defender for Cloud connects AWS and GCP through native, agentless connectors that read the clouds' APIs, and it covers on-premises and other servers through Azure Arc. Each connector lives in an Azure subscription and resource group, and you choose its plans (Foundational CSPM is included; Defender CSPM, Servers, Containers, Databases can be added).

AWS details

• Organization onboarding must use the AWS management account; delegated administrator accounts are not supported, whatever role they have for AWS security services.
• The StackSet error You must enable organizations access to operate a service managed stack set means trusted access between CloudFormation StackSets and AWS Organizations is off: enable it and rerun.
• The connector's scan interval (4, 6, 12 or 24 hours) controls how often resources are read.
• Defender for Servers on EC2: creating a connector needs Contributor, but Arc autoprovisioning needs Owner on the Azure subscription, and instances need the AWS SSM Agent with the AmazonSSMManagedInstanceCore policy. The Log Analytics agent was retired in August 2024 and is not a prerequisite. Defender for Containers on AWS is the plan that needs EKS clusters.

GCP details

• The script needs the IAM, Security Token Service, Cloud Resource Manager, IAM Service Account Credentials and Compute Engine APIs on the project where it runs: the project itself, or the management project for an organization (the script can enable them).
• A missing permissions connectivity status right after a plan change means the GCP side still has the old identities and roles: regenerate and rerun the script.

Hybrid machines

On-premises servers and servers in other clouds are connected by installing the Azure Connected Machine agent (Azure Arc); the Arc resource then sits in a subscription and inherits that subscription's Defender for Servers plan. Detailed server protection settings are covered in the compute security lesson.

Microsoft Defender Vulnerability Management (MDVM) is the built-in vulnerability scanner for machines in Defender for Cloud, and it reaches VMs in two ways: agent-based through the Defender for Endpoint extension, or agentless from disk snapshots. The older built-in Qualys scanner is no longer offered.

The plan also decides the depth. Defender CSPM's agentless scanning gives software inventory, vulnerabilities and secrets; Servers Plan 2 adds agentless malware scanning and the premium MDVM capabilities. Agentless scanning in Defender CSPM therefore delivers MDVM vulnerability findings with no agent and no Defender for Servers plan.

Agentless coverage limits

• Customer-managed-key disks: the principal that needs key access is the Microsoft Defender for Cloud Servers Scanner Resource Provider, not the VM's managed identity. On an Azure RBAC key vault, assign it Key Vault Crypto Service Encryption User; on an access-policy vault, grant Get, Wrap Key and Unwrap Key. Broader roles such as Key Vault Crypto Officer exceed least privilege.
• Unsupported disks and sizes: a VM with any Ultra Disk or Premium SSD v2 disk isn't scanned; VMs with more than 14 attached disks aren't supported; when the combined disk size exceeds 4 TB, data disks are skipped.
• Stopped machines aren't scanned, because there are no current snapshots to take.
• GCP: CMK-encrypted disks need the Compute Engine service agent to hold Cloud KMS CryptoKey Encrypter/Decrypter, and an organization policy that restricts access to disks, images or snapshots silently blocks scanning even when the connector and inventory look healthy.

Defender EASM discovers your internet-facing assets from the outside in, as an attacker would, and flags vulnerabilities and exposures on them, including assets hosted outside your clouds. It comes in two forms that are easy to confuse.

Discovery: seeds and discovery groups

Discovery starts from seeds: domains, IP blocks, hosts, email contacts, ASNs and Whois organizations. Private IP ranges can't be seeds. Seeds live in discovery groups, each with its own recurrence (weekly is the default and recommended). Separate groups suit separate organizations or brands whose infrastructure isn't linked: each has its own seeds and stays separate for reporting. Exclusions stop entities from being used as seeds or added to inventory in future runs.

Asset states

Insights, dashboards and export

• Dashboards include Attack surface summary, Security posture, GDPR compliance, OWASP Top 10, CWE Top 25 and CISA known exploits. These belong to the EASM resource, not to the CSPM integration, and they analyse public web assets wherever they're hosted. The GDPR standard in the compliance dashboard checks your cloud configuration instead.
• Potential insights (for example Potential CVE-…) can't be confirmed from outside, often because of backported fixes. After verifying, mark the observation non-applicable from the insight's drill-down; changing the asset's state would drop owned assets out of Approved Inventory and the dashboards.
• Data connections send asset data and/or attack surface insights to a Log Analytics workspace or Azure Data Explorer, daily, weekly or monthly, and include Approved Inventory only.