TL;DR: Multi-cloud backup often protects data service by service, but recovery still fails when teams must restore synchronised applications across clouds, accounts, and admin domains, according to Commvault. The real control gap is not storage durability but orchestration, dependency mapping, and governed automation across the full recovery path.
At a glance
What this is: This is an analysis of why multi-cloud backup often fails to translate into usable recovery, with the key finding that application-level restoration is harder than protecting individual services.
Why it matters: It matters because IAM, cloud security, and resilience teams must account for cross-cloud accounts, permissions, and admin boundaries before a cyber event exposes the gap between backup and recoverability.
Context
Multi-cloud resilience is not the same as multi-cloud backup. A team can protect data in separate clouds and still fail to restore the application as a coherent service because recovery depends on dependency order, shared identities, and coordinated admin control across environments.
The identity angle is real here even though the topic is broader than IAM. Recovery workflows increasingly span service accounts, automation identities, and agent-driven orchestration, so access scope and delegated permissions become part of the recovery design rather than an afterthought.
Key questions
Q: What breaks when multi-cloud backup is treated as the same thing as recovery?
A: Service-level backup protects data, but recovery fails when teams cannot restore the full application state in the right sequence across clouds, accounts, and identities. The usual failure is fragmented orchestration, missing dependencies, and inconsistent permissions. The fix is application-level recovery design, tested end to end before an incident.
Q: Why do cross-cloud dependencies make recovery slower in practice?
A: Cross-cloud recovery slows down because each cloud, account, and admin domain can impose a different recovery point, approval path, or restore sequence. That creates a coordination burden exactly when teams need speed. When dependencies are not mapped in advance, the team spends time discovering what must be restored together instead of executing a rehearsed plan.
Q: What are the signs that application recovery is not actually ready?
A: The clearest signs are siloed backup ownership, different teams controlling related services, and no tested sequence for restoring the application as a whole. If recovery documentation only covers individual systems, or if restore testing stays inside one cloud, readiness is probably overstated. A true readiness signal is a successful end-to-end restore across the actual dependency chain.
Q: How should organisations govern automation identities in recovery workflows?
A: Organisations should treat recovery automation as privileged access, not background tooling. That means bounding what backup jobs, orchestration agents, and scripts can change, then reviewing those permissions alongside the recovery design. If automation can trigger restores or alter operational settings, it needs explicit ownership, scoped permissions, and monitoring like any other high-value identity.
Technical breakdown
Why service-level backup does not deliver application-level recovery
Service-level backup protects individual datasets or resources, but application recovery depends on the relationships between those resources. In multi-cloud environments, data stores, microservices, secrets, and control planes often live under different recovery points and different administrative boundaries. If those components are restored out of sequence, the application may come back in an inconsistent state even though every backup succeeded. The technical problem is not just data durability, but orchestration across interdependent systems. Practical implication: treat the application graph as the recovery unit, not the individual cloud service.
Practical implication: model recovery around application dependencies, not isolated backups.
Why cross-cloud orchestration becomes the hidden failure point
Native hyperscaler tools are built to operate within one provider’s boundary. That makes them useful for local recovery, but not enough for coordinated restoration across AWS, Azure, Google Cloud, or mixed account structures. The failure point appears when one service restores cleanly while another needs a different recovery point, a different region, or a different account-level control path. At that stage, orchestration determines whether recovery is measured in hours or days. Practical implication: build recovery control planes that can sequence cross-cloud actions without manual stitching during an incident.
Practical implication: design orchestration that spans clouds, accounts, and regions before an incident occurs.
How agentic automation changes recovery governance
Automation can speed backup and restore workflows, but agentic workflows also introduce delegated decision-making into resilience operations. That means the automation identity itself becomes part of the trust boundary. If agents can trigger backups, change recovery sequencing, or modify cost- or access-related settings, they need tightly bounded permissions and clear oversight. The recovery challenge is therefore partly an NHI governance problem: the systems doing the work must be governed like identities, not treated as invisible tooling. Practical implication: govern automation identities with the same rigor as privileged operational accounts.
Practical implication: apply privileged-access controls to recovery automation and agent identities.
Threat narrative
Attacker objective: The objective is to turn complexity into outage by making recovery slow, inconsistent, or incomplete enough to disrupt operations and recovery confidence.
- Entry occurs when a cyber incident forces the organisation to invoke recovery across multiple clouds and account boundaries under time pressure.
- Escalation happens as service-by-service protection collides with incompatible recovery points, fragmented ownership, and manual orchestration gaps.
- Impact is delayed or failed restoration of a synchronized application, which extends downtime and weakens business continuity.
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.
- 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
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
Application-level resilience is now a governance problem, not a storage problem. Multi-cloud environments expose a basic control mismatch: backup is usually organised by service, while recovery must happen at the application layer. That gap is amplified by separate clouds, separate admin domains, and separate ownership models. Practitioner conclusion: resilience programmes need application dependency governance, not just backup coverage.
Recovery aperture is the real risk variable in multi-cloud design. As clouds, accounts, and admin teams multiply, the number of coordination points rises faster than most recovery plans account for. This is where multi-cloud complexity becomes operational fragility. Practitioner conclusion: reduce fragmentation where possible and test the full recovery chain, not just individual restore jobs.
Controlled delegation is now part of disaster recovery architecture. The more recovery depends on automation and agent-driven workflows, the more recovery becomes an identity governance issue. Agent permissions, task scope, and approval boundaries matter because automated recovery actions can create their own failure modes if they are over-broad. Practitioner conclusion: govern recovery automation as privileged identity.
Native cloud tools validate local protection, but they do not prove cross-cloud recoverability. Teams often confuse provider-specific backup success with end-to-end resilience. That assumption breaks when restoring synchronized services across clouds, regions, and admin domains. Practitioner conclusion: use multi-cloud recovery testing to validate orchestration, not just data availability.
Resilience must be designed into application architecture early. The article's central lesson is that recovery planning cannot be postponed until after deployment or incident response design. Dependency mapping, recovery sequencing, and cross-cloud coordination need to sit alongside application design decisions. Practitioner conclusion: treat recoverability as an architectural requirement from day one.
What this signals
Recovery aperture is the practical way to think about multi-cloud resilience. As the number of clouds, accounts, and admin domains grows, the number of failure points in a restore path grows with it. Teams should assume that cross-cloud recovery will fail first at coordination, not at storage.
Recovery testing has to move beyond single-cloud restore validation. If an application spans multiple hyperscalers, the question is whether the full dependency chain can be rebuilt in the right order, under the right permissions, before the incident window closes.
For practitioners
- Map application recovery dependencies Identify which services, data stores, secrets, and control-plane dependencies must come back together for each critical application to function.
- Test cross-cloud restore sequences Run recovery tests that span clouds, accounts, and regions so sequencing failures appear before a real incident does.
- Govern recovery automation identities Review the permissions granted to backup jobs, orchestration agents, and recovery scripts so they can do only the tasks required.
- Reduce vendor and admin fragmentation Consolidate recovery ownership where possible so too many tools, teams, and account boundaries do not slow a restoration window.
Key takeaways
- Multi-cloud backup can give a false sense of resilience when application dependencies span multiple clouds and admin domains.
- The main failure mode is not data loss alone, but the inability to restore a synchronized application across fragmented control planes.
- Practitioners should design recovery around dependency mapping, orchestration, and governed automation identities rather than isolated backup tools.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IR-05 — Recovery Planning | The article is about restoring critical services across clouds after disruption. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Recovery automation and admin boundaries depend on governed permissions. | |
| Recommendation — Align multi-cloud recovery design to PR.IR-05 and validate restore sequencing across environments. Use PR.AA-05 to scope recovery access for backup jobs, scripts, and orchestration agents. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | CIS Data Recovery directly matches the article's focus on restoring systems and data. |
| Recommendation — Apply CIS-11 to test recovery of applications, not just individual datasets. | ||
| MITRE ATT&CK | TA0040 — Impact | The article describes how recovery failure amplifies business impact after an incident. |
| Recommendation — Map restore-gap scenarios to TA0040 and prioritise controls that limit outage duration. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Recovery automation agents and scripts can become overprivileged non-human identities. |
| Recommendation — Review recovery automation accounts for NHI-05 and reduce permissions to the minimum restore scope. | ||
Key terms
- Application-Level Recovery: Application-level recovery is the process of restoring a business service so that its data, dependencies, and identity relationships work together again. It is stronger than restoring individual backups because it measures whether the service actually functions after recovery, not just whether files are available.
- Recovery aperture: Recovery aperture describes the breadth of clouds, accounts, identities, and admin domains that must cooperate for restoration. As the aperture widens, orchestration becomes harder and the chance of restore failure increases because more moving parts must align at the same time.
- Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
- Controlled delegation: Controlled delegation is the practice of giving automation or agentic workflows only the permissions needed to perform a defined task. It is essential when recovery is partially automated, because the identity that executes the workflow can also create privilege and change-management risk.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps practitioners connect privilege, lifecycle, and governance controls to real operational risk.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org