rss.livelink.threads-in-node

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 02 Jul 2026 18:11:31 GMT

What's new in Defender for Cloud?

Microsoft Defender for Open-Source Relational Databases is now generally available for Amazon Web Services Relational Database Service (AWS RDS) instances. Receive database threat protection and sensitive data discovery insights for supported open-source relational databases, including Aurora PostgreSQL, Aurora MySQL, PostgreSQL, MySQL, and MariaDB on AWS RDS.

For more information, see our public documentation.

Expanded multicloud security coverage now GA

Microsoft Defender for Cloud's expanded multicloud security coverage is now generally available. This release significantly broadens posture assessment for AWS and GCP environments, adding support for about 90 new resource types and over 200 new security recommendations across data, identity and access, networking, compute, and container categories.

For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blogs of the month

In June, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Watch the latest Defender for Cloud in the Field YouTube episode here:

GitHub Community

Check out Defender for Cloud GitHub lab module 25. It walks through the integration between Defender for Cloud and XDR to provide a comprehensive CDR solution.

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Hassan Allam Holding. Hassan Allam Holding is an Egyptian private-sector company with operations spanning engineering, construction, and infrastructure investment and was facing operational complexity. To overcome, they leveraged an end-to-end Microsoft Security ecosystem with Defender XDR, which integrates with Defender for Cloud and other products to centralize detection and signals across endpoint, identity, email and cloud workloads. As a result, alert noise reduce by up to 90%, and Hassan Allam Holding is able to respond faster with far less complexity.

Join our community!

We offer several customer connection programs within our private communities. By signing up, you can help us shape our products through activities such as reviewing product roadmaps, participating in co-design, previewing features, and staying up-to-date with announcements. Sign up at aka.ms/JoinCCP.

We greatly value your input on the types of content that enhance your understanding of our security products. Your insights are crucial in guiding the development of our future public content. We aim to deliver material that not only educates but also resonates with your daily security challenges. Whether it’s through in-depth live webinars, real-world case studies, comprehensive best practice guides through blogs, or the latest product updates, we want to ensure our content meets your needs. Please submit your feedback on which of these formats do you find most beneficial and are there any specific topics you’re interested in https://aka.ms/PublicContentFeedback.

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Now generally available: Serverless posture coverage in Microsoft Defender CSPM

donnalee — Wed, 01 Jul 2026 16:00:48 GMT

Serverless workloads are a foundation of modern application development, powering everything from low-code and no-code solutions to AI applications and agentic workflows. Development teams use functions, app services, containers, APIs, and event-driven infrastructure to move quickly, scale on demand, and reduce operational overhead. As AI applications and autonomous workflows increasingly rely on distributed services, background tasks, retrieval pipelines, and event-driven components, serverless architectures have become a natural fit.

At the same time, they introduce new visibility and posture management challenges. While cloud providers manage the underlying infrastructure, organizations remain responsible for securing their applications, including code, container images, dependencies, configurations, identities, permissions, and access paths.

Today, we're announcing the general availability of Serverless Container posture in Microsoft Defender Cloud Security Posture Management (Defender CSPM). Building on the recent general availability of Serverless Compute posture in Defender CSPM, these capabilities extend agentless posture coverage across supported serverless containers, applications, and functions in Azure and AWS.

With this expanded serverless posture coverage, security teams can:

Discover serverless workloads as first-class assets in a unified cloud inventory

Assess workload-specific vulnerabilities, insecure dependencies, and risky configurations

Surface exposure, identity, permission, and configuration context that helps prioritize contextual attack paths to broader applications

Prioritize risk using security graph context and attack path analysis

Act on severity-ranked recommendations in Defender for Cloud

Serverless posture coverage across containers, apps, and functions

Defender CSPM extends posture management across supported serverless workloads in Azure and AWS.

Category	Covered workloads
Serverless applications and functions	Azure Functions, Azure Web Apps, AWS Lambda
Serverless containers	Azure Container Apps, Azure Container Instances, AWS ECS on Fargate

These resources are automatically discovered and surfaced in Defender cloud inventory, helping security teams maintain visibility across dynamic, event-driven application environments.

Across supported serverless workloads, multiple layers of posture assessment are provided:

Inventory: Serverless compute and container workloads are automatically discovered and mapped with key properties, helping teams understand what is running across their environment.

Misconfiguration assessment: identify risky settings such as internet exposure, missing HTTPS, and other configuration issues that can increase exposure.

Vulnerability management: Vulnerabilities are detected across supported serverless workloads and tracked over time, helping teams understand where exposed workloads may also contain known CVEs.

Attack path analysis: Serverless resources are connected into the Security Graph, so teams can understand how a compromised function or container could reach sensitive assets.

Actionable recommendations: Findings are surfaced as resource-level recommendations, making it easier to assign ownership, remediate, and track progress.

Secure Score impact: Serverless findings contribute to the broader Secure Score, so risk reduction is reflected in the organization’s overall posture.

These findings are incorporated into Security Graph and attack path analysis, helping security teams understand risk in context and prioritize remediation based on how serverless workloads connect to other resources across the cloud environment.

In practice

Exposed function with access to sensitive data: A serverless function may look like a simple HTTP endpoint, but if it is internet-facing, running with broad identity permissions, and connected to sensitive storage, it can become part of a real attack path. Defender CSPM helps connect these signals across exposure, vulnerabilities, identity, and data access so teams can prioritize the workload based on actual risk, not just isolated findings.

Serverless container running a vulnerable image: A serverless container running on Azure Container Apps, Azure Container Instances, or Amazon ECS on AWS Fargate may be fully managed at the infrastructure layer, but the customer still owns the image, application code, identity, configuration, and exposure. If that workload is internet-facing, built from an image with a critical CVE, and connected to Key Vault, storage, or other sensitive services, Defender CSPM helps teams discover it, assess the risk, and prioritize remediation in context.

One consistent Defender experience

Defender CSPM now natively includes serverless posture coverage. Discovered functions, web apps, and serverless containers appear in the unified cloud inventory, are evaluated through security recommendations, integrate into attack path analysis, and are queryable through Cloud Security Explorer.

This consistency matters because serverless workloads rarely operate in isolation. A function might call an API, read from a queue, authenticate with a managed identity, and write to storage. A serverless container might expose an endpoint, pull an image from a registry, process events, and connect to secrets or databases.

Defender CSPM helps security teams evaluate these workloads with surrounding context, including exposure, vulnerabilities, identity permissions, configuration risk, and relationships to other resources. That context helps teams move from isolated findings to prioritized remediation.

Built for modern and AI-ready applications

As organizations build AI-powered applications, agentic workflows, and distributed cloud services, serverless infrastructure continues to play a growing role in delivering scalability and operational efficiency.

Defender CSPM helps security teams gain visibility into supported serverless containers, applications, and functions, assess vulnerabilities and misconfigurations, and prioritize remediation using Security Graph context and attack path analysis. By bringing serverless workloads into inventory, recommendations, Cloud Security Explorer, and attack path analysis experiences, Defender CSPM helps organizations better understand and reduce risk across their cloud environments.

Explore the documentation for serverless protection and posture for serverless container workloads, and discover the latest innovations in Microsoft Defender for Cloud in the release notes.

Microsoft Defender for Cloud expands multicloud coverage across AWS and Google Cloud

donnalee — Tue, 30 Jun 2026 17:36:56 GMT

Organizations are building and running applications across multiple cloud platforms and hybrid environments to move faster, improve resilience, and choose the services that best fit each workload. But that flexibility also changes how teams need to manage exposure. A risk may start with an internet-facing resource, an over-permissive identity, a misconfigured managed service, a vulnerable container image, or a serverless workload with access to sensitive data. When those signals are spread across multiple cloud providers and tools, it becomes harder to understand how exposure is created and which actions will reduce risk fastest.

Today, Microsoft is expanding multicloud coverage in Microsoft Defender for Cloud with general availability of approximately 90 new AWS and Google Cloud resource types and more than 200 recommendations. Building on recent enhancements in CIEM, identity security, containers, and serverless workloads, this expansion helps customers evaluate more of their cloud estate through a unified security experience.

With broader coverage across cloud-native applications, data platforms, identity services, networking components, and managed services, security teams can move beyond isolated findings and gain more context across resources, configurations, identities, exposure signals, and prioritization.

What’s new: broader AWS and Google Cloud coverage

Security teams cannot reduce exposure they cannot see. The expanded coverage brings more AWS and Google Cloud resources into the Defender for Cloud experience, helping customers assess a wider set of modern cloud services through a unified security lens, reducing blind spots where teams increasingly build and operate: serverless applications, containers and build systems, identity and entitlement controls, data and analytics services, AI and ML, networking, messaging, storage, and other managed cloud services.

App, platform, and serverless services, including Cloud Run and EventBridge, to help teams identify exposure in cloud-native applications and event-driven workloads.

Containers, registries, and build systems, including Artifact Registry and CodePipeline, to connect software supply chain posture with workload risk.

Identity, data, and managed services, including Cognito and BigQuery, to help teams understand how access, data, and platform configurations can increase exposure.

Multicloud compliance and data protection controls, improving visibility into encryption, logging, backup, auditability, and resilience scenarios.

This broader view helps customers understand their real exposure surface and act on recommendations tied to the scenarios that matter most. Find the full list of recommendations here.

See exposure in context

