ERR Blog: When backups aren’t enough

The core shift: Threat actors are no longer simply encrypting production data. Today’s attacks are engineered to dismantle recovery infrastructure before a ransom note ever appears, targeting the consoles, credentials, and control paths that determine whether restoration is even possible. Software Analyst Cyber Research (SACR) defines the architectural standard for surviving this threat as Ephemeral Ransomware Resilience (ERR). This post explains what ERR means, why it sets a more rigorous bar than storage immutability alone, and the five questions every organization should apply to its own disaster recovery architecture.

For most of the last decade, the prevailing guidance held firm: maintain reliable backups, and a ransomware attack becomes a recovery exercise rather than an existential crisis.

That calculus wasn’t lost on attackers. As backup strategies matured into a dependable recovery mechanism, ransomware operators recalibrated, shifting focus from production systems to the very thing designed to defeat them. Many organizations’ disaster recovery postures, however, haven’t kept pace with that evolution.

What follows examines how the threat developed, what the ERR standard requires in practice, and the diagnostic questions every organization should be able to answer about its own recovery posture.

How ransomware changed

Today’s ransomware threat didn’t arrive fully formed. It evolved in direct response to the defenses organizations deployed against it.

In the early phase, roughly 2013 to 2018, attackers focused on encrypting production data and demanding payment. Organizations with solid backups could restore and move on. That reliability became the problem. Once backups proved effective at neutralizing the extortion model, attackers changed the objective.

From approximately 2019 to 2023, ransomware operators began locating and destroying backup repositories before detonating their payload. Removing the safety net before detonation became a standard step in the attack chain, steadily eroding the effectiveness of traditional backup strategies.

The current phase goes further. Rather than targeting individual backup files, attackers now pursue the control layer, the consoles, credentials, and configuration settings that govern backups themselves. With valid admin access, there’s often no need to break any protection directly. Retention schedules can be quietly shortened, systems can be removed from backup policies, or copies can expire without triggering a single alert. The damage accumulates silently over time.

Dwell time makes this strategy possible. According to Verizon’s 2025 Data Breach Investigations Report, attackers remain inside a network for a median of 24 days in non-actor-disclosed breaches. That window is sufficient to map recovery infrastructure, harvest the credentials that control it, and dismantle recovery options before anyone notices. When detonation finally comes, it arrives fast: Google and Mandiant’s M-Trends 2026 report found the median time between initial access and ransomware deployment shrank from more than eight hours in 2022 to 22 seconds in 2025. Intercepting an attack at detonation is no longer a realistic control. The question that matters is whether recovery remains viable in this adversarial scenario.

Why traditional immutable backups fall short

Immutable backups represent a meaningful layer of protection, but they address only part of the problem. Understanding where that boundary sits is critical.

Immutability protects backup data at rest from modification or deletion. What it doesn’t protect is the control layer surrounding it: the console, the API, the administrative interface through which backups are managed. If those control paths remain reachable, an attacker holding valid credentials can still interfere with recovery.

This is the structural gap that most widely adopted approaches share:

• Cloud object lock protects data at the storage layer, but the management environment surrounding it typically remains network-reachable and credential-accessible.
• Offsite replication provides geographic redundancy but reproduces the access problem. A compromised primary management plane frequently means the replication credential is compromised too.
• Tape backups offer genuine physical separation but carry restoration speed and operational maintenance limitations that make them difficult to sustain reliably at scale.
• Manual backup routines introduce human dependency at precisely the moment it’s least reliable: during an active incident, when teams are under pressure and processes break down.

Each of these approaches was designed to address operational failure modes, such as hardware outages, accidental deletions, and site-level disruptions. None was architected to withstand an adversary who already holds valid admin credentials and has had weeks to operate undetected.

Architectural isolation changes that calculus. When the management plane that governs backup operations is structurally severed from the protected copies, an attacker with valid credentials has no control path to exploit. There’s no console to manipulate, no API to call, no admin interface to reach. The protected copies exist outside the blast radius of a compromised environment entirely, which means recovery viability doesn’t depend on whether the adversary has been evicted before the process begins.

