An immutable backup is a copy that is unchangeable for a defined period: it can neither be overwritten nor deleted nor encrypted — not even by administrators or attackers with stolen admin rights. Technically this is usually object lock in WORM mode (write once, read many).
Immutability thus addresses the core strategy of modern ransomware: destroy the backups first, then encrypt production. An immutable copy remains as the last reliable recovery line — provided it is configured correctly.
How immutability works technically
Object storage with object lock is the most common path: on write, each object receives a retention period during which the storage API itself refuses delete and change operations. In compliance mode this applies without exception — including the root account. Alternatives are hardened Linux repositories with immutability flags, WORM tape or specialised backup appliances.
The mode is decisive: governance mode allows privileged accounts to lift retention early — that protects against operator error but not against attackers with captured admin rights. Effective ransomware resilience needs compliance mode plus separate credentials and MFA for the backup environment.
What matters in practice
- Couple retention to detection times: attacks often stay undetected for weeks.
- Compliance instead of governance mode for the last line of defence.
- Separate administration domain: never derive backup access from the production AD.
- Restore tests from the immutable copy too — immutability replaces no recovery drill.