Wasabi Hot Storage as an Immutable Backup Target for Microsoft 365 and Azure Estates

Ransomware operators no longer confine their attention to production systems. They actively seek out backup repositories, credentials, and retention policies, because destroying the recovery path is the surest way to force payment. For organisations running Microsoft 365 and Azure workloads under regulatory obligation, this means the design of the backup target matters as much as the frequency of the backup itself. An immutable target that cannot be altered or deleted for a defined period changes the calculation entirely, because attackers who reach the storage layer still cannot corrupt what has already been written.

Wasabi Hot Storage has gained attention in this context as an S3-compatible object store that supports object lock, the same immutability primitive found in Amazon S3. When paired with a backup application that can write to S3-compatible endpoints, it provides a cost-predictable location for tamper-resistant copies of Microsoft 365 and Azure data. This article explains how object lock functions, how to configure it defensibly for regulated tenants, and where it fits alongside Microsoft-native protections rather than replacing them.

Why immutability underpins ransomware resilience

Conventional backups protect against accidental deletion and hardware failure, but they assume the backup itself remains trustworthy. Modern intrusions undermine that assumption by encrypting or deleting backup files, revoking retention locks, or manipulating the backup console once administrative credentials are compromised. Immutability breaks this chain by enforcing retention at the storage layer, independent of the backup application and independent of the identity that wrote the data. Even an attacker holding valid storage credentials cannot shorten a retention period or overwrite a locked object before it expires.

The Australian Cyber Security Centre reflects this principle in the Essential Eight, where regular, tested, and protected backups form one of the core mitigation strategies. Immutable object storage supports the intent of that control by ensuring recovery data survives an incident that reaches administrative accounts. For financial services and aged care providers, where an outage or data loss carries both regulatory and human consequences, a retention copy that cannot be tampered with provides a defensible foundation for recovery planning and audit response.

How object lock works in Wasabi

Object lock operates on the write once, read many model. When enabled on a bucket, individual objects receive a retention setting that prevents deletion or modification until the retention period elapses. Wasabi implements the two standard S3 retention modes, governance and compliance. Governance mode allows users with a specific elevated permission to adjust or remove the lock, which suits internal policy enforcement, while compliance mode prevents any account, including the root account, from shortening retention or deleting the object until the term expires. Legal hold provides an additional mechanism that fixes an object indefinitely, regardless of the retention clock, until the hold is explicitly released.

For regulated retention, compliance mode carries the strongest assurance because it removes the possibility of privileged override, which is precisely the capability a sophisticated attacker seeks to exploit. Selecting a retention term requires balancing recovery objectives, storage cost, and regulatory minimums, because objects consume storage for the entire locked period and cannot be reclaimed early. Organisations should model retention against their actual recovery point requirements and their compliance obligations rather than defaulting to arbitrary values, since an overly long term inflates cost while an overly short term weakens defensibility.

Configuring a defensible target for Microsoft 365 and Azure

Most enterprise backup platforms that protect Microsoft 365, including Veeam Backup for Microsoft 365 and comparable products, can write to S3-compatible object storage and enable immutability during job configuration. The backup application defines an immutable object storage repository, points it at the Wasabi endpoint and bucket, and sets an immutability period that aligns with the retention policy. It is important that the bucket has object lock enabled at creation, because the setting cannot be applied retrospectively to an existing bucket, and that the access keys used by the backup job carry only the permissions required to write and read, not to disable versioning or lock configuration.

For Azure estates, teams should recognise that Azure Blob Storage offers native immutable storage with time-based retention and legal hold, which keeps recovery data inside the Microsoft trust boundary and integrates cleanly with Azure identity and network controls. A Wasabi target is best understood as a complementary offline or third-copy location that follows the widely referenced three copies, two media, one offsite principle, providing separation from the primary tenant and its administrative plane. Whichever combination an organisation adopts, credentials for the immutable target should be isolated from day-to-day administrative identities, protected with multi-factor authentication where the platform supports it, and never stored within the environment being backed up.

Compliance and cost considerations for regulated sectors

Aged care and financial services both operate under record-keeping and privacy obligations that require data to remain retrievable and intact for defined periods. Immutable retention supports these obligations directly, because it demonstrates that records could not have been altered after capture, which strengthens the evidentiary position during an audit or investigation. When configuring retention terms, organisations should map each term to a specific obligation, document the rationale, and test restoration regularly so that the immutable copy is proven recoverable rather than merely present.

Cost predictability is a further reason these sectors examine S3-compatible options, since affordable retention allows longer immutable windows without the storage bill becoming the constraint on resilience. That said, storage economics should never be evaluated in isolation from restore performance, data sovereignty, and the location of the storage region, all of which carry weight for Australian regulated entities. A sound approach treats immutability as one layer within a tested recovery strategy, combining Microsoft-native protections, verified backups, isolated credentials, and immutable retention into a design that withstands both accidental loss and deliberate attack.

References

• ACSC Essential Eight Maturity Model
• Microsoft: Overview of immutable storage for blob data