Redefining Cyber Recovery Requirements in the Era of Modern Cyberattacks

 Article written and contrbuted by, Juan Cruz of WWT & Harsha Muktamath and Belu De Arbelaiz of VMware by Broadcom

Ask enough security and infrastructure leaders whether they have lived through a ransomware incident, and a pattern starts to emerge before the question is even finished. Most have, and while many eventually recovered, the process was rarely straightforward. 

In CrowdStrike's 2025 State of Ransomware Survey, 78% of respondents reported being hit by a ransomware attack in the past year, and nearly 40% stated they couldn't restore all the data they lost. What's more, half of the 1,100 security leaders surveyed believed they were well prepared to recover. Without tools purpose-built for the task, recovery from a modern cyberattack is slow, unpredictable, and, for some organizations, never fully completed. 

Even among those who considered themselves well-prepared, confidence did not equal readiness in practice. Identifying a proven-clean backup to restore from, on a timeline the business could tolerate, ended up being the exception rather than the norm. The hardest-hit learned a painful lesson: when the worst happens, the plan you have is not always the plan you need. 

The conversations tend to follow the same arc. 

• Did you recover? Most times the answer is "we are still working on it," months later.
• Did you have an isolated environment to test recovery points before restoring them? Usually no, or something that was labeled a disaster recovery site but was never built or hardened to function as a quarantined environment.
• Were you testing your recovery plan regularly before the attack? Almost never, because testing meant downtime, and downtime meant pulling IT resources away from everything else on the calendar.

Those three answers describe one gap. Disaster recovery makes data available again. Cyber recovery has to make uncorrupted data available, and that requires capabilities most DR programs were never built to include: an isolated clean room where restore point candidates can be powered on safely, behavioral analysis and EDR to catch threats that leave no file behind, and network isolation so a compromised workload cannot spread while it is being validated.  

By the end of the conversation, the organization has usually discovered that the plan it had and the plan it needed were solving two different problems. That gap shows up almost everywhere, not because one company got unlucky, but because disaster recovery and cyber recovery keep getting treated like the same discipline when they are not. 

VMware Cloud Foundation (VCF) and VMware Advanced Cyber Compliance (ACC) were built to solve for this by integrating and automating the parts of cyber recovery that most organizations have historically had to build themselves, usually for the first time, under pressure, while being under active attack. 

WWT acts as the guide through the process: its architects validate the automation inside the Advanced Technology Center (ATC), stress-test it against real operating models, and help customers put it to work before they ever rely on it for their own recovery. 

Understanding Key Differences Between Cyber and Disaster Recovery 

Disaster recovery and cyber recovery get lumped together because they share a vocabulary: backups, snapshots, restore points, recovery time objectives. But they answer different questions. 

Disaster recovery deals with availability. The cause of the outage, whether it is a power failure, a hardware fault, or a natural disaster, does not corrupt the data itself. So, the fix is straightforward: restore from the most recent backup and move on. The assumption built into that plan is that the newest copy is the best copy. 

Cyber recovery breaks that assumption. A ransomware or malware infection does not usually announce itself the moment it lands. It sits inside the environment for a period security teams call dwell time, quietly spreading and waiting, before it ever triggers an alarm. That means the most recent backup is not the safest one to restore. It is highly likely the most infected one since it was taken after the attacker was already inside. Cyber recovery has to work backward through time to find a copy from before the infection took hold, then prove that copy is actually clean before anyone trusts it with production traffic again.  One of the worst scenarios a customer can run into during a ransomware attack is reinfection. 

That single difference, availability versus integrity, changes everything downstream: what has to be tested, what has to be isolated, and how long recovery actually takes. It is also why dwell time is one of the more important numbers in this conversation. The longer an attacker sits undetected, the further back in time a recovery team may need to search, and the more restore points there are to rule out before finding one worth trusting. 

This is also why immutable, air-gapped backups, on their own, fall short of the modern cyber resilience requirements organizations must meet today. Immutability guarantees a copy cannot be altered or deleted, including by an attacker. It says nothing about whether that copy is clean. Treating an unbreakable copy of the infection as a finished recovery plan is one of the more common, and more expensive, assumptions an organization can make. 

The Numbers Behind the Urgency 

