Microsoft Defender for Cloud 2026: New Features Deep-Dive

The Integration Work Microsoft Does Not Do For You

Three weeks after the January 2026 GA release of Defender for Cloud's AI workloads protection plan, a detection engineer at a financial services firm opened the Security Alerts blade and found 47 new alert types she had never seen before. None of them had fired. The plan was enabled. The model endpoints were running. The alert rules existed in the portal. Her SIEM had no corresponding analytics rules imported, and she had been flying blind for three weeks without knowing it.

That pattern repeats with every major Defender for Cloud release cycle: Microsoft ships capabilities in GA, but the integration work (Log Analytics workspace schema updates, Sentinel analytics rule imports, alert suppression tuning, Bicep baseline updates) is left entirely to the operator.

The 2026 feature wave is the largest update to Defender for Cloud since the product rebranded from Azure Security Center. This article covers what changed, what the operational impact actually is, and the specific configuration steps needed to capture value from each new capability. For broader context on where Defender for Cloud fits against Wiz and Orca, see the [CSPM comparison guide](/blog/best-cspm-tools-2026-defender-for-cloud-vs-wiz-vs-orca-vs-prisma-cloud).

---

Copilot for Security Integration

What Changed

Defender for Cloud now surfaces a Copilot button on Security Recommendations, Security Alerts, and Attack Path Analysis views. Clicking it launches an embedded Copilot for Security session with the current resource context pre-loaded. The integration went GA in November 2025 for global tenants.

This is not a chatbot bolted to the sidebar. Copilot for Security in the Defender for Cloud context has three specific, useful functions:

Recommendation remediation guidance: Natural-language explanation of why a recommendation exists, what the blast radius is, and a Bicep or CLI remediation snippet generated with the specific resource pre-populated (subscription ID, resource name, current configuration).

Alert investigation: For complex correlated alerts (for example, "Credential access from Tor exit node followed by lateral movement to storage"), Copilot synthesizes the alert chain, queries related signals from Defender XDR, and returns an incident narrative with TTPs mapped to MITRE ATT&CK.

Attack path explanation: The attack path graph is visual; Copilot verbalizes what a path means in operational terms: which systems are in the blast radius, which intervention points exist, and which ones reduce risk most for the least remediation effort.

What It Costs

Copilot for Security is billed on Security Compute Units (SCUs). Each investigation session consumes SCUs. If you have an existing Copilot for Security license (consumed through the standalone portal), those same SCUs apply to the Defender for Cloud integration. Without a standalone license, SCUs are purchasable through the Defender for Cloud billing screen.

Copilot cannot modify configurations, trigger remediations, or write to your environment. It is read-oriented. Remediations still require human execution.

Sentinel Integration Requirement

The Copilot investigation context is populated from the Defender for Cloud alert payload plus connected Sentinel workspace data. If your Sentinel workspace does not have the SecurityAlert and SecurityIncident tables linked to Defender for Cloud, Copilot's investigation output is shallow: it works from the alert payload alone without cross-signal correlation.

Verify the Defender for Cloud alert connector is bidirectional:

az sentinel data-connector list \
  --resource-group <rg> \
  --workspace-name <sentinel-workspace> \
  --query "[?kind=='AzureSecurityCenter'].{Name:name, State:properties.dataTypes.alerts.state}" \
  --output table

If State is not Enabled, fix the connector before enabling any plan that generates new alert types. Otherwise you will be in the same position as the engineer above: plans enabled, alerts surfaced in the portal, SIEM dark.

---

AI Workloads Protection Plan

Coverage

The Defender for Cloud AI workloads protection plan went GA in February 2026. Pricing is per million tokens processed across monitored endpoints. The plan covers Azure OpenAI deployments, Azure AI Foundry online endpoints, and (in preview) Azure Machine Learning managed online endpoints.

Coverage at GA:

Detection Category	What It Detects	Alert Latency
Prompt injection	Direct injection attempts in user input	Near real-time (under 60s)
Indirect prompt injection	Instructions embedded in documents or tool results	Near real-time
Jailbreak attempts	Role-play, DAN, and known bypass patterns	Near real-time
Anomalous inference volume	Token/request spikes vs. 14-day baseline	5-minute aggregation
Sensitive data in outputs	PII, credentials, secrets in model responses	Near real-time
Model access from unusual geolocation	IP geolocation delta from baseline	Per-request