What Ephemeral Ransomware Resilience means

Ephemeral Ransomware Resilience, or ERR, is a standard developed by SACR to address a specific scenario: an attacker already holds valid administrative access. The question ERR answers is whether recovery remains viable under those conditions.

Several clarifications help frame the standard accurately:

• ERR is vendor-neutral. Any platform that satisfies its requirements can meet the standard, regardless of vendor.
• ERR is an architectural standard, not a product category. It describes a design requirement, not something purchased off a shelf.
• ERR complements detection and response capabilities. It doesn’t replace endpoint protection, threat detection, or incident response. It ensures recovery survives when those defenses are bypassed.

The standard rests on three architectural requirements.

1. Management-plane isolation
   Protected backup copies shouldn’t be reachable through any standard console, application, or command-line interface, even when admin credentials are compromised. If the control path to protected copies doesn’t exist, it can’t be exploited. This is the most critical pillar, because the management plane is where attackers direct their efforts first.
2. Automated continuous protection
   Recovery points should be created automatically, at least hourly, without requiring human action. SACR sets hourly automated copies as the minimum baseline. The rationale is straightforward: manual processes are least reliable at the worst possible time, when systems are disrupted, teams are stretched, and the margin for error is smallest.
3. Ephemeral compute continuity
   If primary infrastructure is destroyed or compromised, there needs to be a separate, temporary environment from which operations can continue while systems are rebuilt. SACR identifies 30 days as a reasonable baseline recovery window. This pillar addresses the operational question that most recovery plans defer: where does the business actually run during reconstruction?

Cloud-native platforms are well-suited to this model. Cove Data Protection™, for instance, stores its protected copies in an environment logically severed from the standard management console, so no automated path exists for a credentialed attacker to locate or modify them. Paired with automated hourly protection and cloud-based disaster recovery for ephemeral compute continuity, it illustrates how these pillars translate into practice. That said, all platforms should be assessed directly against the ERR requirements, not assumed to meet them.

Five questions to apply to your own posture

These questions are designed to move evaluation from marketing language to verifiable architectural design. They apply equally in initial procurement, annual disaster recovery reviews, and post-incident assessments.

1. Could an attacker with full administrative credentials delete or modify your backup copies? If the answer is yes, or if a vendor can’t demonstrate otherwise with architectural specificity, the management-plane test has failed.
2. Are recovery points created automatically, and how frequently? Hourly automated copies represent the baseline. Manual processes introduce failure risk at precisely the moment reliability matters most.
3. If primary infrastructure were completely unavailable, where would your organization operate? Restoring to infrastructure that’s already been destroyed or compromised isn’t a recovery strategy.
4. Can you confirm a recovery point is free of attacker persistence before restoring it? Restoring a compromised image doesn’t end an incident; it restarts one.
5. What service level governs continuity duration if primary systems are offline? Thirty days is a reasonable minimum. Regulated environments may require longer windows and more granular recovery time commitments.

Any vendor or internal team that can’t answer these questions with architectural specificity rather than policy language warrants closer scrutiny before being trusted with recovery-critical infrastructure.

Where to go from here

The foundational guidance, « maintain backups, » hasn’t become wrong. It’s become insufficient. The more meaningful question is whether recovery would hold up if an attacker already had admin access to the systems that control your backups. That’s increasingly the question regulators, cyber insurance underwriters, and CISOs are posing, and organizations that can’t answer it clearly carry measurable exposure.

SACR’s full report goes considerably deeper: the complete attack lifecycle, a technical breakdown of where established recovery architectures fall short under adversarial conditions, and an assessment of how ERR-aligned design performs in practice. Whether your organization is preparing for a compliance review, an insurance renewal, or a substantive evaluation of its own recovery posture, the report provides a structured framework for that analysis.