Ransomware-Resistant Backups: Keeping Storage, Admin Access and Keys Out of the Attacker's Reach
Backups only save you from ransomware if attackers cannot delete them, reach their admin console or lock you out of their keys. Here is how to separate all three, with a checklist to start this week.
Most ransomware playbooks share one assumption: if the worst happens, we restore from backup. That assumption fails more often than it should, and usually not because the backup software broke. It fails because the backups, the accounts that manage them, or the keys that decrypt them sat inside the same environment the attacker had already taken over.
NIST's updated ransomware profile, NIST IR 8374r1, published in June 2026 and aligned with CSF 2.0, keeps backups at the centre of recovery. It asks organisations to "secure and isolate backups of important data" and to verify backup integrity before using them for restoration. This guide turns that into practical design choices, with a focus on the part that is easiest to overlook: who can delete a backup, and who holds the key to read it.
Why backups are a target, not just a safety net
Attackers know that a clean restore removes most of their leverage, so recovery capability is part of what they go after. CISA's #StopRansomware advisory on Akira describes actors deleting Volume Shadow Copy snapshots to inhibit recovery, exploiting unpatched backup servers, and dumping credentials from the backup application's configuration database.
The UK NCSC reported the same pattern years earlier. In Offline backups in an online world, it notes that ransomware has encrypted connected USB and network drives holding backups, and has also compromised connected cloud storage that contained backups.
The lesson is structural. A backup is only as independent as the weakest path to it. If a domain administrator, a synchronised cloud identity, or a stolen service credential can reach the backup console, the backup shares the fate of production.
Three kinds of separation that matter
Isolation is often reduced to "keep a copy offline". That remains good advice, and both NIST IR 8374r1 and CISA's Ransomware Guide recommend offline, encrypted backups. In practice, a resilient design separates three things.
1. Separation of storage: copies that cannot be changed
At least one copy should resist deletion and alteration, even by an account with apparently full rights. The NCSC's principles for ransomware-resistant cloud backups start here: block deletion or alteration of a backup once it is created, or use recoverable soft-delete and time-delayed changes, and apply this to machine identities too, not only humans.
Immutability is not the whole answer. CISA cautions that immutable storage should be used with care because it does not meet compliance criteria for certain regulations. Check how retention locks interact with your own deletion and erasure obligations before you set long lock periods.
2. Separation of identity: a different blast radius for admins
The backup platform should not trust the identity system it is meant to rescue. If your backup console signs in through the same directory and the same privileged groups as production, a compromised directory gives the attacker your backups as well.
The NCSC principles go further: a backup service should be configured so that it is not possible to deny all customer access, for example by forbidding an access policy that leaves a single attacker-controlled account in charge, and by keeping a separate out-of-band route back in. They also ask for alerts on significant changes and privileged actions, raised whether or not the attempt succeeds, and delivered in a way that still works if your own infrastructure is compromised.
3. Separation of keys: can you still decrypt?
Encrypted backups protect confidentiality, but they add a dependency. If the keys that protect backup data live in a key service that is unavailable, deleted, or controlled by the attacker, a perfectly intact backup can still be unreadable.
The NCSC's fourth principle asks for robust key management for data at rest, including an offline backup of the master key. CISA's guide adds two controls for customer-managed keys: limit which users and roles can act on keys, and separate duties so that the account that provisions or manages keys cannot also use them. Together, these mean an attacker who gains a backup operator role cannot also schedule key deletion, and an attacker who gains a key administrator role cannot read the data.
A checklist you can work through this week
Each step below is small enough to start now, and each one produces evidence you can show an auditor or a board.
- Map the paths to your backups. List every account, group, service principal and API key that can delete, modify, or change retention on backups. Anything that also has rights in production is a shared blast radius.
- Move backup administration out of the production directory, or at least out of its privileged groups. Use separate administrator accounts with phishing-resistant MFA, and keep a documented break-glass route that does not depend on corporate SSO.
- Turn on deletion protection for at least one copy. Use object lock, retention locks, recoverable soft-delete or a time delay on destructive changes. Confirm it applies to service accounts, not only to people.
- Check the key path end to end. For each backup set, record which key encrypts it, where that key lives, who can disable or delete it, and how the key itself is backed up. If the answer is "the same administrator as everything else", split those duties.
- Patch and monitor the backup servers themselves. Treat them as tier-zero assets, since attackers specifically go after them. Alert on retention changes, mass deletions, new administrators and key-policy edits.
- Back up the rebuild kit. CISA recommends keeping golden images of critical systems and offline copies of infrastructure-as-code templates, so you can rebuild a clean platform to restore into.
- Test a real restore, then verify it. NIST's RC.RP-03 outcome is that backup integrity is verified before restoration. Restore a representative system into an isolated environment, time it, and confirm the data is complete and clean.
Make recovery measurable
A restore test that only proves "the job finished" says little. Record how long each critical service took to return, which steps depended on systems that might be down during an incident, and which credentials or keys you had to reach for. Those dependencies are your real recovery plan.
NIST IR 8374r1 also asks organisations to prioritise mission-critical services for recovery and to plan out-of-band communications. Fold the backup and key dependencies into that plan, so the people running the restore know which accounts and which key custodians they need on day one.
Conclusion
Backups remain the most dependable way to recover from ransomware, but only when they sit outside the attacker's reach in three ways: storage that cannot be silently changed, administrative identities that are not the production identities, and keys that someone other than the attacker still controls. None of this requires new technology; it requires drawing the boundaries deliberately and testing them.
If you are reviewing how keys and encrypted storage are governed, OXU KMS and OXU Drive are where Oten focuses on encryption and private storage. Whatever tools you use, the checklist above is a good place to start.