What is not covered at GA: grounding data integrity (blob writes to RAG containers), model fine-tuning data exfiltration, multi-tenant API key sharing patterns, and model catalog import anomalies (Activity Log only). The [Azure AI Foundry security threat model](/blog/azure-ai-foundry-security-threat-model-rbac-governance) covers those gaps with compensating controls.

Enabling the Plan

az security pricing create \
  --name "AI" \
  --tier "Standard" \
  --subscription <subscription-id>

Enabling the plan alone is not enough. For Azure OpenAI, you must also enable diagnostic settings to forward RequestResponse logs to a Log Analytics workspace. Without those logs, Defender has no content to analyze for prompt injection or sensitive data in outputs:

az monitor diagnostic-settings create \
  --name "defender-ai-monitoring" \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<aoai-name> \
  --workspace /subscriptions/<sub-id>/resourceGroups/<rg>/providers/microsoft.operationalinsights/workspaces/<law-name> \
  --logs '[{"category":"RequestResponse","enabled":true,"retentionPolicy":{"days":90,"enabled":true}}]'

The RequestResponse log category is what feeds content analysis. Teams that only enabled Audit logs (the default many configure) get access control events but no prompt or response content flowing to Defender.

False Positive Baseline Period

The anomalous inference volume detection uses a 14-day rolling baseline. Newly deployed endpoints generate volume anomaly alerts frequently in the first two weeks, even under normal traffic, because the baseline has insufficient history. Suppress these alerts by type for new endpoints during the learning period:

az security alert suppress \
  --alert-type "AI_AnomalousInferenceVolume" \
  --reason "New endpoint learning period" \
  --expiry-date <date-14-days-out> \
  --subscription <subscription-id>

Remove the suppression after the learning period ends. Do not suppress indefinitely; this alert type catches real anomalies after the baseline is established.

---

DevOps Security: Three Changes That Matter

1. Automatic Code-to-Cloud Traceability

Previously, linking a cloud resource finding back to the IaC that created it required manual resource tagging. Now, if you deploy via Azure DevOps or GitHub Actions pipelines with the Defender DevOps extension installed, resources receive automatic tags: SourceRepoURL, SourceBranch, and CommitId. A Defender for Cloud recommendation on a misconfigured storage account now includes a direct link to the Bicep file and line number that configured it.

Operational implication: your remediation workflows can now route directly to the IaC team responsible for the resource rather than requiring manual triage to find the source of a misconfiguration.

2. GitHub Advanced Security Secrets Surface in Defender

GitHub Advanced Security secret scanning results now flow into the Defender for Cloud DevOps security findings alongside cloud posture findings. Discovered secrets (API keys, connection strings, certificates) appear in the same pane as cloud security recommendations, with severity ratings and direct links to the committing developer.

Secret coverage for Azure-specific types:

Secret Type	Defender Detection	Severity
Azure Storage account key	Yes	High
Azure SAS token	Yes (scope-dependent)	Medium-High
Azure Service Principal client secret	Yes	High
Azure Function host key	Yes	Medium
Azure Cognitive Services key	Yes	High
Entra ID client secret	Yes	Critical

When a secret is detected, the finding includes commit hash, repository, and whether the secret is still valid. Defender attempts a non-destructive validity check for Azure-type secrets. Prioritize findings marked "Verified Active" above all others in the remediation queue.

3. Container Image Scanning at Push Time

Defender for Containers now scans images pushed to Azure Container Registry at push time rather than on a scheduled batch. Findings appear in the DevOps blade linked to the pipeline that pushed the image. For compliance-gated pipelines, this means you can fail a deployment based on a Defender vulnerability finding before the image ever reaches a running cluster.

Configuring the DevOps Connector

az security devops github-owner create \
  --owner-name <github-org-name> \
  --resource-group <rg> \
  --security-connector-name <connector-name>

The connector requires repo scope on a GitHub App installation. Use a dedicated machine user account for the installation. The machine user needs read-only repository access; Defender for Cloud does not require write access for DevOps security posture scanning.

---

Defender CSPM: Attack Path Analysis Updates

New Path Detectors

Defender CSPM added 40+ new attack path types in early 2026. The three highest signal-to-noise paths in Azure environments:

Internet-exposed VM to Key Vault via Managed Identity: Detects when a VM with a public IP and open inbound NSG rules has a system-assigned managed identity with Key Vault Secrets User or higher. This path appears in roughly 15% of subscriptions reviewed. Almost always a dev/test environment promoted to production with the NSG left open.

