StorageDataScanner remains after Defender for Storage malware scanning is disabled — what is the supported cleanup?

Context

I ran a bounded, resource-level Defender for Storage malware-scanning experiment against one Development/PoC Storage account in France Central. The account allows selected networks rather than unrestricted public access. No Production environment was involved, and no files were uploaded or scanned during the failed live run.

Enabling malware scanning automatically created the subscription-scoped Microsoft.Security/dataScanners/StorageDataScanner resource with a system-assigned identity. It also added that scanner to the Storage account's resource-instance network rules, which matches Microsoft's documented architecture.

What happened

Before the experiment, seven inspected Storage control-plane responses showed zero scanner resource-instance rules, and no earlier StorageDataScanner lifecycle operation was found. Activity Log records show that scanner creation occurred in the same correlated enablement operation group as the Defender experiment, followed immediately by creation of the Storage allowance.

The resource-level experiment was then fully disabled. The custom and system Event Grid resources, Service Bus resources, experiment role assignments, and provider-created scanner role were removed. However, the StorageDataScanner resource and the exact Storage resource-instance allowance remain.

Current state

At the latest read-only observation:

• Resource-level Defender for Storage was disabled, with subscription override disabled.
• On-upload malware scanning and Sensitive Data Discovery were disabled.
• Defender for Storage and Defender CSPM were both on their Free/inactive tiers, with no active malware-scanning or Sensitive Data Discovery extension.
• No custom results topic remained.
• The scanner's system-assigned identity still existed, but it had zero direct or inherited Azure RBAC assignments.
• The Defender for Storage Data Scanner and Storage Blob data roles were absent.
• Only the inspected Development Storage account referenced this scanner; no other scanner consumer was established.
• No relevant Azure Policy assignment required or recreated it.

The important security distinction is:

NETWORK PATH ALLOWED BUT NO DATA AUTHORIZATION PROVEN.

The resource-instance rule remains as a network exception, but the scanner identity has no corresponding RBAC/data role. I am not treating this as evidence of a data breach or confirmed data exposure.

Evidence and timeline

All timestamps are UTC:

• 2026-08-22T17:18:41.9058641Z: scanner creation started.
• 2026-08-22T17:18:57.7662853Z: scanner creation succeeded.
• Approximately 2026-08-22T17:19:02Z: the Storage scanner allowance first appeared.
• 2026-08-22T17:19:35.2575209Z: the bounded Defender experiment became active.
• 2026-08-22T17:28:15.3781564Z: Defender experiment disablement completed.
• 2026-08-23T09:39:42.7449629Z: both residual objects were still present, approximately 16 hours 11 minutes after disablement.

The inspected Activity Log window contains no StorageDataScanner delete attempt, no scanner-network cleanup operation, no provider cleanup error, and no post-disable Defender operation touching the scanner. Two bounded convergence waits, followed by the additional elapsed time above, did not change the state.

What has already been ruled out

The subscription inventory contained one Storage account, and only that account referenced the scanner. Defender for Storage malware scanning, Sensitive Data Discovery, and Defender CSPM were inactive. The scanner had no RBAC/data authorization, and no policy assignment or other active consumer requiring it was found.

Microsoft's malware-scanning documentation explains automatic StorageDataScanner creation, managed identity, role assignment, and resource-instance network access. The resource-instance networking documentation also explains that a network exception does not itself grant data access. I could not find a documented automatic-cleanup SLA or supported teardown sequence for this scanner/rule pair.

Relevant documentation:

• Introduction to Defender for Storage malware scanning
• Data security posture management
• Storage resource-instance network rules

Questions for Microsoft

1. Is Microsoft.Security/dataScanners/StorageDataScanner expected to remain after Defender for Storage malware scanning, Sensitive Data Discovery, and Defender CSPM are all inactive?
2. Should the Storage resource-instance rule referencing the scanner remain when its identity has no RBAC or data authorization?
3. If this pair is orphaned, is customer-side deletion supported?
4. If manual cleanup is supported, what is the required order: delete StorageDataScanner first and then remove the exact Storage resource-instance rule, or another sequence?
5. Could manual removal interfere with future Defender for Storage re-enablement?
6. Is there a provider-side cleanup mechanism, or an expected garbage-collection period longer than the elapsed observation period?
7. What control-plane state should be treated as the correct baseline after Defender for Storage malware scanning is disabled?

I have deliberately not deleted either residual object or repeated the Defender enable/disable cycle while waiting for supported lifecycle guidance.