Multi-cloud recovery gaps expose weak application-level resilience

At a glance

What this is: This episode argues that multi-cloud recovery breaks when organisations confuse service-level backup with application-level restoration and when orchestration, dependency mapping, and governance are fragmented.

Why it matters: It matters because IAM, PAM, NHI, and resilience teams must control the identities, permissions, and automation that recovery workflows use across clouds, not just the backup data itself.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Commvault's discussion on multi-cloud recovery and application-level resilience

Context

Multi-cloud recovery sounds simple until an incident forces teams to restore data, services, and dependencies across several providers at once. In practice, the hard part is not copying bytes back into place. It is coordinating identities, permissions, recovery order, and application state across clouds, accounts, and teams while systems are under stress.

This is where the identity angle becomes material. Recovery workflows increasingly depend on service accounts, automation tokens, and agentic workflows that can trigger backup, orchestration, and failover actions. If those non-human identities are over-privileged, poorly governed, or inconsistently managed across environments, resilience becomes a privilege problem as much as a storage problem.

The article reflects a common starting position: organisations often assume their cloud-native tools and backup coverage translate into recoverability, but that assumption is typically too optimistic.

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 multi-cloud environments make recovery harder for IAM and PAM teams?

A: Because recovery depends on the permissions of service accounts, automation tokens, and privileged workflows that span multiple providers and admin domains. If those identities are broad, shared, or undocumented, teams cannot contain restoration actions cleanly. IAM and PAM must govern recovery access as carefully as production access.

Q: How do you know if multi-cloud recovery is actually working?

A: A recovery programme is working only if it can restore a real application, with its dependencies and identity bindings intact, within its target recovery time. Evidence comes from repeated cross-cloud tests, not from backup coverage alone. If restoration needs manual improvisation, the programme is not yet reliable.

Q: Who should own permissions for recovery automation and agentic workflows?

A: Ownership should sit jointly with resilience, IAM, and PAM, because recovery automation is privileged identity infrastructure. The owner must define scope, approval boundaries, logging, and offboarding for every service account or agent that can trigger recovery actions. That prevents a recovery tool from becoming a hidden admin plane.

Technical breakdown

Service-level backup vs application-level recovery

Backing up a database, object store, or workload snapshot protects a component, not the business service that depends on it. Application-level recovery requires consistent state across dependencies, configuration, identity bindings, queues, and inter-service trust. In multi-cloud environments, different providers, regions, and accounts can each restore on different timelines, which makes coordination the real technical problem. When recovery sequencing is wrong, a technically successful restore can still leave the application unusable or inconsistent.

Practical implication: Map recovery at the application layer, not just the storage layer, and test whether service dependencies can be restored in the right order.

Dependency mapping and recovery orchestration across clouds

Dependency mapping is the discipline of identifying which services, identities, and data paths must come back together for the application to function. In multi-cloud estates, that includes cross-account roles, API dependencies, DNS, secrets, and control-plane permissions. Orchestration then turns that map into a repeatable recovery sequence. Without both, teams default to manual decision-making during an outage, which is exactly when complexity and time pressure are highest.

Practical implication: Maintain a dependency graph that includes non-human identities and automate the restoration sequence against it.

Agentic workflows in resilience operations

AI-enabled automation can improve recovery speed, but only if its permissions are tightly scoped and observable. Agentic workflows are not just scripts because they can decide when to act, which tools to call, and how far to continue. That makes them non-human identities in practice and sometimes privileged ones. If those identities can trigger backups, change recovery settings, or escalate remediation without clear guardrails, automation becomes a risk amplifier instead of a resilience control.

Practical implication: Treat recovery automation as privileged identity infrastructure and apply least privilege, approval boundaries, and logging to every agentic workflow.

Threat narrative

Attacker objective: The objective is to turn a recoverable disruption into a prolonged operational outage by exploiting fragmentation, privilege gaps, and weak orchestration.

1. Entry occurs when a cyber incident disrupts one cloud or workload and forces the organisation into recovery mode before teams have verified dependency state across the environment.
2. Escalation happens when fragmented tools, cross-account permissions, and mis-scoped automation identities make restoration inconsistent across clouds and services.
3. Impact follows when the business cannot restore a synchronised application state fast enough, extending outage duration and undermining containment, trust, and revenue.

NHI Mgmt Group analysis

Application recoverability is now an identity governance problem as much as an infrastructure problem. Multi-cloud recovery depends on service accounts, automation tokens, and cross-cloud permissions that decide what can be restored and in what order. If those identities are inconsistent across providers, the recovery plan is already brittle. Practitioners should treat recovery access as governed identity, not as an afterthought to backup design.

