Azure Backup Immutable Vault and Ransomware Hardening

Not through the routes this engagement closes, and we will not claim more than that. With immutability locked, Microsoft blocks deletion of a recovery point before its expiry date and blocks any retention cut that would achieve the same thing — and locking cannot be undone, by you or by them. With multi-user authorization, the remaining destructive operations need the Backup MUA Operator role on a Resource Guard that your backup admin does not hold and, if the Resource Guard sits in another tenant, cannot even see. What no vault setting prevents is deletion of the source itself — the VM, the disk, the file share — or the recovery points ageing out normally when your retention expires. That is why retention design and server-side threat protection are part of the conversation, not afterthoughts.

On a Recovery Services vault, three things: stopping protection with deletion of data, editing a backup policy in a way that reduces retention, and moving a protected item onto a different policy with lower retention. You can still stop protection while retaining data, still increase retention, and still change the backup schedule. On a Backup vault the blocked list is narrower — stop protection with deletion of data. One wrinkle worth knowing before you lock: increasing retention is not allowed on an item whose backups are suspended, so items in that state need sorting out first. We find those during the review window rather than after the lock.

It is genuinely irreversible — Microsoft's documentation says the setting cannot be disabled once locked, and there is no support path that undoes it. That is why locking is a separate, approved step in the middle of this engagement rather than something we do on day one. We enable immutability first, your team works normally against the vault for several days, we review together what it blocked, and you sign off per vault. If a vault is not ready, we leave it enabled and unlocked, say so in the handover, and you can lock it later yourself using the same steps we document.

Yes, and it is Microsoft's requirement rather than our preference. Multi-user authorization only means anything if the person who administers the vaults cannot approve their own destructive operation, so the backup admin must not hold Contributor, Backup MUA Admin or Backup MUA Operator on the Resource Guard. If both hats sit on one head, the control is decorative. Where an organisation genuinely has only one infrastructure person, we usually put the Resource Guard under a different function — a security lead, a CFO-sponsored break-glass identity, or an owner outside IT — and design the approval flow around their availability. That conversation happens in the design step, not after the invoice.

It is a small Azure resource that acts as the gatekeeper: your vaults are associated with it, and the critical operations you choose then require a role on the Resource Guard, not just on the vault. Microsoft's guidance is that it should be in the same region as the vaults it protects, but in a different subscription — or, for maximum isolation, a different tenant — owned by the security admin. Different subscription gives medium isolation and is easy to run; different tenant gives the strongest isolation and is harder to test. We recommend one based on how your organisation is actually structured and record the trade-off, because the wrong answer here is a Resource Guard sitting in the same subscription with the same owners, which protects nothing.

Two are mandatory and cannot be excluded: disabling soft delete or security features, and removing MUA protection itself. The optional set, all enabled by default, covers stopping protection with deletion of data, modifying protection or policy in a way that reduces retention or worsens the recovery point objective, changing encryption settings, retrieving the MARS backup security PIN, deleting hybrid DPM, MABS and MARS containers, and disabling immutability. Restore is protectable too but off by default, and we normally leave it off — gating your own recovery during an incident is rarely what you want. We agree the exact set with you in the design step and record it, because it applies to every vault associated with that Resource Guard.

They request the Backup MUA Operator role on the Resource Guard, the security admin approves it, they perform the operation, and the role expires. We set that up in Microsoft Entra Privileged Identity Management as an eligible assignment with named approvers, multifactor authentication and, if you want it, a mandatory ticket reference — so the approval is logged rather than a Teams message. Microsoft's own advice, which we follow, is to grant Backup MUA Operator and never Contributor or Backup MUA Admin for these requests, because those two also carry delete rights on the Resource Guard itself.

