Why does restoring from backups not fully solve ransomware recovery?

Backups restore data and configuration, but they can also restore orphaned accounts, stale group memberships, and over-privileged service identities. That means the attacker’s access conditions may return with the environment. Clean recovery requires a governed access baseline so teams can validate what should exist before they reconnect systems or declare the environment safe.

Why This Matters for Security Teams

Backups are necessary, but they do not prove that the recovered environment is trustworthy. Ransomware operators often compromise identity first, then use service accounts, API keys, and delegated admin paths to persist. If those identities are restored along with data, the organisation can reconnect a system that is already primed for re-entry. That is why recovery has to include identity validation, not just file restoration.

NHI Management Group has repeatedly shown how often identity controls fail in practice, including the finding that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that recovery must preserve control integrity, not just system availability. In practice, many security teams discover that backup-based recovery reintroduces the same access paths only after attackers have already leveraged them once.

How It Works in Practice

Effective ransomware recovery starts with a clean access baseline. That means inventorying which human and non-human identities should exist, which secrets should be valid, and which privileges should be removed before restoration proceeds. Backups may contain stale local admins, orphaned service accounts, embedded API keys, old certificates, and group memberships that no longer reflect current business need. If those objects are restored blindly, the environment may come back online with the attacker’s original footholds intact.

A practical recovery workflow usually includes the following steps:

• Freeze restoration until identity records are reviewed against an approved baseline.
• Revoke or rotate secrets that were present at the time of compromise.
• Validate service accounts, scheduled tasks, and automation tokens before reconnecting workloads.
• Rebuild privileged access paths rather than trusting restored membership data.
• Confirm that logging, monitoring, and admin recovery accounts are clean before declaring the environment safe.

This is especially important because NHI Management Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them in the Ultimate Guide to NHIs. Backup restoration should therefore be treated as a data recovery task, while identity recovery is handled as a separate control exercise. The NIST CSF 2.0 recovery function supports this distinction by emphasizing that restored services must be dependable, not merely online.

That distinction matters because ransomware groups often exploit automation paths, cloud control planes, and delegated credentials that are not obvious in a traditional restore checklist. The Codefinger AWS S3 ransomware attack is a useful reminder that cloud recovery must account for access governance as much as object restoration. These controls tend to break down when backups are restored into the same identity plane that was already compromised, because the attacker can re-use valid secrets faster than the team can complete revalidation.

Common Variations and Edge Cases

Tighter recovery controls often increase downtime and coordination overhead, requiring organisations to balance speed against assurance. That tradeoff is real in regulated environments, where business pressure pushes teams to bring systems back quickly, but current guidance suggests that speed without identity verification simply shortens the path back to compromise.

There is no universal standard for exactly how much identity data should be revalidated before restore, but best practice is evolving toward a tiered approach. High-value systems should require manual review of privileged identities, service principals, and trust relationships before reconnection. Less sensitive systems may rely on automated checks, provided the organisation can prove secrets were rotated and orphaned access was removed. For environments with third-party integrations, restored backups can also re-enable external access paths that were never intended to survive an incident.

The operational lesson is simple: backups help restore availability, but only governed identity cleanup restores trust. Teams that skip that step often end up reintroducing the same exposure through a seemingly successful recovery. That failure pattern has appeared repeatedly in incidents involving credential abuse, including cases documented by NHI Management Group such as the Cisco Active Directory credentials breach and the Schneider Electric credentials breach.

Related resources from NHI Mgmt Group

• Why can't OAuth 2.0 and OIDC alone fully solve NHI authentication challenges?
• Why does shift-left security not fully solve AI agent risk?
• Why do backups fail during ransomware incidents even when they exist?
• What is the difference between ransomware containment and recovery planning?