Ransomware operators learned long ago that encryption alone is not enough leverage if the victim can simply restore from backup. So they go after the backups first. A typical intrusion today involves stealing administrator credentials, quietly disabling backup jobs, shortening retention, deleting recovery points and only then detonating the encryptor. If the backup system shares an identity plane with production, a single compromised admin account can erase the safety net.
Cloud platforms have responded with a new generation of controls: immutable vaults, logically air-gapped storage, multi-party approval for recovery and built-in malware scanning of recovery points. Used well, they make backups genuinely ransomware-resilient. Used carelessly, they create a false sense of security. This article explains the threat model, the controls that matter and a step-by-step plan to build backups that survive a determined attacker and restore cleanly.
Why Traditional Backup Strategies Fail Against Ransomware
Classic backup design assumed accidental failure: a disk dies, a region goes offline, someone deletes a table. Ransomware is different because the adversary is intelligent, patient and often already inside the environment with privileged access. Several common patterns fail under that threat model:
- Backups in the same account and identity domain. If the credentials that run production can also delete backups, an attacker who compromises them controls both.
- Mutable retention. Policies that administrators can shorten let an attacker reduce retention to a day and wait.
- Untested restores. Many organizations discover during an incident that restore times are far longer than their recovery time objective, or that key dependencies were never backed up.
- Restoring the infection. Attackers often dwell for weeks. Restoring the most recent backup may restore their persistence mechanisms too.
- Ignoring SaaS and identity. Microsoft 365, identity providers, source code repositories and infrastructure-as-code state are frequently outside the backup scope, yet recovery depends on them.
What Authorities Recommend
Government guidance has been consistent. CISA’s #StopRansomware Guide, referenced in joint FBI, CISA and MS-ISAC advisories such as the 2025 advisory on Ghost (Cring) ransomware, advises organizations to maintain offline, encrypted backups of critical data, to make them immutable where possible, and to regularly test that they can be restored within business recovery objectives. The guidance also stresses protecting cloud backups with appropriate immutability settings and avoiding reinfection of production during recovery.
Those principles map closely to the familiar “3-2-1-1-0” extension of the 3-2-1 rule: three copies of data, on two different media or services, one off-site, one immutable or air-gapped, and zero errors in verified restores. In the cloud, “media” and “off-site” translate into separate accounts, regions and storage services, and “air-gapped” increasingly means logically isolated rather than physically disconnected.
The Cloud Controls That Matter in 2026
Immutable Vaults and WORM Retention
Immutability means that once a recovery point is written, no one can delete it or shorten its retention until the retention period expires. Azure Backup implements this through vault immutability with three states, as documented in Microsoft Learn: disabled; enabled but unlocked, which can still be reversed; and enabled and locked, which is irreversible and cannot be disabled by any user, including Global Administrators. Once locked, retention can be increased but never reduced. AWS Backup offers equivalent protection through Vault Lock in compliance mode.
The important design choice is when to lock. Locking is irreversible, so test policies in unlocked mode first, confirm retention periods and storage costs, and then lock deliberately as a governed change.
Soft Delete as a Safety Net
Soft delete keeps deleted recovery points recoverable for a retention window. In Azure Backup, Microsoft documents a configurable window of 14 to 180 days and an “always-on” setting that makes the soft delete configuration itself irreversible, so attackers cannot disable it before deleting backups. Soft delete alone does not stop an attacker who waits out the window, which is why it should complement immutability rather than replace it.
Logically Air-Gapped Vaults
AWS Backup’s logically air-gapped vault stores recovery points in a service-owned account, isolated from the customer’s own accounts, with Vault Lock compliance-mode protection. According to AWS’s 2025 year-in-review post for AWS Backup, the service expanded this capability during 2025: support for additional Amazon FSx file systems, the ability to back up directly into a logically air-gapped vault without first creating a copy in a standard vault, and support for customer-managed AWS KMS keys for encryption of these vaults. The direct-to-vault option matters because it removes the cost and complexity of maintaining a second copy purely to achieve isolation.
Multi-Party Approval and Multi-User Authorization
Isolation solves only half the problem. If the account that owns the backups is compromised or locked, you still need a way to recover. AWS introduced multi-party approval for logically air-gapped vaults in 2025, allowing a designated approval team to authorize access to the backups from a different account, even when the owning account is unavailable. Azure provides Multi-User Authorization, which requires a second administrator, using a separate Resource Guard, to approve sensitive operations such as disabling soft delete or reducing retention. Both mechanisms ensure that no single compromised identity can either destroy or unilaterally recover protected data.
Malware Scanning of Recovery Points
The AWS year-in-review also highlights Amazon GuardDuty Malware Protection for AWS Backup, which scans recovery points for malicious content so teams can identify a clean restore point before recovering. Scanning does not replace forensic investigation, but it narrows the search for a known-good backup and reduces the risk of restoring compromised images.
A backup is only ransomware-resilient if it is immutable, isolated from the identities an attacker is likely to compromise, recoverable by an independent approval path and proven clean through regular restore testing. Missing any one of these turns the backup into a target rather than a safeguard.
A Reference Architecture for Resilient Backups
The following architecture works on AWS, Azure or Google Cloud with platform-specific services substituted. It is designed around the assumption that the production environment, including its administrators, may be fully compromised.
- Production accounts or subscriptions run workloads and create local, short-term backups and snapshots for fast operational restores.
- A dedicated backup account, in a separate organizational unit with its own administrators and break-glass credentials, holds vaults with locked immutability and always-on soft delete.
- An isolated copy in a logically air-gapped vault, a second region, or a second provider holds the copies that matter most for disaster recovery, encrypted with keys whose administration is separated from production.
- A recovery account, or clean room, is pre-provisioned with networking, identity and tooling so that restores can be performed and validated without touching potentially compromised production infrastructure.
- Independent approval through multi-party approval or multi-user authorization governs destructive changes and cross-account recovery.
- Monitoring alerts security operations on any attempt to change backup policies, disable jobs, delete recovery points or modify key policies.
Do Not Forget the Recovery Dependencies
A restored database is useless if you cannot authenticate to it. Make sure the backup scope includes identity configuration, DNS zones, secrets and key material (handled according to your key management design), infrastructure-as-code repositories and state files, CI/CD configuration, and SaaS data such as email and collaboration content. Document the order in which systems must be restored; identity and networking almost always come first.
Decision Criteria: Choosing the Right Isolation Model
Not every workload needs the same level of protection, and the strongest isolation is also the most expensive to operate. Use the following questions to decide where each class of data belongs.
- How damaging would permanent loss be? Systems of record, such as customer, financial and transactional databases, justify locked immutability plus an isolated copy. Rebuildable data, such as caches and derived analytics tables, may only need standard backups or can be regenerated from source.
- How far back might you need to go? Because attackers can dwell for weeks, retention for critical systems should cover at least your realistic detection window, not just the last few days.
- What is the recovery time objective? Data in a logically air-gapped vault or another provider may take longer to restore than local snapshots. Keep fast local copies for routine incidents and isolated copies for the worst case.
- Who must be able to approve recovery? Define an approval team that does not depend on the production identity provider, and make sure members are reachable around the clock.
- Is single-provider isolation enough? Logical air gaps within one cloud protect well against compromised customer credentials. Organizations with strict concentration-risk or regulatory requirements may additionally keep a copy with a second provider or on separate infrastructure.
Documenting these decisions per service also produces the evidence auditors and cyber insurers increasingly ask for: what is protected, how, for how long and how recovery has been tested.
Step-by-Step Implementation Plan
Phase 1: Assess (Weeks 1–3)
- Inventory critical business services and map each to its data stores, dependencies and current backup coverage.
- Agree recovery time and recovery point objectives per service with business owners, distinguishing ordinary outages from a ransomware scenario where you may need to go further back in time.
- Review who can modify or delete backups today, including service roles and automation pipelines.
Phase 2: Isolate and Harden (Weeks 3–8)
- Create the dedicated backup account or subscription with separate administrators, phishing-resistant MFA and break-glass procedures stored offline.
- Configure vaults with immutability in unlocked mode, validate retention and cost, then lock.
- Enable always-on soft delete, multi-user authorization or multi-party approval, and alerts on backup configuration changes.
- Set up the isolated copy, with encryption keys managed outside production.
Phase 3: Prove Recovery (Weeks 8–12, Then Ongoing)
- Build the clean-room recovery environment and automate restore tests for representative workloads.
- Integrate malware scanning into restore testing so each test confirms both recoverability and cleanliness.
- Run a full ransomware tabletop exercise, followed by a technical recovery exercise of at least one critical service end to end.
- Track measured recovery times against objectives and feed gaps back into architecture and runbooks.
Worked Example: Recovering a Compromised SaaS Platform
Consider a B2B software company hosting its platform on a single cloud provider. Its administrators discover that an attacker with stolen credentials has encrypted production databases and virtual machines and attempted to delete all snapshots in the production account.
Because the company had moved its long-term backups into a separate backup account with locked immutability, the deletion attempts against those vaults failed and triggered alerts. The production account itself was treated as untrusted. Using the multi-party approval process, two designated approvers from security and engineering leadership authorized access to the isolated recovery points from the pre-built recovery account.
The team ran malware scans across recovery points from the previous several weeks and, combined with indicators from the incident response investigation, identified the last point before the attacker established persistence. It restored identity configuration and networking from infrastructure-as-code, then databases and application servers into the clean environment, rotated all credentials and keys, and validated the application before redirecting customer traffic. Some recent data had to be reconstructed from application logs and customer re-submissions, but the platform recovered without paying a ransom, and the post-incident review focused on reducing the recovery point gap rather than on whether recovery was possible at all.
Common Pitfalls
- Locking immutability without cost planning. Locked retention cannot be shortened, so storage costs for long retention periods are committed. Model them first.
- Sharing identity providers without safeguards. If backup administrators sign in through the same compromised identity provider, isolation is weaker than it appears. Keep break-glass access independent.
- Never testing cross-account recovery. Approval workflows that have never been exercised tend to fail under pressure.
- Assuming snapshots are backups. Snapshots in the production account are useful for operational restores but offer little protection against a privileged attacker.
- Ignoring SaaS. Provider-native retention in SaaS platforms is not the same as an independent backup.
Outlook: From Backup to Cyber Recovery
The market is moving from “backup” toward “cyber recovery”: platforms that combine immutable storage, anomaly detection on backup data, malware scanning, clean-room orchestration and evidence for regulators. Regulation is accelerating this shift, especially in financial services, where frameworks such as the EU’s Digital Operational Resilience Act require tested backup and recovery capabilities. Expect cloud providers to keep extending air-gapped protection to more services and to integrate recovery testing more tightly with security tooling. The organizations that fare best will treat recovery as a security capability, owned jointly by infrastructure and security teams and tested as rigorously as any other control.
Conclusion
Ransomware has turned backups from an insurance policy into a primary target. The cloud now offers the building blocks to defend them: locked immutable vaults, always-on soft delete, logically air-gapped storage, independent approval for recovery and malware scanning of recovery points. The difference between having these features and being resilient is architecture and practice: separate accounts and identities, a pre-built clean recovery environment, complete coverage of recovery dependencies and restore tests that prove you can meet your objectives. Build those in deliberately, test them regularly, and your backups will be there when you need them most.
How Hanoi Technology Can Help
Hanoi Technology designs and tests ransomware-resilient backup architectures on AWS, Azure and Google Cloud, from immutable vaults to clean-room recovery.