Defender for Cloud Now Covers Serverless Containers: ACA and ACI Posture
We kept running into the same gap on client Azure estates: Defender for Cloud's container posture story was strong for AKS, and almost silent for anything serverless. A team would stand up an Azure Container Apps environment to avoid managing a cluster, and that workload would sit outside the posture graph entirely. No misconfiguration recommendations, no inventory entry, nothing to show an auditor asking "what's your container coverage." Microsoft shipped the fix as GA on September 1, 2026: Defender for Cloud support for Azure Container Apps (Serverless Containers Posture).
This closes a real hole. It also comes with a billing wrinkle worth flagging before a client's next invoice surprises them.
What actually shipped
The Serverless Containers component inside Defender CSPM now covers two resource types explicitly: Azure Container Apps (ACA) and Azure Container Instances (ACI). Per the CSPM concept doc, these sit in a billable-resource table alongside Serverless protection (Function Apps, Web Apps). ACI has had posture coverage for a while; the new GA brings ACA environments into the same workflow, so a security team reviewing serverless container risk isn't stitching together two different views.
Our read: this is the posture layer catching up to adoption. ACA has become the default choice for teams that want containers without the Kubernetes operational tax, and Defender for Cloud not seeing those workloads was a blind spot we've called out in more than one Sentinel onboarding.
How it fits the five domains
Defender for Containers organizes its coverage into five domains per the introduction doc: security posture management, vulnerability assessment, run-time threat protection, software supply chain protection, and deployment & monitoring. The ACA addition lands squarely in the first domain. It's agentless: continuous API-based discovery, misconfiguration detection with mitigation guidance, and inventory entries you can pull through Security Explorer alongside your AKS clusters, pods, and images.
What it is not, based on what's documented: a run-time sensor for ACA workloads. The vulnerability assessment and run-time threat protection domains are described in terms of registry images, running containers, and Kubernetes nodes. Serverless containers show up specifically under "Discovery and posture for serverless container workloads" as a Defender CSPM feature, not under the vulnerability-scanning or threat-detection rows. If you're expecting ACA-equivalent of agentless VM vulnerability scanning, check the current Defender for Containers documentation before promising that to a client; we're writing around it here because the sources in front of us don't confirm it.
The billing detail that will bite someone
This is the part we'd put in bold in a client email. From the CSPM concept doc's billable-resource table:
To protect Azure Container Apps and Azure Container Instances and begin billing for this capability, enable the Serverless Containers component in Defender CSPM. Enable Registry access for full Serverless Containers coverage. Billing became effective July 1, 2026.
Two things to sit with. First, billing for serverless containers started July 1, 2026, which predates this September 1 GA announcement. That tells us ACI billing was already live and this GA extends the same billing boundary to ACA, rather than starting a fresh clock. Second, "Enable Registry access for full Serverless Containers coverage" is a second toggle. Turning on the Serverless Containers component without registry access gets you partial coverage; you need both switches for the full posture picture. We've seen teams flip the headline feature on, assume they're covered, and never touch the registry access setting.
There's a parallel pattern here worth remembering from the same table: Serverless protection for Function Apps and Web Apps became billable April 1, 2026. Microsoft has been incrementally turning on billing for CSPM sub-components tied to specific resource types rather than changing the top-level Defender CSPM price. If you're the one reconciling an Azure bill against a security budget, check which sub-components are enabled per subscription, not just whether Defender CSPM is "on."
Checking what's enabled right now
Before you tell a client their ACA environments are covered, confirm the plan state. From the Azure CLI:
# Check Defender CSPM plan status on a subscription
az security pricing show \
--name "CloudPosture" \
--query "{plan:pricingTier, extensions:extensions}" \
-o table
# List the extensions (this is where Serverless Containers and
# registry access toggles live) to confirm they're actually on
az security pricing show \
--name "CloudPosture" \
-o json | jq '.extensions[] | select(.name | test("Serverless|Registry"))'
Run this per subscription, not just once at the tenant root. We've found plenty of estates where Defender CSPM is enabled at the management group level but a specific subscription has an override, or where a subscription was added to the tenant after the policy assignment ran and never picked up the setting.
Inventory and recommendations, not detections
Once the component is enabled, the ACA and ACI resources start appearing in Defender for Cloud's asset inventory and generate security recommendations the same way any other CSPM-covered resource does. That means you can pull them into a Microsoft Sentinel workbook or query them from the security graph in Security Explorer for attack path analysis, assuming you're on the paid Defender CSPM plan (attack path analysis and the security graph are listed as Defender CSPM-only features, not available on the free Foundational CSPM tier).
A rough query shape, assuming your Sentinel workspace ingests Defender for Cloud assessments:
SecurityRecommendation
| where RecommendationName has_any ("Container Apps", "Container Instances")
| summarize count() by RecommendationName, RecommendationSeverity
| order by RecommendationSeverity desc
Treat the table and field names in your own environment as something to verify against your actual Log Analytics schema before you ship this into a production detection. We're giving you the shape of the query, not a guarantee it matches your workspace's exact ingestion.
Where this leaves multicloud shops
The CSPM doc is explicit that Defender CSPM supports Azure, AWS, and GCP, with a separate multicloud workload protection support matrix for how AWS and GCP container coverage compares. If your estate runs Fargate or Cloud Run alongside ACA, don't assume parity. The GA announcement here is Azure-specific; nothing in what Microsoft published confirms equivalent serverless container posture timelines for the other two clouds. If a client asks us "does this mean my AWS Fargate tasks are covered too," the honest answer right now is no, check the multicloud support matrix directly, because we don't have a source confirming that scope.
Next steps
If you're running Container Apps and want a straight answer on whether Defender CSPM is actually watching them, get in touch and we'll audit the plan configuration alongside your broader detection engineering posture.
