TL;DR: S3, Azure Blob and Google Cloud Storage durability features reduce outage risk but do not provide point-in-time recovery, immutability or independent governance, according to HYCU, leaving teams exposed when misconfigurations, deletions or compromise hit primary storage. The real control gap is treating replication as backup instead of maintaining separately governed, recoverable copies.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on HYCU's blog post: Object storage durability and replication are not substitutes for independently governed, point-in-time backups.
Why it matters: It matters because IAM, cloud security and recovery teams need backup controls that survive compromised credentials, bad policies and accidental deletion across primary storage accounts.
Context
Object storage now carries production workloads, analytics data, ETL outputs and AI training sets, so backup design has to assume business-critical recovery requirements rather than simple availability needs.
Replication and erasure coding improve durability, but they still mirror bad policy changes and do not create an independently governed recovery point. That distinction matters wherever cloud storage is tied to privileged access, lifecycle policy control or delegated administration.
Key questions
Q: What breaks when cloud replication is treated as backup?
A: Replication preserves the same mistakes that affect production, including bad lifecycle policies, deletions and compromised writes. If the recovery copy shares the same control plane, you may have durability but no clean rollback point. Independent backups need separate governance, point-in-time recovery and retention that production administrators cannot silently overwrite.
Q: Why do immutable backup copies matter for cloud object storage?
A: Immutable copies stop backup data from being altered or deleted during the retention period, which matters when the primary environment is compromised or misconfigured. They reduce the chance that one privileged action can destroy both production data and recovery data. In practice, immutability turns backup from a copy problem into a trust problem with clearer boundaries.
Q: What are the biggest cost drivers in cloud object storage backup?
A: Three costs usually dominate: moving large data volumes, storing repeated full copies, and restoring more data than the incident requires. When a programme can deduplicate early, store only unique segments and restore at object or bucket scope, it lowers egress, storage and operational disruption at the same time.
Q: How should teams recover after ransomware hits object storage?
A: Start from a pre-incident recovery point that was protected with immutable retention, then restore the smallest viable scope and validate integrity before expanding. The key is not just getting data back, but proving the recovery copy was isolated from the same administrative path that was abused during the attack.
Technical breakdown
Why replication does not equal backup
Replication copies the same object state to another location, which means it faithfully preserves bad deletions, misapplied lifecycle rules and compromised writes. Backup needs an independent control plane, point-in-time versioning and retention separate from production authority. In object storage environments, durability features are designed to keep data available, not to provide a clean rollback point after human error or malicious activity. When the production policy engine is the source of truth, the blast radius expands across every replica. See the Cloud Security Guide. See the Cloud Security Guide.
Practical implication: treat replication as resilience, not recovery, and separate backup authority from production storage administration.
How immutability and deduplication change recovery economics
Immutable storage prevents alteration or deletion during the retention window, which is essential when recovery must survive ransomware, insider deletion or compromised credentials. Deduplication changes the cost profile by storing only unique segments, reducing both storage footprint and the amount of data moved during backup and restore. For object storage at petabyte scale, the control challenge is not just keeping copies, but keeping governed copies economically enough to make recovery sustainable. That is why catalogued, granular restores matter as much as retention policies. See the Backup Security and Immutable Backup Guide. See the Backup Security and Immutable Backup Guide.
Practical implication: pair immutable retention with deduplicated storage and granular restore paths so recovery remains affordable at scale.
Why granular restore scope matters in cloud recovery
A recovery design that forces full-account restores to retrieve a few objects creates unnecessary data transfer, longer outage windows and operational drag. Granular restore, at object, bucket or account scope, reduces the amount of data that must move and shortens the time to resume service. For cloud teams, restore scope is a governance decision as much as a technical one because it determines whether recovery can be executed surgically or only through disruptive rebuilds. In cloud backup programmes, restoration precision is part of resilience engineering. See the Cloud Security Guide.
Practical implication: validate that recovery tooling can restore the smallest useful scope without requiring a full environment rebuild.
Threat narrative
Attacker objective: The objective is to destroy or corrupt the only viable recovery path so the organisation cannot restore object data cleanly after the incident.
- Entry occurs through a bad lifecycle policy, deleted objects or other primary storage change that is then replicated across the environment.
- Escalation happens when the same policy error, compromised credential or malicious action propagates to the copies that were assumed to be recovery points.
- Impact follows when teams discover that replicated data is not a clean backup and cannot be used to roll back to a pre-incident state.
Breaches seen in the wild
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Durability controls are being confused with recovery controls. Cloud storage platforms are excellent at preserving availability, but availability is not the same as an independently governed restore point. When teams rely on replication, they inherit production mistakes into every copy and lose the control separation that backup depends on. The governance gap is not storage capacity, it is backup independence.
Object storage backup is now an identity and governance problem as much as a storage problem. The article’s core risk appears when lifecycle rules, deletion rights or cross-account access are too broad for the recovery model. Privileged access rights to storage are therefore part of backup resilience, because the same credentials that manage data can also erase recovery options. Practitioners should treat backup control planes as privileged systems, not passive repositories.
Cost pressure is the hidden failure mode that weakens resilience. When backup spending rises with every full copy, organisations delay protection, reduce scope or accept brittle restore paths. That creates a false economy: the apparent savings of relying on native replication are overwhelmed by the operational cost of failed recovery. Economic sustainability is now a backup control: if recovery is too expensive to run, it is not a dependable control at all. Practitioners should design for deduplication, granularity and immutability together.
Searchable, immutable recovery is becoming the baseline expectation for cloud object stores. The article points to a model where catalogued restores, retention controls and audit evidence are tied together. That is the right direction for programmes that must recover not just data, but evidence that recovery is possible and governed. Teams should regard searchable recovery metadata as part of the control, not an optional convenience.
Read next: Backup Security and Immutable Backup Guide
What this signals
Recovery independence is the control that separates resilience from convenience. As cloud object stores take on more production data, organisations need a backup architecture that can survive the same misconfigurations and credentials that affect primary storage. If the recovery path cannot outlive the production path, it is only a mirror, not a control.
Economic sustainability will decide whether backup policies are actually enforced. In petabyte-scale environments, protection that is technically sound but financially brittle tends to get deferred. The programme signal here is clear: deduplication, immutability and scoped restore must be designed together, or recovery becomes too expensive to trust.
For practitioners
- Separate backup authority from production storage control Ensure the people and roles that manage lifecycle rules, deletion and replication cannot unilaterally destroy backup copies or retention settings.
- Require immutable retention on backup copies Use write-once or locked retention for object backups so recovery points survive accidental deletion, ransomware and policy mistakes. See the Backup Security and Immutable Backup Guide.
- Test object, bucket and account restores Prove that teams can restore the smallest needed scope without rebuilding the full environment or paying unnecessary transfer overhead.
- Reduce data movement before backup lands Apply source-side reduction and deduplication so only unique segments move, lowering egress cost and making large-scale protection sustainable.
Key takeaways
- Object storage resilience features help with availability, but they do not by themselves create an independent recovery path.
- When backup copies share production governance, bad policies and compromised access can destroy the restore point as well as the source data.
- The strongest response is a separately governed, immutable and deduplicated backup design with granular restore scope.
Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Cloud Security Guide · Active Directory and Entra ID Hardening Guide · Codefinger S3 ransomware 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Backup administration and storage control are vulnerable when access is broader than recovery needs. |
| NHI-07 — Long-Lived Secrets | Cloud backup workflows depend on credentials that should not remain valid indefinitely. | |
| Recommendation — Restrict backup and storage administration to the minimum roles needed to protect recovery points. Rotate and shorten the lifetime of backup credentials so they cannot be reused after exposure. | ||
| NIST SP 800-53 Rev 5 | CP-9 — System Backup | Cloud object backup and restore are directly governed by backup and recovery controls. |
| Recommendation — Apply CP-9 to ensure backup copies are independent, restorable and protected from production changes. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | The article is fundamentally about recoverability, restore scope and retention economics. |
| Recommendation — Use CIS-11 to verify that recovery is tested, scoped and separate from primary storage operations. | ||
| MITRE ATT&CK | TA0005;TA0040 — Defense Evasion; Impact | The threat pattern involves destructive storage changes and recovery denial. |
| Recommendation — Map destructive storage activity to defense evasion and impact tactics so detection covers recovery-targeting behaviour. | ||
Key terms
- Immutable Backup: An immutable backup is a copy that cannot be altered or deleted during its retention period. It protects recovery points from ransomware and accidental deletion, but it only delivers value when the organisation can restore from it successfully during an incident.
- Point-in-Time Recovery: Point-in-time recovery restores data or assets to the exact state they had at a specific moment before deletion, corruption, or unwanted change. In SaaS analytics environments, it must preserve the object and the dependencies needed for it to function, not only a static export.
- Deduplication: Deduplication is the process of identifying repeated applicants or identities across programmes so the same person or entity is not approved multiple times without detection. It is a fraud and governance control that helps expose synthetic identity patterns, reuse, and hidden overlap across customer populations.
- Recovery Scope: The set of configuration objects, identities, and dependencies that must be restored after a cyber incident or operational failure. For observability, recovery scope should include the logic that drives detection and notification, not only the platform hosting the data.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is a practical next step for practitioners who need to connect identity controls to cloud recovery and resilience decisions.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org