What do security teams often get wrong about immutable backups?

Why This Matters for Security Teams

Immutable backups are valuable, but they are not a complete resilience strategy. Security teams often assume that once backup data cannot be altered, recovery is effectively guaranteed. That is the wrong model. The real risk sits in the surrounding control plane: who can access backup systems, who can initiate restores, whether privileged accounts are protected, and whether restore workflows actually work under stress. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that protection and recovery are separate control concerns, not interchangeable ones.

NHI Management Group’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, which means backup platforms often inherit the same overreach that undermines production systems. Immutability does not reduce that exposure. It simply preserves whatever was stored, including bad policy, stale secrets, and operational mistakes.

In practice, many security teams discover backup weakness only after a restore fails during an incident, rather than through intentional recovery testing.

How It Works in Practice

Immutable backups protect backup objects from deletion or modification for a defined retention period. That helps against ransomware and destructive admin actions, but only at the storage layer. Recovery still depends on the identities, policies, and procedures that surround the vault. If an attacker compromises backup administrators, a cloud control plane, or the automation that triggers restores, immutability may remain intact while recovery is still blocked.

Operationally, teams should treat backup resilience as a chain of controls:

• Restrict who can change retention policies or vault configuration.
• Separate backup administration from production administration using strong RBAC and privileged access management.
• Use short-lived access for restore operations where possible, especially for emergency break-glass paths.
• Test point-in-time restore, cross-account recovery, and full environment rebuilds, not just backup creation.
• Validate that backup encryption keys, service accounts, and API tokens are governed as NHIs, not left as long-lived standing access.

The Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is exactly the kind of weakness that can turn a protected backup store into an inaccessible one. NIST guidance on access control and recovery planning in NIST SP 800-53 Rev 5 Security and Privacy Controls supports the same operational conclusion: a backup is only useful if the organisation can reliably reach and restore it when needed.

These controls tend to break down when backup platforms share identities, consoles, or keys with production systems because one compromise can interrupt both retention and restoration.

Common Variations and Edge Cases

Tighter backup governance often increases operational overhead, so organisations have to balance resilience against restore speed and administrative friction. That tradeoff is especially visible in air-gapped, cross-region, and regulated environments where every restore may require multiple approvals or manual key handling. Current guidance suggests that this extra friction is acceptable only if recovery objectives are still achievable.

One common edge case is the “immutable but unusable” backup. The data exists, yet the organisation cannot restore it because the KMS key is lost, the restore role was never tested, or the credentials needed for rebuild were revoked too aggressively. Another is partial immutability, where only the storage layer is protected while catalog metadata, orchestration jobs, or identity providers remain writable. In that scenario, an attacker may not delete backups, but can still disrupt the restore path.

There is no universal standard for this yet, but best practice is evolving toward treating backup identities as first-class NHIs. That means inventorying service accounts, rotating secrets, and validating emergency access just as rigorously as production access. The Ultimate Guide to NHIs is explicit that visibility gaps are common, and those gaps become most painful during recovery events, not during steady-state operations.

Related resources from NHI Mgmt Group

• What do security teams get wrong about posture reports that list hundreds of findings?
• What do security teams get wrong about conditional access exclusions?
• What do security teams get wrong about Active Directory change confirmation?
• What do security teams get wrong about custom user management UIs?