By default the malware scanner covers 10,000 GB per storage account each month. Past that it does not slow down, it stops.
The cap is there to keep costs predictable, and the consequence is that everything uploaded after the threshold goes unscanned until the month rolls over. None of which takes away from the product. Protection across Blob, Files and Data Lake is genuinely strong here. How much of it you end up with is decided by a handful of configuration choices.
- 10,000 GBDefault monthly scan cap per storage account
- 3 servicesBlob Storage, Files and Data Lake Storage
- AgentlessEnable at subscription, resource or scale
- No logs neededDiagnostic logs are not a prerequisite
Eight decisions that settle how much of this protection you actually receive.
Coverage across three storage services
Telemetry comes from both the data plane and the control plane across Azure Blob Storage, Azure Files and Azure Data Lake Storage. That breadth matters more than it sounds. Most businesses think about storage protection as a blob question, while their file shares quietly hold just as much sensitive material.
Malware scanning using Defender Antivirus
Uploaded objects can be scanned in full, or you can run a targeted scan on demand against particular blobs, files, containers or file shares, with Microsoft Defender Antivirus doing the work. There is no agent involved. This is the feature that keeps a storage account from becoming both an entry point and a distribution channel.
The monthly cap, which is on by default
The default sits at 10,000 GB of uploaded blobs per storage account per month. Cross it and scanning simply ends for whatever else arrives, within a 20 GB confidence interval. Nothing on screen makes that state apparent unless somebody configured the alerts that flag it.
Sensitive data threat detection at no extra cost
This runs on Sensitive Data Discovery, an agentless engine that uses smart sampling to locate resources holding sensitive material, and it draws on Microsoft Purview sensitive information types and classification labels. Since it can be switched on or off at no extra cost, there is very little argument for leaving it off.
Detecting activity from entities with no identity
What it watches for is suspicious behavior from entities carrying no identity at all, reaching data through shared access signatures that were misconfigured or written far too permissively, and which may well have leaked or been stolen. Anywhere SAS tokens get handed out casually, this tends to be the single most valuable detection in the whole set.
Event driven response for actual remediation
Wiring it into Azure Event Grid lets remediation happen on its own, with Azure Functions or Logic Apps deleting, quarantining or alerting on a malicious blob almost as it lands. Without that connection, a detection is just a notification somebody may read. With it, the object stops being reachable.
Activity monitoring without turning on logs
Data plane and control plane logs are analyzed continuously without anybody having to enable resource logging first, with threat intelligence identifying the suspicious signatures, malicious IP addresses and Tor exit nodes among them. The documentation is clear that this monitoring has no effect on performance, on ingestion capacity, or on how data is accessed.
Enabling it at scale and keeping it enabled
Enabling at subscription level picks up every existing storage account and every new one automatically, which is why it is the recommended approach. Azure Policy can then enforce that on new subscriptions and hold back configuration drift, and that is the mechanism that keeps coverage from decaying as the estate grows underneath you.
Cross 10,000 GB inside a month and nothing further gets scanned until the calendar turns.
Having a cap at all is perfectly reasonable, since costs need to stay predictable. What is not reasonable is discovering the cap existed only after an unscanned upload turned into an incident.
- The shipped limit is 10,000 GB of uploaded blobs per storage account per month. Once you pass it, scanning ends for everything else that arrives, within a 20 GB confidence interval. Activity monitoring keeps running, so the account is not unprotected, but nothing new coming in is being scanned for malware.
- There are two alerts built for precisely this situation, and both belong somewhere an actual person will see them. One fires at 75 percent of the monthly cap, which leaves time to raise it before anything lapses. The other fires when the cap is reached and scanning has paused, naming the storage accounts affected.
- Caps can be applied across a whole subscription or set individually per storage account, and within a protected subscription each account is free to carry a different limit. An account taking large volumes of untrusted uploads has no business sharing a cap with one that barely receives anything.
- One more thing belongs in the cost model. Malware scanning generates charges against other Azure services beyond the plan itself, specifically Storage read operations, Storage blob indexing and Event Grid notifications. None of those sit inside the plan price, so put them in the estimate from the start.
Four things that turn this from enabled to effective.
Scan caps get sized account by account instead of inheriting the default everywhere
That default is 10,000 GB of uploaded blobs per storage account each month, and passing it ends scanning for whatever arrives afterwards. Any account taking heavy volumes of untrusted uploads needs a higher ceiling, otherwise its protection lapses partway through every single month and nobody finds out.
We build the response, not just the detection
With Event Grid connected to a Function or a Logic App, a malicious blob gets deleted or quarantined almost as soon as it is identified. Without it, that object stays downloadable for however long it takes somebody to read an alert. The entire value of malware scanning sits in that difference.
We turn on the feature that costs nothing
Sensitive data threat detection costs nothing to switch on or off, and it runs on Sensitive Data Discovery using Purview sensitive information types and classification labels. Leave it off and your alerts arrive stripped of the one piece of context that decides urgency: whether the data at risk mattered in the first place.
We check what hash reputation cannot see
Every plan includes hash reputation analysis, and its gaps are documented rather than hidden: SMB file shares are an unsupported use case, as are blobs created through Put Block and Put Block List. Any business leaning on it to cover file shares is leaning on something that does not reach them.
Four phases across roughly four weeks.
- 01Week 1
Inventory storage and understand the upload profile
We establish which storage accounts exist at all, which of them hold sensitive material, which take uploads from outside the business, and roughly how much data each receives in a month. That final figure is what tells you whether the default cap is generous or restrictive for any given account.
- Storage account inventory across subscriptions
- Accounts receiving untrusted uploads identified
- Monthly upload volume estimated per account
- Classic plan usage identified for migration
- 02Week 2
Enable at subscription scope and set caps deliberately
We enable at subscription level so existing and future accounts are covered without anybody having to remember, with exclusions only where there is a genuine reason for one. Caps are then set per account against how much that account actually receives, rather than every account inheriting the same default.
- Plan enabled at subscription level
- Exclusions documented with reasons
- Scan caps set per account against volume
- Sensitive data threat detection enabled
- 03Week 3
Build the response path
Event Grid gets wired to a Function or a Logic App so a malicious blob is deleted, quarantined or escalated automatically. Skip this and a detection amounts to a message sitting in a portal while the malicious object stays exactly where somebody can download it.
- Event Grid integration configured
- Automated remediation action chosen and built
- Quarantine location and retention defined
- Response tested with a benign test file
- 04Week 4
Route the alerts and prevent drift
Both cap alerts get routed to a person with the authority to do something about them, security alerts are integrated into wherever your team actually works, and Azure Policy is configured to enforce enablement on new subscriptions so coverage holds as the estate grows.
- Cap alerts routed to a named owner
- Security alerts integrated with the SOC workflow
- Azure Policy enforcing enablement on new subscriptions
- Coverage reporting established
Six situations where storage is the exposure.
A business accepting customer file uploads
The moment an application lets somebody outside the business put a file into storage, it is accepting untrusted content by definition. The direct control is malware scanning at upload with Event Grid remediation quarantining anything malicious, and the cap has to be sized against the volume that application actually generates.
A regulated firm with a data exfiltration concern
Activity monitoring detects unusual access patterns and potential exfiltration, and sensitive data threat detection prioritizes alerts by the sensitivity of the data at risk. Together they answer the question a bank examiner, a SOC 2 auditor or an FTC Safeguards assessment asks about detecting data leaving, with alerts rather than assurances.
An organization handing out shared access signatures
The service picks up suspicious activity from entities with no identity behind them, arriving through SAS tokens that were misconfigured or written too permissively, and which may have leaked or been stolen. Where SAS tokens are handed out casually, this is frequently the first detection to find something genuinely wrong.
A HIPAA-covered provider storing records in Azure Files
File shares hold just as much sensitive material as blob containers do and get a fraction of the attention, and in healthcare they routinely contain protected health information. Azure Files is covered, though that is worth verifying in your own tenant rather than assuming. It matters especially where hash reputation analysis is being relied upon, since SMB file shares are an unsupported use case for that feature.
An operator ingesting data from field systems
When Data Lake Storage is taking telemetry and files from operational systems, it becomes a route into your environment from equipment that is almost never secured to the same standard as the corporate estate. Data Lake Storage is covered, and activity monitoring works there without anybody having to enable diagnostic logs first.
A company whose Azure estate keeps growing
Subscriptions get created, project teams spin up storage accounts, and coverage quietly erodes. Azure Policy enforcing enablement on new subscriptions holds back that configuration drift, which converts coverage from something somebody tidies up periodically into a property of the platform itself.
How US organizations protect Azure storage.
| Feature | Enabled and configured | Enabled at defaults | Not enabled |
|---|---|---|---|
Blob, Files and Data Lake covered | Yes | Yes | No |
Malware scanning active | Yes | Until the cap | No |
Caps sized to upload volume | Per account | Default everywhere | Not applicable |
Cap alerts routed | Yes | No | Not applicable |
Sensitive data detection on | Yes | Sometimes | No |
SAS abuse detected | Yes | Yes | No |
Malicious blob removed automatically | Event Grid remediation | No | No |
New subscriptions covered | Azure Policy enforced | Manual | No |
Additional Azure charges modeled | Yes | No | Not applicable |
Storage as a distribution point | Addressed | Partly | Unaddressed |
Malware scanning against hash reputation analysis.
Consideration
Method
- Malware scanning
- Microsoft Defender Antivirus, deep file scan
- Hash reputation analysis
- Hash compared against known malware
Consideration
Includes hash reputation
- Malware scanning
- Yes, incorporated
- Hash reputation analysis
- It is the whole method
Consideration
Plan availability
- Malware scanning
- New plan only, paid feature
- Hash reputation analysis
- Available in all plans
Consideration
Scope
- Malware scanning
- Blob storage
- Hash reputation analysis
- Blob storage and Azure Files
Consideration
SMB file shares
- Malware scanning
- Not in scope of this comparison
- Hash reputation analysis
- Unsupported use case
Consideration
Blobs created with Put Block and Put Block List
- Malware scanning
- Not in scope of this comparison
- Hash reputation analysis
- Unsupported use case
Consideration
Catches unknown malware
- Malware scanning
- Yes, content is analyzed
- Hash reputation analysis
- No, only known hashes
Consideration
On demand scanning
- Malware scanning
- Yes, targeted blobs, files, containers, shares
- Hash reputation analysis
- No
Consideration
Monthly cap applies
- Malware scanning
- Yes, 10,000 GB by default
- Hash reputation analysis
- No
Consideration
Additional Azure charges
- Malware scanning
- Read operations, blob indexing, Event Grid
- Hash reputation analysis
- None stated
Five steps, and two of them are about defaults.
- 1
Inventory storage and profile the uploads
We list every storage account across every subscription, identify which hold sensitive data, which accept uploads from outside the business, and roughly how much each takes in a month. Without that last figure the cap decision is arbitrary. With it, the decision makes itself.
- 2
Enable at subscription scope, with justified exclusions
The recommendation is to enable at subscription level, so every existing and future storage account is covered without anyone acting. Where an account is excluded, the reason gets written down, because in every summary view an excluded account looks exactly like a covered one.
- 3
Set caps per account and enable sensitive data detection
Caps are set against each upload profile instead of leaving 10,000 GB in place everywhere, since crossing that threshold ends scanning entirely. Sensitive data threat detection goes on as well, there being no additional cost attached to it.
- 4
Build automated remediation through Event Grid
A Function or Logic App gets connected so malicious blobs are deleted, quarantined or escalated almost immediately, with the quarantine location and its retention period agreed in advance. Then the whole path is tested using a benign test file, on the grounds that an untested response path is an assumption rather than a control.
- 5
Route alerts and prevent drift with policy
Both scan cap alerts go to a named owner rather than a shared mailbox, security alerts land inside your team workflow, and Azure Policy enforces enablement on new subscriptions so coverage grows with the estate instead of trailing behind it.
What US organizations ask about Defender for Storage.
Fifteen questions about your own storage protection.
Coverage
- Is the plan enabled at subscription level?Recommended for coverage.
- Which accounts are excluded, and why?Exclusions should be justified.
- Are we still on the classic plan?It needs migration.
- Are Azure Files accounts covered?Not only blobs.
- Does Azure Policy enforce new subscriptions?It prevents drift.
Scanning
- What cap is set per storage account?Default is 10,000 GB monthly.
- Which accounts exceed it?Scanning stops when they do.
- Are the two cap alerts routed anywhere?75 percent and reached.
- Is sensitive data threat detection on?No additional cost.
- Do we rely on hash reputation for file shares?SMB is unsupported there.
Response
- Is Event Grid integration configured?For automated remediation.
- What happens when malware is found?Delete, quarantine or alert.
- Has the response been tested?With a benign test file.
- Who receives the security alerts?A person, not a shared inbox.
- Do we track additional Azure charges?Reads, indexing, Event Grid.
Find out whether any of your storage accounts takes more than 10,000 GB of uploads in an ordinary month.
That figure is the default scan cap, and beyond it scanning halts until the month ends. An account crossing it regularly means your protection carries a recurring monthly gap that nobody has ever been informed of.
Related Services
Explore more solutions that work great with this service
Microsoft Defender for Cloud Services
Defender for Cloud deployment for US organizations: enabling free
Learn moreMicrosoft Defender for Servers
Defender for Servers engagements for US organizations: estate
Learn moreMicrosoft Defender for SQL
Defender for SQL deployment for US organizations: the full SQL estate
Learn moreMicrosoft Purview
Data governance and compliance solutions
Learn moreMicrosoft Security Services
The Microsoft security stack deployed and managed end to end
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn more