Synthetic recovery changes what clean ransomware restore means

At a glance

What this is: Synthetic Recovery is a Commvault Cloud Unity capability that automatically identifies and assembles clean recovery points from backup data.

Why it matters: It matters because ransomware recovery now depends on proving restored data is clean, not just restoring fast, and that requirement cuts across backup, IAM, and resilience programmes.

👉 Read Commvault's article on Synthetic Recovery and clean cyber recovery

Context

Recovery after ransomware is no longer just a backup problem. If malicious or encrypted files have already reached the backup estate, teams can restore availability and still reintroduce the original compromise. Synthetic Recovery is designed to reduce that confidence gap by identifying a clean point and excluding known bad content before restore begins, which is a resilience issue as much as a data-protection one.

For identity and security practitioners, the deeper question is how much trust should be placed in backup data, recovery tooling, and the operational assumptions around last-known-good restore. In environments where service accounts, backup operators, and platform credentials can access large data sets, recovery itself becomes part of the control plane, not a post-incident afterthought.

Key questions

Q: How should security teams validate that a restore point is actually clean?

A: Teams should require a restore process that tests for known bad indicators, compares candidate versions across backup sets, and records why the chosen point was accepted. Clean means more than recent. It means the recovered data was screened before re-entry into production and the decision can be explained during incident review. Suggested anchor: recovered data was screened.

Q: Why does ransomware recovery need identity governance input?

A: Because recovery systems are privileged. Backup operators, service accounts, and automation roles can move large amounts of data and can accidentally reintroduce malware if their permissions and approvals are not controlled. Identity governance matters when the restore decision itself becomes a high-impact action that should be scoped, logged, and reviewed like any other privileged operation. Suggested anchor: high-impact action.

Q: What breaks when organisations restore backups without clean-point validation?

A: They risk bringing encrypted or malicious files back into production, which can restart the incident and force another round of containment and rollback. The failure is not only technical. It is operational, because teams lose confidence in the restored state and spend time validating what should already have been governed before cutover. Suggested anchor: restored state.

Q: What should teams do before automating cyber recovery workflows?

A: They should define approval boundaries, evidence requirements, and exception handling for restore actions before automation is enabled. Automation should accelerate a governed process, not replace one. If the workflow can select, assemble, and restore data, then the control question becomes who can trust that action and who can challenge it. Suggested anchor: approval boundaries.

Technical breakdown

Clean-point identification across backup estates

Synthetic Recovery works by scanning across backup data sets to find the most recent uncorrupted versions of files, then assembling those into a curated restore point. The important mechanism is selection, not just detection. Instead of restoring an entire snapshot and hoping validation catches problems later, the process tries to separate healthy data from encrypted or malicious content before recovery starts. That changes the recovery workflow from manual triage to controlled assembly, which is especially relevant when dormant malware has had time to contaminate multiple versions of the same data.

Practical implication: teams should treat clean-point selection as a governed recovery control, not a convenience feature.

Multi-engine threat detection in recovery workflows

The platform uses behavioral analytics, signatures, machine learning, heuristics, YARA and hash scanning, and partner signals to determine whether data should be included in recovery. No single detection method is sufficient on its own because ransomware and related malware can evade one control while still leaving indicators for another. The architectural point is that recovery validation becomes a layered detection problem. That matters because restore pipelines often assume the source data is already trustworthy, when in reality the recovery system is making a security decision under uncertainty.

Practical implication: validate which detection inputs actually feed recovery decisions and which are only producing alerts.

Why synthetic recovery changes cyber resilience operations

Synthetic recovery turns restore from a reactive process into an automated resilience workflow. The value lies in reducing rollback, excluding malicious versions, and shortening downtime while preserving confidence in the restored state. In practical terms, that means recovery is no longer only about speed. It is about the ability to restore the most recent clean state across cloud, storage, and workload boundaries without rebuilding trust manually after the fact. For organizations with large estates, this is a meaningful operational shift because the bottleneck is often certainty, not capacity.

Practical implication: measure recovery success by clean-state assurance and rollback reduction, not only by restore time.

Threat narrative

Attacker objective: The attacker aims to make recovery unreliable enough that the organisation either restores infected data or loses valuable time validating every candidate restore point.

1. Entry begins when ransomware or malware reaches production systems and backup data through compromised endpoints, credentials, or delayed-detection contamination. Escalation occurs as encrypted or malicious files are written into multiple backup versions, creating uncertainty about which restore point remains clean. Impact follows when a traditional restore reintroduces infected data into production, extending downtime and risking reinfection.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Caesars Entertainment Breach 2023 — Scattered Spider — Scattered Spider Okta credential theft enables Caesars Entertainment breach — ransom paid to prevent data release.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Clean-recovery confidence is now a security control, not a backup convenience. When ransomware can sit dormant long enough to contaminate backup sets, the real control question is whether the organisation can identify a verifiable last-known-good state before restore. That is a resilience governance issue as much as a technical one, because recovery without validation simply replays the compromise. The implication is that recovery programmes must be measured by trustworthiness of the restored state, not by restore speed alone.

