Blob Storage ransomware protection needs more than one setting

Blob Storage is one of the Azure services I still find dangerously exposed in far too many real projects. Blobs often hold logs, backups, AI data or compliance records, which is exactly what attackers want to encrypt or wipe, and that's easy to forget. Ransomware and insider incidents aren't theoretical anymore. In the tenants I review, I regularly come across Storage accounts running on default settings, without soft delete or versioning, and often with the old shared key still wide open. Relying on Azure's defaults invites trouble. Once a privileged identity or a shared key is compromised, an attacker can delete or encrypt every container in seconds. Real Blob Storage ransomware protection comes in layers, and each one matters.

Soft delete, versioning and point-in-time restore cover the basics

Start in the Storage account under Data management → Data protection. Soft delete for blobs and containers has become standard. A deleted blob isn't gone but sits in a hidden recycle bin for a set retention period (usually 7–30 days). Blob versioning adds a second safety net, because every overwrite creates a new version, so even in-place ransomware that encrypts existing files can be rolled back. Point-in-time restore is the most admin-friendly of the three, since it lets you roll back an entire container to its state at any moment within the retention window. In my experience you get the best result by combining all three: soft delete for deletions, versioning for overwrites and point-in-time restore for quick recovery by an admin. Don't treat this as a one-off. Review the settings at least once a year on every production Storage account, because automation and migrations often overwrite or skip them.

Immutable storage is the real barrier against ransomware

If you need actual resilience and not just a way to undo accidents, you need immutable storage. Microsoft has expanded the feature over time with time-based retention, legal hold and, more recently, version-level immutability. The idea is simple. Once a blob or version is written, nobody can delete or change it for the chosen retention period, not even Owners or attackers with full account access. For highly sensitive data such as audit logs, regulatory archives and backup containers, I consider immutable storage essential. Keep in mind that it can't be reversed, so enabling it commits you for the whole retention period. The overview of immutable storage has the details. In practice, I strongly recommend turning it on for any container you can't afford to lose.

The diagram below shows how the main protection layers fit together in a typical Azure Storage account:

flowchart TD
    UserApp["User/App"] --> SoftDelete["Soft Delete"]
    SoftDelete --> Versioning["Versioning"]
    Versioning --> PITR["Point-in-Time Restore"]
    PITR --> Immutability["Immutable Storage"]
    Immutability --> Backup["Azure Backup (Vault)"]
    Backup --> Restore["Recovery"]
    Admin["Admin or Attacker"] --> Lock["Resource Lock"]
    Lock --> StorageAccount["Storage Account"]

Figure: How the protection layers guard Blob Storage against deletion and encryption

Resource locks and Azure Backup form the last line of defense

However good your Blob Storage ransomware protection is, none of the built-in data protection settings help if an attacker deletes the entire Storage account. This is where resource locks come in. A “CanNotDelete” lock applied at resource group or subscription level blocks delete operations, even for Owners and system-level access. Every production Storage account should have one.

The next safeguard is Azure Backup for blobs (vaulted backup). It backs up blob snapshots and versions outside the Storage account, so you can restore from the vault even if the account itself has been wiped. This is your option of last resort, and for business-critical data I wouldn't go without it. The data protection documentation explains how to set up application-centric backup and restore. Before you can use it, you need a Backup Vault, the Backup Contributor role and a suitable backup policy.

Shared key remains the attack path most teams overlook

In almost every security review I've done lately, I've found Storage accounts that still allow shared key access, usually for legacy reasons or because of old automation. Shared key is the number one cause of mass deletions and stealthy ransomware attacks. Since 2024 you can disable shared key per account and require Entra ID authentication instead. I've written up the process in my guide to disabling shared key and moving to Entra ID. If shared key is still on, migrate away from it and add a resource lock on top.

Tip from the field: For a quick view of which containers or accounts lack protection, open the Azure Portal and go to Storage Account → Data management → Data protection, which gives you the full picture. Build regular reviews into your security process.

Ransomware protection takes more than ticking a checkbox

Azure Blob Storage has come a long way on ransomware protection, but only if you actually turn the features on and combine them. My default is to always use soft delete and versioning, enable point-in-time restore where possible, require immutable storage for critical data and back it up to a vault. Resource locks close the remaining gap, and shared key has no place in production. Anyone who has had to recover from a compromised Storage account knows that only multilayered protection gives you real Blob Storage ransomware protection. My linked guide walks through the practical steps for disabling shared key. And as always, review all settings at least once a year and don't trust the defaults. Otherwise you'll only find out what's missing when it's too late.