Overprivileged service principal to storage exfiltration: Identifies service principals with Storage Blob Data Reader or higher on storage accounts containing classified data (requires Purview integration for sensitivity label propagation to work). High-value finding when paired with a Defender for Storage sensitive data discovery result on the same account.

Container escape to node identity: Flags AKS node pools where pods run as root and the node pool identity has more than Reader access on other Azure resources. A container escape becomes cloud lateral movement. See the [Kubernetes security best practices guide](/blog/kubernetes-security-best-practices-2026) for the pod security standards that close this path.

Querying Attack Paths

az security attack-path list \
  --subscription <subscription-id> \
  --query "[].{Title:displayName, Severity:severity, Type:attackPathType}" \
  --output table

For a KQL remediation queue sorted by severity:

SecurityRecommendation
| where RecommendationName contains "attack path"
| where RecommendationState == "Unhealthy"
| extend ResourceId = tostring(split(AssessedResourceId, "/providers")[0])
| project TimeGenerated, ResourceId, RecommendationName, Severity
| order by
    case(Severity == "High", 0, Severity == "Medium", 1, 2) asc,
    TimeGenerated desc

---

API Security Posture Management

API security posture management went GA in Defender for Cloud in Q1 2026. This is a posture feature, not a runtime detection feature. It does not generate real-time alerts: it generates recommendations.

What It Scans

Defender API Security Posture discovers APIs across Azure API Management instances, Azure App Service apps with detected REST endpoints (via traffic analysis), and Azure Function Apps with HTTP triggers. For each discovered API it assesses three things:

Authentication coverage: Is every operation behind an auth requirement? Does any operation accept unauthenticated calls?
Sensitive data exposure: Does any endpoint return data matching PII, payment card, or credentials patterns in sampled responses?
Unused APIs: Endpoints with no traffic in 30+ days represent high attack surface with likely no one watching alerts.

Enabling API Posture

az security pricing create \
  --name "Api" \
  --tier "Standard" \
  --subscription <subscription-id>

Allow 24 hours for APIM discovery and 72 hours for App Service and Functions (traffic analysis requires observation time).

The Unauthenticated Endpoint Finding

API_NoAuthentication is the highest-value finding from API posture. About 30% of subscriptions have at least one unauthenticated endpoint in practice. The pattern is almost always the same: a /health or /status path added for a load balancer probe, forgotten, and never scoped to the VNet.

az security sub-assessment list \
  --assessed-resource-id /subscriptions/<sub-id> \
  --query "[?contains(displayName,'authentication')].{Finding:displayName, Resource:resourceDetails.id, Status:status.code}" \
  --output table

Triage: is the unauthenticated endpoint reachable from the public internet? If yes, remediate immediately. If it's VNet-internal only (NSG blocking public inbound), it's lower urgency but should still have auth added before NSG rules change.

---

Defender for Storage: Agentless Malware Scanning

Near-Real-Time Scanning

Defender for Storage's agentless malware scanning now runs on blob writes within 60 seconds rather than on a scheduled batch. When a blob is written to a monitored storage account, Defender initiates a scan. Clean files are tagged MalwareScanningResult: No threats found. Infected files trigger a Defender alert and, if configured, automated blob deletion or quarantine to a separate container.

Bicep Configuration

resource storageDefender 'Microsoft.Security/defenderForStorageSettings@2023-01-01' = {
  name: 'current'
  scope: storageAccount
  properties: {
    isEnabled: true
    malwareScanning: {
      onUpload: {
        isEnabled: true
        capPerGbPerMonth: 5000
      }
      sensitiveDataDiscovery: {
        isEnabled: true
      }
    }
    overrideSubscriptionLevelSettings: true
  }
}

The capPerGbPerMonth parameter is critical. Without a cap, Defender scans all uploads regardless of volume. For high-throughput storage accounts (logs, telemetry), uncontrolled scanning becomes expensive. Set a per-GB-per-month cap that reflects your budget, and alert on the StorageDefenderCap metric in Azure Monitor when approaching the ceiling: at the cap, scanning stops silently.

The sensitiveDataDiscovery flag enables Defender to sample blob content and flag storage accounts containing PII, payment card data, or credential patterns. This runs independently of malware scanning and bills separately. It does not require Purview integration and uses Defender's built-in classifiers.

---

Regulatory Compliance Changes

New Frameworks Added

Defender for Cloud added these compliance frameworks in early 2026:

NIS2 (EU Network and Information Security Directive 2): applicable to European organizations in critical infrastructure sectors
DORA (Digital Operational Resilience Act): financial sector ICT risk management requirements
CIS Azure Benchmark v3.0: updated from v2.0 with new controls for AI services, Container Apps, and API Management

