In this blog post How Azure SDK Changes Expose Immutable Backup Recovery Gaps we will explain why a small change in Azure’s software development kits should trigger a practical recovery readiness review.
Your Azure dashboard may show successful backups every day. However, that does not tell you whether an attacker can delete them, whether the retention settings match business needs, or whether your team can restore critical systems within an acceptable timeframe.
Recent Azure management changes make immutable backup settings more visible to automation tools. A software development kit, or SDK, is simply a set of code libraries that lets your team inspect and manage Azure without clicking through the portal. This improved visibility is useful, but its real value comes from the business questions it prompts.
What immutable backup technology actually does
Azure Backup stores recovery points inside a Recovery Services vault or Backup vault. Think of a vault as a protected container holding previous versions of your servers, databases, files and other workloads.
Immutability prevents protected recovery points from being altered or deleted during a defined period. When the setting is locked, it becomes irreversible and can use write once, read many storage, commonly called WORM storage. In plain English, the data can be created and read, but not overwritten or removed before its protection period expires.
Azure can apply immutability in two main ways. AsPerPolicy ties the immutable period to each backup policy’s retention settings. TimeBased uses a fixed number of days, independently of the longer retention period.
For example, a recovery point might be retained for one year but protected from deletion for the first 30 days. That difference matters when balancing ransomware protection, legal deletion obligations, operational flexibility and storage cost.
Why an SDK update should interest business leaders
An SDK change may look like a developer issue. In practice, it can reveal that existing reports and governance scripts are no longer asking the right questions.
An older script might record only whether immutability is enabled. Newer models can also expose how it is configured and, for time-based protection, the duration in days. A report that still displays a simple green tick may therefore hide important differences between vaults.
This is the right moment to move beyond backup inventory. As discussed in turning Azure backup inventory into recovery decisions, knowing that a backup exists is not the same as proving the business can recover.
Turn the change into a five-part readiness review
1. Find every vault and classify its protection
Start with a complete list across every Azure subscription, including development, acquired businesses and older environments. For each vault, record whether immutability is disabled, enabled but unlocked, or enabled and locked.
Also capture the configuration type, immutable duration, backup policy, workload owner and data location. The business outcome is straightforward: fewer unknown recovery gaps and less dependence on one administrator’s memory.
2. Match protection periods to business risk
A 14-day immutable period may be adequate for one system and dangerously short for another. Ransomware can remain undetected for weeks, while financial, health or customer records may have longer regulatory and contractual requirements.
Ask each system owner how much data the business can afford to lose and how long operations can remain unavailable. These are known as recovery point and recovery time objectives, but the plain-English question is more useful: “How far back must we recover, and how quickly?”
If Azure SQL is a priority, our guide to practical immutable Azure SQL backups explores the database-specific decisions in more detail.
3. Review who can change backup controls
Immutable data is only one layer. Review role-based access control, which determines who can manage each vault, and separate backup administration from everyday infrastructure administration.
Consider Azure Resource Guard for sensitive operations. Resource Guard adds multi-user authorisation, meaning a second protected authority must approve actions that could weaken recovery. Ideally, that control should be managed separately from the main production administration path.
Microsoft Defender and Wiz can help identify excessive permissions, exposed resources and risky cloud configurations. The business outcome is reduced reliance on a single privileged account that could be stolen or misused.
4. Test a realistic restoration
Immutability protects recovery points, but it does not guarantee that applications will start, credentials will work or dependent services will reconnect. Select a critical workload and restore it into an isolated environment.
Measure the complete process from approval to usable service. Include identity, networking, application testing and communication with the business owner. Record the result rather than accepting “the restore job completed” as proof.
This also supports the Australian government’s Essential 8 cybersecurity framework, which includes regular backups and expects restoration to be tested during disaster recovery exercises. Immutability strengthens that control, but does not prove compliance by itself.
5. Check cost and lifecycle consequences before locking
Locking a vault is intentionally difficult to reverse. Before doing so, confirm retention periods, legal deletion requirements, workload lifecycle plans and who will pay for data that must remain stored.
Do not reduce protection simply to cut the Azure bill. Instead, remove unnecessary data, correct excessive retention and use the right storage settings. Our article on lowering Azure backup costs without adding risk explains this balance.
A simple read-only review pattern
The following Python example shows the intent of an SDK-based inventory. It reads vault information and does not apply or lock settings. Field names can vary between package versions, so test the script in a non-production subscription and pin the approved SDK version before operational use.
from azure.identity import DefaultAzureCredential
from azure.mgmt.recoveryservices import RecoveryServicesClient
credential = DefaultAzureCredential()
client = RecoveryServicesClient(credential, subscription_id)
for vault in client.vaults.list_by_subscription_id():
data = vault.as_dict()
properties = data.get("properties", {})
security = properties.get("security_settings", {})
immutable = security.get("immutability_settings", {})
configuration = immutable.get("configuration", {}) or {}
print({
"vault": data.get("name"),
"location": data.get("location"),
"state": immutable.get("state", "Not reported"),
"type": configuration.get("type", "Not reported"),
"duration_days": configuration.get("duration_in_days")
})The important step comes after collection. Join this information with workload criticality, restore-test results, access controls and accountable owners. Otherwise, you have produced a more detailed spreadsheet without improving recovery.
What the review can uncover
Consider a 200-person business with six Azure vaults. Its monthly report showed that every protected workload had a recent backup, so management believed ransomware recovery was covered.
A deeper review found that only one vault was locked, two were enabled but could still be unlocked, and three had no immutability. The payroll system had a suitable backup, but nobody had tested the identity and network steps needed to make the restored application usable.
The remediation was not a major technology project. The company aligned protection periods to business priorities, removed unnecessary administrator access, locked settings after testing and scheduled quarterly restores of its most important systems.
The result was clearer risk ownership, stronger Essential 8 evidence and a recovery plan based on measured timings rather than assumptions.
Use the update as a governance trigger
SDK changes should not be treated as routine maintenance when they expose new security information. They are an opportunity to confirm that reports, automation and recovery plans still reflect how Azure behaves today.
At CloudProInc, our experience as a Microsoft Partner and Wiz Security Integrator has shown that the strongest backup programs combine Azure controls with practical restore testing and clear business ownership. Our Melbourne-based team brings more than 20 years of enterprise IT experience without the overhead of a large, faceless provider.
If you are unsure whether your immutable backup settings provide real recovery confidence, we are happy to review the current setup and identify the practical gaps — no strings attached.