The nightmare scenario for a SCADA site is not just that ransomware encrypts the live servers, but that it also finds and encrypts the backups, leaving nothing to restore from. An immutable backup is designed to survive exactly that attack. It is a copy that, once written, cannot be modified or deleted by anyone - not an operator, not an administrator, not malware holding stolen credentials - until a defined retention period expires. This guide explains how immutability is enforced through object lock and hardened repositories, why it is the last line of defense when the attacker already has the keys, and how OT sites put immutable copies in place.
Immutable backup in one line: An immutable backup is a backup copy that cannot be changed, overwritten, or deleted for a fixed retention period after it is written, even by an administrator or by malware. It is implemented with write-once-read-many storage, object-lock features, or hardened backup repositories, and its purpose is to guarantee a clean, restorable copy exists even after ransomware has compromised the network and encrypted every other backup it could reach.
Immutability comes from the acronym WORM, write once read many, a storage behavior where data can be written a single time and thereafter only read, never altered. A conventional backup lives on storage that permits overwrite and delete, which is convenient for housekeeping but fatal when an attacker gains write access. Immutable storage flips that: for the length of the retention period you set, the platform refuses every request to modify or remove the protected copy, returning an error rather than obeying, regardless of who is asking.
The most common mechanism today is object lock on cloud or on-premises object storage. When a backup is written as a locked object with, say, a thirty-day retention, the storage system itself enforces that the object survives untouched for thirty days. Some deployments add a legal-hold or compliance mode in which even the account owner cannot shorten the retention or delete early, closing the loophole where a compromised administrator account could otherwise cancel the protection. The lock is enforced below the application, so it holds even if the backup software or the credentials above it are subverted.
On-premises, immutability is often delivered through a hardened backup repository: a purpose-built appliance or a Linux repository server whose immutability flag prevents the backup files from being changed for their retention window, exposing no general-purpose management path an attacker could use to strip the flag remotely. Tape, rotated out and stored offline, is a low-tech form of the same idea - once the cartridge is ejected and shelved, nothing on the network can rewrite it. What all these share is that the guarantee comes from the storage layer, not from a policy someone could quietly override.
Ordinary backups assume the threat is hardware failure or human error, and against those they work fine. Ransomware breaks that assumption because it is an intelligent adversary that, once inside, deliberately hunts for backups and destroys them before triggering encryption, precisely so the victim has no choice but to pay. Attackers frequently spend days moving through a network, learning where backups live, harvesting administrator credentials, and disabling or encrypting the backup jobs first. Against that playbook, a backup that any administrator can delete is only as safe as the most compromised admin account.
An immutable copy defeats this because the destruction step simply cannot succeed. Even with full administrator credentials and full network access, the attacker's delete and overwrite commands against the locked copy are refused by the storage. The ransomware can encrypt the live SCADA server, the historian, the engineering stations, and every mutable backup it can reach, and the immutable copy still sits there intact and restorable. That is why immutability is described as the last line of defense: it is the copy that is still standing after every copy the attacker could touch is gone.
This last-line role is why immutability pairs naturally with air-gapping rather than replacing it. An air-gapped copy is unreachable because it is disconnected; an immutable copy may stay online and reachable but is unchangeable. Layering both - an offline copy plus an online immutable copy - covers the two ways a backup dies during an attack: being reached and being altered. For OT, where a prolonged control-system outage has physical and safety consequences, having a copy that is mathematically guaranteed to be restorable shortens the worst day from an existential crisis to a recovery operation.
In practice, OT sites layer immutability onto the copies that matter most: the SCADA project files, the historian database, and full server images. A common pattern sends the nightly backup to a hardened on-premises repository for fast local restore, then copies it to immutable cloud object storage with a retention period matching the recovery window, so a clean copy always exists both near and far. Retention is chosen to comfortably exceed the time it typically takes to detect an intrusion, because a copy that unlocks before the attack is discovered offers no protection.
Access discipline surrounds the immutable store. The credentials that write immutable backups should be separate from ordinary administrative accounts and should have no authority to shorten retention or disable the lock, so that stealing a domain administrator does not hand the attacker control of the last clean copy. Immutability guards against alteration, but it does not verify content, so restore drills are still essential: a copy that is safely locked but was captured while the historian was mid-write is a preserved corruption. Testing restores from the immutable copy confirms it actually rebuilds a working system, not just that it survived.
Cloud SCADA reduces the burden here for the historical data. When a platform such as Merobix ingests field measurements into a managed cloud historian, that history is stored, replicated, and retained on infrastructure outside the customer's control room, insulated from ransomware that lands on site engineering stations. Configuring immutable retention on those exports means the measurement history from remote wells, tanks, and meters cannot be silently rewritten or wiped, so the record operators and auditors rely on stays trustworthy even if the on-site network is compromised.
No, though they solve overlapping problems. An air-gapped backup is protected by being disconnected, so nothing on the network can reach it. An immutable backup can stay connected and online but is protected because the storage refuses to alter or delete it for its retention period. Strong OT strategies use both, so a copy survives whether the attacker tries to reach it or tries to change it.
In a properly configured compliance or locked mode, no - not until the retention period expires. That is the point: even a legitimate administrator, or an attacker who has stolen administrator credentials, is refused when they try to delete or shorten the retention early. In weaker governance modes an administrator can override the lock, so OT deployments that want true ransomware resilience use a mode where no one can cancel the retention early.
No. Immutability guarantees the copy will not be altered or deleted, but it does not check that the copy was captured cleanly. If you snapshot a running historian without quiescing it, you can lock in a corrupt copy that is perfectly preserved but will not restore. That is why immutable backups must still be validated with periodic restore drills to confirm they actually rebuild a working system.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.