Exposure is rarely created by a single finding. Consider a security team managing applications across AWS and Google Cloud. A publicly accessible BigQuery dataset, a cloud-native application running in Cloud Run, and an over-permissioned identity may each generate separate findings. Viewed independently, these issues can appear as routine posture alerts; together, they reveal a higher-risk exposure scenario that could lead to unauthorized access to sensitive data. More AWS and Google Cloud resources can now be assessed in the same security experience, helping teams move beyond isolated findings and toward a clearer understanding of potential exposure and remediation priority.

Why this matters

For most security teams, the bigger challenge isn't generating more findings, it's prioritizing the ones that matter most. By bringing more AWS and Google Cloud resources into inventory, evaluating them with recommendations, and correlating them with identity context, exposure signals, regulatory compliance results, Secure Score insights, and business criticality, Defender for Cloud helps teams focus on the exposures most likely to impact their organization, without adding another fragmented tool to the stack. As coverage expands, teams can answer practical questions across a broader part of their environment:

Which AWS and Google Cloud services are now visible in my cloud inventory?

Which newly evaluated resources have recommendations that should be reviewed?

Which findings are tied to exposed, high-value, or security-sensitive resources?

Where should my team prioritize remediation based on exposure, not just finding volume?

Building on recent multicloud investments

This release builds on a series of multicloud investments in Defender for Cloud over the past several months that bring deeper, more consistent protection across multicloud environments.

CIEM and identity: Identity is one of the most common entry points for cloud exposure. Defender for Cloud evaluates overprovisioned identities, risky permissions, weak authentication, and privilege-escalation paths. Modernized CIEM logic now assesses identity risk based on actual entitlement usage rather than sign-in activity, using a 90-day lookback. Customers benefit from improved accuracy using log ingestion from AWS CloudTrail and Google Cloud Logging, and drive actionable recommendations. Learn more about permissions management.

Containers and serverless: In containers and serverless, Microsoft expanded multicloud posture coverage across serverless compute, serverless containers, and modern Kubernetes environments. This expansion brings more cloud-native workloads into a unified code-to-runtime security model with vulnerability assessment, misconfiguration analysis, container-level recommendations, and a richer exposure context. Last month we introduced general availability of serverless compute posture coverage for AWS Lambda, Azure Functions, and Azure Web Apps, and the public preview of serverless container posture coverage for Azure Container Apps, Azure Container Instances, and Amazon ECS on AWS Fargate. Learn more about the latest in container security, and find documentation about serverless protection and serverless containers posture protection.

Together, these investments give security teams a more complete view of exposure across Azure, AWS, and Google Cloud.

Built into the Microsoft Security experience

The expanded AWS and Google Cloud coverage strengthens the foundation for multicloud exposure management in Defender for Cloud. Customers can use the same experience they already rely on to understand inventory, posture, serverless and container risk, CIEM and identity context, compliance, Secure Score, and risk prioritization across more of their cloud estate.

Because exposure is shaped by relationships across resources, identities, entitlements, workloads, configurations, controls, and reachable services, a more complete multicloud view helps security teams understand risk and act with greater confidence. For customers standardizing on Microsoft Security, this means broader multicloud exposure management in one place – without adding another fragmented tool to the stack.

Get started

Customers can begin reviewing the expanded coverage by exploring Cloud Inventory, filtering by cloud provider and resource category, reviewing newly introduced recommendations, and monitoring Secure Score changes as broader assessment becomes available.

We recommend that security teams:

Use Cloud Inventory to understand which additional AWS and Google Cloud resource types are now represented in Defender for Cloud.

Review new recommendations across key workload, identity, compliance, data protection, and networking.

Reassess top exposure scenarios across clouds, including serverless, containers, identity, data, and managed services.

Prioritize remediation based on exposure, criticality, and business context, not only recommendation volume.

Learn more

With expanded AWS and Google Cloud coverage, Microsoft Defender for Cloud helps security teams improve multicloud visibility, assess more resources, and prioritize exposure across their cloud estate.

To learn more, visit the Microsoft Defender for Cloud documentation, review the latest release notes, and follow the Microsoft Defender for Cloud Tech Community blog for updates on cloud security and posture management.

Exempt a specific container in MDC

gokhantatar — Thu, 25 Jun 2026 20:22:45 GMT

You don't need a full exemption for this — the built-in policy behind "Immutable (read-only) root filesystem should be enforced for containers" already supports per-container and per-image exclusions natively, which is more precise than exempting at the resource/cluster level.

This recommendation is implemented via the Azure Policy Add-on for Kubernetes (Gatekeeper constraint) as part of Defender for Cloud's data plane hardening. The underlying policy definition supports these parameters:

