What breaks when organisations rely on backups without immutability?

Why This Matters for Security Teams

Backups are often treated as the recovery answer, but immutability changes their role from “copy of data” to “trusted historical record.” Without it, a restore may bring systems back while also bringing back attacker tampering, altered logs, or poisoned configurations. That leaves security teams unable to prove what was genuine, what was modified, and when the compromise began.

This matters because recovery and evidence are not the same objective. Security guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls treats integrity, auditability, and contingency planning as separate control concerns. NHIMG research also shows how often identity and secret sprawl undermines trust boundaries: the Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage. In practice, many security teams discover the absence of immutable backups only after an extortion event has already destroyed their only trustworthy recovery point.

How It Works in Practice

Immutability means backup data cannot be altered, deleted, or silently rewritten for a defined retention period. That can be implemented with object lock, write-once media, air-gapped vaults, or storage controls that enforce retention at the platform level. The important point is not the brand of storage, but the guarantee that neither an administrator nor a compromised account can casually modify the backup set.

For incident response, immutable backups support three distinct needs:

• Recovery of systems to a known-good state after ransomware, sabotage, or accidental deletion.
• Forensic comparison against current systems, logs, and configs to identify when drift began.
• Evidence preservation so investigators can validate authenticity without relying on already-contaminated primary infrastructure.

That separation matters for NHI-heavy environments, where service accounts, API keys, and automation pipelines can be abused to encrypt, delete, or overwrite recovery data. NHIMG’s Ultimate Guide to NHIs highlights the scale of the problem, including the fact that 97% of NHIs carry excessive privileges. In parallel, NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to protecting backup integrity through access restrictions, media protection, and recovery testing.

Operationally, teams should protect backup administration with separate credentials, isolate backup planes from production identity providers, and test restoration from immutable copies on a schedule. These controls tend to break down when backup systems share the same admin domain as production and a privileged compromise can rewrite retention settings before responders notice.

Common Variations and Edge Cases

Tighter backup immutability often increases storage cost, retention overhead, and operational complexity, so organisations have to balance stronger evidence preservation against faster deletion and lower infrastructure spend. That tradeoff is real, especially when regulatory retention windows differ across regions or business units.

Best practice is evolving on how much immutability is enough. Some environments need immutable daily backups plus shorter-lived operational snapshots, while others require long-retention archives for legal hold or incident reconstruction. There is no universal standard for this yet, but the minimum expectation is that at least one recovery tier is resistant to privileged tampering.

Edge cases appear in cloud-native and hybrid environments where backup data is copied across accounts, tenants, or regions. If the same identity plane controls both the source and the copy, an attacker who compromises that plane can still damage the recovery path even when the data itself is protected. In those cases, teams should separate duties, harden backup access, and treat backup credentials as high-value NHIs rather than routine service accounts. For broader identity governance context, the Ultimate Guide to NHIs remains the clearest benchmark for why privileged non-human access demands stricter controls than ordinary application access.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on SAML without lifecycle automation?
• What breaks when organisations rely on IAM without identity threat detection?
• What breaks when organisations rely on provisioning without governance?
• What breaks when organisations rely on IAM automation without policy governance?