Defender for Storage on-demand malware scan fails without explanation

Question

Initially tried running on-upload malware scans. The event fires but it has the scan result of "Not Scanned". Then, tried scanning again with the on-demand scan on the portal instead to sanity check, which resulted in a failure without an explanation. A subsequent request to get the scan details from a curl on the management API returns this:
{

"scanId": "3197b835-bfc2-413c-9bb4-8166ccaee43c",

"scanStatus": "Failed",

"scanStartTime": "2026-02-12T07:27:10.3623637Z",

"scanEndTime": "2026-02-12T07:27:10.8084288Z",

"scanSummary": {

"blobs": {

  "totalBlobsScanned": 0,

  "maliciousBlobsCount": 0,

  "skippedBlobsCount": 0,

  "failedBlobsCount": 0,

  "scannedBlobsInGB": 0

},

"estimatedScanCostUSD": 0

}

}

Answer 1

Hi @Ken Nguyen,

Thank you for reaching out on Microsoft Q&A forum.

This issue was caused by a subscription‑level allow‑list / access restriction that was unintentionally blocking the Defender for Storage malware scanning service from reading blob data, even though:

• Network Security Perimeter (NSP) rules were in place and allowed the required service tags (for example, MicrosoftDefenderForCloud, DefenderCloudAppInternal).
• User RBAC (such as Storage Blob Data Contributor) was correctly assigned.

For SAM259203, Defender for Storage emits this result when the malware scanner cannot read the blob at the data plane, typically due to policy‑ or scope‑based access restrictions, not due to malware or scan engine failure.

In this case, a subscription‑scoped allow‑list rule was restricting access in a way that affected Defender’s managed service identity. This is consistent with Microsoft’s documented behavior: even if networking is permitted, higher‑scope policies or allow‑list logic can still prevent the scanner from accessing blob content.

After an explicit allow rule was added at the subscription level, the Defender for Storage service was able to read blobs successfully, and malware scans began completing as expected. This confirms the issue was policy / access‑scope related, rather than NSP, RBAC, or Defender configuration.

Key takeaways

• SAM259203 indicates an access issue, not a malware detection or transient service error.
• Allowing Defender service tags at the network layer alone is not sufficient if subscription‑ or management‑group–level policies restrict data access.
• Subscription‑level allow‑list or trusted‑service configuration can override narrower‑scope restrictions and restore Defender scan access.

Once the subscription‑level allow rule was applied, Defender for Storage malware scanning functioned normally, confirming this as the root cause.