Myth Buster: "Ransomware cannot hack immutable storage"

Share

Immutable storage is a key and proven technology. But we are seeing growing confidence from business and IT leaders who use it to protect some of their most sensitive and vulnerable data. The technology deserves confidence. Some of the assumptions that now surround it do not.

For many organisations, the ransomware conversation has become reassuringly simple. Backups are taken, an immutable copy is created, retention is applied and the organisation can say that ransomware cannot encrypt or delete its protected recovery data.

There is truth in that. There is also a danger in stopping there.

Immutability is a specific technical control. It is designed to protect the state of data against defined changes. It does not make the wider storage environment disappear. It does not remove identities, management interfaces, APIs, software, networking or recovery dependencies. Most importantly, it does not automatically remove the path by which those systems can be reached.

That distinction has become more important as ransomware has changed. Modern attacks are not simply pieces of malware moving through file shares and encrypting anything they can see. Threat actors seek privileged identities, move laterally, attack recovery infrastructure, manipulate cloud and storage controls, exfiltrate information and deliberately undermine the victim's ability to restore.

MITRE ATT&CK calls this Inhibit System Recovery, T1490. Its current guidance records adversaries disabling backup policies, deleting snapshots, attacking previous object versions and targeting online backups connected to the victim's network. MITRE's mitigation is equally revealing: keep recovery copies off system and protect them from the common methods attackers use to reach and destroy backups.

The UK's National Cyber Security Centre reaches the same conclusion from the defensive side. Its ransomware-resistant backup guidance begins not with immutability, but with the ability to isolate the backup solution. It explicitly warns that unnecessary connectivity can allow an attacker to pivot from a compromised device towards backups.

So this myth buster is not an argument that immutable storage has no value.

It is an argument that immutable should not become the final destination.

If the information is valuable enough to make immutable, business and IT leaders should be asking what else remains exposed around it.

What is immutable storage?

NIST defines immutable storage as a special type of backup storage that provides additional data integrity by storing data in a read-only format.

The concept is commonly associated with Write Once, Read Many, or WORM. Data is written and then prevented from being altered or deleted according to the technical rules of the storage system. Depending on the implementation, that protection may be permanent or may last for a defined retention period.

That definition is important because it tells us both what immutability does and what it does not do.

At its core, immutability deals with the state of the stored data.

It can prevent an existing protected version from being overwritten. It can prevent deletion. It can preserve a recovery point against destructive actions. Those are significant protections against ransomware.

But the definition itself says nothing about whether the storage remains network connected.

It says nothing about whether the wider platform has an IP address.

It says nothing about whether administrative APIs are available.

It says nothing about whether privileged identities can reach the surrounding control plane.

And it says nothing about whether a clean business can actually be reconstructed from the protected copy.

Those are separate security questions.

Who invented immutable storage?

There is no single inventor of immutable storage.

The modern lineage comes from WORM storage, particularly optical systems developed and commercialised during the early 1980s.

The US National Archives records that WORM optical media were first introduced in the early 1980s. These systems used a laser to make permanent physical changes to the recording surface. Once information had been recorded in that location, it could not simply be erased and rewritten.

That history matters.

Immutability was not invented for ransomware.

The original objective was data integrity and records preservation. Organisations needed a way to hold information that could be read later but could not quietly be changed after it had been committed to the medium.

Over time the physical WORM principle evolved into software, filesystem, snapshot and object-storage implementations capable of enforcing similar behaviour without requiring write-once optical media.

Ransomware gave the principle a powerful new purpose. If an attacker cannot alter or delete the recovery copy, that copy is substantially more useful after a destructive attack.

But the underlying security property has not changed.

Immutability protects what has been written from subsequent change.

It was never a technical definition of offline, unreachable or immune from compromise.

That is where some of today's myths begin.

The myths

Myth 1: Ransomware can't hack immutable storage

This is the claim that needs the most careful interrogation.

If by "hack" we mean rewrite a correctly locked immutable object during an enforced retention period, the technology may genuinely prevent that operation.

But that is a very narrow definition of what a ransomware attacker is trying to achieve.

