Immutable backup architecture that holds even when attackers have admin access.
The modern attacker playbook destroys or encrypts backups before encrypting production data. An architecturally immutable backup is both the commercial control — because the insurance question now requires it — and the operational control, because it is what actually works when attackers reach the backup system.
See what makes a backup genuinely immutableAn immutable backup is a recovery copy that cannot be altered, encrypted or deleted for a defined retention period — even by an account with administrator-level credentials to the backup system or storage platform. The defining test is adversarial: can an attacker with legitimate admin credentials destroy or modify the backup within its retention period? If the answer is no, the backup is immutable. It matters now because the modern attacker playbook destroys backups first, and insurers explicitly ask about it on renewal questionnaires.
What it is, why it matters, and what implementations work.
What is an immutable backup?
A recovery copy that cannot be altered, encrypted or deleted for a defined retention period, even by an admin-level account. Immutability is enforced by the underlying storage layer, not by a policy that a compromised administrator could reverse. The test is adversarial: can an attacker with legitimate admin credentials destroy it within its retention period? If no, it is immutable.
Why does it matter now?
The modern attacker playbook destroys or encrypts backups before encrypting production. Insurers know this and now explicitly ask about immutable backup architecture on renewal questionnaires. It is both the commercial control (the question requires it) and the operational control (it is what works when attackers reach the backup system).
What approaches work?
Three common patterns: a Veeam Hardened Linux Repository with the immutable flag; cloud Object Lock in compliance mode (S3, Azure Blob immutable, Wasabi); or a dedicated appliance (Rubrik, Cohesity). What matters is that immutability is enforced at the storage layer, credentials are separated, and retention covers realistic attacker dwell time.
Attackers target the backups first. The recovery path is the reason most organisations do not pay.
The economics changed when attackers started treating backup infrastructure as the primary target. An organisation with intact backups can refuse to pay and restore; an organisation whose backups have been deleted, encrypted or rendered inaccessible often cannot — regardless of what the documentation says. The common attack sequence is predictable.
Phishing, credential theft, or an unpatched perimeter device gives the attacker a foothold. Lateral movement identifies administrator credentials and the structure of the environment, including where backups live.
The attacker finds or phishes credentials with administrator access to the backup system. In many environments this is easier than it should be, because backup admin credentials are shared with general IT admin roles or stored in accessible password vaults.
Using the legitimate admin credentials, the attacker deletes, encrypts or corrupts the backup repository. Shadow copies are removed, retention policies shortened, backup jobs disabled. This is completed before production encryption because it removes the victim's primary negotiating position.
With the recovery path destroyed, the production environment is encrypted and the ransom demand presented. The organisation discovers during incident response that their backup is also gone, and the commercial pressure to pay is substantially higher.
Immutability is a property of the storage, not a claim about intent.
The word immutable has become marketing language. The test for whether a specific configuration actually is immutable is narrower than the marketing. A backup is genuinely immutable when all four of the following hold.
The storage itself refuses to modify or delete the data within the retention period. A policy or configuration setting a privileged user can reverse is not immutability. Write-Once-Read-Many (WORM) storage with time-bound retention locks is.
If a root or global administrator can reduce the retention period or remove the lock during its life, the lock is advisory rather than structural. Compliance mode on Object Lock, Veeam's immutable flag on a hardened repository, or appliance-enforced retention meet this test.
The backup system is not accessible using the same identity that runs the production environment. Separate accounts, separate MFA, separate administrative boundaries. A compromise of production admin does not automatically reach the backup.
Industry observation places median attacker dwell time in the weeks-to-months range before encryption is triggered. Immutability retention measured in single-digit days is too short — the window has to outlast the attack timeline, not just the backup rotation cycle.
If any of the four fails, the backup is immutable in documentation but recoverable-from in an adversarial scenario. The distinction matters because the scenario the backup is protecting against is exactly the adversarial one.
Three architectural approaches, each with different operational trade-offs.
All three produce architecturally immutable backups when configured correctly; all three have specific failure modes when not. The choice is platform-neutral — it depends on what the environment already runs, the real recovery requirements, and what the operational team can maintain.
Veeam Hardened Linux Repository
A dedicated Linux host with the immutable flag set on backup files, enforced by Linux file attributes with a per-job retention period. Single-purpose, no general shell access, SSH disabled, dedicated service accounts. Best suited to organisations running Veeam as the primary backup product with infrastructure to host a dedicated repository — common in Australian environments with existing Veeam investment.
Cloud Object Storage with Object Lock
Backup data written to cloud object storage with Object Lock in compliance mode: Amazon S3, Azure Blob immutable storage, Wasabi or equivalent. Retention is set per object and cannot be shortened by any account, including root, until the lock expires. Best suited to cloud-first environments. Compliance mode is the meaningful configuration; governance mode allows override and does not meet the test.
Dedicated Immutable Backup Appliance
A purpose-built appliance (Rubrik, Cohesity and similar) that implements immutability as a primary architectural feature, enforced by the appliance's internal architecture rather than a configurable option on general-purpose storage. Best suited to enterprise-grade recovery requirements, multiple workload types, or environments where the appliance's evidence output is material. Higher investment than the other two.
The configurations that turn immutable backup into a destroyable recovery path.
Every failure pattern below is documented in Australian backup architecture reviews. Each converts a backup that is immutable in name into one destroyable by a sufficiently privileged attacker.
Governance mode allows specially privileged users (or account root) to shorten or remove retention locks; compliance mode does not. A review that finds governance mode where compliance mode was assumed is one of the most common specific findings in current renewal assessments.
The same account that manages production Active Directory, Microsoft 365 or hypervisor infrastructure also manages the backup system. A compromise of that account reaches the backup regardless of WORM configuration, because the attacker logs in as the legitimate admin.
A 7-day immutability window does not protect against an attacker who has been in the environment for weeks. Backups valid at the start of the dwell time roll out of immutability before the attack is detected.
Storage-layer immutability prevents deletion of backup files. It does not prevent an attacker on the production network from reaching the backup infrastructure's management plane, disabling new backup jobs, or ransoming the backup system itself. Network separation is an additional layer, not an optional one.
The backup admin account is MFA-enforced, or it is not. On current insurance questionnaires this is one of the most specific questions, and absence of MFA on backup admin is one of the most common claim-denial triggers after a loss event.
The architecture is immutable; nobody has actually restored from it. A backup never restored in anger is an assertion about recovery capability, not evidence of it. Insurance questionnaires and the Recovery Readiness Assessment both ask for the test, not just the architecture.
Every one of these failure modes looks fine on an architecture diagram. A configuration-layer review is the only way to know which one is quietly true in your environment — before an attacker finds out for you.
Verify your immutabilityImmutability is demonstrated through configuration, not attestation.
An insurance questionnaire asking about immutable backup architecture expects evidence. A statement that backups are immutable is the starting point of the conversation, not its conclusion. Each question maps to a specific artefact.
A visual representation showing where immutability sits: which workloads flow to which repository, network boundaries, credential boundaries. It makes the architecture legible to an underwriter who is not going to audit the environment directly.
For Veeam, the repository configuration showing the immutable flag and retention period. For cloud Object Lock, the bucket policy showing mode (compliance) and retention. For an appliance, the immutability configuration screen. This is the specific evidence that immutability is enforced as described.
Documentation showing backup admin accounts are distinct from production admin accounts, MFA enrolment records for backup admin, and a privileged access review showing the backup admin role is scoped appropriately.
A dated record of a restore test with scope, procedure, timing, outcome and any issues. The test should cover a restore from the immutable copy specifically, not just from any copy. This converts the architecture from a claim into a verified capability.
A short rationale explaining why the chosen retention period covers the attack scenarios the backup protects against. Not demanded by every underwriter, but providing it pre-empts the question and signals operational sophistication.
Four characteristics that turn an immutable backup from a claim into evidence.
WORM, Object Lock in compliance mode, or appliance-enforced retention. Never a mutable storage layer with a documented policy against deletion.
30 to 90 days on recent backups, longer on periodic full backups. Not default-7-days set because that was what the install wizard suggested.
Backup admin accounts distinct from production admin accounts. MFA enforced. Break-glass documented. Shared-account patterns treated as architectural gaps.
A restore from the immutable copy performed and documented within the current review cycle, covering a representative workload, with a report that is current when an insurer asks.
One architectural layer in a broader recovery position.
Immutable backup architecture is one category in a broader recovery posture. It connects to backup credential separation, network isolation, restore testing, identity recovery sequencing, dependency modelling and the evidence layer that current insurance questionnaires increasingly require. Where the broader question is "could we recover from a destructive cyber event with evidence that holds up at renewal," immutable backup architecture is assessed inside a Recovery Readiness Assessment rather than as a standalone problem. Where immutable backup architecture is the specific area that needs attention and the rest of the recovery position is already understood, the work can be scoped directly within Backup and Disaster Recovery.
The Inlight IT view on immutable backup architecture.
Immutable in the documentation and immutable in the architecture the attacker actually meets are not the same thing. The distinction matters because the scenario immutability is protecting against is exactly the one where the documentation stops being relevant. The failure patterns are not failures of imagination or investment — they are the accumulated consequence of configurations made at different times by different people under different priorities, with no single pass ever checking the whole architecture against the specific adversarial scenario. That pass is cheap relative to the loss event it protects against, and on current insurance questionnaires it is also what the renewal process now implicitly demands.
Where organisations usually have work to do is in four places: storage-layer enforcement actually verified rather than assumed; backup admin credentials separated from production admin credentials with independent MFA; retention set against realistic attacker dwell time rather than backup rotation defaults; and a dated restore-test report from the immutable copy specifically. None of these is exotic, and all four are commonly absent until a structured review surfaces them. Defensible immutability is the benefit; the operational discipline to verify the configuration, separate the credentials and run the dated restore test is the trade-off.
A backup that exists is not the same as a recovery path that works. The difference matters most on the day it is tested by an attacker.
“We have immutability” and “our restore points survived an attack on the backup platform” are different claims. Only one is testable in advance.
Test the claim →Immutable backup architecture in practice.
As an illustration of the framing rather than a headline: in one professional-services environment, a backup architecture was reviewed specifically for storage-layer enforcement, credential separation from the production administrative identity, retention against realistic attacker dwell time, and dated restore-test evidence. The review surfaced specific configuration findings — the kind that are invisible on an architecture diagram but decisive under adversarial conditions — which were then sequenced into a defined remediation pass. The point of the example is the method: immutability verified at the configuration layer, not assumed from the diagram.
Questions Australian organisations ask about immutable backup architecture.
What is an immutable backup?
Why does immutability matter specifically for cyber attacks?
What are the common ways to implement immutable backup?
What is the difference between governance and compliance mode?
How long should the immutability retention period be?
Does immutability replace the 3-2-1 backup rule?
Where do immutable backup implementations commonly fail?
How is immutability demonstrated to insurers and auditors?
Can Microsoft 365 backups be made immutable?
How is immutable backup architecture assessed?
Verify immutability at the configuration layer, not the diagram.
A short review checks storage-layer enforcement, credential separation, retention adequacy and dated restore evidence against the adversarial scenario your backup actually has to survive.
Review your backup immutability