The overlooked ransomware dependency is identity recovery

Veeamโ€™s upcoming Data Platform 13.1 release promises more than 70 new capabilities. Its most important message – broader than any individual feature – is that cyber resilience is no longer just a matter of having a couple of backups of your data. It’s now a continuous operating requirement.

To put that another way, can your business prove that it can recover cleanly, fast and with its trust intact?

That distinction matters because a board may be told that it will only take four hours to get everything up and running following an incident. Unfortunately, a Recovery Time Objective (RTO) on a slide is often very different when the reality of a ransomware incident hits.

Suddenly, the security team must restore the application whilst grappling with determining whether the attacker has compromised credentials, backups or the wider identity estate.

Backups are only the start

Backups are the easy part. The tougher question is whether the backups are immutable, isolated from production, and free of malware, demonstrably. Ransomware that gains administrative access does not need to encrypt every file if it can delete recovery points, alter retention policies or wait inside the environment until the next backup cycle.

According to Veeam’s Data Trust and Resilience Report 2026, โ€œonly 28% of companies fully recovered their data following a ransomware attack while 44% recovered less than 75% of their affected dataโ€.

Veeam Data Platform 13.1โ€™s emphasis on continuous resilience speaks to this reality. The objective isnโ€™t to simply recover the latest available copy of the data but to establish a clean recovery point, validate it and restore service without reintroducing the attacker. 

This requires clean recovery room environments where teams can inspect and validate restored workloads before reconnecting them to production.

Identity is the catch

Recovery does not happen in isolation.

Every environment is reliant on identities and access controls: directory services, privileged accounts, service credentials, API keys, workload identities and multi-factor authentication policies.

For example, applications and databases in Microsoft environments depend on Active Directory or Entra ID. In an AWS or Azure environment, it would include IAM roles, cloud accounts, service principals and access policies. Across Linux, Unix, NAS and virtualised infrastructure, it can mean root credentials, automation accounts, SSH keys and the machine identities that keep workloads talking to one another.

Restoring a critical application and then reconnecting it back to compromised access controls gives attackers a way back in. As we have previously explored in our coverage of identity-focused ransomware resilience, attackers increasingly understand that disrupting identity services can be as damaging as encrypting data.

Veeam Data Platform 13.1โ€™s malware detection capabilities extend across Azure, AWS, NAS, Unix and Proxmox, reflecting the reality that ransomware recovery is no longer confined to a Windows domain. The prime objective being to identify clean recovery points across the environment, validate them in isolation, and restore services without spreading the infection from one platform to another.

Test the promise

RTO objectives must be tested under conditions that resemble a real incident. Security teams must measure how long it takes to locate clean data, restore core identity services, validate applications, rotate credentials and bring users back safely.

At the board level, the question should not be, โ€œdo we have backups?โ€ But:โ€if weโ€™re hit by ransomware, can we prove our business can recover?โ€

More ransomware articles

Kihara Kimachia
Kihara Kimachia

Kihara Kimachia is a seasoned technology writer and journalist with more than 20 years of experience. He's a contributor at TechFinitive where he covers Enterprise technology and has written for publications such as TechRepublic, eSecurity Planet and The Epoch Times.