Keep backups for 180 days, make them immutable for the first 30, and understand what happens when you lock the vault.
Keeping a backup for six months and protecting it from deletion for six months are two decisions worth discussing separately. How far back do you need to restore? How long should nobody be able to remove that recovery point?
Azure Backup now lets you configure those periods independently for Recovery Services vaults. Microsoft lists the change in its September 2026 Azure Backup updates.
Here's how the setting works, where to find it, and what I would check before locking it.
What actually changed?
With policy-based immutability, deletion protection follows the recovery point's retention period. The new time-based option lets you choose a fixed protection window instead.
For example, a recovery point could have 180-day retention and a 30-day immutability period:
| Age of the recovery point | Retained by the policy? | Protected by immutability? |
| First 30 days | Yes | Yes |
| After 30 days, before retention expires | Yes | No |
| After 180-day retention expires | Eligible for policy cleanup | No |
The clock starts with each recovery point. Reaching 30 days doesn't delete it; it ends that protection window. Microsoft's release notes explain the separation between protection and retention.
That creates a real trade-off. If someone compromises backup administration after the protected window, older retained points no longer have this immutability protection.
Step 1: Check the vault and your retention requirements
This fixed-duration option currently applies to Recovery Services vaults. Backup vaults still use policy-based immutability. Immutability also excludes operational backups. The fixed period applies across the vault, so review its workloads together. Check WORM storage availability for your region and workload separately in the support matrix.
For this example, use a daily backup policy with 180-day retention and a 30-day protection window. Choose your actual values from your recovery requirements.
Step 2: Configure the duration in the Azure portal
1. Open your Recovery Services vault.
2. Go to Properties → Immutable vault → Settings.
3. Enable vault immutability.
4. Select Enable for specific duration and enter 30 days.
5. Leave the lock unchecked while validating the configuration.
6. Select Apply.
These steps follow Microsoft's vault management guide.
Enabling immutability and locking it are separate steps. While unlocked, the setting remains reversible. Locking makes it irreversible and fixes the selected duration too. Give that decision its own review.
Step 3: Read back the settings with PowerShell
I like a configuration check that can be saved alongside a change record. The following uses a GET request to inspect the vault through the Recovery Services REST API.
Use Azure Cloud Shell in PowerShell mode, or a session with `Az.Accounts` and `Az.RecoveryServices` installed. Sign in, select the subscription containing your vault, and replace the example names:
Connect-AzAccountSet-AzContext -SubscriptionId '<your-subscription-id>' | Out-Null
$vault = Get-AzRecoveryServicesVault `-ResourceGroupName 'rg-backup' `-Name 'rsv-backup'
$response = Invoke-AzRestMethod `-Method GET `-Path "$($vault.ID)?api-version=2026-05-01"
if ($response.StatusCode -ne 200) {throw "Vault lookup failed: HTTP $($response.StatusCode)"}
$details = $response.Content | ConvertFrom-Json$settings = $details.properties.securitySettings.immutabilitySettings
$settings | ConvertTo-Json -Depth 5
The vault lookup uses Get-AzRecoveryServicesVault; Invoke-AzRestMethod sends the request without changing vault settings.
An illustrative response for the unlocked example is:
{  "state": "Unlocked",  "configuration": {   "type": "TimeBased",   "durationInDays": 30  }}
Check both the state and configuration. `Unlocked` means immutability is enabled but reversible; `Locked` is irreversible. `TimeBased` identifies the fixed-duration mode. The API documents a minimum of 30 days. API field definitions.
What I would validate before locking
In a disposable lab vault, check that a new vaulted recovery point exists, then try reducing the example policy's retention from 180 to 60 days. The documented expectation is that this reduction is allowed, while a reduction below 30 days is blocked. Retention restrictions.
Run a restore as well. A configuration check alone doesn't tell you whether the data and application can recover successfully.
Once the settings meet your requirements, return to the same portal pane to lock immutability. Record the duration and the approval for that permanent choice. Locking behavior.
Does this reduce backup costs?
A shorter immutability period doesn't automatically shrink the storage bill. If you still retain the same backups for 180 days, you are still keeping that data.
The flexibility matters when retention needs change: the fixed protection window gives you a lower boundary for permitted retention reductions. Microsoft's release notes describe this as a way to balance protection requirements with storage costs.
For my change record, I would write down both periods explicitly: 180 days retained, 30 days immutable. That gives the next administrator a much clearer picture of what is protected, and for how long.