Defender for Storage malware scanning: SHA-256 sharing with Defender for Endpoint — can it be disabled, and where is it processed?

Question

Defender for Storage malware scanning: SHA-256 sharing with Defender for Endpoint — can it be disabled, and where is it processed?

Andy James 25

We are enabling Microsoft Defender for Storage with on-upload malware scanning on a UK South storage account. Our platform is used by secondary school students aged 11 to 18 in the UK and UAE. The files written to this account are student-uploaded documents, photographs and annotation images. Under UK GDPR the schools are data controllers and we are the processor.

Your documentation states two things we can confirm: malware scanning runs in the same Azure region as the storage account, and scanned files are not stored by the service.

Your documentation also states a third thing we need to understand before we go live. From the Defender for Cloud introduction to malware scanning page and the Defender for Cloud data security page:

"In limited cases, file metadata such as the SHA-256 hash might be shared with Microsoft Defender for Endpoint for further analysis."

Your GA announcement for this feature adds that this sharing may go outside the scanning region, and describes the metadata as "classified as customer data".

We have five questions. Please answer each by number.

1. Can this sharing be disabled at subscription, resource or storage account level while leaving on-upload malware scanning enabled? If it cannot be disabled, please confirm that plainly.

2. Where is the metadata processed when it is shared? "Outside the scanning region" does not tell us whether the Defender for Endpoint endpoint receiving it is in the United Kingdom, the EU, or elsewhere. We need the geography, not the region. If it varies, what does it vary between?

3. If the metadata leaves the United Kingdom, which mechanism in the Microsoft Products and Services Data Protection Addendum covers that transfer?

4. What triggers the sharing? "Limited cases" and "when a file is suspicious" is not enough to describe this accurately to schools. Any detail on the trigger conditions would help.

5. Is the shared metadata only a digest of the file's bytes? Please confirm it does not include filename, blob path, container name, storage account name or any customer identifier. If anything beyond the hash is shared, please list what.

Three further questions arising from your troubleshooting documentation, which was sent to us in response to this same question through a separate support channel and did not address the above:

6. Is sensitive data threat detection enabled by default when the Defender for Storage plan is enabled, or does it require explicit opt-in? We do not want it enabled and need to know whether disabling it requires an action or whether it is off unless opted in.

7. The documentation states that StorageDataScanner is granted Storage Blob Data Owner. Is that role required for malware scanning alone, or only when sensitive data discovery is also enabled? If we enable malware scanning without sensitive data discovery, what access does the service take?

8. StorageDataScanner is added to the storage account's network access control list resource access rules. Our network configuration is managed in Terraform. Will a subsequent Terraform apply that reasserts our declared network rules remove that entry and break malware scanning, and if so what is the correct way to declare it in infrastructure as code?

We are not asking for a legal opinion on whether a file hash is personal data under UK GDPR. That determination is ours. We are asking for the technical facts so we can make it correctly and describe this processing accurately to schools.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Below are the possible best answers and I compared it with the official documentation vs LLMs. Based on the currently published Microsoft documentation, the following answers can be supported:

Can SHA-256 sharing be disabled while keeping on-upload malware scanning enabled?

I could not find any documented setting that allows the metadata-sharing behaviour to be disabled while retaining on-upload malware scanning.

Microsoft documents that, in limited cases, file metadata such as a SHA-256 hash may be shared with Microsoft Defender for Endpoint for further analysis, but the documentation does not describe a subscription-level, resource-level, or storage-account-level option to independently disable that behaviour while continuing to use malware scanning.

Therefore, based on the current public documentation, Microsoft has not documented a mechanism to disable this sharing independently of malware scanning.

Where is the metadata processed when it is shared?

Microsoft documents that malware scanning is performed in the same Azure region as the storage account.

Microsoft also documents that, in limited cases, metadata such as a SHA-256 hash may be shared with Microsoft Defender for Endpoint. However, I could not find Microsoft documentation that explicitly identifies the geographic location where metadata shared from Defender for Storage to Defender for Endpoint is processed.

Defender for Endpoint supports multiple data geographies, including the UK, EU, US, Australia, Switzerland, India, and UAE. The Defender for Endpoint service location depends on the Defender for Endpoint tenant configuration and provisioning model. For UK organisations, Microsoft documentation states that Defender for Endpoint tenants are generally provisioned within European data boundaries unless an existing tenant determines the location.

However, I could not find documentation that specifically states that metadata originating from a UK South storage account will always be processed within the UK or EU when shared from Defender for Storage to Defender for Endpoint.

Based on the public documentation, the most supportable statement is:

Malware scanning occurs in the storage account's Azure region, while limited metadata may be shared with Defender for Endpoint according to Defender for Endpoint's service architecture. Microsoft does not currently document a specific processing geography for this metadata exchange.

If the metadata leaves the UK, what transfer mechanism applies?

Microsoft's Products and Services Data Protection Addendum (DPA) states that transfers of Customer Data and Personal Data are covered by Microsoft's contractual commitments, including the 2021 Standard Contractual Clauses (SCCs).