excludedContainers — exclude by container name
excludedImages — exclude by image (supports prefix matching, e.g. myregistry.azurecr.io/legacy-app:*)
excludedNamespaces — exclude entire namespaces (e.g., kube-system, useful for system pods that legitimately can't run read-only)

To configure: Defender for Cloud → Recommendations → select this recommendation → Take action tab, where you can set these parameters directly without touching raw policy JSON. Alternatively, if you manage policy via Environment Settings → Security policies → Standards, you can set the same parameters on the standard assignment.

Given you said multiple containers across airflow/db1, airflow/sql1, etc. show "Unhealthy" — if these are legitimate exceptions (e.g., a database container that needs to write to its filesystem by design, not just a misconfiguration), excludedContainers naming each container is the cleanest fix and keeps the recommendation enforcing everywhere else in the cluster. I'd reserve a full policy exemption (Azure Policy exemption resource) for cases where you need it tracked for compliance/audit purposes specifically — the parameter-based exclusion is the more "native" and maintainable fix for ongoing operational cases like this.

Exempt - Azure CSPM Recommendation" (Terraform exemption

gokhantatar — Thu, 25 Jun 2026 20:22:04 GMT

The reason you're not finding a standalone policyAssignmentId/policyDefinitionId for this specific recommendation is that it isn't a standalone assignment — it's one control inside the built-in CSPM initiative (the "ASC Default" / Microsoft Cloud Security Benchmark assignment). That initiative does have an assignment ID; you just need to target the specific control within it, not look for a separate one.

In azurerm_resource_policy_exemption (or the subscription/resource-group variants), the relevant fields are:

policy_assignment_id → the ID of the initiative assignment (ASC Default / MCSB), not a per-recommendation assignment
policy_definition_reference_ids → an array scoping the exemption to just this one control instead of the whole initiative

resource "azurerm_resource_policy_exemption" "function_app_network_exemption" {

name = "exempt-function-network-restriction"

resource_id = azurerm_linux_function_app.example.id

policy_assignment_id = data.azurerm_subscription_policy_assignment.asc_default.id

policy_definition_reference_ids = [

"<reference-id-for-the-specific-control>"

]

exemption_category = "Waiver" # or "Mitigated" if an equivalent control exists

expires_on = "2026-12-31T00:00:00Z"

}

To find the policy_definition_reference_id for this specific control: in the Azure Portal, go to Policy → Definitions, search for "Restricted network access should be configured on Internet exposed Function app" to get its definition ID, then open the initiative definition (ASC Default) and find the matching entry in its policyDefinitions[].policyDefinitionReferenceId array — that string is what goes in the array above.

Two things worth deciding upfront before automating this:

Waiver vs Mitigated — if you've genuinely restricted access another way (e.g., Private Endpoint), use Mitigated so it's distinguishable from accepted risk in reporting.
Consider whether the exemption belongs at the resource scope (just this Function App) vs resource group/subscription — narrower is safer, but if you have a pattern of similar apps, a tagged-based resourceSelectors block can scale this without per-resource blocks.

Remediation Workflow Automation — Biggest Gap vs. Competing Exposure Management Platforms?

gokhantatar — Thu, 25 Jun 2026 20:05:56 GMT

Exposure graph and attack path correlation in MSEM are genuinely strong — the cross-domain visibility (endpoints, identities, cloud, external surface) is one of the better implementations I've worked with, especially for shops already standardized on the Microsoft stack.

The gap I keep running into is closed-loop remediation orchestration. Right now, when an attack path or critical exposure is identified, there's no native way to auto-generate a ticket, assign ownership, and track an SLA against it — that handoff still has to be built externally (Logic Apps, Sentinel playbooks, or a 3rd-party ITSM integration). This isn't just my experience; it's echoed in published Gartner Peer Insights reviews of the product, where users specifically flag the absence of in-platform workflows to raise tickets automatically and route them to the owning team.

For comparison, Qualys built this natively into their Enterprise TruRisk Platform (QFlow) — automatic ticket creation in ServiceNow/Jira, ownership assignment, and SLA tracking, all without manual handoffs. Tenable One markets "workflow automation" as a core differentiator of its unified platform for the same reason: it's what turns continuous detection into continuous risk reduction, not just a better dashboard.

Questions for the team / community:

Is closed-loop ticketing/SLA tracking on the roadmap natively, or is the expectation that this stays external (Logic Apps/Sentinel)?
For those running MSEM at scale — how are you currently bridging this gap operationally? Custom playbooks, or a 3rd-party orchestration layer on top?

Exempt - Azure CSPM Recommendation

ABhatia610 — Wed, 17 Jun 2026 00:40:30 GMT

We are implementing creating exemptions on policies through Terraform.

Is there a way to exempt this specific Azure CSPM standard policy "Restricted network access should be configured on Internet exposed Function app" through Terraform since it does not have any policyassignmentid and policyid.

I think this standard policy cannot be exempted with this code. Please confirm.

My understanding is this is Assessment type and has no policy id or policy assessment id. I can exempt through Azure Portal but not from Terraform.

Any guidance is greatly appreciated.

resource "azurerm_subscription_policy_exemption" "this" {

for_each = local.subscription_exemptions

name = each.key

subscription_id = each.value.resource_id

policy_assignment_id = each.value.policy_assignment_id

policy_definition_reference_ids = each.value.policy_definition_reference_ids

exemption_category = each.value.category

expires_on = each.value.expires_on

description = "Ticket: ${each.value.ticket} | ${each.value.remediation_plan}"

metadata = jsonencode(merge(var.tags, {

owner = each.value.owner

ticket = each.value.ticket

risk_level = each.value.risk_level

remediation_plan = each.value.remediation_plan

approved_by = each.value.approved_by

approval_date = each.value.approval_date

environment = var.environment

managed_by = "terraform"

}))

}

Thanks,

Anshu

Closing the loop on container security: From code to runtime in the AI era

mahersko — Tue, 16 Jun 2026 23:15:21 GMT

Containers are the backbone of modern cloud-native apps — and increasingly, the infrastructure powering AI, from AI assistants to a new wave of intelligent agents. They also blur the line between build, deploy, and runtime: a single code change can become a running workload in minutes. A misconfiguration committed in the morning can be deployed in minutes and exploited before noon. At that speed, container security can no longer be a point-in-time check, it has to work as one continuous loop.

The numbers back this up. For the first time, 31% of breaches now begin with an attacker exploiting a software vulnerability — overtaking stolen credentials as the most common way in — and 15% of attack techniques are now accelerated by generative AI, with adversaries using it to find gaps and write malware faster at every stage.

Source: Verizon 2026 Data Breach Investigations Report (incidents Nov 2024–Oct 2025).

Over the last few quarters, Microsoft Defender for Cloud has been evolving to offer you this continuous security, end to end. Explore container security’s new capabilities across posture, shift-left, runtime, multicloud coverage, and operations. Collectively they form a more comprehensive approach to container security — one that offers security right during developing a code to a running pod across Azure, AWS, and GCP.

There is a second reason why container security matters more in 2026: containers are increasingly where AI runs. Many AI workloads — from model-serving APIs to retrieval systems and intelligent agents — now live as pods on AKS, EKS, and GKE (the managed Kubernetes services from Azure, AWS, and Google), often connected to some of an organization’s most sensitive models and data. As those crown jewels move into the cluster, the same posture, code‑to‑runtime, and runtime protections described in this post extend to AI workloads. The contest is increasingly AI against AI: attackers use it to find and reach the cluster faster, while defenders use it to push back — surfacing the risks that matter most and turning runtime findings into AI‑assisted code fixes.

One platform, code to runtime

A container finding is not treated as an isolated issue; it is connected to the identity it runs under, the registry and code repository it came from, and the cluster where it is running - all unified under one Microsoft Defender platform.

Container posture and shift-left security are now redesigned for least vulnerabilities in production

Conventional container security posture offered challenges to scale: a single grouped recommendation could stack thousands of findings under one bucket, making ownership, exemptions, and risk scoring too coarse to act on. That experience is now evolved. We have rebuilt the experience so that each finding is its own recommendation — per software, per image, per container. If two CVEs in the same image belong to two different teams, they can now be triaged, exempted, and reported separately. The grouped recommendations are deprecated and will be removed on July 30, 2026, We suggest updating any automation, export rules, and ServiceNow integrations to target the new per-finding recommendations before that date.

That per-finding precision becomes even more powerful once you connect each finding to its source code and to the runtime resources it impacts. Defender for Cloud — part of Microsoft Defender suite — connects this code-to-runtime chain end-to-end. For example, an image built through Azure DevOps or GitHub, pushed to ACR, ECR, Google Artifact Registry, Docker Hub, or JFrog, and pulled by AKS, EKS, or GKE is one continuous evidence chain — traceable from a running container back to the pull request (PR) and line of code that introduced the risk. With GitHub Advanced Security integrated (GA), secrets, code, and dependency findings join the same attack story. The developer-first Defender for Cloud CLI runs the same scanner locally or in any CI/CD pipeline, with consistent exit codes for gating.

The Code-to-Runtime “Development phases” diagram: one continuous Code → Build → Ship → Runtime evidence chain, with a one-click path to open a GitHub issue.

In this diagram, you can see how we have embedded container security at every stage of the software development lifecycle (SDLC), not just the endpoints. At Code, GitHub Advanced Security and the Defender for Cloud CLI catch secrets, vulnerable dependencies, and insecure code before commit. At Build, the same scanner runs as a CI/CD gate — in GitHub Actions, Azure DevOps, Jenkins, or Bitbucket — failing the pipeline on critical findings. At Ship, registry scanning and Gated Deployment block risky or misconfigured images at the cluster door. And at Runtime, the sensor enforces anti-malware and binary-drift policy on the live workload. No stage is left as a blind spot, and a finding can be traced forward to the running pod or backward to the developer who introduced it.

Visibility without enforcement only creates backlog. Gated Deployment — a Kubernetes admission controller — uses the same vulnerability signal, you trust, to block risky images at the cluster level. It supports phased rollout (audit, then deny), targets rules by cluster, namespace, pod, image, or label, and runs across AKS (including AKS Automatic), EKS, and GKE. A newer extension gates on Kubernetes misconfigurations too. Posture practitioners also get KSPM at container granularity — Kubernetes security posture management, available through both Defender for Containers and Defender CSPM — and, on Azure, a new actionable recommendation, Upgrade Azure Kubernetes Service Version (preview), that helps you remediate vulnerabilities in AKS-managed system pods.

Misconfiguration gating rules in Defender for Cloud — block risky deployment before they reach production.

Coverage that matches containers’ evolution

Historically, many container security programs concentrated on managed Kubernetes clusters in AKS, EKS, and GKE. The 2026 reality is broader: a growing share of production runs on serverless container platforms that abstract the cluster away, many sensitive workloads sit behind private, network-isolated clusters, and platform teams increasingly standardize on hardened or distroless base images. The surfaces that were blind spots are now part of the same posture graph as everything else.

Serverless compute posture is now generally available across AWS Lambda, Azure Functions, and Web Apps, while Serverless containers posture (preview) takes the same idea to Azure Container Apps, ACI, and AWS Fargate. Together, they bring more of today’s cloud-native production footprint into the same posture graph.

Coverage also improves where platform teams are standardizing on locked-down environments. The long-standing gap around private EKS and GKE clusters is closed, bringing some of the hardest-to-reach environments into the same security model. Scanning now works on hardened images from Docker Hardened or Minimus, and runtime protection supports BottleRocket on EKS — with the full feature set also available in Azure Government, which matters for teams running regulated workloads.

Runtime threat protection that prevents, not just detects

Posture closes the door on attackers; runtime threat protection guards the room if they still succeed. The key shift is that the Defender for Containers sensor now adds prevention on top of detection. The goal is simple: stop malicious code before it runs. Anti-malware detection and prevention (GA) scans container workloads and Kubernetes nodes and, based on the policies you define, blocks malicious execution instead of only alerting. Those alerts then flow into Microsoft Defender XDR’s unified incident model.

The second is binary drift detection and prevention (preview). Containers are meant to be immutable. When a process starts from a binary that was not part of the original image, that is drift — and one of the highest-signal indicators of compromise in cloud-native workloads. Defender detects drifts and, with policy enabled, can now also block the drifted process before it executes.

Anti-malware and Drift policies can be scoped by cloud, cluster, namespace, image, or label, with allow-lists for legitimate cases.

Anti-malware policies can alert, block, or ignore — scoped to clusters, namespaces, pods, labels, or images.

Rounding out runtime protection, DNS-based threat detection (GA) catches command-and-control beaconing, DGA traffic, and exfiltration over DNS.

A unified approach to container security

Step back, and the bigger picture is simple. The same platform that secured your VMs and identities now extends across AKS, EKS, GKE, private clusters, serverless containers, and serverless compute. The same Code-to-Runtime chain that once tied Infrastructure as Code (IaC) findings to running infrastructure now connects Dockerfile commits — through CI/CD and any major registry — to the running pod. Admission control turns posture findings into prevention at deploy time, and runtime protection actively blocks. That is a continuous container security loop living inside Microsoft Defender — not a checklist bolted onto Kubernetes. And it rebalances the fight: as attackers use AI to find and exploit gaps faster, the durable answer is security teams using AI of their own — protecting and triaging at machine speed.

If you’ve already enabled container security with Microsoft, the clearest next step is to strengthen the core lifecycle stages first:

Code + build: connect GitHub Advanced Security and integrate the Defender for Cloud CLI into your pipelines so findings are caught early and CI/CD gates can fail builds before an image is pushed.
Ship: stand up Gated Deployment in audit mode on a non-production cluster, tune it, then flip to deny; extend it to Kubernetes misconfigurations.
Run: enable the Defender for Containers sensor, extend it to private EKS and GKE clusters, then tune anti-malware and binary-drift rules in Block mode — starting with your crown-jewel namespaces.
Extend protection: turn on serverless compute posture for Lambda, Functions, and Web Apps, and enable serverless container posture for Container Apps, ACI, or Fargate.

Ask Microsoft Anything: Microsoft Defender expands protection to AWS RDS

Trevor_Rusher — Tue, 09 Jun 2026 16:19:01 GMT

Hey all! We are currently answering questions over on the event page here:

https://aka.ms/DefenderAWSExpansionAMA

Come join and learn something about Defender for Cloud and the expansion of protection!

Exempt a specific container in MDC

ABhatia610 — Tue, 09 Jun 2026 15:25:11 GMT

I have this recommendation showing in defender.

Immutable (read-only) root filesystem should be enforced for containers

There are multiple containers inside AKS that are showing as "Unhealthy"

airflow/db1
airflow/sql1
airflow/scheduler1

Is there a way to exempt a specific container or the whole recommendation has to be exempted.

Thanks

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 04 Jun 2026 18:30:12 GMT

What's new in Defender for Cloud?

Defender for Cloud is now integrated into the Defender portal to bring together cloud security posture management and threat protection in a single experience. Read more about it here.

Cloud security reporting in the Defender portal is now in public preview

Customers can now create, customize, and share security insights across the organization through Defender portal’s integrated cloud security reporting capabilities. With these reporting capabilities, customers can view built-in reports like CNAPP Executive Summary, create custom reports, export to PDF and more. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blog(s) of the month

In May, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Check out the two short videos on Defender Portal integration and Start Secure Stay Secure with Defender for Cloud

GitHub Community

Check out this PS script and CLI to help you enable Defender for API at scale:

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Loyens & Loeff, a law and tax firm, that operates in a high complex environment, sought to modernize the digital workplace with Microsoft 365 Copilot, Defender for Cloud and Purview.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

The end of patching era for containers: Microsoft Defender for Cloud expands hardened image support

Yulia_Zhurbinsky — Tue, 02 Jun 2026 22:53:19 GMT

Why hardened images are becoming the new baseline for container image security

Container security is evolving beyond vulnerability scanning alone. Across the ecosystem - spanning container platforms, registries, and software supply chain tooling - customers are increasingly adopting hardened container images - images that are minimal by design, transparent in composition, and continuously maintained to reduce inherited risk at the base layer.

This shift is happening against a backdrop of increasingly fast-moving attacks. AI-assisted techniques - such as those demonstrated by Mythos-class tooling - continue to compress the time between vulnerability discovery and exploitation. In this environment, reducing exposure to exploitable vulnerabilities and attack surfaces in container images before deployment is becoming just as critical as detecting vulnerabilities after the fact.

Traditional container images are optimized for flexibility and reuse, not for security - meaning they are not designed to minimize included components, reduce attack surface, or limit inherited vulnerabilities by default. As a result, many base images include large package sets and transitive dependencies that significantly increase attack surface and vulnerability noise.

Hardened images take a different approach:

Minimal by construction, including only what’s required to run the workload

Reduced attack surface, limiting exploitable components

Strong transparency, with SBOMs and provenance metadata

Continuous maintenance, so vulnerabilities are addressed through rebuilding rather than downstream patching

For customers, this represents a shift from reactive CVE triage to preventative risk reduction at the image layer.

In practice, this changes how container image risk is managed - from prioritizing and patching vulnerabilities in place to replacing images with updated, rebuilt versions, making remediation more predictable and easier to scale across environments.

As hardened images become more widely adopted, organizations still need to continuously assess these images for vulnerabilities and compliance, since minimal or frequently rebuilt images can still introduce new risks over time or differ from expected configurations - making continuous image scanning and monitoring essential.

Microsoft Defender for Cloud’s approach: support choice, centralize visibility

Today, Microsoft Defender for Cloud already supports vulnerability assessment for hardened image providers such as Chainguard, alongside traditional Linux distributions. We recently expanded this coverage further with additional hardened image types, giving customers more flexibility to adopt secure-by-default images while continuing to scan these images and manage findings in a centralized Microsoft Defender for Cloud experience.

Microsoft Defender for Cloud does not prescribe a single hardened image solution. Instead, it focuses on enabling customer choice while providing consistent, centralized vulnerability assessment and posture management.

This capability builds on the container vulnerability assessment foundation powered by Microsoft Defender for Endpoint and Microsoft Defender Vulnerability Management (MDVM), bringing together high-fidelity vulnerability insights across the container lifecycle with support for modern, hardened image models.

From now on, Microsoft Defender for Cloud’s vulnerability assessment supports hardened image ecosystems including:

Chainguard images, rebuilt from source and designed to minimize inherited vulnerabilities

Minimus images, which are minimal and continuously rebuilt to ship with zero known CVEs at publish time

Docker Hardened Images (DHI), secure, minimal, production-ready base images maintained by Docker (recently added)

Photon OS-based images and other minimal operating system distributions

Across all of these, Microsoft Defender for Cloud’s experience remains consistent:

Images are scanned through the existing container vulnerability assessment pipeline

Findings surface in the same Azure and Defender portals

Policy evaluation, alerting, and compliance reporting stay centralized

Security teams do not need to onboard new scanners, manage separate dashboards, or maintain parallel remediation workflows. Hardened image adoption fits directly into existing Microsoft Defender for Cloud posture management.

What this means for customers

As hardened image adoption accelerates, Microsoft Defender for Cloud enables customers to adopt secure‑by‑default foundations without fragmenting their security posture.

The benefits are tangible:

Reduced vulnerability noise from inherited base‑image packages

Earlier risk reduction at the image layer

Consistent vulnerability assessment across hardened image providers

Centralized security posture, compliance, and reporting

Whether customers choose Chainguard, Minimus, Docker Hardened Images, Photon OS–based images, or a combination, Microsoft Defender for Cloud provides a single control plane for understanding and managing container image risk - without forcing a change in operational model.

How this works across hardened image providers

Microsoft Defender for Cloud supports multiple hardened image providers, enabling organizations to adopt secure‑by‑default container images while maintaining a consistent approach to vulnerability assessment and posture management.

While each provider takes a different approach to minimizing risk at the image layer, Microsoft Defender for Cloud ensures that all images are scanned through the same vulnerability assessment pipeline, with findings surfaced centrally for security teams to monitor, prioritize, and remediate.

Examples:

Minimus

Minimal, continuously rebuilt container images designed to ship with zero known CVEs at publish time. Microsoft Defender for Cloud enables native scanning of Minimus images stored in Azure Container Registry, allowing security teams to assess vulnerabilities and maintain centralized visibility without introducing new workflows.

Docker Hardened Images (DHI)

Production‑ready, minimal base images designed as drop‑in replacements for standard container images. By supporting DHI, Microsoft Defender for Cloud allows customers to adopt these hardened images while continuing to rely on the same vulnerability scanning, governance, and reporting capabilities.

Looking ahead

Hardened images are no longer niche - they are becoming a foundational element of modern container security. As attacker automation and AI‑assisted attack techniques continue to shorten response windows, reducing exposure at build and image layers becomes increasingly important.

Microsoft Defender for Cloud will continue expanding support for hardened and minimal image ecosystems, ensuring customers can evolve their image strategies without sacrificing visibility, control, or operational simplicity.

Security should start with what you build on - not with what you fix later.

Learn more: Scanning support for Docker Hardened container images

Start Secure, Stay Secure: How Microsoft is Closing the Gap from Code to Runtime

JasonWeber — Tue, 02 Jun 2026 21:22:01 GMT

Modern software applications composed of hundreds of artifacts, multiple programing languages, and cloud infrastructure provide an extensive attack surface that only continues to expand in the era of AI. According to Microsoft Threat Intelligence and industry research, threat actors are also increasingly leveraging AI-assisted techniques to accelerate vulnerability discovery and exploitation (Source: Digital Defense Report 2025). Rule-based scanning and manual review alone may not keep pace with the speed and scale of these emerging threats.

As AI-generated code grows exponentially, organizations need tools designed to apply security researcher-inspired techniques at scale, keeping pace with new development processes and a rising number of AI-powered threats. That is the challenge we set out to solve.

At Build 2026, we are taking two steps forward: the expanded preview of Codename MDASH, a multi-model agentic scanning system designed to find and validate exploitable vulnerabilities, and the general availability of the Microsoft Defender for Cloud and GitHub Code Security native integration, which connects runtime risk to code and bridges the gap between security and development teams in a single workflow.

Together, these announcements represent a shift in how organizations should address software security considerations across the development lifecycle, natively integrating into their existing tooling and work processes.

The Problem: Alert Fatigue, Disconnected Tools, and a Widening Gap

Industry data consistently shows that critical and high-severity vulnerabilities take an average of more than 100 days to remediate. Research suggests applications face attacks as frequently as once every three minutes (Source: Digital Defense Report 2025).

Security teams are overwhelmed with alerts they cannot easily prioritize and assign. Developers spend time investigating issues that may never be exploited in production. Both teams often rely on separate, non-integrated tools, making collaboration slower and more difficult. The result is a growing gap between how fast organizations ship code and how fast they can secure it.

The answer is not more alerts, but higher actionable findings, smarter triage, and workflows designed to support more efficient agentic remediation, fostering improved collaboration between security teams and developers.

Codename MDASH: Agentic Vulnerability Discovery (Expanded Preview)

Codename MDASH introduces a new approach to vulnerability discovery and validation. Built by Microsoft's Autonomous Code Security team, which includes members of the DARPA AI Cyber Challenge-winning Team Atlanta, codename MDASH orchestrates more than 100 specialized AI agents across an ensemble of frontier and distilled models to discover, debate, and validate exploitable security findings end to end.

Unlike single-model approaches, codename MDASH works as a coordinated system. Different agents scan code for potential vulnerabilities. A separate set of agents debate whether each finding is real and exploitable. A final set constructs proof-of-concept attacks to confirm the bugs exist. The goal is to deliver validated findings, like the test results listed below, intended to help teams focus on security issues that are more likely to be exploitable, rather than theoretical warnings.

Results from internal testing and the public CyberGym benchmark (developed by UC Berkeley researchers, covering 1,507 real-world vulnerability reproduction tasks across 188 open-source projects, as of May 2026):

16 New Vulnerabilities Discovered and Patched across the Windows networking and authentication stack, including four critical remote code execution flaws, all patched in the May 2026 Patch Tuesday release. (Source: MSRC CVE disclosures, May 12, 2026.)
MDASH identified all 21 planted vulnerabilities in a controlled test, with no false positives observed in that test. Results in broader production environments may vary. (Source: Microsoft Security Blog)
Near-Total Recall on Historical MSRC Cases 96% recall against five years of confirmed MSRC cases in clfs.sys and 100% recall in tcpip.sys. These are retrospective recall benchmarks on internal code with a finite case count; they indicate the system would have been useful had it existed at the time, but do not by themselves predict future performance. (Source: Microsoft Security Blog)
Codename MDASH recently jumped ~10% in less than three weeks to a new CyberGym industry benchmark score of 96.55%.

o CyberGym scores are self-reported by participating organizations; the benchmark code is public, but no independent party has verified any of the scores. Benchmark results do not necessarily reflect real-world performance across all environments. (Source: CyberGym public leaderboard, cybergym.ai)

What makes the architecture durable is its model-agnostic design. When a new model becomes available, the targeting, debating, deduplication, and proof stages do not need to be rewritten. That means every improvement in the underlying AI automatically makes your existing scans smarter, without requiring teams to rebuild context, retune plugins, or revalidate proving agents. The work you put in today keeps paying off tomorrow.

Codename MDASH will be in expanded preview at Build 2026. Please reach out to your Microsoft Account rep for more information.

Microsoft Defender for Cloud+GitHub Code Security: Now Generally Available

Codename MDASH brings a new class of multi-model agentic discovery to high-value targets. The Microsoft Defender for Cloud and GitHub Code Security native integration brings runtime context to vulnerability detections that developers already see in their pull requests, so both teams can prioritize what's exploitable and remediate inside the same workflow. This integration, now generally available, connects runtime context to code, so developer and security teams can prioritize and fix what matters.

Here is the core problem it solves: a vulnerability flagged in your codebase might look critical in isolation, but is it running in production? Is it internet-facing? Is it touching sensitive data? Those three questions should drive everything. Until now, getting those answers typically meant jumping between tools, chasing context, and hoping someone on the other team had the right information.

The integration changes that in three ways:

Real-time visibility across the app lifecycle so developer and security teams can collaborate in the tools they already use. Security teams can track the status of vulnerabilities detected by GitHub Code Security directly in Defender for Cloud. When remediation is needed, a security campaign alerts GitHub repository owners, and developers can open a GitHub issue straight from Defender for Cloud to track progress from fix to close.
Critical alert prioritization By connecting runtime context to code, developer teams will be able to prioritize exploitable issues. Security teams will be able to understand the traceability of the artifact from code to runtime and trace runtime threats directly to the code in GitHub. As a result, the most critical alerts will be fixed first.
Remediation time reduction AI-suggested fixes with Copilot Autofix and GitHub Copilot cloud agent will automatically be generated, making it faster for developers to help accelerate remediation.

Together, Defender and GitHub Code Security give security and engineering teams a shared, runtime-prioritized list of vulnerabilities, so the alerts developers see in their pull requests are the ones the security team has already confirmed are deployed, exposed, and worth fixing. Copilot Autofix turns those prioritized findings into review-ready pull requests, with developers in control of what merges. We believe this combination of runtime-to-code correlation and agentic AI remediation within a single integrated workflow is a meaningful differentiator. Check out our new onboarding videos to help you get started today.

How It All Fits Together: Code to Runtime

Codename MDASH and the Defender and GitHub Code Security integration are two parts of the same vision: enforcing security across the entire software lifecycle, from the first line of code to the running workload. By helping organizations find and fix vulnerabilities faster, development teams can help reduce time spent on security remediation and more time building new products.

At the code level, codename MDASH adds a new layer of multi-model agentic discovery focused on high-value targets like logic flaws, race conditions, and AI-specific risks such as prompt injection and insecure model endpoints. It complements the deep semantic analysis that GitHub Code Security already performs on every pull request with CodeQL. It validates findings using multiple AI models and aims to deliver proven results rather than theoretical warnings.

At the runtime level, Defender provides the context that turns a finding into an actionable priority: is this deployed, is it exposed, and does it matter right now? When a fix is needed, Copilot can assist with remediation, with the developer retaining control over what gets merged.

The developer stays in GitHub. The security team stays in Defender. Both can see how code problems become real security risks, and both can act on them with reduced context switching and fewer handoff delays.

Get Started

Microsoft Defender for Cloud + GitHub Advanced Security is now generally available. Set up the integration in the Defender for Cloud portal and connect your GitHub organization. [learn.microsoft.com]
Check out our new onboarding videos here: https://aka.ms/DefenderGHCSOnboardingVideos
Codename MDASH expanded preview launches at Build 2026.
Read the full technical deep dive: Defense at AI speed: Microsoft's new multi-model agentic security system tops leading industry benchmark.
Read the full Microsoft Security Build update: https://aka.ms/BUILD_SecurityBlog

With AI-powered vulnerability discovery, runtime-to-code context, and AI-assisted remediation built into the developer workflow, these tools are designed to help teams move faster while maintaining a strong security posture

Sources:

Microsoft Digital Defense Report 2025, MSRC Patch Tuesday trend data, industry publications on AI-assisted exploit development. Digital Defense Report 2025: https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2025
Microsoft Security Response Center (MSRC), "Security Update Guide — May 2026 Release Notes," May 12, 2026. https://msrc.microsoft.com/update-guide/releaseNote/2026-May
Microsoft Security Blog, "Defense at AI Speed: Microsoft's New Multi-Model Agentic Security System Tops Leading Industry Benchmark," May 12, 2026. https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/
GitHub and Microsoft internal analysis of enterprise security backlogs. See the Microsoft Defender for Cloud blog (aka.ms/SecureCodetoCloudBlog) for methodology.

Now Generally Available: Microsoft Defender for open source relational databases on AWS RDS

lisetteranga — Mon, 01 Jun 2026 17:11:16 GMT

Securing multicloud databases to help reduce risks

Open‑source (OSS) relational databases are becoming increasingly critical and increasingly targeted in organization of all sizes. As organizations adopt multicloud architectures, these databases often run across Azure and Amazon Web Services (AWS), while security tools remain fragmented. The result is inconsistent visibility into sensitive data, disconnected alerts, and limited insight into how database exposure translates into real risk.

Today, Microsoft announces the general availability (GA) of Microsoft Defender for open‑source relational databases with support for Amazon Relational Database Service (AWS RDS). Customers can gain visibility into potentially sensitive data, identify indicators of database threats, and support risk prioritization across Azure and AWS through a unified experience in Microsoft Defender for Cloud, with capabilities that continue to expand across environments.

This GA release highlights Microsoft’s existing protection for open‑source relational databases in Azure and extends the same database‑focused security signals, risk context, and investigation capabilities to AWS RDS: helping organizations strengthen database security the way modern applications are actually deployed.

What’s new with GA support for AWS RDS

Defender for open-source relational databases now provides GA support for security capabilities designed for enterprise cloud environments, including:

Amazon Aurora for PostgreSQL
Amazon Aurora for MySQL
Amazon RDS for PostgreSQL
Amazon RDS for MySQL
Amazon RDS for MariaDB

These capabilities are integrated directly into Microsoft Defender for Cloud, providing consistent visibility and protection across Azure and AWS environments.

Core security capabilities for multicloud databases

Defender for Cloud delivers database‑specific security signals that help teams move beyond isolated alerts to risk‑based prioritization. This strengthens Defender for Cloud’s visibility into databases security by extending sensitive data discovery insights and threat protection specifically to supported AWS resources. As part of this delivery, we’ve also added recommendations that help validate AWS RDS resources’ enablement, discovery, scanning and protection status.

Advanced threat protection at the database layer

Defender for Cloud detects suspicious access patterns and brute force attempts that indicate active database threats. Alerts are enriched with cloud and workload context to help security teams quickly determine which issues require immediate attention.

Built‑in sensitive data discovery

Automated, recurring and agentless scans help identify data that may be sensitive, such as payment details or credentials without requiring additional configuration in supported AWS resources. This visibility helps teams understand where high-risk data resides and focus protection efforts where exposure matters most.

Attack path analysis with cloud context

Rather than viewing alerts in isolation, Defender provides visibility into potential attack paths, showing how exposed databases, weak authentication, and sensitive data can combine into real attack scenarios. This capability, provided by also enabling Defender CSPM, enables teams to prioritize remediation that breaks the attack chain to not only their Azure resources but also AWS RDS databases.

Unified investigation with Microsoft Defender portal

Database alerts integrate with Microsoft Defender portal, allowing security operations teams to correlate database incidents with signals from identities, endpoints, and workloads to support investigation and response workflows. This plan allows for supported AWS RDS signals to be added and correlated as well.

Why this matters now

Together, these capabilities help organizations move beyond isolated database alerts toward risk‑based prioritization, which becomes especially critical as open‑source databases increasingly store high‑value and regulated data in multicloud architectures.

Customer outcomes: prioritized database risk across clouds

With GA support for AWS RDS, organizations can move from fragmented database security to prioritized risk management across Azure and AWS:

Detect real database threats by identifying risky access patterns tied directly to exposed databases.
Understand where sensitive data lives through built‑in discovery that highlights high‑risk data stores automatically.
See how attacks actually unfold using attack path analysis that connects exposure, misconfiguration, and data sensitivity and connecting those to actual alerts generated on the resource.
Customer can respond faster with database alerts integrated into Microsoft Defender XDR for unified investigation across environments and correlation into incidents and attack stories across various resources and plans.

Together, these outcomes help security teams move from reactive database monitoring to proactive risk reduction in multicloud architecture.

Database security as part of a unified CNAPP strategy

This GA milestone is part of Microsoft’s broader Cloud‑Native Application Protection Platform (CNAPP) approach, which brings together posture management, workload protection, and threat protection across the cloud lifecycle.

By integrating database security into CNAPP, Defender for Cloud ensures databases are not isolated controls, but a critical part of a unified view across applications, identities, workloads, and data to support risk reduction while maintaining operational efficiency.

Get started today

GA support for AWS RDS is available now.

Billing for this plan starts on June 1, 2026, and charges will appear on the July 2026 bill.

Enable Microsoft Defender for open‑source relational databases in the Azure portal to begin applying additional protections for open-source databases across Azure and AWS with unified visibility and risk‑based security.

Learn more → Cloud Security Solutions | Microsoft Security

Resources:

Learn more about Microsoft Defender for Cloud
Read the Defender for open‑source relational databases documentation
Explore sensitive data discovery
Review available trial options
Share your experience with Microsoft Defender for Cloud on Gartner Peer Insights

Public preview: Expanded coverage and unified management for SQL VA Express Configuration

Catalin Esanu — Tue, 19 May 2026 21:11:13 GMT

SQL Vulnerability Assessment (SQL VA) is a core capability in Defender for SQL that helps customers identify possible misconfigurations, excessive permissions, and other deviations from security best practices through continuous scanning of their databases. Traditionally, enabling SQL VA on SQL PaaS resources required customers to provision and maintain a dedicated Azure Storage account to hold scan results and baselines. In addition, managing SQL VA across resource types required different API endpoints, which made it harder to script consistent enablement and baseline management across a mixed SQL estate. For customers managing large SQL estates, this added operational overhead to onboarding and ongoing management. This friction may lead to inconsistent enablement across environments and leave gaps in vulnerability visibility.

To simplify this experience, Microsoft introduced Express Configuration, which uses Microsoft-managed storage and does not require a customer-provisioned storage account. Express Configuration is generally available for Azure SQL Database and is the recommended enablement mode for SQL VA, where supported.

This public preview extends Express Configuration to Azure SQL Managed Instance and Azure Synapse Analytics workspaces, and introduces a new preview API version that brings SQL VA management under a unified model across Azure SQL Database, SQL Managed Instance, Synapse workspaces, and SQL on machines (Azure VMs and Arc-enabled SQL Servers). Customers can now enable SQL VA on SQL Managed Instance and Synapse workspaces without provisioning a dedicated storage account and can manage SQL VA across all supported resource types through a single API.

Together, these changes broaden Express Configuration coverage across Azure SQL PaaS services and consolidate SQL VA operations under a single API, helping standardize how SQL VA is enabled and managed and reduce operational overhead across a customer's SQL estate.

What’s new in this release

Express Configuration support for additional Azure SQL PaaS services: Azure SQL Managed Instance (public preview) and Azure Synapse Analytics workspaces (dedicated SQL pools, public preview); Express Configuration for Azure SQL Database remains generally available.
Express Configuration is the default when enabling Defender for SQL on a resource from the UI.
New preview API version for unified SQL VA management across Azure SQL Database, SQL Managed Instance, Azure Synapse Analytics workspaces (Express Configuration only), and SQL on machines (Azure Virtual Machines and Arc-enabled SQL Servers).

Why use Express Configuration

Express Configuration simplifies how SQL Vulnerability Assessment is enabled and managed for Azure SQL Managed Instance and Azure Synapse Analytics workspaces, without changing the security coverage or rule set provided by SQL VA.

No customer-managed storage required. Express Configuration uses Microsoft-managed storage, so customers don’t need to provision or maintain storage accounts for scan results and baselines.
Automatic weekly scans and on-demand scans through the UI, unified API, or scripts.
Baseline management at scale, including setting baselines per finding or in bulk. Baseline changes take effect without waiting for the next scan to complete.

Unified management across SQL platforms

The latest preview API version enables a unified model for configuration, scanning, and governance for SQL Vulnerability Assessment across all supported SQL deployments:

Manage SQL VA across Azure SQL Database, SQL Managed Instance, and Azure Synapse Analytics workspaces.
Manage SQL VA across SQL on machines, including Azure Virtual Machines and Arc-enabled SQL Servers.
Use a consistent model for configuration, scans, results retrieval, and baseline management across supported resource types.

Limitations and prerequisites Permissions

Task	Required roles
View SQL vulnerability assessment results in Microsoft Defender for Cloud recommendations	Security Admin or Security Reader
Change SQL vulnerability assessment settings	Security Admin or SQL Security Manager
Access resource-level scan results or automated email links	Security Admin or SQL Security Manager

Classic Configuration conflict: If Classic Configuration is already enabled on a resource, enabling Express Configuration through the API will fail with an error. To migrate an existing Classic Configuration to Express Configuration, use the updated migration script.
UI enablement supports clearing Classic Configuration settings and re-enabling with Express Configuration.
SQL Managed Instance prerequisite: A system-assigned managed identity is required for Express Configuration to work on SQL Managed Instance.
Preview enablement scope: During public preview subscription-level enablement does not automatically apply Express Configuration to SQL Managed Instance or Synapse workspaces during public preview.
Reverting to Classic Configuration: After migrating to Express Configuration, reverting to Classic Configuration is possible programmatically but not through the UI.

Get started

Try it through the portal: Enable Express Configuration on a SQL Managed Instance or Synapse workspace through the Defender for Cloud portal, run an on-demand scan, and review findings in Defender for Cloud recommendations.
Automate your first steps: Use the SQL VA Express Configuration quickstart script to enable Express Configuration, discover databases, run scans, and manage baselines through the unified API.
Migrate from Classic Configuration: If you have Classic Configuration enabled on existing resources, use the migration script to move to Express Configuration.

Microsoft.Security/policies GET endpoint returning 404 — deprecated? What is the replacement?

mahendra_kamble_sumo — Fri, 15 May 2026 07:58:31 GMT

Hi,

We are using the Azure Security Center REST API (api-version=2015-06-01-preview) to retrieve security policies for a subscription. We are hitting a 404 Not Found error on the Get endpoint while the List

endpoint works fine. Looking for clarification on whether this resource type has been deprecated and what the modern replacement is.

---

Endpoints in use

List Security Policies (WORKING):

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/microsoft.Security/policies?api-version=2015-06-01-preview

This returns a valid JSON response with an array of policies, each having an id, name, type, and a properties object containing policyLevel, recommendations, pricingConfiguration,

securityContactConfiguration, etc.

Get Security Policy by Name (BROKEN):

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/policies/{policyName}?api-version=2015-06-01-preview

---

Error received

Not Found for url:

https://management.azure.com/subscriptions/<sub-id>/resourceGroups/AzureEventHubIT-resource-group/providers/Microsoft.Security/policies/AzureEventHubIT-resource-group?api-version=2015-06-01-preview

HTTP Status: 404 Not Found

---

What we've observed

- The List endpoint works and returns policies whose id values follow this exact structure:

/subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/microsoft.Security/policies/{policy-name}

- The policy name in the List response matches the resource group name (1:1 mapping), so we are passing the correct value to the Get endpoint.

- Despite using the exact name and resource group from the List response, the Get endpoint returns 404.

- We also checked the https://learn.microsoft.com/en-us/rest/api/defenderforcloud/operation-groups?view=rest-defenderforcloud-2015-06-01-preview and noticed that Security Policies does not appear as a

documented operation group in any version — including 2015-06-01-preview. The only documented groups for that version are: Discovered Security Solutions, Locations, Operations, and Tasks.

---

Questions

1. Has the Microsoft.Security/policies resource type at the resource group scope been officially deprecated or removed? If so, is there a migration guide or announcement?

2. Why does the List endpoint still respond successfully while the individual Get endpoint returns 404? Is the List endpoint returning legacy/cached data?

3. What are the recommended replacement APIs for the functionality that was in the old policies resource? Specifically we need equivalents for:

- properties.pricingConfiguration → Is this now covered by https://learn.microsoft.com/en-us/rest/api/defenderforcloud/pricings/get?view=rest-defenderforcloud-2024-01-01?

- properties.recommendations (patch, antimalware, diskEncryption, etc.) → Is this now https://learn.microsoft.com/en-us/rest/api/defenderforcloud/assessments?view=rest-defenderforcloud-2020-01-01?

- properties.securityContactConfiguration → Is this now Microsoft.Security/securityContacts (2020-01-01-preview)?

4. Is there any announced retirement date for the List endpoint as well?

Any official documentation links or migration guides would be very helpful.

Thank you.

Better together with Azure WAF + Microsoft Defender for Storage + Defender for Azure SQL Databases

Yura_Lee — Wed, 06 May 2026 17:22:23 GMT

Authored by: Fernanda_Vela , saikishor, Yura_Lee

Reviewed by: YuriDiogenes, Mohit_Kumar, Amir_Dahan, eitanbremler , Kitt_Weatherman

Introduction

Often, customers ask why additional workload protection is needed when a web application firewall is already in place. Azure Web Application Firewall (WAF) serves as a critical control at the application edge, inspecting inbound HTTP/S traffic and blocking common web-based exploits before they reach backend services. However, modern attack paths are no longer limited to the web entry point. Attackers increasingly target components that bypass HTTP/S inspection altogether such as direct access to storage and SQL through SDKs, native integration tools, private endpoints, or compromised identities and third-party integrations.

This is where Microsoft Defender for Cloud complements WAF. While WAF focuses on securing the application boundary, Defender for Cloud extends protection into the resource layer by providing Cloud-Native Application Protection Platform (CNAPP) capabilities, including security posture management and workload protection. Using resource-native signals, it helps identify misconfigurations and detect suspicious control-plane and data-plane activity that would otherwise remain invisible to perimeter controls.

The Azure Networking Security blog post “Zero Trust with Azure Firewall, Azure DDoS Protection, and Azure WAF: A practical approach” highlights WAF’s role in inspecting inbound HTTP/S traffic, detecting malicious request patterns (such as OWASP Top 10 vulnerabilities), and reducing direct exposure of backend endpoints by enforcing a controlled application entry point.

Building on that foundation, this blog focuses on a “better together” approach that combines WAF with Microsoft Defender for Cloud protecting storage and database. Through practical scenarios and posture insights, we will underline how these controls together:

Reduces attack surface at the application entry point
Continuously improves security posture through configuration and exposure analysis
Detects and responds to threats targeting storage accounts and SQL databases beyond the web perimeter

By the end of this post, you will understand how Defender for Cloud’s Storage and SQL protections extend the visibility provided by WAF, enabling protection not only at the edge, but also across the underlying data services. Together, these controls form a cohesive model that addresses both external attack vectors and internal or indirect access paths.

Note: This is not a deep configuration guide for rule tuning, nor a replacement for official product documentation. It is intended to help architects and security teams align responsibilities and understand how these services reinforce each other.

Architecture:

The architecture below shows the traffic flow and where each service fits in the lab used in this blog to simulate the attacks. Azure Application Gateway with WAF is the internet-facing entry point, inspecting inbound HTTP/S traffic before it reaches the backend. Behind it, Azure Firewall provides both network- and application-layer inspection for inbound and outbound flows. In the backend subnet, multiple VMs host the workload.

For our demonstration, we focus on a single host running:

OWASP Juice Shop (port 3000),
An upload API that writes to Azure Storage (port 8080)
An API that connects to Azure SQL Database (port 5000).

This setup allows us to simulate realistic attack paths originating both from the internet and from within the network.

Figure 1: Architecture that shows resources with Application Gateway with WAF, Azure Firewall Premium and inbound traffic

Note: The patterns in this blog apply to both Azure WAF platforms: Application Gateway WAF and Azure Front Door WAF. The lab uses Application Gateway WAF for the demonstration.

Now, let’s head to the next section where we dive deep into these services to understand their capabilities with some attacks, alerts and insights.

Azure Web Application Firewall at the Edge

As we may have understood by now, Azure WAF is the first layer of protection, inspecting external web traffic for malicious patterns. Each incoming request is evaluated against its rulesets to either allow, block or log this traffic by using its managed and custom rulesets. Now, what are these rulesets?

Azure WAF uses managed rule sets like the Default Rule Set (DRS) (version 2.2 as of this writing), which incorporate OWASP Top 10 protections and Microsoft threat intelligence to block common attacks (SQL injection, XSS, remote file inclusion, etc.) in real time. Additional managed sets include a Bot Protection rule set (to guard against malicious bots scraping content) and HTTP DDoS rule set (to detect Layer 7 DDoS patterns). Beyond the built-ins, you can define custom WAF rules for application-specific needs—blocking or allowing traffic based on attributes like geolocation, IP ranges, or specific URL paths.

Now let’s talk about an example scenario. In our lab, Azure WAF is protecting multiple backend services on different paths and ports. When an external attacker tries to exploit the Juice Shop app with a crafted XSSattack, Azure WAF immediately detects the malicious pattern and blocks the request at the gateway as seen below.

Figure 2: An XSS attack on the juiceshop website, immediately results in a 403 Forbidden as WAF catches this attack in the application layer.

However, WAF’s inspection is inherently limited to traffic it can see, primarily, the HTTP/S flows it fronts. Let’s say our attacker changes tactics: instead of trying to force malicious code through the web interface, they obtain a stolen storage key or credentials through phishing and attempt to access the Azure Storage account directly via APIs. This request never goes through WAF, so WAF cannot assess or block it. In such a case, Microsoft Defender for Storage’s threat detection monitors for such suspicious activity, for example by raising an alert about the unusual direct access or flagging a malware file uploaded to a blob container. Likewise, if our attacker exploited a weakness in application code to run malicious SQL commands on the database (whether through potentially harmful application or a suspicious service account), Defender for SQL monitors for and alerts anomalous query patterns or suspicious logins. This illustrates why WAF and Defender for Cloud are complementary: WAF stops web attacks at the door, while Defender for Cloud watches for threats that get inside or come through alternate doors.

Figure 3: Single-host lab architecture with Azure Application Gateway (WAF) and resource‑level protection

Figure 3 illustrates the key distinction: WAF inspects and protects the application entry point, while Defender for Cloud provides visibility into the resources themselves. Together, they cover both the path into the application and the behavior within the environment—forming a complete protection model across layers. Because not all access to storage and databases may flow through the application gateway, you also need resource-level posture and threat detection to see and stop activity that never appears in WAF logs.

Cloud Security Posture Management with Defender for Cloud

With the edge covered, the next challenge is reducing risk that originates from misconfiguration and resource exposure. Most successful attacks originate from exposed services and misconfigurations rather than direct application-layer exploits.

Microsoft Defender for Cloud’s storage and database protection provide security posture insights that help identify and prioritize these security gaps at the resource level. Defender for Cloud has visibility insights that capture the resources’ misconfigurations on the control and data plane via the Recommendations view in the Azure portal, as shown in the example below:

Figure 4: Juice Shop’s storage account and SQL server recommendations

Figure 4 is a list of recommendations organized by risk level for this particular environment. The security team should harden the “defendertestsai” storage asset by preventing shared access keys, and the “juiceshop” SQL database by provisioning an Entra administrator. Each recommendation will also provide guidance to remediate these findings.

The “Data & AI Dashboard” in Defender for Cloud, with Defender CSPM, will also provide security posture insight into storage, database and AI resources by surfacing their risks, alerts and sensitive data discovery all in one dashboard.

Figure 5: Juice Shop’s Sensitive data discovery and Data threat detection dashboard in Defender for Cloud’s “Data&AI section”.

Under Data closer look, in Figure 5, you can see in this example, starting from the left, sensitive information found in scanned resources, level alerts for databases and storage resources based on severity, templatized queries from the Cloud Security Explorer, and a graph displaying all internet exposed data resources below. These powerful insights on data resources all come from Defender for Cloud, designed to help customers harden their environment by priority through visibility across their entire data ecosystem based on risk level.

Figure 6: Juice Shop’s attack path “Internet exposed Azure VM with high severity vulnerabilities allows lateral movement to Critical Storage used by Azure AI Foundry”.

Attack paths are potential avenues in which an attacker can infiltrate and compromise data. In Figure 6 above, we see insight into not only the storage account itself, but the context around it: an internet exposed storage account is connected to other assets like a virtual machine and a managed identity that has permissions to manipulate data.

These Defender for Cloud security posture insights complement WAF and complete the defense-in-depth security approach: harden the data services so that even if an attacker reaches them the blast radius is smaller, and the likelihood of compromise is reduced.

Defender for Cloud’s advanced threat protection

Even in well-secured environments, attackers often interact directly with storage accounts or databases through identities, APIs, or trusted internal paths. Reducing exposure is critical but not sufficient. Detection is required once an attacker begins interacting with data Defender for Cloud’s advanced threat protection for Storage and SQL surfaces resource-level security alerts such as suspicious access patterns, anomalous queries, and malware detections—often with richer context than perimeter telemetry alone.

Let’s use a malware alert for a storage account in the Defender portal as an example:

Figure 7: Juice Shop’s storage account security alert “Malicious blob uploaded to storage account”.

Malware scanning is a common requirement for teams that process user uploads or must meet security benchmarks. In this lab, Juice Shop allows users to upload files (for example, feedback attachments), and the upload API writes those files to Azure Blob Storage.

Azure WAF inspects the HTTP request that delivers the upload headers, parameters, payload patterns and blocks web-layer attacks like XSS or SQLi. Scanning blob contents after they land is a different job, performed at the resource layer by Defender for Storage. With Defender for Storage malware scanning enabled, each uploaded blob is scanned; if the verdict is malware, Defender for Cloud raises an alert such as “Malicious blob uploaded to storage account” as shown in figure 7. Then, with Defender for Storage’s automated malware remediation, the malicious blog is set to soft-delete for quarantine and further analysis.

SQL databases are high-value targets for data access, privilege escalation, and exploitation of vulnerable applications. Database protection in Defender for Cloud has the visibility to provide customers with control plane and data plane level insight to alert on suspicious activity such as anomalous logons, unusual client applications, and injection-like query patterns.

For example, here’s a potential SQL injection alert for a database in the Defender portal:

Figure 8: Juice Shop’s database security alert on a potential SQL injection.

These alerts typically include investigation context such as the client application, client principal name, and the statement or pattern in question, along with severity to help you prioritize, as shown in Figure 8. From there, analysts can use recommended response actions (for example, to contain risky access paths or harden the database) to reduce the chance of repeat activity.

In practice, Defender for Cloud threat detection gives SOC teams prioritized, resource-specific alerts with the context needed to investigate quickly and take action at the storage and database layers.

Conclusion

Azure Application Gateway with WAF is a necessary control to reduce application-layer risk at the edge. But defense in depth requires the assumption that some threats will reach or target data services directly. By layering Microsoft Defender for Storage and Microsoft Defender for SQL on top of Azure WAF, you add continuous posture insights to reduce preventable exposure, plus threat protection that detects suspicious activity at the resource layer. Operated together, these services provide stronger prevention, better detection coverage, and clearer response paths than single control alone.

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Mon, 04 May 2026 16:47:10 GMT

What's new in Defender for Cloud?

Container runtime anti-malware detection and blocking and DNS Detection for Kubernetes is now GA in Defender for Containers for AKS, EKS, and GKE. Learn more about these announcements here and here.

Defender for Storage integration in Azure Portal Storage Center now Generally Available

Customers can now view Defender for Storage threat protection and security posture coverage directly in Storage Center, next to their storage resources to understand which storage accounts are protected, where malware scanning, activity monitoring and sensitive data discovery are enabled and identify security gaps in Azure Blog Storage and Azure File storage. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blogs of the month

In April, our team published the following blog posts we would like to share:

Securing multicloud (Azure, AWS & GCP) with Microsoft Defender for Cloud: Connector best practices

Defender for Cloud in the field

Check out the two short videos on Defender Portal integration and Start Secure Stay Secure with Defender for Cloud

GitHub Community

Check out the AI Red Teaming Workshop below:

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Photon Education, a Poland-based edtech company that uses Defender for Cloud to protect their App Services and databases immediately.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Securing multicloud (Azure, AWS & GCP) with Microsoft Defender for Cloud: Connector best practices

ckyalo — Fri, 10 Apr 2026 18:03:39 GMT

Many organizations run workloads across multiple cloud providers and need to maintain a strong security posture while ensuring interoperability. Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) solution that helps secure these environments by providing unified visibility and protection for resources in AWS and GCP alongside Azure.

