Almost every backup storage proposal now carries the word immutable on the first page. Behind that word is usually a specific mechanism, S3 object lock, and behind that mechanism is a set of guarantees narrower and more precise than the shorthand suggests. Teams that know exactly what is locked, by whom and for how long tend to recover from ransomware; teams that assume “immutable” means “safe” sometimes discover the difference during an incident.
This matters because attackers have adapted. Encrypting production data is half of a modern ransomware operation; the other half is destroying backups first so the victim has no alternative to paying. Object lock exists to make that second step fail. It does so reliably when configured correctly and does nothing at all when it is not. This article defines object lock precisely, covers the three modes, explains why retention windows are the most common weak point, describes how backup applications use it, and ends with a checklist.
S3 object lock is a write-once-read-many (WORM) control applied by the storage system to individual object versions. When a version is locked, no API call can delete or overwrite it until its retention period expires. That sentence contains four qualifiers, and each matters.
Object lock is enabled at the bucket level, but the lock itself is a property of each object version. A bucket with object lock enabled can still contain unlocked versions if the writer requested no retention and the bucket has no default. Enabling the feature is a prerequisite, not the protection.
A locked version can be read as often as needed and copied or replicated elsewhere. A PUT to the same key creates a new version rather than modifying the old one. What object lock prevents is removal or replacement of the existing version; the old data stays readable regardless of what is written afterwards.
Every lock has a “retain until” timestamp. Before that date, deletion is refused. After it, the version becomes an ordinary object that lifecycle rules or the backup application can clean up. Retention can be extended on an existing version but, in compliance mode, never shortened.
This qualifier gives object lock its value. The backup server, its database, its service account and every administrator who can log in to it are outside the enforcement boundary. If all of them are compromised, the storage layer still refuses the delete because the decision is made against the object’s own metadata. A protection enforced by the application the attacker has already taken over is not a protection.
The list of things object lock does not do is longer than the list of things it does. None of the following are flaws in the feature; they are boundaries, and most real-world failures fall into one of them.
S3 defines two retention modes and one independent flag. They behave differently under attack, so the choice deserves more thought than accepting a default.
| Control | Who can remove or shorten it | How it expires | Typical use |
|---|---|---|---|
| Compliance mode | No identity, including the account owner. | Only at the retain-until date. Retention can be extended, never reduced. | Ransomware recovery copies, regulated retention, any copy that must survive a compromised administrator. |
| Governance mode | Any identity granted the bypass permission. | At the retain-until date, or earlier via bypass. | Protection against accidents and ordinary misuse where a controlled escape hatch is acceptable. |
| Legal hold | Any identity with the legal hold permission. | Never on its own; remains until explicitly cleared. | Litigation or investigation holds layered on either mode; not a ransomware control by itself. |
For backup repositories whose purpose is to survive a breach, compliance mode is the appropriate default. Governance mode is often chosen because keeping a way out feels safer, but the way out is exactly what an attacker with stolen credentials will use. If a governance escape hatch is genuinely needed, the bypass permission should belong to an identity never used for routine work and protected by strong multi-factor authentication.
A lock that expires before anyone notices the breach protects nothing. Retention length is a security decision, not a capacity decision, and should be set against the expected time between initial compromise and detection, often called dwell time.
Suppose an organization sets a seven-day immutability period because that matches its backup cycle and keeps capacity predictable. Suppose an attacker gains a foothold on day one, spends three weeks harvesting credentials and triggers encryption on day twenty-two. Every backup written before day fifteen has already left its retention window and can be deleted by anyone holding the backup service credentials. The only immutable restore points are the most recent seven, which may already contain staged or encrypted data. The lock worked exactly as configured; the configuration did not match the threat. Three consequences follow.
Published dwell-time estimates vary and change year to year, so this article will not quote one. The principle is stable: if the organization cannot confidently detect an intruder within a given number of days, the immutable window must be longer than that number. Thirty days is a common starting point; regulated or high-value environments often go further.
Backup applications distinguish between how long a restore point is kept (retention policy) and how long the storage refuses to delete it (immutability period). The two may be aligned or the immutability period may be shorter. What must not happen is an immutability period so short that the application’s own cleanup, or a compromised copy of it, can remove restore points the organization still needs.
Data that cannot be deleted cannot be reclaimed. Extending the lock from seven to thirty days increases the retained footprint, and the increase must be planned rather than discovered; the post on backup repository sizing covers how to model it.
Backup software rarely exposes raw S3 retention settings. Instead the repository or job carries an immutability setting that the application translates into per-object retention as it writes. Typically the administrator points a repository at an object-lock-enabled bucket and specifies an immutability period in days. Each object the job creates receives a retain-until date calculated from that period and, in many products, extended so the whole chain a restore point depends on stays locked as long as the restore point itself.
Two details deserve verification. First, confirm which mode the application requests; most vendors that support object lock write in compliance mode, but the operator should check rather than assume. Second, confirm how the application interacts with the bucket’s default retention. Where both exist the longer generally wins, but mismatches between the two are a frequent source of confusion during audits.
The validated backup applications page lists the platforms tested against ARTESCA, which removes some of this guesswork.
These checks take an afternoon and would have prevented most of the failures above.
Object lock is dependable precisely because its guarantees are narrow and mechanical. Knowing where they stop turns it from a checkbox into a recovery plan. Further architectural background is available at immutable backup.
Scality ARTESCA is S3 object storage designed as a backup target, and object lock is enforced in its data path rather than layered on as a gateway over a separately writable file system. A locked version is refused for deletion by the storage system itself, whichever credentials or console issued the request.
ARTESCA supports compliance mode, so a retention period once set cannot be shortened or removed by any account, including the storage administrator. It is validated with the major backup applications, including Veeam, Commvault, Cohesity and Rubrik, so the mapping between a job’s immutability setting and the retention written to each object is tested rather than assumed. The security model is described on the security and cyber resilience page.
Whatever platform holds the backups, the practical step is the same: read the retention metadata on a real object, try to delete it with the credentials an attacker would steal, and set the window longer than the time it would take to notice them.