Microsoft Defender for Cloud’s August 2026 release notes contain four notable changes. On August 6, targeted on-demand malware scanning for Defender for Storage entered public preview, and a CIEM breaking change removed unused-action information from AWS and GCP overprovisioned-identity assessments. On August 17, Microsoft announced the future retirement of classic Defender for SQL APIs. On August 21, Microsoft changed how detailed vulnerability CVE information is consumed through Azure Resource Graph.
The main focus here is Defender for Storage. Previously, the on-demand model could scan existing data across a storage account. The August public preview adds REST request filters that let a security operator target one blob or file, a specific container or file share, or objects matching a path prefix. Omitting filters retains the full-account behavior.
This changes the operational economics of investigations. A suspected malicious object no longer has to justify rescanning a multi-terabyte account. The SOC can focus the scan on the object, its directory-like prefix, or the associated container/share. Microsoft explicitly identifies security-event response, targeted investigation, failed-scan retry, compliance scanning, recurring proactive scanning, and creation of an initial security baseline as core on-demand use cases.
The service uses Microsoft Defender Antivirus with current malware definitions and provides a cloud-native scanning capability without requiring customers to operate separate malware-scanning infrastructure. On-demand scanning is particularly useful for content that existed before malware scanning was enabled and for re-evaluating stored data as threat conditions change.
Detailed Updates and Fixes
The main filtering primitive is the filters object. Requests can define blobs and/or files. An object path has a value and an optional match strategy of Exact or Prefix; when match is omitted, the default is Exact. Blob paths use container/blob-path, while Azure Files uses share/path. Matching is case-sensitive.
The filter semantics matter for automation. Providing only Blob filters causes file shares to be skipped; providing only Files filters causes blobs to be skipped. A filter that matches no objects is not treated as a scan failure—the operation can complete successfully with zero items scanned. Omitting filters causes the scan to cover all applicable blobs and files in the storage account. Consequently, a successful HTTP/API call should not be the only success criterion in a SOAR workflow; scanned-object counters should also be validated.
Before initiating an on-demand scan, Defender for Storage with on-upload malware scanning must be enabled at the subscription or storage-account level. The built-in Security Admin role can perform the operation. For a least-privilege custom identity, Microsoft documents the actions Microsoft.Security/defenderForStorageSettings/startMalwareScan/action, Microsoft.Security/defenderForStorageSettings/malwareScans/read, and Microsoft.Security/defenderForStorageSettings/malwareScans/cancelMalwareScan/action. This allows a security-automation identity to operate scanning without being granted broad Contributor or Owner rights.
Only one on-demand scan can run at a time for a storage account. Cancellation is also time-bound: a scan can be cancelled only in its initial stages, before it reaches WaitingForCompletion or a later state. Security orchestration therefore needs concurrency handling, retry/backoff behavior, and a clear policy for requests that arrive while a scan is already active.
Once initiated, the service enumerates the eligible blobs/files—either across the full account or within the filter scope—and sends them for scanning in parallel. Data remains accessible during the scan. Operators can monitor scanned and skipped object counts, volume, detected malicious objects, status, and duration; depending on the volume and number of objects, scans can take from minutes to hours.
Results can be consumed in four primary ways: Blob index tags, Defender for Cloud security alerts, Event Grid, and Log Analytics. By default, Blob tags can record results such as No threats found, Malicious, Error, or Not scanned plus the scan time. Microsoft cautions that Blob index tags are not tamper-resistant, so an actor with permission to modify tags can alter them; they should not be the sole source of truth for high-assurance enforcement.
A malicious finding can produce a Defender for Cloud security alert for investigation and automated response. Event Grid supports lower-latency event-driven workflows through Function Apps, webhooks, Event Hubs, or Service Bus. When Log Analytics is configured, malware scan results can be stored in the StorageMalwareScanningResults table, providing a better fit for audit trails, compliance evidence, historical investigation, and analytical queries.
Microsoft also documents automated remediation patterns, including soft-deleting malicious files, using ABAC to block access to malicious or unscanned data, using Logic Apps or Functions to move/delete content into a quarantine workflow, and forwarding clean data to another storage location. This is the architectural bridge from detection to preventive control.
The other August Defender changes deserve attention because they can break security engineering integrations. From August 21, extended CVE details are consumed through the Azure Resource Graph resource type microsoft.security/cvedetails. Microsoft says the change improves performance, scalability, and support for larger datasets. Existing ARG/API queries that expect detailed CVE properties directly from vulnerability assessment records can therefore stop returning the expected detail unless they are updated.
On August 17, Microsoft announced that the classic Defender for SQL Vulnerability Assessment and Advanced Threat Protection APIs will retire on August 16, 2027. Existing scripts, automation, and configuration logic that depend on those APIs need to move to the supported configuration model before the retirement date.
The August 6 CIEM change is a genuine breaking change for some cross-cloud workflows: unused actions are no longer included in Defender for Cloud’s AWS and GCP overprovisioned-identity recommendations. Microsoft says this improves assessment-generation performance and scalability. Organizations that relied on that field must instead obtain permission-usage evidence from AWS or Google Cloud’s native IAM/activity tooling.
Practical Implementation and Configuration
For a full-account scan through the Azure portal, navigate to the relevant storage account and select Security + networking → Microsoft Defender for Cloud → On-demand malware scanning. The portal presents an estimated cost based on storage capacity/data volume before the scan begins. Operators can then start the scan and monitor status, objects scanned, GB scanned, detected threats, and duration; Microsoft documents portal status refreshes approximately every 20–30 seconds.
Targeted filtering is exposed through the REST API. The management-plane request follows this pattern:
POST https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/providers/Microsoft.Security/defenderForStorageSettings/current/startMalwareScan?api-version=2024-10-01-preview
Authorization: Bearer <ENTRA_TOKEN>
Content-Type: application/json
This is the endpoint Microsoft documents for starting Defender for Storage on-demand malware scans programmatically.
To investigate one suspicious blob:
{
"properties": {
"filters": {
"blobs":
}
}
}Here, incoming is the container name and the remainder is the Blob path. The Exact match confines the scan to that specific object.
When the SOC believes an entire upload batch is at risk, prefix matching can be more operationally efficient:
{
"properties": {
"filters": {
"blobs":
}
}
}The scan then targets objects whose paths begin with that prefix instead of forcing a full storage-account rescan.
The equivalent concept for Azure Files is:
{
"properties": {
"filters": {
"files":
}
}
}The first path element represents the share. Because matches are case-sensitive, security automation should preserve canonical path casing from the source event rather than normalizing it arbitrarily.
The latest scan can be monitored programmatically:
GET https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/providers/Microsoft.Security/defenderForStorageSettings/current/malwareScans/latest?api-version=2024-10-01-preview
Authorization: Bearer <ENTRA_TOKEN>
Microsoft’s documented response model includes scan status and summary values such as scanned and malicious blob/file counts, skipped or failed items, and scanned data volume. These values are useful as explicit workflow acceptance criteria.
A practical Azure CLI plus REST automation pattern can obtain a management-plane token and issue the filtered request:
TOKEN=$(az account get-access-token \
--resource https://management.azure.com/ \
--query accessToken \
--output tsv)
curl -X POST \
"https://management.azure.com/subscriptions/$SUB_ID/resourceGroups/$RG/providers/Microsoft.Storage/storageAccounts/$STORAGE/providers/Microsoft.Security/defenderForStorageSettings/current/startMalwareScan?api-version=2024-10-01-preview" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
--data @scan-filter.jsonFor an enterprise SOAR implementation, the service principal or managed identity behind this workflow should be scoped to the malware-scan actions documented by Microsoft rather than given broad resource-management permissions.
Business and Security Benefits
The clearest business benefit is a reduction in scan blast radius and unnecessary per-GB consumption. On-demand scanning is usage-based and, unlike on-upload malware scanning, does not have a monthly cap. Microsoft states that when filters target a subset of objects, the charge is based on the data actually scanned rather than the total storage-account capacity. That materially improves the economics of repeated incident-response scans on large storage estates.
There can still be dependent Azure-service costs from Storage reads, Blob indexing, and Event Grid. Microsoft recommends checking the portal estimate, choosing scanning frequency according to risk, triggering scans only when operationally justified, and using targeted filters to reduce scan time and consumption.
The principal security benefit is the potential to reduce time to investigate. When an alert already identifies a suspicious object, a SOC analyst or SOAR playbook can revalidate the object directly, expand scope to its prefix if necessary, and only escalate to a broader scan when evidence justifies it. The feature is also valuable for retrying objects whose previous scan failed, without paying the operational cost of rescanning everything else.
Targeted scanning should nevertheless be viewed as a detection primitive, not a complete quarantine mechanism. Data can remain accessible while scanning occurs, and Blob index tags are not tamper-resistant. High-assurance architectures should combine scan findings with Defender alerts, Event Grid or Log Analytics and enforce response through ABAC, soft delete, Functions, Logic Apps, or a dedicated quarantine workflow.
At the governance level, the other August Defender changes underscore a broader principle: security-data contracts and security APIs need active lifecycle management. The CVE data-shape migration, CIEM field removal, and Defender for SQL retirement can each affect KQL/ARG queries, SOC parsers, dashboards, scripts, or IaC. A mature cloud-security operating model therefore needs regression tests and release-note-driven change management for security automation itself. This conclusion follows from Microsoft’s documented breaking, migration, and retirement notices.
Use Cases
For a malware or ransomware investigation, a SIEM might flag incoming/client-883/archive.zip. A SOAR playbook can initiate an Exact scan for that object and, if it is malicious, trigger an Event Grid- or alert-driven quarantine/deletion workflow. This combines Microsoft’s targeted filtering and automated remediation patterns into a focused incident-response loop.
In a software supply-chain workflow, a third-party vendor might upload nightly packages under a prefix such as vendor-feed/2026/08/31/. When threat intelligence later identifies that delivery window as suspect, the security team can rescan only the affected prefix instead of the entire data lake. Prefix filtering directly supports this operating model.
For compliance and legacy-data baselining, an organization can perform an initial full scan after Defender for Storage is introduced and use targeted container, share, prefix, or object scans for subsequent exception handling. Microsoft explicitly documents baseline creation, compliance scanning, and targeted investigation as relevant on-demand use cases.
For failed-scan remediation, a small number of objects that returned errors in an earlier operation can be resubmitted individually rather than forcing a new account-wide scan. Microsoft specifically identifies retrying a failed on-upload or on-demand scan for a particular file or blob as a targeted-scanning scenario.
Conclusion
The strategic value of the August 2026 Defender for Storage update is not a new antivirus engine; it is the transformation of scan scope into a granular security-orchestration control. SecOps teams can move from a binary “scan the entire account or do nothing” model to risk-based object, prefix, container, and file-share scanning. That improves investigation precision, cost governance, and automation design. At the same time, the August CVE data-model change, CIEM breaking change, and forthcoming Defender for SQL API retirement make it clear that the Defender platform itself must be managed with disciplined API and query lifecycle governance.