What breaks when multi-cloud backup is treated as the same thing as recovery?

Why This Matters for Security Teams

Multi-cloud backup is often measured by whether data exists in another place, but recovery is judged by whether the business can rebuild the application, dependencies, and trust chain fast enough to resume service. That gap matters because backup tooling can succeed while identity, network, and platform permissions still block restore. In practice, the failure is rarely “no backup”; it is “backup cannot become a working system.”

This is especially visible in cloud incidents that involve stolen credentials, privilege abuse, or destructive actions against storage and control planes, as seen in cases such as the Codefinger AWS S3 ransomware attack and 230M AWS environment compromise. Recovery depends on the same identities and permissions that attackers often target first. NIST frames this as a resilience and recovery problem, not just a storage problem, in the NIST Cybersecurity Framework 2.0. In practice, many security teams discover restore gaps only after an outage or ransomware event, rather than through intentional end-to-end recovery testing.

How It Works in Practice

Real recovery design starts by defining the application’s restore order, trust dependencies, and minimum viable operating state across clouds, accounts, and regions. That means mapping data stores, secrets, certificates, IAM roles, DNS, queues, and orchestration layers into a sequence that can be re-created under stress. A backup copy alone is insufficient if the restore path requires manual access approvals, expired credentials, or an intact production control plane.

Teams that treat backup and recovery as the same thing typically miss four operational steps:

• Restore identity first, including break-glass access and service roles needed for automation.
• Validate dependency order, such as database before application, secrets before services, and policy before workloads.
• Test cross-cloud permissions, since the restore target may not have the same assumptions as the source environment.
• Prove recovery under failure conditions, including compromised admin accounts and unavailable primary tooling.

This is where NHI governance becomes part of recovery engineering. The 2024 Non-Human Identity Security Report shows that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which is exactly the kind of issue that slows restoration. If a backup job is protected by one set of static secrets and the recovery workflow depends on another, the team may have data but still be unable to act on it. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for access, contingency, and recovery controls that are tested, not assumed. These controls tend to break down when organisations rely on manual runbooks in highly ephemeral cloud environments because the identities, permissions, and infrastructure state no longer match the documented restore path.

Common Variations and Edge Cases

Tighter recovery design often increases operational overhead, requiring organisations to balance faster failover against the cost of maintaining tested restore paths in every cloud. Current guidance suggests that the right balance depends on workload criticality, regulatory exposure, and how much automation the environment can safely tolerate.

Some edge cases need special handling. Immutable backup storage helps against deletion or encryption attacks, but it does not solve orchestration failure. Cross-account recovery may work in one cloud and fail in another because of differing IAM models or network dependencies. In regulated environments, recovery objectives may also need to account for auditability, data residency, and evidence preservation, not just technical uptime.

Agentic automation adds another layer of risk. If AI systems are allowed to operate recovery workflows, their access must be tightly scoped, monitored, and reversible. The same NHIMG research shows that 70% of organisations grant AI systems more access than they would give a human employee performing the same job, which is a poor fit for disaster recovery tooling. The practical lesson is simple: backup is a copy, recovery is a controlled reconstitution of service. If the target state cannot be rebuilt without the original control plane, the design is only a backup strategy, not a recovery strategy.

Related resources from NHI Mgmt Group

• What breaks when simulator access and agent access are treated as the same thing?
• What breaks when single logout is treated as the same thing as offboarding?
• What breaks when certificate trust is treated as the same thing as access control?
• What breaks when credential security is treated as the same thing as access governance?