Commvault AirGap immutability raises the bar for backup resilience

At a glance

What this is: This is a Commvault analysis of AirGap immutability, WORM lock support, and the cost trade-offs around protected backup storage.

Why it matters: It matters because backup immutability is only useful when identity, storage, and recovery controls work together under real incident pressure, especially for ransomware and resilience programmes.

👉 Read Commvault's analysis of AirGap immutability and backup resilience

Context

Backup immutability is meant to prevent an attacker or an accidental process from modifying protected recovery data after it is written. In practice, the control only matters if the platform can preserve that state across the storage targets, operational model, and recovery workflow that organisations actually use.

Commvault frames AirGap as immutable by design and extends that posture with WORM lock support for organisations with compliance requirements. The wider governance issue is not just storage protection, but whether teams can validate that backup resilience holds up when systems, credentials, and recovery paths are stressed in the real world.

Key questions

Q: How should organisations test whether immutable backups actually survive an attack?

A: They should test the full recovery path, not just the backup job. That means simulating deletion attempts, credential misuse, and restore pressure against production-like data, then checking whether protected objects remain intact and recoverable. The goal is to prove that immutability, access controls, and recovery orchestration all hold together under realistic incident conditions.

Q: Why does WORM lock change the way backup costs should be evaluated?

A: WORM lock creates retention that cannot be optimised like mutable storage, so the right cost model must include infrastructure, compute, operations, and restore validation. A low storage price does not mean a low-risk or low-friction recovery design. Practitioners should compare architectures on durability and operational burden, not just capacity consumption.

Q: What do security teams often get wrong about immutable backups?

A: They often treat immutability as proof of resilience. In reality, immutability only protects the stored data. Recovery still depends on access governance, privileged administration, and restore process reliability, so teams need to validate the entire path from retention policy to successful recovery.

Q: Who should be accountable for backup immutability and restore access?

A: Backup immutability and restore permissions should sit under identity governance, not storage alone. The teams that can change retention settings, manage object-lock policy, or run restores are holding privileged access and should be reviewed accordingly. PAM, access review, and separation-of-duties controls all apply here.

Technical breakdown

Immutable backup storage and WORM lock semantics

Immutable backup storage prevents protected objects from being changed or deleted for a defined period, while WORM lock enforces write-once, read-many behaviour at the storage layer. The architectural question is where the immutability guarantee is enforced, because backup software, object storage policy, and retention controls each contribute differently. Commvault points to support for Amazon S3 Object Lock and Azure Blob immutability policies, which are common cloud enforcement points for protected backup data. The critical distinction is between a vendor claim of immutability and a policy-backed retention state that survives normal administrative action.

Practical implication: verify where immutability is enforced in your backup stack and test whether administrators can override it in practice.

Why WORM-enabled storage changes total cost of ownership

WORM-locked data cannot be optimised in the same way as mutable data, so storage overhead is only one part of the cost model. The broader total cost of ownership includes infrastructure, compute, operational effort, and the design choices needed to keep protected data available over time. Commvault argues that cloud-native architectures can reduce some of that overhead by avoiding persistent appliance dependencies and by managing data more efficiently. For practitioners, the key technical point is that immutability introduces a durability trade-off, not a free security layer. The right comparison is therefore resilience per unit of operational friction, not raw capacity price alone.

Practical implication: evaluate immutable backup designs using full lifecycle cost, not just storage consumption per terabyte.

Real-world recovery testing is the only proof that matters

Backup resilience is not proven by a feature list. It is demonstrated when recovery workflows succeed under realistic conditions such as malicious deletion attempts, large-scale restore events, and constrained operational environments. Testing should cover the full path from protected storage to restore validation, because a backup that is technically immutable can still fail if access paths, orchestration, or recovery sequencing are brittle. Commvault’s emphasis on simulated cyberattack scenarios reflects a broader best practice in resilience engineering: controls must be exercised, not assumed. The important measure is not whether a backup exists, but whether it can be restored within the organisation’s operational tolerance.

Practical implication: run recovery exercises against production-like data and prove restore success before an incident forces the test.

NHI Mgmt Group analysis

Immutable backup claims only matter when the restore path is equally defensible. A backup platform can prevent modification at rest and still leave organisations exposed if the recovery workflow is weak, overly privileged, or too brittle to survive a real attack. The governance question is not whether immutability exists in isolation, but whether the identity and operational controls around restore can be trusted under pressure. Practitioners should treat backup resilience as an end-to-end control, not a storage feature.

