A ransomware crew that has been sitting quietly on a network for three weeks doesn’t need to break your encryption to ruin your week. They just need your backup admin’s password. Once they have valid credentials, they can log into the backup console like anyone else, walk through the retention settings, and delete every recovery point they can find — often minutes before detonating the payload on production. This is now a standard part of the ransomware playbook, and it’s the reason “we have backups” stopped being a sufficient answer years ago.
Object Lock, and the broader category of write-once-read-many (WORM) storage it belongs to, closes that gap. It is the mechanism that turns an S3 immutable backup from a marketing phrase into an enforceable, API-level guarantee: once an object is locked, no identity — not the account root user, not an administrator, not even the storage provider’s own support staff — can delete or overwrite it before its retention period expires. This article explains how the mechanism actually works, where it fits in a modern data protection architecture, and where its limits are.
What Object Lock Actually Does
Object Lock is a bucket-level and object-level feature, originally introduced on Amazon S3 and now implemented as an open, widely-supported convention across many S3-compatible object storage platforms — including on-premises appliances and other public cloud object stores that expose an S3-compatible API. When Object Lock is enabled, every write to a protected object carries a retention setting that the storage layer itself enforces, independent of any application logic sitting on top of it.
Two things happen at the protocol level:
- Delete becomes a no-op. A
DELETErequest against a locked object during its retention window is rejected by the storage service, not by an application-layer permission check. There is no admin override button. - Overwrite creates a new version, it doesn’t destroy the old one. On a versioned, locked bucket, a
PUTto the same key doesn’t erase history — it adds a new version while the locked version remains intact and recoverable.
This distinction matters because it moves the guarantee out of the application and into the storage substrate. A backup product can have a bug, a misconfigured retention job, or a compromised service account, and none of it matters if the underlying object storage itself refuses the delete.
Governance Mode vs. Compliance Mode
Most S3-compatible implementations expose two retention modes, and picking the right one is the single most consequential decision in an Object Lock deployment.
Governance mode applies retention by default but allows users holding a specific elevated permission (typically something like s3:BypassGovernanceRetention) to shorten a retention period or delete an object early. It’s the flexible option — useful for internal testing, staged rollouts, or environments where a documented, audited exception process needs to exist. The catch is obvious: if an attacker compromises an identity that holds that bypass permission, governance mode’s protection evaporates.
Compliance mode removes the exception entirely. Once an object is locked under compliance mode, no identity in the account — including the root user — can delete it or shorten its retention period before expiration. Not through the console, not through the API, not through a support ticket to the storage provider. The only way data protected this way disappears on schedule is time passing.
For ransomware resilience specifically, compliance mode is the mode that matters. Governance mode is better than nothing, but any control that an attacker with sufficiently elevated stolen credentials can switch off should be treated as a convenience feature, not a security boundary.
Retention Periods vs. Legal Hold
Object Lock actually offers two independent controls, and conflating them is a common design mistake.
A retention period is a fixed clock: an object is locked until a specific date, set either as a number of days/years or an explicit “retain until” timestamp. It’s the right tool for a rolling backup policy — for example, “every nightly backup is immutable for 35 days,” matching a recovery point objective decided as part of your RPO vs RTO planning.
A legal hold has no expiration date at all. It stays in effect until someone with permission explicitly removes it, independent of any retention period math. Legal holds are the right tool for litigation, regulatory investigation, or any scenario where “keep this until further notice” is the actual requirement rather than “keep this for N days.” A backup object can carry both simultaneously — a 90-day retention period and a legal hold — and it will remain locked until both conditions clear.
Conflating the two leads to predictable failures: teams set an indefinite legal hold when they meant a long retention period, and end up with backup buckets that never shrink and cost lines that never stop growing. Decide which control you actually need before you touch the API.
Why Compromised Credentials Aren’t Enough
The specific threat model Object Lock is built for is the one that defeats almost every other backup protection: an attacker who has already obtained valid, working credentials for your environment. This describes the overwhelming majority of real ransomware incidents — the initial access is rarely a storage-layer exploit, it’s a phished password, an exposed RDP port, or a stolen session token.
Under a conventional backup architecture, valid credentials mean the attacker can do anything a legitimate backup admin can do, including deleting the backups. Object Lock in compliance mode breaks that equivalence. Even a fully privileged, fully authenticated identity cannot delete or shorten a compliance-locked object’s retention before it expires. The control isn’t “detect the bad login” or “restrict the permission” — it’s “make the destructive action structurally impossible regardless of who’s asking.”
This is also why Object Lock protects against insider threats and operational accidents in the same stroke it protects against external attackers. A disgruntled employee, a scripting error in a cleanup job, or a fat-fingered lifecycle policy all hit the same wall: the storage layer simply won’t comply. That’s a meaningfully stronger property than access control lists, which only work as well as the accounts protecting them.
It’s worth being precise about what this does not cover. Object Lock protects existing locked objects from deletion — it does nothing to stop an attacker from encrypting or corrupting new data before it’s backed up, and it doesn’t substitute for the broader hardening (endpoint detection, credential hygiene, network segmentation) that keeps attackers out in the first place. It is one control in a stack, not a replacement for the stack. For the wider set of controls this fits into, see our guide to immutable backups and ransomware recovery.
Fitting Object Lock into Cross-Region Replication
Object Lock retention settings replicate along with the objects themselves when cross-region replication (CRR) is configured between S3-compatible buckets, provided both source and destination buckets have Object Lock enabled. This is an important detail to verify before relying on a replicated copy for recovery — a destination bucket that lacks Object Lock support will accept the replicated data but silently drop the immutability guarantee, leaving you with a copy that looks the same but can be deleted on request.
The practical pattern most practitioners converge on:
- Enable Object Lock at bucket creation (it cannot be turned on retroactively on an existing bucket without recreating it in most implementations — plan for this before you provision).
- Enable versioning, which Object Lock requires as a prerequisite.
- Configure replication to a second bucket in a separate region, with Object Lock enabled on that destination bucket too, and ideally under a separate account or credential boundary.
- Set retention periods on the replica independently if your regulatory or recovery requirements differ by region.
The separate-account detail deserves emphasis: if the same compromised credential set has administrative reach into both the primary and replica accounts, geographic separation buys you very little. Isolating the replication target under distinct identity and access boundaries is what actually raises the bar for an attacker.
Where This Fits in a 3-2-1-1-0 Strategy
The classic 3-2-1 backup rule — three copies, two different media, one offsite — has been extended by practitioners into 3-2-1-1-0 in recent years to account for ransomware specifically: one copy offline or immutable, and zero errors confirmed through recovery testing.
Object Lock is the mechanism that satisfies the “one immutable” leg of that model without requiring physical media rotation. Where a traditional air-gapped tape or disconnected disk achieves immutability through physical disconnection, S3-compatible Object Lock achieves the same outcome through an API-enforced write-once guarantee that stays online and instantly retrievable. Both approaches have a place — organizations with the most stringent requirements often run both an air-gapped backup strategy and immutable cloud object storage, on the reasonable assumption that any single control can eventually be defeated or misconfigured.
The “zero” in 3-2-1-1-0 refers to zero errors on recovery verification, and it applies just as much to immutable copies as to any other. A locked object that was corrupted, incomplete, or malware-laden at the moment it was written stays exactly that way — Object Lock guarantees the bytes don’t change, not that the bytes were good to begin with. Regular restore testing remains mandatory regardless of how the backup is stored, and it pairs naturally with a documented incremental vs differential backup schedule so you know precisely which locked objects a given recovery point depends on.
Operational Considerations Before You Enable It
A few practical constraints catch teams off guard:
- Cost accumulation is real. Locked objects cannot be deleted early even to reclaim storage costs, including by lifecycle rules, until retention expires. Size retention periods to actual regulatory or business need, not “as long as possible to be safe.”
- Bucket-level enablement is often permanent. Many S3-compatible implementations do not allow Object Lock to be disabled once turned on for a bucket, and some don’t allow it to be added after the bucket already contains data. Design retention into the initial provisioning step, not as a later hardening pass.
- It’s a complement to encryption and access control, not a replacement. Object Lock stops deletion; it says nothing about who can read the data. Encryption at rest and least-privilege IAM policies remain necessary alongside it.
- Test the failure mode you’re actually defending against. Simulate a compromised-credential scenario in a non-production bucket and confirm that a delete attempt under compliance mode genuinely fails end to end, rather than assuming the configuration is correct.
For teams building or maintaining backup tooling outside the object-storage layer entirely, the same immutability thinking applies at the file-system level — see our overview of Linux backup command-line tools and our companion rsync backup script guide for how retention and read-only targets can be approximated without object storage. Immutability as a concept doesn’t require any one platform — the principle of making destructive actions structurally impossible is what matters, wherever it’s implemented.
NIST’s Special Publication 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events, documents this exact category of control — storage-enforced protection against unauthorized data modification and deletion — as part of a broader data integrity architecture. CISA’s #StopRansomware Guide likewise recommends maintaining offline, encrypted backups and regularly testing them as a core mitigation against ransomware’s destructive endgame. Both are useful reading for anyone building the policy layer around a technical control like Object Lock.
Frequently Asked Questions
What’s the difference between governance and compliance mode?
Governance mode locks objects but allows identities with a special bypass permission to delete them early — useful for controlled internal exceptions. Compliance mode removes that exception entirely: no identity, including the account root user, can delete or shorten retention before expiration. Compliance mode is the stronger guarantee against compromised credentials.
Can an admin delete an Object Lock backup early?
Under governance mode, an admin holding the specific bypass permission can. Under compliance mode, no — the storage layer rejects the delete request regardless of privilege level. This is the entire point of compliance mode: it removes the possibility of an authorized-looking delete request succeeding, whether it comes from a legitimate admin or an attacker holding stolen credentials.
Does Object Lock protect against ransomware?
It protects existing locked backup copies from deletion or encryption-in-place by ransomware operators who have gained valid credentials, which is how most real incidents unfold. It doesn’t prevent the initial infection or protect data that hasn’t been backed up yet, so it works best alongside endpoint defenses and a tested recovery process.
Does enabling Object Lock replace the need for offline or air-gapped backups?
Not necessarily. Object Lock provides API-enforced immutability while data stays online and instantly accessible, whereas air-gapped media achieves immutability through physical disconnection. Many risk-averse organizations run both, since no single immutability mechanism is invulnerable to every possible misconfiguration or platform-level compromise.
Can Object Lock retention be added to a bucket that already contains data?
In most S3-compatible implementations, no — Object Lock must be enabled when the bucket is created, and it typically requires versioning as a prerequisite. If you have an existing bucket without Object Lock, the usual path is creating a new Object Lock-enabled bucket and migrating data into it, then applying retention going forward.