Planning for multicloud security with Microsoft Defender for Cloud

As customers adopt Microsoft Defender for Cloud in multicloud environments, Microsoft provides several resources to support planning, deployment, and scalable onboarding:

Planning Guides: Multicloud Protection Planning Guide that walks through key design considerations for securing multicloud with Microsoft Defender for Cloud.
Deployment Guides: Connect your Azure subscriptions - Microsoft Defender for Cloud.

With the right planning and adoption strategy, onboarding to Microsoft Defender for Cloud can be smooth and predictable. However, support cases show that some common challenges can still arise during or after onboarding AWS or GCP environments. Below, we walk through frequent multicloud scenarios, their symptoms, and recommended troubleshooting steps.

Common multicloud connector problems and how to resolve them

1. Problem: Removed cloud account still appears in Microsoft Defender for Cloud

The AWS/GCP account is deleted or removed from your organization, but in Microsoft Defender for Cloud it still appears under connected environments. Additionally, security recommendations for resources in the deleted account may still show up in recommendations page.

Cause

Microsoft Defender for Cloud does not automatically delete a cloud connector when the external account is removed. The security connector in Azure is a separate object that remains unless explicitly removed. Microsoft Defender for Cloud isn’t aware that the AWS/GCP side was decommissioned as there’s no automatic callback to Azure when an AWS account is closed. Therefore, the connector and its last known data linger until manually removed.