An attacker does not necessarily need to break the immutable data itself.

They need control.

If they can compromise a privileged identity, reach the management environment, change policies, attack recovery services, disrupt new backups, manipulate keys or prevent the victim reaching their recovery data, the immutable copy can remain perfectly intact while the attack is still succeeding.

This is not theoretical.

In 2025, Microsoft Threat Intelligence documented Storm-0501 operating inside compromised cloud environments. The actor enumerated protections around storage, attempted to remove resource locks and immutability policies and successfully deleted multiple immutability policies before continuing with mass deletion of data stores. Where immutability protections remained active, the attacker could not simply remove those protected resources and instead changed tactics, using cloud-based encryption.

That example is important because it shows both sides of the argument.

Immutability that remained properly enforced did its job.

But the attacker had already reached the surrounding environment with sufficient privilege to manipulate other immutability controls.

That is exactly the distinction business leaders need to understand.

The protected object and the system controlling the protected object are not the same security boundary.

Modern ransomware increasingly attacks the latter.

MITRE's current T1490 guidance documents the same behaviour at a broader level. In cloud environments, attackers may disable versioning and backup policies and delete snapshots, database backups, machine images and prior object versions used for disaster recovery.

The NCSC also warns that backup management interfaces need to be separated, privileged credentials need isolating, administrative access needs protecting and backup software itself needs updating. Those controls would be unnecessary if making the data immutable automatically made the surrounding system safe.

So the reality behind Myth 1 is uncomfortable but straightforward.

Ransomware may not have to break the immutable copy. It can attack the controls, identities and infrastructure around it.

That is why "our data is immutable" should not end the conversation.

It should trigger the next question:

What can still reach it?

Myth 2: Immutable means offline

It does not.

This is not a matter of interpretation. They are different technical properties.

Immutable describes what can happen to the data.

Offline describes whether a network path to the data exists.

An immutable repository can remain online. It can operate across an IP network, authenticate users and machines, receive API requests and expose management interfaces while still correctly preventing a protected version from being altered or deleted.

That is connected immutable storage.

It is not offline storage.

The NCSC makes this separation explicit. Its first ransomware-resistant backup principle is to make the backup solution isolatable. The guidance recommends network segregation and specifically identifies physically disconnected backup media stored away from the network as an air-gap implementation.

CISA makes the same separation. Its StopRansomware guidance recommends maintaining offline encrypted backups because ransomware commonly searches for accessible backups and attempts to encrypt or delete them. The same guidance separately recommends delete protection or Object Lock for storage resources.

That is important.

If immutable automatically meant offline, authoritative guidance would have no reason to recommend both.

The difference is the path.

With connected immutable storage, a route may remain available while the storage system decides which operations a particular identity is permitted to perform.

A connection request arrives.

An identity is evaluated.

A policy is checked.

A decision is made.

The fact that a destructive action may then be refused is valuable, but the environment has still been reached.

Offline is different.

An offline state begins earlier in the chain. There is no usable network route waiting for the next authentication or authorisation decision.

This is why the network and control plane deserve much more attention in conversations about sensitive data.

Ransomware cannot exploit a remote path that does not exist.

That does not make offline storage invulnerable to every possible threat. Physical access, authorised sessions, insider risk, endpoint security and operational controls still matter.

But it changes what a remote attacker can reach while the storage is disconnected.

And that is a fundamentally different security condition from being continuously connected and relying on software policy to refuse certain actions.

Myth 3: Immutable storage guarantees easy recovery

Preserving data and recovering a business are not the same job.

An immutable recovery copy is useful precisely because it may survive an attack against the live environment.

But recovery still requires a chain of things to work.

The correct recovery point has to be identified. Credentials must be available. Encryption keys need to remain usable. Recovery software and catalogues need to function. Infrastructure may need rebuilding. Applications have dependencies. Systems have to return in the right sequence. Restored data needs to be checked before the organisation can trust it.

And there is an even more fundamental problem.

When did the compromise begin?

Ransomware is often the visible end of an intrusion rather than the beginning.