Increasingly it is, and that is a good thing — but the picture is mid-rollout and worth checking rather than assuming. Under Microsoft's secure-by-default work, soft delete for Recovery Services vaults is enforced and can no longer be disabled from the portal, and soft delete now applies to vaults themselves as well as to items and recovery points. Backup vaults are further behind: generally available in Australia East, West Central US and East Asia, in preview elsewhere, and in those other regions the portal still offers a disable option. Older PowerShell modules, CLI versions and API versions can also still behave the old way in preview regions. Part of what you get from this engagement is a written statement of where each of your vaults actually stands and what your admins can still switch off.

Microsoft allows 14 to 180 days and defaults to 14. The first 14 days are free; beyond that, regular backup charges apply to the extra days on your own subscription. The case for going longer is dwell time — an intrusion that is only identified after six weeks is not helped by a 14-day window — and the case against is the bill on however much data you are protecting. We usually land organisations between 30 and 90 days after looking at their protected data volume and their detection story, and we show you the arithmetic rather than pick a number for you.

Microsoft does not publish a separate meter for enabling vault immutability, for the Resource Guard resource, or for soft delete inside the free 14 days. What does change your Azure bill is data you keep longer: soft-delete retention beyond 14 days, recovery points that immutability prevents you from deleting early, and cross-region restore, which Microsoft states incurs extra charges. All of those bill to your own subscription. We model the likely change during the design step and, because Microsoft's pricing is Microsoft's to change, we ask you to confirm it against your first invoice rather than take a number off this page.

Usually not, and it is better that you hear that now. Microsoft supports creating private endpoints only for vaults with no items registered to them — in both the version 1 and version 2 experiences — so a vault that already protects production generally cannot have them added. What we do is assess each vault, tell you plainly which qualify, and describe what a private-endpoint-enabled replacement vault would involve if you want one. That rebuild is a separate, quoted piece of work, not a line item we slip into a two-week hardening.

It lets you restore into the paired secondary region whenever you choose — for an audit or a drill, not only when Microsoft declares a regional disaster. The conditions matter: the vault must be geo-redundant, it is an opt-in per vault, it cannot be reverted once protection has started, it carries extra Microsoft charges, and it can take up to 48 hours before your items appear in the secondary region. For Azure VM backups the worst-case secondary-region recovery point objective is up to 36 hours. If your vault is locally or zone redundant, it is not available at all. We enable it where it fits and you have accepted those terms, and we write down the reason where we do not.

Setting up Azure Backup makes copies. This engagement makes those copies survive a compromised administrator, which is a different problem with different controls. If you are still running an incumbent product, the migration service builds the new estate with these controls on from the start and this page is redundant. If you want someone watching the jobs, chasing failures and restore-testing on a cadence afterwards, that is Managed Backup and Backup-Restore. We will tell you which of the three you actually need before you buy any of them.

This is the question the runbook exists to answer, and it is why we insist on writing one. The design names a break-glass identity that also holds the security-admin role on the Resource Guard, stored under your own privileged-credential process, plus a documented succession path: who can be granted Backup MUA Admin, by whom, and with what approval. We also rehearse it, so the first time your team raises and approves an out-of-hours activation is during the handover rather than during an incident. Getting this wrong is the single most common way multi-user authorization turns from a control into an outage.

$2,950 fixed for a two-week engagement covering up to three Recovery Services or Backup vaults in one Azure tenant, one Resource Guard and one restore test. The price is quoted in writing before work begins and you pay after you approve delivery. More vaults, more tenants or an estate-wide rollout is quoted per estate, because the effort follows vaults and Resource Guards rather than protected servers. Microsoft's Azure charges — protected instances, storage, extended soft-delete retention, cross-region restore — are yours and are never part of our fee. There is no lock-in: you can stop using our services at any point, subject only to invoices you have already approved.

Prove it, and the evidence is part of the closeout. We attempt a protected operation as the backup admin and show it failing without Resource Guard approval; we run the PIM activation and show the same operation succeeding; we fire a test backup security alert and show it arriving with your named recipients; and we restore a protected item you choose against the hardened configuration and record how long it took. A hardening engagement that hands over a screenshot of settings and no test results is not one we would sell.