Solution

Delete the connector to clean up the stale entry. Use one of the following methods.

Option 1: Use the Azure portal

Sign in to the Azure portal.
Go to Microsoft Defender for Cloud > Environment settings.
Select the AWS account or GCP project that no longer exists.
Select Delete to remove the connector.

Option 2: REST API

Delete the connector by using the REST API: Security Connectors - Delete - REST API (Azure Defender for Cloud).

Note: If a multicloud organization connector was set up and the organization was later decommissioned or some accounts were removed, there would be several connectors to clean up. Start by deleting the organization’s management account connector, then remove any remaining child connectors. Removing connectors in this order helps prevent leftover dependencies.

Additional guidance see: What you need to know when deleting and re-creating the security connector(s) in Defender for Cloud.

2. Problem: Identity provider is missing or partially configured

After running the AWS CloudFormation template, the connector setup fails. Microsoft Defender for Cloud shows the AWS environment in an error state because the identity link between Azure and AWS is not established.

On the AWS side, the CloudFormation stack exists, but the required OIDC identity provider or the IAM role trust policy that allows Microsoft Defender for Cloud to assume the role via web identity federation is missing or misconfigured.

Cause

The AWS CloudFormation template doesn’t match the correct Azure subscription or tenant. This can happen if:

You were signed in to the wrong Azure directory when generating the template.
You deployed the template to a different AWS account than intended.

