Why do ransomware groups like Qilin make identity security and backup resilience equally important?

Why This Matters for Security Teams

Ransomware groups do not need to “break” modern environments when they can log in, impersonate a service account, or abuse a cloud token. That is why identity security and backup resilience rise or fall together: compromised identity is often the path in, and backup failure is what converts a contained incident into an enterprise-wide outage. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and the ENISA Threat Landscape both reinforce that access control, monitoring, and recovery planning have to be treated as linked disciplines, not separate checklists.

The same pattern appears in real incidents: adversaries steal credentials, search for privileged paths, disable security tooling, and then target backup repositories, snapshot permissions, and recovery accounts before encryption begins. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is exactly the sort of access ransomware crews exploit once they are inside. In practice, many security teams encounter backup loss only after identity misuse has already given attackers time to sabotage recovery paths.

How It Works in Practice

Ransomware operators like Qilin usually follow a chain rather than a single tactic. They begin with stolen credentials, initial access through exposed remote services, or abuse of a trusted integration, then use that identity to move laterally and identify systems that matter most to recovery. If those identities have excessive privilege, weak rotation, or broad Active Directory trust, attackers can disable backup jobs, delete recovery points, or encrypt management servers before defenders notice. The 52 NHI Breaches Analysis shows why this matters: identity compromise is rarely isolated, and once privileged access is stolen, many environments fail at both containment and restoration.

• Harden privileged identity first: separate admin accounts, enforce MFA where possible, and remove standing access that is not operationally necessary.
• Protect backup systems as tier-zero assets: isolate backup controllers, protect snapshot and vault credentials, and require separate authentication paths from production.
• Use immutable or append-only recovery where feasible so attackers cannot silently rewrite or delete backups.
• Monitor for identity abuse and backup tampering together, because backup deletion is often a late-stage indicator of a larger compromise.
• Test restoration from clean-room conditions, not just backup job success, so recovery proves usable under attack.

Current guidance suggests treating service accounts, API keys, and backup operators as high-risk identities, with tighter rotation and more aggressive logging than ordinary user accounts. This is especially important for cloud and hybrid estates, where an attacker who gains one valid identity can chain access across identity providers, storage services, and virtualization layers faster than manual response can react. These controls tend to break down when backup administration shares the same identity plane as production operations, because one stolen credential can undermine both containment and recovery.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance faster recovery against more frequent credential changes, isolated admin workflows, and stricter approval paths. That tradeoff is real, but current guidance suggests it is safer than accepting broad standing access to backup infrastructure.

There is no universal standard for this yet, but best practice is evolving toward separating backup identities from production identities, using short-lived access for restoration, and placing immutable storage behind dedicated administrative controls. For SaaS backups and third-party recovery tools, the challenge is different: the backup data may be protected, but the vendor connection itself can become the weak point if OAuth tokens or API keys are over-privileged. NHI Management Group’s Top 10 NHI Issues highlights how over-privileged and poorly rotated credentials continue to drive avoidable exposure.

Edge cases also matter in incident response. If backups are immutable but restore credentials sit in the same directory domain as production admin accounts, attackers may still block recovery. If identity is locked down but backups are copied into accessible object storage, ransomware crews can still destroy the last line of defence. The practical answer is to design for independent failure domains, because ransomware campaigns succeed when identity and resilience controls fail together rather than separately.

Related resources from NHI Mgmt Group

• Why do AI-driven and automated workloads make network resilience more important for identity teams?
• What is workload identity federation and why is it important for CI/CD security?
• What is secrets exposure in NHI security?
• Why is visibility over NHIs critical for security?