An attacker may already have compromised systems before encryption is finally deployed. Backups can continue running during that time.

An immutable system will preserve those backups exactly as it is supposed to.

That can include copies containing corrupted or compromised data.

The NCSC specifically models this problem in its cloud-backup principles. It warns that if an attacker can flood the backup store with corrupted backup data, the attacker may not need to delete the existing backups at all. The NCSC therefore recommends fixed retention periods, version histories and regular restoration testing so that an organisation can return to an earlier state.

NIST reaches the same conclusion in its work on recovering from ransomware and destructive events. Successful recovery includes identifying the correct backup version free from malicious code and corrupted data and restoring to the last known-good state.

That exposes another limitation in the comfort surrounding immutability.

Immutability can tell you that the copy has not subsequently been changed. It cannot tell you that what originally entered the copy was clean.

The distinction is critical.

If compromised source data becomes the next immutable recovery point, the storage has not failed. It has done precisely what it was designed to do.

The difficulty belongs to recovery.

This is why CISA recommends that organisations regularly test both the availability and integrity of backups in a disaster-recovery scenario, rather than assuming that the presence of backup data proves recoverability.

An immutable copy is therefore a recovery asset.

It is not, by itself, a recovery outcome.

Myth 4: An attacker can't touch the immutable copy, so I'm safe

This myth assumes that changing the copy is the attacker's only objective.

It is not.

Modern ransomware operations frequently combine disruption with data theft and extortion. A threat actor may steal valuable data long before deciding whether to encrypt anything.

The NCSC makes this limitation unusually clear. Its ransomware-resistant backup guidance explicitly says that the principles are focused on destructive ransomware and do not solve the growing problem of attackers stealing data to use for extortion. It therefore says the backup system itself must still be protected against unauthorised access because it holds sensitive and critical information.

That is a major distinction.

A file can remain completely immutable while its confidentiality has already been lost.

The attacker does not have to delete it.

They do not have to encrypt it.

They do not have to change one byte.

If they can reach it with sufficient read access and extract the information, the immutable copy can remain pristine while the organisation still has a serious breach.

Nor does an attacker necessarily have to destroy the backup to deny recovery.

The NCSC's cloud guidance explicitly considers a scenario where a threat actor disables or deletes customer accounts or corporate identities so the victim can no longer reach its own backups. In that situation, the guidance notes that the attacker does not need to do anything as destructive as deleting the data. It recommends retaining a separate out-of-band mechanism for obtaining backup access even when normal corporate IT is unavailable.

The same guidance also considers encryption keys. If backup data is encrypted at rest, an attacker may find it easier to delete or manipulate the key than to delete the underlying stored data. The NCSC therefore recommends robust key management and even an out-of-band key backup.

Again, the immutable bits can survive.

Control of the data can still be lost.

This is why immutability, confidentiality, availability and isolation should not be collapsed into one reassuring word.

They are different security properties.

Myth 5: I don't need more controls. Immutability is enough

This is the myth that concerns us most.

Not because immutability is ineffective, but because success in one area can create overconfidence in the rest of the architecture.

We increasingly encounter business and IT leaders who are understandably reassured that their most important recovery data is immutable.

But if immutability were enough on its own, the leading cyber authorities would not recommend so many additional protections around it.

The NCSC's on-premises ransomware-resistant backup guidance contains six separate principles. Isolation comes first. Updating the backup solution comes next. Resilience against destructive actions, restoration from earlier versions, robust key management and alerts around significant or privileged activity all follow.

Its guidance also tells organisations to isolate backup credentials from the accounts used to administer the rest of the network because ransomware attackers commonly discover enterprise administrator accounts and use them to move laterally.

CISA recommends offline backups, restoration testing, Object Lock or deletion protection, version control and incident-recovery planning.

MITRE advises organisations to keep backups off system and protected from common methods adversaries use to gain access to them.

The pattern is remarkably consistent.

Protect the copy, but do not stop there.

Why?

Because ransomware is not a single-control problem.

It attacks endpoints.

It attacks identity.

