How to Recover Endpoints After a Ransomware Attack
Key Takeaways
- Isolate first, but don't power off. Disconnecting a compromised endpoint from the network stops the spread; cutting power can destroy volatile memory that forensics and recovery both depend on.
- Reimaging isn't optional. A reboot or a quick malware scan isn't the same as restoring an endpoint to a trusted, fully managed state, and skipping that step is how reinfections happen.
- Backup-based recovery reached 66% of encrypted-data cases in 2026, but the average recovery cost still climbed to $1.7 million, which shows the gap is the endpoint itself, not just the data.
- User devices are where 30% of ransomware attacks originate, making endpoint recovery a core part of the response plan rather than an afterthought to backup.
Why endpoint recovery is the step most playbooks skip over
Most ransomware response content covers two moments well: how to stop the attack, and how to restore the data. What's covered far less often is what happens to the endpoint itself in between. According to the Sophos State of Ransomware 2026 report, based on a survey of 2,158 IT and security leaders, user devices are where 30% of ransomware attacks originate, the second most common entry point after exposed applications and systems. Despite that, backup-based recovery, which restores data, jumped to 66% of encrypted-data cases in 2026, up 12 percentage points year over year, while the average recovery cost still climbed to $1.7 million per incident, up 11% year over year. More organizations are restoring their data than ever, and recovery is still getting more expensive. That gap points to the endpoint itself, not the data sitting on it.
The process below walks through what it actually takes to get a compromised endpoint back to a trusted, fully managed state, step by step, and where that process tends to break down once it has to happen across more than one device at a time.
Step 1: Isolate the endpoint, but don't power it off
The first move is containment, not cleanup. Disconnect the device from the network, wired and wireless, to stop the ransomware from spreading or continuing to communicate with its command-and-control infrastructure. The CISA and MS-ISAC #StopRansomware Guide is explicit that this should happen without powering the device down. Volatile memory can hold indicators of compromise, and in some cases decryption keys, that are lost the moment the machine shuts off. If a decision-maker's instinct is to pull the plug, that instinct needs to be corrected before an incident, not during one.
If the endpoint connects to shared drives, backup targets, or other network storage, isolate those too. A backup system that's still reachable from a compromised device is a backup system that's still at risk.
Step 2: Preserve evidence and triage the scope
Before anything gets wiped, confirm what happened and how far it spread. The CISA guide recommends preserving logs, disk images, and samples of the ransomware itself for forensic analysis, and prioritizing which systems get restored first based on criticality rather than convenience. (NIST SP 800-184, Guide for Cybersecurity Event Recovery) frames this as the handoff point between tactical response, the immediate actions in a pre-built recovery playbook, and strategic recovery, the broader plan for getting the business back to normal. Skipping triage to move faster usually costs more time later, when a device gets reconnected before anyone confirmed it was actually clean.
Step 3: Wipe, reimage, and rebuild trust
A reboot is not a recovery step. Once an endpoint's scope is confirmed, it needs to be fully wiped, including hidden partitions, and the operating system reinstalled from a known-clean source, not restored in place. This is also the point to rotate every credential that existed on that device before it reconnects to anything. If an attacker had access to the machine, assume they had access to whatever credentials were cached on it.
Step 4: Restore data from verified-clean backups
Only after the endpoint itself has been rebuilt should data come back. Restore into an isolated environment first if possible, and scan the backup for malware before trusting it; a backup taken after the initial compromise but before detection can reintroduce the same problem. This is also where the limits of backup alone show up most clearly. For a closer look at that gap, see Ransomware Recovery vs. Backup: Why Backup Alone Isn't Enough.
Where this process breaks down at scale
Reimaging a single laptop by hand is a manageable afternoon. Reimaging 500 of them, in the middle of an active incident, with IT staff who also need to handle the rest of the business, is not. That's where manual recovery runs out of road: not because any individual step above is wrong, but because doing all of it device by device, with technicians physically present or remotely reinstalling each OS, is slow enough that it shows up directly in the cost and duration of the incident.
How Absolute shortens the last mile
This is the specific gap Absolute Rehydrate is built to close. It restores a compromised endpoint remotely back to a fully trusted, compliant state, even if the device's OS, security agents, or management tools have crashed, been disabled, or gone inaccessible, because Absolute's connection to the device lives in firmware, below all of that. Recovery happens in minutes, not through a truck roll or a multi-day reimaging queue. Absolute Ransomware Response pairs that capability with automated restoration of the security and management tools a device needs to stay protected once it's back, so it doesn't come back into the same vulnerable state it left in. See Incident Response & Endpoint Recovery for how this plays out as a use case, or Ransomware Response Tools for IT Teams for how endpoint recovery fits into the rest of a response stack.
Post-recovery hardening checklist
- Patch the restored endpoint before reconnecting it fully, not after; a freshly reimaged device with old patches is exposed again immediately.
- Rotate every credential that existed on the device prior to the incident, not just the ones directly tied to the initial compromise.
- Re-verify MFA coverage, not just MFA existence. The Sophos 2026 report found 97% of victims with compromised credentials had MFA enabled somewhere, but coverage gaps on VPNs, firewall admin consoles, and legacy apps were where the damage actually happened.
- Re-isolate backup targets once confirmed clean, so the next incident doesn't start by compromising the thing recovery depends on.
- Document the timeline and scope for compliance purposes while it's still fresh, rather than reconstructing it weeks later.
Closing thoughts
Stopping an attack and restoring data are necessary, but neither one is the same as recovering the endpoint itself. The organizations that come back fastest treat endpoint recovery as its own deliberate process, isolate, triage, reimage, restore, harden, rather than assuming it will sort itself out once backup finishes. Want to see how Absolute shortens that process for your fleet? Request a demo to see our solutions in action, or explore our resource library for more
