Microsoft has made backup immutability generally available for the most recent seven days of backups on Azure SQL Database and Azure SQL Managed Instance. The change is enabled by default for every database, and it removes one of the last easy ways for an attacker to destroy your recovery path.
The idea is straightforward. Backups for the last seven days are locked so they cannot be modified or deleted, even by someone with administrative control over the database or the subscription. If a ransomware operator gets in and starts deleting your restore points, they will hit a wall on the most recent week of backups, which is exactly the window you are most likely to need.
Why backup immutability is a big deal
Ransomware gangs have long understood that the way to maximize pressure is to go after the backups. Delete or encrypt the restore points, and the victim has no choice but to negotiate. Most backup systems, including database backups, have historically been controlled by the same credentials that manage the database itself, so a compromise of those credentials effectively handed the attacker the keys to the recovery data too.
Immutable backups break that chain. Because the seven-day window is enforced by the platform rather than by a user-level permission, there is no in-band action that can undo it. An attacker who has compromised the database admin account still cannot touch that week of backups. The separation of control is what makes this a genuinely useful protection rather than a cosmetic one.
How it works
The immutability applies automatically, with no configuration on your side. It affects the backups Azure SQL takes as part of its standard automatic backup and point-in-time restore (PITR) service, so you do not lose any existing recovery functionality. The immutable window sits on top of your configured retention, which means longer retention policies still work as before, but the recent seven days are now additionally protected against tampering.
Because it is enabled by default and applies to all databases regardless of your point-in-time restore or retention configuration, this is not something you have to remember to turn on. New and existing databases both get the protection.
What it means for your recovery strategy
If you have been treating your Azure SQL backups as a formality, this is a good moment to rethink them. Immutable recent backups give you a realistic fallback when something goes wrong, whether that is a ransomware event, a malicious insider, or an accidental destructive operation.
A few things are worth checking now that this is available:
- Review your retention policy so it matches your actual recovery objectives. The seven-day immutable window is a floor, not a target, and longer retention still makes sense for compliance-heavy workloads.
- Test a point-in-time restore from the protected window so you know the restore path works before you need it. A backup only counts if you can actually recover from it.
- Make sure your incident response playbook includes verifying backup integrity as an early step, and assume the immutable window is what you will recover from during an active incident.
The bigger picture
This fits a broader pattern across cloud platforms: security controls that used to require careful configuration are becoming the default. Secret management, encryption, and now backup immutability are all moving into the category of “on by default because turning it off would be a mistake.”
That trend is good news for operators, because it means fewer decisions where the wrong choice leads to a data loss event years later. The cost of getting immutability wrong historically has been steep, usually discovered only at the exact moment you needed the backups most. Making it automatic removes that failure mode for the most recent, most valuable week of data.
Comparing with long-term backup options
It is worth placing the seven-day immutable window in context with the rest of the Azure SQL backup story. The platform has long offered longer retention, including the ability to extend automatic backups beyond the default and to take manual or long-term backups for archiving. Those options are about how far back you can restore. Immutability is about something different: it protects the integrity of whatever backups exist, no matter how long you choose to keep them.
The seven-day window is the part that is enforced by default today. What it gives you is a guaranteed recovery point for the most recent week, the window that is both the most likely target for an attacker and the most likely to be needed in an emergency. For organizations that want immutability on a longer horizon, the option to layer additional controls on top remains available, but the default now covers the critical recent period without any effort.
There is a practical benefit to that split. Backup strategy can drift when it depends on every team remembering to configure a security setting correctly. When the most vulnerable and most important window is automatically protected, the consequences of that drift are much smaller. Even a team with a poorly planned retention policy keeps a tamper-proof recent recovery point.
Bottom line
Backup immutability on Azure SQL is a quiet but important upgrade to the platform’s default security posture. For the cost of no configuration and no loss of existing restore functionality, you get a week of backups that neither ransomware nor a compromised admin account can touch. If you run SQL workloads on Azure, the right response is to verify your retention and restore paths line up with that new protection, then move on. The hard part is already handled for you.