Synthetic recovery creates a new identity-adjacent control boundary around backup operators and recovery automation. Backup estates contain privileged service access, cross-environment connectivity, and broad data reach, which means recovery tooling can become a high-value target even when it is not the original infection path. This is why least privilege and workload boundaries matter inside resilience workflows. Practitioners should treat recovery orchestration as part of the privileged execution surface, not a separate IT utility function.

Validated restore is emerging as a distinct resilience pattern alongside detection and response. Traditional cybersecurity models often stop at preventing, detecting, or remediating compromise. That leaves a gap in the recovery phase where organisations still need assurance that the data being restored is not the problem. The market is moving toward recovery pipelines that can prove data integrity before re-entry into production, and that should force resilience, IGA, and PAM teams to coordinate on recovery access, approval paths, and validation evidence.

Clean-point selection is the right named concept for this category. The operational challenge is not simply finding a backup. It is selecting the newest usable version while excluding corrupted or malicious material at scale. That distinction matters because it shifts the centre of gravity from manual judgment to policy-driven recovery decisioning. The practitioner conclusion is that clean-point selection should be designed, tested, and audited as a formal control objective.

Resilience tooling is becoming part of the attack surface that identity teams must understand. If recovery systems can read across estates, restore across workloads, and automate selection logic, they effectively hold a privileged position in the environment. That means incident response plans need to account for who can trigger recovery, who can approve the clean point, and how recovery actions are logged and reviewed. The implication is broader than backup: recovery governance belongs in the identity conversation.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, increasing the risk of accidental exposure according to The 2025 State of NHIs and Secrets in Cybersecurity.
• For deeper context on lifecycle control gaps, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding failures create lasting exposure.

What this signals

Clean-recovery assurance will become a governance metric, not just an operational one. As backup and recovery platforms take on more of the work of validating what is safe to restore, identity teams will need to decide who can trigger, approve, and audit those actions. That puts recovery orchestration squarely inside privileged access governance and incident evidence management.

With 44% of NHI tokens exposed in the wild, according to The 2025 State of NHIs and Secrets in Cybersecurity, the control problem extends beyond detection into recovery trust. If credentials and secrets are already leaking through tickets, chats, and commits, organisations must assume backup estates can also hold contaminated material. Recovery design should therefore include clean-state validation, not only immutable storage and retention policies.

The next planning step is to align backup, PAM, and incident response so restore authority is scoped like any other high-risk privilege. That means recovery workflows need evidence, review, and exception handling before a crisis compresses those decisions into one overloaded action.

For practitioners

• Define clean restore criteria before an incident occurs Document what qualifies as a clean-point candidate, which data sources are authoritative, and who can override the selection logic during an incident. If those decisions are made under pressure, recovery will drift into ad hoc judgement. Suggested anchor: clean-point candidates.
• Map recovery tooling to privileged access paths Review which backup operators, service accounts, and automation roles can read, select, and restore data across estates. Treat those permissions as privileged access and review them with the same rigour used for admin workflows. Suggested anchor: privileged access.
• Test reinfection resistance in restore exercises Run tabletop and technical recovery tests that include malicious files already present in backup sets, then verify that the restore process excludes them before production cutover. Record how much rollback was avoided and how long validation took. Suggested anchor: malicious files already present.
• Instrument recovery approvals and restore evidence Require logs that show who approved the restore point, what was excluded, and which validation signals supported the final recovery decision. Without that evidence, clean recovery claims are hard to defend after the event. Suggested anchor: restore evidence.

Key takeaways

• Synthetic Recovery shifts cyber recovery from restoring data quickly to restoring only data that can be trusted.
• The main security value is clean-point selection, which reduces rollback and helps prevent reinfection from backup data.
• Identity and privileged access teams should treat recovery orchestration as a governed control surface, not just an IT restore task.

Key terms

• Clean-point selection: Clean-point selection is the process of choosing the newest restore point that can be trusted as uncorrupted. In cyber recovery, it combines data validation, version comparison, and exclusion of malicious material so the organisation restores a usable state rather than simply the latest snapshot.
• Synthetic recovery: Synthetic recovery is a recovery method that assembles a new restore set from validated file versions instead of replaying an entire backup image. It is designed to reduce rollback, avoid reinfection, and make the trust decision explicit before data is returned to production.
• Reinfection risk: Reinfection risk is the chance that compromised data, credentials, or malicious payloads are reintroduced into production during recovery. It is especially important when backup sets contain dormant malware or when restore workflows lack strong validation and approval boundaries.
• Recovery orchestration: Recovery orchestration is the controlled coordination of restore tasks, approvals, and validation steps across backup and infrastructure systems. It matters because the orchestration layer often holds privileged access and determines which data is reintroduced into the environment.

What's in the full article

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

• AI-enabled multi-engine threat detection components used to score candidate files before recovery.
• The Cleanpoint identification and assembly workflow for building a curated restore point.
• Examples of how Synthetic Recovery is positioned across cloud, storage, and backup environments.
• FAQ detail on how the restore process reduces reinfection risk in practice.

👉 The full Commvault article explains how Synthetic Recovery assembles clean restore points and reduces reinfection risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.