Three figures from the two most recent industry threat reports explain why this search can no longer be handled on an ad hoc basis, and they are worth reading correctly. 

82% of intrusions detected in 2025 involved no malware at all. According to CrowdStrike's 2026 Global Threat Report, the large majority of attacks now use stolen but valid credentials and an organization's own administrative tools to move around, which means there is no malicious file for a traditional antivirus scan to find. 

Global median dwell time rose to 14 days in 2025, up from 11 the year before. According to Mandiant's M-Trends 2026 report, that increase is driven largely by patient, long-running espionage operations, and fraudulent employment schemes, some of which went undetected for well over a year. 

Once an intrusion is headed toward ransomware, the handoff from initial access to the actor who deploys it has collapsed to a median of 22 seconds, down from more than eight hours in 2022, also according to Mandiant's M-Trends 2026 report. 

The last two figures look like they contradict each other, and it is worth pausing on why they do not. Global dwell time is a median across every kind of intrusion Mandiant investigated, and it is being pulled upward by attackers who are in no hurry: espionage actors and fraudulent employment schemes built to persist quietly for months, not to cash out quickly. The 22-second figure describes a different, faster-moving population: intrusions where an initial access broker has already gotten in and is handing control to whoever will run the ransomware. Both things are true in the same year, in the same report, because the threat landscape has split into two different speeds. Some attackers are willing to wait. The ones most relevant to cyber recovery, the ones aiming for a fast, destructive payout, are not. Planning a recovery process around the 14-day median, and assuming there is time to notice and react before damage is done, is planning for the wrong attacker. 

When the Attack Leaves No File Behind 

The 82% figure above deserves its own explanation, because it is the reason a simple antivirus scan is no longer enough to declare a restore point safe. 

For years, most attacks left something behind: a file. Recovery teams could run a signature scan against a static, powered-off backup, find the malicious file, delete it, and call the restore point clean. That model started breaking down as attackers shifted toward what CrowdStrike calls malware-free tradecraft: intrusions that never install anything at all. Instead of a file, the attacker uses stolen but valid credentials and an organization's own administrative tools to move around, sometimes alongside malware that lives only in memory and never touches disk. Either way, there is nothing for a signature scan to catch, because nothing was ever installed. 

That has a consequence most security programs have not caught up to. Perimeter controls are built to keep intruders out. When the attacker arrives holding valid credentials, there is nothing at the perimeter to stop, and the question quietly shifts from how to keep them out to how quickly the business can be made whole once they are in. Cyber recovery is the part of a resilience program that answers the second question, and it is the part most often assumed to be covered by a backup policy written for a different kind of failure. 

Catching this kind of activity requires a different approach: behavioral analysis, also referred to as next-generation antivirus. Instead of scanning a workload for known malicious files while it sits powered off, a recovery team must power the workload on and watch how the data behaves over time. Does it try to contact an external server? Does it attempt to spread to other systems? Does it start modifying files it has no reason to touch? Those behaviors, not a file signature, are what expose a malware-free intrusion. 

That requirement creates an immediate problem. Powering on a workload to observe it is exactly the kind of thing an organization cannot safely do in production, since a still-compromised VM could reinfect everything around it the moment it comes online. An intrusion that spreads through network connections between workloads will use whatever access that powered-on VM has to reach for the next target. That is what forces the need for an isolated clean room: a quarantined environment where restore point candidates can be powered on, tested, and either cleared or discarded, with each VM's network access locked down so nothing can spread while it is being evaluated. 

The Attack Chain Got Automated Too    

Everything described so far is the threat as it exists today. Where it is headed matters just as much, because the same automation reshaping the rest of technology is reshaping how attacks get built in the first place. 

Finding vulnerabilities and chaining them into a working attack used to be specialized, time-consuming work. An attacker needed to know a lot of individual bugs, understand how each one behaved, and figure out which ones fit together into a path from a single opening to a critical system. That was slow, and it was a skill relatively few people had. AI has compressed that work considerably. Vulnerabilities are recorded in public, open-source repositories for anyone to see, and an attacker can now point a model at a codebase and ask it to find the openings, sequence them, and explain exactly how to chain them together, without a person working through it bug by bug. The same acceleration applies to the malware itself: attackers who once wrote a tool, used it, and reused it, giving defenders time to build and share a signature, can now customize or rebuild a variant for a specific target with comparatively little effort. 