In both cases, the Azure and AWS IDs won’t align, and the connector setup will fail.

Solution

Verify your Azure directory and subscription.
- In the Azure portal, go to Directories + subscriptions and make sure the correct directory and subscription are selected before you set up the connector.

Clean up the incorrect configuration
- In AWS, delete the CloudFormation stack and any IAM roles or identity providers it created.
- In Microsoft Defender for Cloud, remove the failed connector from Environment settings.

Re-create the connector.
- Follow the steps in Connect your Azure subscriptions - Microsoft Defender for Cloud to generate and deploy a new CloudFormation template using the correct Azure and AWS accounts.

Verify the connection.
- After the connection succeeds, the AWS environment shows Healthy in Microsoft Defender for Cloud. Resources and recommendations begin appearing within about an hour.

3. Problem: Duplicate security connector prevents onboarding

When an AWS or GCP connector is added in Microsoft Defender for Cloud, onboarding fails with an error that indicates another connector with the same hierarchyId already exists. In the Azure portal, the environment shows Failed, and no resources appear in Microsoft Defender for Cloud.

Cause

Microsoft Defender for Cloud allows only one connector per cloud account within the same Microsoft Entra ID tenant. The hierarchyId uniquely identifies the cloud account (for example, an AWS account ID or a GCP project ID). If the account was previously onboarded in another Azure subscription within the same tenant, you can’t onboard it again until the existing connector is removed.