For transfers from the United Kingdom, Microsoft references the UK International Data Transfer Addendum (UK IDTA) as the applicable transfer mechanism. Accordingly, if customer data is transferred outside the UK, the applicable contractual safeguards are generally those provided through the Microsoft Products and Services DPA, including the SCCs and UK IDTA, subject to the terms governing the customer's Microsoft agreement.

What triggers the sharing?

Microsoft's public documentation currently describes the behaviour only at a high level.

The documentation states that, in limited cases, file metadata such as a SHA-256 hash may be shared with Defender for Endpoint for further analysis. However, I could not find a published description of the specific decision logic, trigger conditions, or an exhaustive list of scenarios that result in metadata being shared. As a result, I would avoid describing the behaviour as occurring only for confirmed malware, only for suspicious files, or under any other specific condition unless Microsoft publishes additional detail.

At present, "limited cases" is the most precise description available in the public documentation.

Is the shared metadata only a SHA-256 digest of the file?

Microsoft documentation explicitly mentions SHA-256 as an example of file metadata that may be shared.

However, I could not find an exhaustive list of attributes exchanged between Defender for Storage and Defender for Endpoint. Microsoft does not state that SHA-256 is the only field that may be transmitted, nor does it explicitly state that fields such as filename, blob path, container name, storage account name, or other identifiers are excluded.

Therefore, based on the currently published documentation, it is not possible to conclusively state that only a SHA-256 hash is shared, nor is it possible to confirm which additional metadata fields, if any, may be included.

Is Sensitive Data Threat Detection enabled by default?

According to the current Defender for Storage documentation, Sensitive Data Threat Detection is enabled by default when Defender for Storage is enabled. If you do not want this capability enabled, it must be explicitly disabled after Defender for Storage is configured.

Therefore, it should not be treated as an opt-in feature.

Is StorageDataScanner/Storage Blob Data Owner required for malware scanning?

The documentation contains references that can be interpreted differently depending on the document being reviewed.

Current malware-scanning documentation references the Defender for Storage Data Scanner role, which is used by the scanning service to read content and perform scanning-related operations.

Other documentation states that the StorageDataScanner identity may receive the Storage Blob Data Owner role for scenarios involving malware scanning and Sensitive Data Discovery.

Based on the public documentation, I could not find a definitive statement that distinguishes the minimum permissions required for malware scanning alone versus those required when Sensitive Data Discovery is also enabled.

Therefore, the current documentation does not clearly establish whether Storage Blob Data Owner is always required for malware scanning, only required for combined scenarios, or used as part of an updated implementation model.

Will Terraform remove the StorageDataScanner network rule?

Potentially, yes.

Microsoft documents that StorageDataScanner is added to the storage account's resource-instance network access rules so that scanning can function even when network access restrictions are configured.

If Terraform is managing the storage account network configuration declaratively and the Microsoft-created resource-instance rule is not represented in the Terraform configuration, a subsequent apply operation may attempt to reconcile the configuration and remove that entry.

For that reason, any infrastructure-as-code implementation should ensure that Microsoft-managed entries required by Defender for Storage are preserved rather than overwritten. The exact implementation depends on the Terraform resource type and provider version being used.

Bottom line

Based on the current public Microsoft documentation:

I could not find a documented mechanism to disable the Defender for Endpoint metadata-sharing behaviour while retaining on-upload malware scanning.
Microsoft documents that malware scanning runs in the same Azure region as the storage account.
Microsoft documents that, in limited cases, file metadata such as a SHA-256 hash may be shared with Microsoft Defender for Endpoint for further analysis.
I could not find public documentation that definitively identifies the processing geography for that metadata exchange, the exact trigger conditions, or an exhaustive list of metadata fields that may be shared.

Therefore, for DPIA or compliance documentation, the most supportable statement from currently published documentation is:

Malware scanning occurs in the storage account's Azure region. In limited cases, file metadata such as a SHA-256 hash may be shared with Microsoft Defender for Endpoint for further analysis. The currently published documentation does not provide an exhaustive description of the trigger conditions, processing geography, or field-level metadata schema associated with that exchange.

This avoids making claims that are not currently substantiated by Microsoft documentation while accurately reflecting the behaviour that Microsoft does document.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Andy James 25 Reputation points

2026-08-30T11:51:06.5533333+00:00

Thank you, this is genuinely one of the most useful responses I have received on a compliance question. You have gone well beyond what I asked and the precision of your answers, particularly in distinguishing what the documentation does and does not support, is exactly what I needed.

The point about avoiding trigger-condition language more specific than "limited cases" is something I would not have caught myself.

The UK IDTA confirmation and the note on sensitive data threat detection defaulting to on are both immediately actionable. The latter in particular would have caught me out tomorrow.

I will update the thread if Microsoft support provides anything more specific on the processing geography or the metadata field list. If they do, your framing of what is and is not currently supportable will make it straightforward to know what has actually changed.

Thank you again for taking the time.
Vinodh247-1375 44,556 Reputation points Volunteer Moderator

2026-08-30T12:01:14.7766667+00:00

Thanks @Andy James -that helps. I am glad that you found it useful.