The effect is not just that sophisticated attackers move faster, though they do. It is that attackers who were never sophisticated enough to build an attack chain on their own now have a tool that will build one for them. That expands who is capable of running a serious attack, not just how fast the most capable attackers operate. 

It also breaks an assumption that has quietly underpinned security for years: that friction works. Extra hops, added complexity, enough annoyance that an attacker gives up and moves to an easier target, has functioned as a real, if informal, layer of defense. That does not hold up against automation. A model does not get frustrated and go bother someone else. It works through friction the same way it works through everything else: methodically, and at machine speed. That is precisely why recovery speed and confidence now carry more of the defensive weight than they used to. When prevention alone can no longer be counted on to hold, how fast and how certainly an organization can recover becomes the more durable line of defense. 

Which raises the practical question: what does it actually take to recover that way? 

Built Under Pressure 

Understanding why an isolated clean room is necessary is the easy part. Building and running one is where most organizations run into trouble, because a functioning cyber recovery environment is not one tool. It is several integrated components: replication to keep restore point candidates current; orchestration to sequence the recovery process end to end; network isolation to contain each workload while it is being tested; endpoint detection built into that isolated environment to actually catch fileless behavior, and a defensible way to decide which restore point to try first. 

Most organizations are left to assemble all of this themselves, and they are frequently doing it for the first time under the worst possible conditions: during an active incident, against a recovery time objective the business is watching in real time, often with executive leadership asking for frequent updates. 

Every seam between those pieces is a place where recovery can stall. A replication tool that does not talk cleanly to the orchestration layer. An endpoint detection platform never configured to run inside a quarantine. A restore point selection process that amounts to guessing and checking, one snapshot at a time, while the clock runs. 

Simply put, modern cyber recovery requires everything DR requires (replication, immutable and air-gapped copies, orchestration, and a recovery plan that has been exercised) plus four things DR never had to provide: 

1. An isolated clean room where restore point candidates can be powered on and observed without touching production.
2. Behavioral analysis and EDR integrated into the recovery workflow because a signature scan of a powered-off copy cannot detect an intrusion that never installed a file.
3. Network isolation for every VM under validation, to stop lateral movement in the clean room and prevent reinfection if a compromised workload is restored.
4. A defensible method for deciding which restore points to test first, so the search is narrowed rather than guessed.

Assembled from five vendors, that list is an integration project. Delivered as one workflow, it is a process. 

One Workflow Instead of a Five-Vendor Project 

Every component described above -- replication, orchestration, network isolation, endpoint validation, and restore point selection-- exists today as its own product from its own vendor. Most organizations are running exactly that: a stack of point solutions wired together by hand, with every seam described above built in by default. VMware Advanced Cyber Compliance, a VMware Cloud Foundation Advanced Service, replaces that stack with a single guided workflow spanning identification, validation, and restore, run at scale instead of assembled during an incident. A few specific capabilities are worth walking through because they are the difference between recovery measured in weeks and recovery measured in hours. 

Guided Restore Point Selection 

Instead of guessing which snapshot to try first, ACC analyzes data and metadata across a series of stored, powered-off snapshots to flag likely points of infection before any workload is powered on. One signal it tracks is entropy, a measure of how random or disordered the data in a snapshot is. Encrypted data is far more random, and therefore far less compressible, than ordinary unencrypted data, so a sudden spike in entropy across consecutive snapshots often signals that encryption started somewhere in that window. Combined with other signals, such as an unusual rate of change within a virtual disk or a spike in file creation, deletion, and modification, this analysis narrows down where to start looking. It does not replace the need to validate a candidate restore point. It replaces guesswork with a defensible starting point. 

An Isolated Clean Room, Built In 

Rather than requiring customers to design, build, and secure their own quarantined environment, ACC provides a prescriptive isolated clean room with push-button network isolation for every VM brought into it. A restore point candidate can be powered on and evaluated without any risk of it reaching production, or reaching any other workload being tested alongside it. 

Built-In Behavioral Analysis to Identify Fileless Malware 