Solution
Find and remove the existing connector and then retry onboarding.

Step 1: Identify the existing connector

Sign in to the Azure portal.
Go to Microsoft Defender for Cloud > Environment settings.
Check each subscription in the same tenant for a pre-existing AWS account or GCP project connector.

If you have access, you can also query Azure Resource Graph to locate existing connectors:

| resources | where type == "microsoft.security/securityconnectors" | project name, location, properties.hierarchyIdentifier, tenantId, subscriptionId

Step 2: Remove the duplicate connector
Delete the connector that uses the same hierarchyId. Follow the steps outlined in the previous troubleshooting scenario for deleting security connectors.

Step 3: Retry onboarding After the connector is removed, add the AWS or GCP connector again in the target subscription. If the error persists, verify that all duplicate connectors were deleted and allow a short time for changes to propagate.

Conclusion

Microsoft Defender for Cloud supports a strong multicloud security strategy, but cloud security is an ongoing effort. Onboarding multicloud environments is only the first step. After onboarding, regularly review security recommendations, alerts, and compliance posture across all connected clouds. With the right configuration, Microsoft Defender for Cloud provides a single source of truth to maintain visibility and control as threats continue to evolve.

Further Resources:

Microsoft Defender for Cloud – Multicloud Security Planning Guide – Start here to design your strategy for AWS/GCP integration, with guidance on prerequisites and best practices.
Connect your AWS account - Microsoft Defender for Cloud.
Connect your GCP project - Microsoft Defender for Cloud.
Troubleshoot connectors guide - Microsoft Defender for Cloud.

We hope this guide helps you successfully implement end-to-end ingestion of Microsoft Intune logs into Microsoft Sentinel. If you have any questions, feel free to leave a comment below or reach out to us on X @MSFTSecSuppTeam.

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 02 Apr 2026 20:43:28 GMT

What's new in Defender for Cloud?

Kubernetes gated deployment is now generally available for AKS automatic clusters. Use help to deploy the Defender for Containers sensor to use this feature. More information can be found here.
Grouped recommendations are converted into individual ones to list each finding separately. While grouped recommendations are still available, new individual recommendations are now marked as preview and are not yet part of the Secure Score. This new format will allow for better prioritization, actionable context and better governance and tracking. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blogs of the month

In March, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Revisit the malware automated remediation announcement since this feature is now in GA!

GitHub Community

Check out the new Module 28 in the MDC Lab: Defending Container Runtime from Malware with Microsoft Defender for Containers

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring ManpowerGroup, a global workforce solutions leader, deployed Microsoft 365 E5, and Microsoft Security to modernize and future-proof their cyber security platform. ManpowerGroup leverages Entra ID, Defender for Endpoint, Defender for Identity, Defender for O365, Defender for Cloud, Microsoft Security Copilot and Purview to transform itself as an AI Frontier Firm.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe