According to Mandiant’s M-Trends 2025 report, when organizations discover a ransomware intrusion on their own (without being tipped off by law enforcement or, ironically, by the attacker’s ransom note), the median dwell time is 29 days – nearly a month of access before anyone noticed.
Now consider what a typical backup configuration looks like: daily incrementals, a rolling retention window of seven to fourteen days, and a management console reachable from the public internet.
If the attacker was in your environment for 29 days before you knew, every restore point in that fourteen-day window was created while they were already present. Recovery from any of those points restores the compromised state. The backups ran on schedule. The dashboard was green. None of it mattered.
This is not a theoretical failure mode. Sophos’s State of Ransomware 2025 found that only 54% of organizations with encrypted data managed to restore it using backups – the lowest backup recovery rate the report has recorded in six years. Backups existed. They just didn’t work when it counted.
The question worth asking is not whether backups are running. It is whether any restore point exists that an attacker with 29 days of access cannot reach.
The retention window is the real attack surface
Longer retention is part of the answer. GFS (Grandfather-Father-Son) retention – which preserves selected weekly, monthly, and yearly restore points independently of the rolling window – extends recovery options back beyond any realistic dwell period. A monthly restore point from 60 days ago predates the attacker’s arrival. Recovery from it might mean going back further than you’d like, but it is a real recovery, not a negotiation.
But retention alone does not close the problem. An attacker who reaches the management console can shorten the retention window retroactively, delete older restore points directly, or disable immutability settings on future backups. Which is where the counterintuitive part of this comes in.
The best protection is giving up control
Compliance-mode Object Lock is a feature that makes most administrators uncomfortable the first time they hear its full accurate description.
When Object Lock is configured in Compliance mode on supported storage – Amazon S3, Wasabi, Backblaze B2, Azure, Google Cloud, and other S3-compatible destinations – backup objects cannot be deleted or modified until the retention period expires. Not by the backup software. Not by a compromised admin account. Not by the storage account’s root user. Not by anyone. The only exit is terminating the storage account entirely.
This is not a limitation. It is the mechanism. The protection works precisely because it cannot be overridden. An attacker with full administrative access to the environment, the backup management console, and the cloud storage credentials cannot delete a Compliance-mode protected restore point. There is no privilege level that grants deletion, before the clock runs out.
The implication is significant: effective ransomware protection for backup data requires deliberately relinquishing your own administrative control over it for the duration of the retention period. You are not locking out the attacker specifically; you are locking out everyone, including yourself.
Governance mode – Object Lock’s less restrictive variant – protects against accidental deletion and most automated attacks, but objects can still be removed using storage provider tools by users with sufficient permissions. However, it won’t stop a sophisticated actor who has already spent 29 days mapping your access controls – only Compliance mode will.
In MSP360, Object Lock defaults to Governance mode. Compliance mode is available but requires enabling through the MSP360 support team – a deliberate friction point, given that the decision to use it is effectively irreversible for the retention window. The practical cost either way is that storage for the locked period becomes fixed. Immutable objects cannot be deleted early, even to cut costs. Object Lock must also be configured through MSP360’s own workflows, not directly in the storage provider’s console – settings applied outside MSP360 are not supported and can cause unexpected behavior. The coupling with GFS retention is intentional: immutability without long-horizon restore points protects only the window the attacker already owns.
What the management console actually protects – and what it doesn’t
Compliance-mode Object Lock closes the deletion vector at the storage layer. But it does not protect restore points that simply never existed (due to a stopped backup job), nor those created without immutability – i.e., if the settings were changed prior to the attack.
This is why the management console is the more valuable target. An attacker who controls it cannot delete existing immutable objects – but they can disable Object Lock on new backup plans, stop backup jobs from running, or modify settings so future restore points have no protection. By the time the ransom note arrives, the most recent restorable point might be weeks old regardless.
Hardening the console is therefore not secondary to immutability; it is what keeps immutability meaningful over time. To close the configuration vector that Compliance mode cannot address, you must implement:
- Mandatory multi-factor authentication for all administrators.
- Role-based access controls to limit who can change storage account and retention settings.
- IP allowlisting to restrict console access to known networks.
The two layers are not redundant – they defend against different stages of the same attack. Immutability assumes the attacker has already reached storage. Access hardening tries to prevent them from getting there. The 29-day dwell window suggests that a compromised console should be treated as a planning baseline, not a failure case.
The test tha treveals actual recovery posture
There is a practical way to pressure-test whether any of this holds.
Take your oldest GFS restore point – the one that predates the most plausible attacker dwell window. Attempt a restore. Time how long it takes to locate the decryption password, hand it to a second administrator, and confirm the restore can proceed. If that sequence takes longer than five minutes or fails for any reason – you have a plan “on paper”, but not a functioning one.
The MSP360 backup hardening guide structures this as a quarterly test block – seven specific pass/fail checks covering integrity, access controls, and recovery verification – designed to produce auditable evidence rather than a subjective sense of readiness. The distinction matters: auditors, insurers, and boards are increasingly asking not whether backups exist, but whether recovery can be demonstrated.
Organizations that can pass that test consistently are in a materially different position than those that cannot. The difference is rarely a larger budget or a more complex architecture. It is the decision to treat recovery infrastructure as a security surface with defined controls, not an IT process with a green status icon.
The attackers doing pre-encryption reconnaissance have already figured out which environments have real recovery capability and which ones just have backups. The 54% backup recovery rate suggests the gap is still large enough to build a business around.
MSP360 provides backup, RMM, and remote access solutions for managed service providers and IT departments.
About the Author
Lidiia Fofanova is a Lead of Product Marketing Manager of the MSP360 with expertise in cybersecurity, cloud technologies, and B2B software solutions. She focuses on developing products that help businesses improve data protection, backup, and IT management processes. Passionate about technology and user experience, Lidiia works closely with engineering, marketing, and customers to deliver practical solutions tailored to modern business needs.
Lidiia can be reached online at LinkedIn and at the MSP360 website.