When restore point candidates are powered on in the isolated clean room, an EDR sensor is automatically installed on each VM to run behavioral analysis for fileless threats, a signature-based scan, and a vulnerability analysis. That AI/ML-based validation runs on each powered-on candidate until a clean restore point is identified. The clean copy is then returned to production once the affected site has been remediated and hardened. Carbon Black is included by default, and ACC 9.1 added CrowdStrike Falcon as a bring-your-own-license option, so teams can validate restore points with the endpoint tooling they already run in production. 

Instant Power On 

Given the nature of cyber recovery, where IT teams must roll back in time to find uninfected restore points, the ability to quickly iterate across snapshots to find clean copies is critical. Traditional recovery requires data rehydration, converting a backup copy back into a runnable format before it can even be powered on, a process that can take hours to days. Instant Power On eliminates that step, so a restore point candidate can be powered on in the isolated clean room immediately. Because cyber recovery is iterative by nature, testing one candidate, ruling it out and moving to the next, that saves compounds across every iteration rather than being counted once. 

Recovery plan testing is a separate exercise, and it benefits for a related reason. Because a plan can be rehearsed in the clean room without rehydration and without taking production down, testing can move from a once-a-year fire drill to a routine operational cadence. 

Recovery at Scale 

Once a clean restore point is confirmed, ACC restores at scale rather than one virtual machine at a time, which matters enormously in large environments where a per-VM approach would take days on its own. Recovery point objectives as low as one minute are achievable, meaning an organization loses, at most, a minute's worth of data even in a full failover. ACC also incorporates Recovery Plans to organize which resources to restore and when to restore them.  What this means is the customer can restore Tier 1 applications with priority to bring the business back online in a short amount of time while supporting resources are restored afterwards.

Common Gaps in Recovery Readiness 

Even organizations actively investing in recovery tend to fall into a handful of familiar traps, and they are worth naming plainly because most are fixable before an incident, not during one. 

The most common is treating the clean room as an afterthought, something to figure out once an attack is already underway rather than something built and tested in advance. A close second is relying exclusively on immutable, air-gapped backups and traditional disaster recovery orchestration, on the assumption that those controls alone amount to a cyber recovery plan. They are necessary. They are not sufficient. 

Customers who have been through an actual incident say some version of the same thing afterward: whatever gaps existed, they wish they had closed them before the attack. 

Recovery as a Compliance Discipline, Not Just a Technical One 

It is easy to think of everything above as a purely technical problem, owned entirely by infrastructure or security teams. In practice, cyber recovery increasingly sits at the intersection of technology and compliance, which is reflected in the name of VMware's own service. 

Heavily regulated industries, financial services, healthcare, government, education, and any organization holding substantial intellectual property, face the most scrutiny here, because the cost of a breach in those sectors extends well beyond downtime into regulatory fines and reputational damage tied to how customer data was handled. Auditors and regulators increasingly expect proof, not assurances: documented, regular disaster recovery and cyber recovery test results, evidence that infrastructure is being actively monitored, and a clear record that recovery plans are more than a document sitting in a shared drive. 

VMware Cloud Foundation supports that reporting need directly. Advanced Cyber Compliance produces the evidence itself: recovery plan test results, restore point validation records, and the current state of the isolated recovery environment. VCF Operations then provides the fleet-level view, consolidating that picture across every VCF instance and site in a single console, so recovery readiness and the reports needed to prove it can be pulled centrally rather than assembled site by site under deadline pressure. In an audit conversation, that difference matters. Being able to show that infrastructure is healthy, that recovery tests run on a regular cadence, and that the isolated recovery environment behind those tests is real and current is what turns a compliance requirement from a scramble into a routine report. 

Proving It Before You Need It 

World Wide Technology tests ACC in its Advanced Technology Center (ATC) against a replicated version of a customer's actual environment, at the scale that environment actually runs, rather than at demo scale. Because customer data never enters the ATC, architects build a mirror of the production environment with randomly generated data and run restores against it, including controlled ransomware exercises where that level of validation is warranted. 

That testing usually surfaces something before it ever reaches the product. Most organizations have never formally separated their priority-one systems, the front-end applications, the databases behind them, anything that directly generates revenue, from everything else. Without that separation, the plan defaults to restoring the entire environment at once, which is rarely realistic and almost never fast. Sorting out that order, and the dependencies inside it, comes first. A web front end is useless if the database behind it has not come back yet.