It attacks administrative privilege.

It attacks backup and recovery infrastructure.

It attacks software.

It attacks connected storage.

It attacks cloud control planes.

It steals information.

It exploits the route that remains available.

Immutability can close one extremely useful door.

It does not close all of them.

The reality

There is a reason immutable storage has become popular.

It addresses a real problem very effectively: destructive modification of protected data.

That deserves recognition.

But the comfort around immutability needs resetting because the technology's protection boundary is narrower than the language sometimes used around it.

An immutable copy may resist alteration while still sitting inside an IP-connected environment.

The storage may still have a live management plane.

Privileged identities may still administer it.

Machine identities may still access it.

APIs may still be available.

Backup software may still interact with it.

Recovery may still depend on connected infrastructure.

A compromised source may still send bad data into it.

An attacker with authorised read access may still be able to obtain information without changing it.

The NCSC's guidance effectively acknowledges all of those surrounding dependencies. It calls for isolated credentials, separated management interfaces, physical disconnection as an isolation option, out-of-band authorisation for exceptional destructive requests, out-of-band recovery access, key protection and version histories.

That is not a criticism of immutable storage.

It is evidence that immutability alone cannot be the final control.

And it raises a question that is particularly important for the most sensitive and vulnerable information an organisation holds.

Does this data actually need to remain continuously reachable?

The answer will not always be no.

Production workloads need connectivity.

Applications need to function.

Operational data needs to move.

A business cannot disconnect everything and continue operating.

But that is not the question.

The question is whether everything needs the same permanent connectivity.

Intellectual property that is rarely accessed.

Completed legal matters.

Board and governance records.

Corporate archives.

High-consequence customer information.

Recovery gold copies.

System configurations and golden images.

Sensitive documents retained because of their importance rather than because people need them every minute.

For that category of data, "we made it immutable" should not end the architectural discussion.

It should begin another one.

Why is it still reachable when nobody needs it?

Immutable vs Offline Secure Storage®

This is where immutable storage and Offline Secure Storage® separate technically.

They are not two names for the same idea.

They control different things.

Immutable storage controls the state of the copy.

A protected copy can remain available through the wider storage architecture while rules determine whether it can be overwritten, changed or deleted.

The route may still be live.

The control plane may still be IP connected.

The management environment may still be available.

The policy decides what a user or machine reaching that system is permitted to do.

Offline Secure Storage® controls the physical path to what matters.

Firevault OSS is physically disconnected from the network by default. Access begins through an authorised out-of-band command, separate from the normal data path, which controls whether the physical Layer 1 connection exists. The storage is enabled for an approved, identity-verified and time-limited session and physically disconnected again afterwards. Outside that session there is no standing network path or IP address to the storage.

That last point is fundamental.

OSS is not IP-controlled at the point that determines whether the physical path exists.

An attacker sitting inside the protected organisation's normal IP environment cannot simply discover another storage IP address or send an IP request to a control endpoint on that network to make the offline storage path appear.

The authorisation that controls the physical Layer 1 route begins out of band from that normal network path.

Once connected for an authorised session, of course, the storage is reachable and normal cyber-security controls matter again.

That is why Firevault describes OSS as online when you need it, offline when you do not rather than pretending the data exists in some permanently inaccessible state.

The aim is to reduce the amount of time the route exists.

That changes the attack surface.

With conventional connected immutable storage, the security conversation often begins after the attacker reaches the service:

Is this identity valid?

Does this principal have permission?

Can this object be deleted?

Can this policy be changed?

Is MFA required?

What operations will the API accept?

Those controls matter enormously.

OSS introduces a more basic question before them:

Is there currently a physical path to the storage at all?

When the answer is no, there is no standing IP route for a remote attacker to enumerate, authenticate against or exploit.

This is why we do not see Offline Secure Storage® as a replacement for backup, encryption, identity management or immutability.

It addresses another part of the problem.

The part that begins with connectivity itself.

Why non-IP path control matters

Ransomware normally depends on reachability.

The attacker compromises something connected, establishes access, moves through identities or network paths and tries to expand what can be controlled.