Deprecation Notice

Azure CIS 1.1.0 and Azure CIS 1.3.0 benchmarks are deprecated and scheduled for removal in July 2026. If you have custom Azure Policy initiatives or reporting pipelines based on these benchmarks, migrate to CIS Azure v3.0 before the deprecation date. Post-removal, the compliance dashboard shows N/A for affected controls rather than a graceful degradation.

---

KQL: Detection Queries for New Capabilities

AI Workload Alert Volume Baseline

Run this before building suppression rules to understand what volume and alert type distribution you are dealing with on newly covered endpoints:

SecurityAlert
| where AlertType startswith "AI_"
| where TimeGenerated > ago(30d)
| summarize AlertCount = count() by AlertType, bin(TimeGenerated, 1d)
| order by TimeGenerated desc, AlertCount desc

High-volume AI_AnomalousInferenceVolume in the first 14 days is expected. High-volume AI_PromptInjection or AI_SensitiveDataInOutput is not expected and requires immediate investigation.

DevOps Secret Findings With Repository Context

SecurityRecommendation
| where RecommendationName contains "secret"
      or RecommendationName contains "credential"
| where RecommendationState == "Unhealthy"
| extend ResourceInfo = parse_json(RecommendationAdditionalData)
| project TimeGenerated, ResourceId, RecommendationName,
    Repository = tostring(ResourceInfo.sourceRepoUrl),
    CommitId = tostring(ResourceInfo.commitId),
    SecretValid = tostring(ResourceInfo.isActive),
    Severity
| where SecretValid == "true"
| order by Severity asc

The SecretValid == "true" filter isolates findings where Defender confirmed the secret is still live. These are the critical-priority items for immediate rotation.

New Attack Paths Created in Last 7 Days

SecurityRecommendation
| where RecommendationName contains "attack path"
| where RecommendationState == "Unhealthy"
| where TimeGenerated > ago(7d)
| extend ResourceId = tostring(split(AssessedResourceId, "/providers")[0])
| project TimeGenerated, ResourceId, RecommendationName, Severity
| order by TimeGenerated desc

Use this as a weekly digest query. New attack paths created in the past week are the most likely to be tied to recent infrastructure changes (new VMs, new role assignments, new public endpoints) and the easiest to remediate before they become accepted background noise.

---

What Has Not Improved

Governance assignment is still manual. Defender for Cloud recommendations still require manual owner assignment, due date setting, and tracking. The governance feature exists but integrating it with ITSM systems (ServiceNow, Jira) requires custom Logic Apps. This has not improved in 2026 and remains the primary friction point for teams trying to operationalize recommendations at scale.

GCP coverage lags AWS significantly. Attack path analysis for GCP is shallower than for Azure. If your environment spans Azure and GCP, do not assume equivalent coverage.

Alert fatigue on new plan activation. Enabling all Defender plans simultaneously on an unhardened subscription can generate thousands of recommendations within 24 hours. Enable plans one at a time: start with Defender CSPM, then Servers, then Storage, then AI. Allow a two-week hardening period between each before enabling the next.

---

Hardening Checklist

[ ] Sentinel AzureSecurityCenter connector verified as Enabled before activating any new Defender plans
[ ] AI workloads plan enabled: az security pricing show --name "AI" returns Standard
[ ] Azure OpenAI RequestResponse diagnostic logs flowing to Log Analytics workspace (not just Audit category)
[ ] AI anomalous volume alert suppression configured for new endpoints during 14-day baseline learning period, with expiry date set
[ ] DevOps connector installed with dedicated machine user, not a personal account
[ ] Code-to-cloud tagging verified: deployed resources show SourceRepoURL tag from pipeline
[ ] API security posture plan enabled and initial discovery run completed (allow 72h for App Service and Functions)
[ ] Unauthenticated API endpoint findings reviewed: public-facing ones remediated within 24h of discovery
[ ] Defender for Storage malware scanning enabled with capPerGbPerMonth set to a budgeted value
[ ] StorageDefenderCap metric alert configured for high-throughput storage accounts
[ ] Legacy CIS 1.1.0 and 1.3.0 frameworks removed or migrated to CIS Azure v3.0 before July 2026 deprecation
[ ] NIS2 or DORA framework added if applicable to your organizational regulatory context
[ ] Defender plans activated one at a time with two-week hardening periods between each
[ ] KQL weekly digest scheduled for new attack paths created in the past 7 days