Dependency mapping is the named control gap this discussion exposes: recovery fails when organisations cannot prove which systems, identities, and services must return together. The article correctly shows that service-level protection does not equal business-service restoration. That gap widens when teams operate across separate admin domains and backup tools. Practitioners should align resilience planning to application dependencies, not to storage boundaries.

Controlled delegation is becoming a resilience requirement for agentic automation. The article’s AI section points to a broader shift: recovery operations increasingly rely on software entities that behave like privileged identities. That means permission scope, trigger conditions, and logging must be designed before an incident, not during one. Practitioners should govern recovery automation with the same discipline they apply to other high-risk privileged identities.

Multi-cloud resilience validates zero standing privilege thinking for recovery operations. Permanent broad access makes failover, orchestration, and incident response harder to contain because every script and every agent inherits more power than it needs. The practical answer is not to eliminate automation, but to constrain it tightly enough that one recovery pathway cannot become a systemic control failure. Practitioners should scope recovery access to task, time, and environment.

What this signals

Multi-cloud resilience programmes now need the same identity discipline that IAM teams apply to production access. If recovery workflows still rely on broad shared credentials or unclearly owned service accounts, the first incident will expose that control debt rather than the backup platform. The practical signal is to bring NHI Lifecycle Management Guide thinking into recovery design before the next failover test.

Recovery orchestration debt: the gap between having backups and being able to reassemble a working service across clouds is widening. That gap is usually hidden until a real outage forces teams to coordinate identities, permissions, and dependencies under pressure. A good benchmark for maturity is whether every recovery automation path is mapped to a named owner and a least-privilege role.

If agentic workflows are part of backup or failover, teams should assume they are managing privileged non-human identities. That means aligning the programme with The 52 NHI breaches Report patterns on standing access, then validating that automation can be disabled, scoped, and audited without breaking recovery.

For practitioners

• Map recovery at the application layer Document the service dependencies, identity bindings, and cross-cloud control paths required to restore each critical application in a usable state. Test whether those dependencies come back in the correct order before a real incident does.
• Inventory recovery automation identities List every service account, token, and agent that can trigger backup, failover, or orchestration actions. Confirm which identities are privileged, which are shared, and which can act across multiple cloud accounts.
• Scope restoration permissions to task and environment Remove broad standing access from backup and recovery workflows, and separate read, restore, and orchestration permissions by environment. Recovery tooling should only reach the accounts and services needed for the current scenario.
• Run cross-cloud recovery tests under incident conditions Exercise failure scenarios that force coordinated restoration across providers, regions, and teams. Measure whether the runbook still works when one cloud is degraded, one admin team is unavailable, or one dependency is missing.
• Align resilience owners with IAM and PAM teams Put identity governance into the recovery design review so that access reviews, privileged workflow controls, and offboarding of stale automation identities are part of resilience planning.

Key takeaways

• Multi-cloud recovery fails when organisations protect data sources but cannot restore the application as a coordinated system.
• The main control gap is orchestration, especially where service accounts and agentic workflows carry privileged recovery permissions across clouds.
• Resilience teams should design and test recovery access as governed identity infrastructure, not as an informal backup exception.

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 Orchestration: Recovery orchestration is the sequencing and coordination of tasks needed to bring systems back online in the correct order. In multi-cloud environments, it spans accounts, clouds, permissions, and dependencies, so orchestration failures often matter more than backup failures.
• Agentic Workflow: An agentic workflow is a software-driven process that can choose actions, tools, and timing during execution. In resilience operations, that makes the workflow behave like a non-human identity and therefore a governed access subject, not just a convenience script.
• Dependency Mapping: Dependency mapping identifies which services, identities, data paths, and control-plane connections must be available for an application to operate. It is a prerequisite for reliable recovery because it tells teams what must come back together, and in what order, after an incident.

What's in the full article

Commvault's full episode covers the operational detail this post intentionally leaves for the source:

• Step-by-step discussion of why service-level backup does not guarantee application-level recovery across AWS, Azure, and Google Cloud.
• Specific examples of how dependency mapping changes recovery sequencing when multiple admin teams and vendor tools are involved.
• The practical impact of AI-enabled automation on backup triggers, permission scope, and recovery governance.
• The source conversation's own framing of what CISOs and DevOps leaders need to align on before the next incident.

👉 The full Commvault episode covers dependency mapping, orchestration gaps, and AI-related recovery controls in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to control privileged automation and identity risk across modern environments.