WORM lock shifts the conversation from capacity to control assurance. The industry still tends to evaluate protected backups through a storage-cost lens, but that misses the governance value of a retention state that resists tampering. Once organisations accept that immutability carries overhead, the more relevant question becomes whether that overhead is justified by the reduction in rollback risk and recovery uncertainty. Backup teams should align retention design with incident recovery objectives, not with procurement shortcuts.

Real-world validation is the only credible test of cyber resilience. Vendor claims about immutable storage do not answer the operational question that matters most: can the organisation still restore when credentials are compromised, systems are under load, or administrators are operating under incident constraints. This is where resilience programmes often drift into paper compliance. Security leaders should insist on recovery exercises that measure actual restore success, not just policy existence.

Cloud-native backup architecture changes the cost conversation, but not the control requirement. Moving away from appliance-heavy models may reduce persistent infrastructure burden, yet it does not remove the need for strong retention, access governance, and recovery assurance. The underlying issue is that teams often over-focus on unit storage cost while under-investing in the operational controls that determine whether backup data remains usable. Practitioners should assess architecture through the lens of recoverability, not just spend.

Identity governance extends into backup operations because recovery access is privileged access. Backup administration, object-lock management, and restore permissions all create high-impact identity paths that are easy to overlook in resilience programmes. If those permissions are not tightly scoped and reviewed, immutability can coexist with excessive operational privilege. The practical conclusion is that backup platforms should be governed as part of PAM and lifecycle control, not as a separate storage domain.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, a confidence gap that often shows up first in privileged recovery paths.
• For a broader governance lens, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding shape durable identity control.

What this signals

Identity governance reaches into backup operations the moment recovery becomes a privileged workflow. If restore, retention, and object-lock administration are not folded into lifecycle and access review processes, backup immutability becomes a storage claim rather than a resilience control. That gap is especially visible when teams still rely on Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for human and machine access separation but leave backup permissions outside the same governance model.

Protected backup programmes should be benchmarked against broader identity control maturity, not against vendor claims. With 88.5% of organisations saying their NHI practices lag human IAM, it is unsurprising that backup resilience often inherits the same control blind spots. The practical signal is simple: if privileged recovery access is not reviewed, the organisation does not yet have a complete resilience posture.

For practitioners

• Validate immutability at the storage layer Test whether protected backup objects remain unchangeable across the exact storage targets you use, including cloud object storage and any on-premises repositories. Confirm that administrative roles cannot silently bypass retention controls.
• Model full backup total cost of ownership Include compute, infrastructure, operational overhead, and restore validation effort when comparing immutable backup designs. Storage price alone will not show the cost of maintaining durable recovery state.
• Exercise recovery under attack conditions Run restore simulations against production-like data and measure whether backups survive malicious deletion, credential compromise, and constrained recovery windows. Treat successful restore as the control outcome, not backup creation.
• Review privileged backup access paths Map who can change retention settings, modify object-lock policy, and execute restores. Those are privileged pathways and should be included in access reviews, separation-of-duties checks, and break-glass governance.

Key takeaways

• Immutable backup features are only meaningful when the restore path, retention policy, and privileged access model are controlled together.
• WORM lock introduces real overhead, so backup decisions should be judged on full operational cost and recoverability rather than storage price alone.
• The strongest proof of resilience is a successful recovery exercise against production-like conditions, not a vendor claim about immutability.

Key terms

• Immutable Backup: A backup copy that cannot be changed or deleted after it is written for a defined retention period. In practice, immutability depends on where the retention enforcement lives, who can administer it, and whether restore workflows preserve that protection end to end.
• WORM Lock: Write-once, read-many protection that prevents stored data from being overwritten during the retention window. For backup programmes, it is a storage-layer control that strengthens resilience, but it also changes cost, administration, and recovery design assumptions.
• Backup Resilience: The ability of a backup programme to preserve and restore data under failure, ransomware, or operator error. It is measured by successful recovery under realistic conditions, not by the existence of a backup feature or a retention policy on paper.
• Recovery Privilege: The authority to change retention settings, manage object-lock policy, or initiate restores. This is privileged access because it can determine whether protected data remains recoverable, so it should be governed like any other high-impact identity path.

What's in the full article

Commvault's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific claims about AirGap immutability and how the platform describes its WORM lock behaviour across supported storage targets.
• The vendor's own discussion of storage overhead, compute costs, and why it argues total cost of ownership is broader than capacity alone.
• Details of the Get Real Challenge and how the vendor frames real-world validation of backup and recovery performance.
• The article's FAQ section, which answers implementation questions about immutability, cloud targets, and resilience testing.

👉 Commvault's full post includes the WORM lock discussion, TCO framing, and resilience testing approach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.