Modern attacks increasingly make legitimate management systems and administrative interfaces part of that journey.

Storm-0501 is a useful real-world illustration. The actor did not need an exotic attack against the underlying storage physics. It obtained sufficient privilege within the connected control environment to perform legitimate control-plane operations maliciously, including attempts to delete the very policies designed to protect recovery data.

That is what makes the point of control important.

If the decision that connects sensitive storage is another normal IP-accessible function within the environment an attacker is attempting to compromise, it becomes another digital control that has to remain perfectly protected.

OSS changes where that decision sits.

The physical route is controlled out of band rather than through the protected IP path.

The distinction is subtle until an organisation is compromised.

Then it becomes very significant.

One architecture says:

"The route exists, but the system should refuse what the attacker is trying to do."

The other can say, for much of the time:

"The route does not exist."

That is not a claim of invulnerability.

It is reduction of exposure through architecture.

Immutability is a layer, not the final destination

The point of this myth buster is not that organisations have been wrong to invest in immutable storage.

It is that they should be careful about what confidence they take from that investment.

Immutable storage is a proven technical control.

But no immutable label can remove realities that sit outside its protection boundary.

If the surrounding platform remains connected, a connected attack surface remains.

If privileged identities control it, identity remains part of the trust model.

If APIs administer it, those APIs remain part of the control plane.

If the source is compromised, later protected copies may preserve compromised data.

If an attacker can read the information, immutability alone does not prevent exfiltration.

If recovery relies on other infrastructure, the existence of an intact copy does not guarantee the business can immediately use it.

And if the data has no operational reason to remain continuously accessible, permanent connectivity itself deserves to be challenged.

This is where we believe the ransomware conversation needs to move.

For years the industry has rightly focused on making the recovery copy harder to destroy.

The next question is whether some of that data should remain remotely reachable in the first place.

Protect the copy. Then protect the path.

Immutability protects an important property of a protected copy.

Offline Secure Storage® addresses a different property: reachability.

For data that needs to stay live, the organisation will continue to rely on connected security controls.

For selected sensitive and vulnerable information that does not need permanent access, another option exists.

Remove the standing path.

Make access intentional.

Control when the physical connection exists.

Disconnect it again when the authorised session ends.

That is the purpose of Offline Secure Storage®.

Not to pretend ransomware has one simple answer.

Not to dismiss a proven technology.

But to challenge the comfort that comes from assuming the protected copy is the end of the problem.

Because the most useful question for some of the data that matters most may no longer be:

"Is it immutable?"

It may be:

If nobody needs access to it right now, why is there still a path to it?

Immutability protects the copy. Offline Secure Storage® protects what matters.

Technical note

Immutable storage covers a range of WORM, retention, snapshot, filesystem and object-storage implementations, and capabilities vary according to design and configuration. This article does not claim that ransomware can necessarily overwrite or delete a correctly enforced immutable object during its protected retention period. The evidence instead shows why ransomware resilience must also consider the identities, management plane, policies, source data, recovery infrastructure and network paths surrounding that object.

The Storm-0501 incident is included on that basis. Published threat intelligence records successful deletion of multiple immutability policies after privileged compromise, while resources whose immutability protections remained enforced resisted deletion. That distinction is central to the article, rather than an exception to it.

Primary sources and further reading

The technical position above is grounded principally in NIST's definition of immutable storage and ransomware recovery research, the NCSC's ransomware-resistant backup principles, CISA's StopRansomware guidance, MITRE ATT&CK's Inhibit System Recovery technique, the US National Archives' history of WORM storage, and published Microsoft Threat Intelligence on Storm-0501

• NIST, immutable storage glossary definition
• NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events
• NCSC, Offline backups in an online world and ransomware-resistant backup principles
• NCSC, Principles for ransomware-resistant cloud backups
• CISA, #StopRansomware Guide
• MITRE ATT&CK, T1490 Inhibit System Recovery
• US National Archives, optical WORM media history
• Microsoft Threat Intelligence, Storm-0501 cloud-based ransomware

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.