A Backup System Is Not Outside the Blast Radius

“If production is compromised, the backups are our way back.”

Let me stop you there, before that sentence goes into the incident response plan as the recovery strategy.

A backup system is not outside the blast radius.

It is a system.

It has administrators, credentials, a management console and a database of its own.

It is reachable from somewhere.

And it holds a login for every server, database and hypervisor it copies, because that is how it copies them.

The sentence above quietly assumes the attacker stops at production.

Why would they?

Nobody says “the burglar took the jewellery, but the spare keys in the kitchen drawer are safe because they are spare.”

Say the same about a backup server and it becomes a recovery plan.

The durable claim is short.

A copy reachable through the same credentials or control plane as production is not an independent fallback.

It is the same trust boundary rendered twice.

Everything below is the evidence, and it is dated.

1. “But the Backups Are on Separate Storage.”

Good.

Separate storage protects you from a disk failure, a corrupted volume or a deleted directory.

It does not protect you from somebody who holds the credentials that administer both.

Code Spaces is the clean case, because it involves no ransomware at all.

In June 2014 an attacker got into the company’s AWS management console.

From there they deleted customer repositories.

Then machine configurations.

Then the company’s own backups.

The backups lived in the same AWS account, under the same credentials, as the production systems they were meant to protect.

Code Spaces closed permanently within hours.

Notice what the backups were not separate from.

Whatever they were stored on, they sat behind the same console and the same credentials as the production systems.

One login reached both.

Storage separation is a location. Independence is an administrative boundary.

You can put the copy in another bucket, another region, another storage class.

If one console session can reach both, the attacker needs one console session.

The question is not “where does the copy live?”

The question is “what credential deletes it, and who holds that credential today?”

2. “But the Backup Software Is Patched and Supported.”

Also good.

Keep it that way.

But look at what you are patching.

Backup software has to authenticate to everything it protects.

So it stores usernames and passwords for your servers, your databases, your hypervisors.

It is, functionally, a credential store with a scheduler attached.

Akira and Fog, two ransomware operations, made that concrete in 2023 and 2024.

Both exploited CVE-2023-27532 in Veeam Backup & Replication.

The flaw let them run SQL queries directly against the product’s own configuration database.

Out came every credential the backup software held for the infrastructure it protected.

That is the moment “we have backups” becomes “the attacker has a valid login for our backups, and for everything else.”

A patch closes one path into that database.

It does not change what the database contains.

The next flaw, the phished administrator, the reused service password, all arrive at the same key ring.

This is the same shape as the database service account nobody scopes, because scoping it takes engineering time and a broad grant never blocks a deploy.

The backup platform is that service account, multiplied by every system in its job list.

Patched is a state. Tier zero is a classification.

A system holding credentials for the whole estate belongs with the domain controllers and the identity provider, not with the file shares.

Monitor it like one.

Restrict who logs into it like one.

Assume someone will try.

3. “But Every Backup Job Reports Success.”

It does.

Now read what the green tick is certifying.

A job that reports success has confirmed a write finished without an error code.

That is all.

It has not confirmed the data is readable.

It has not confirmed the copy restores.

And it has certainly not confirmed that nobody else can delete it.

GitLab’s January 2017 outage showed how quiet the failure side can be: its backup failure emails were being silently rejected by the mail server for months.

That was an accident.

Now picture the same silence with intent behind it.

The job status comes from the backup platform.

The backup platform is the system under attack.

A dashboard of green ticks tells you what the scheduler did last night.

It tells you nothing about the retention setting someone shortened this afternoon, the restore points someone expired, or the bulk read that pulled a copy of every database out through the backup channel.

Those events are what an attacker working on your backups actually generates.

Success status measures the job. It does not measure the boundary.

If nothing alerts on deletions, retention changes and unusual reads inside the backup system, then the first person to notice the backups are gone will be the one trying to restore from them.

4. “But We Keep Years of Backups, So Something Will Survive.”

Years of backups under one credential are one target.

Not many.

Retention depth protects you against time: a compromise discovered late, a corruption that crept in slowly, bit rot on a copy written once and never read again.

It does nothing against an attacker who can reach the retention store.

Code Spaces did not lose its newest backup.

It lost its backups.

The economics push you toward exactly this.

Backblaze’s B2 object storage, at the low end of the cold-storage market, prices at $6.95 per terabyte per month.

Under a cent per gigabyte-month.

At that price an extra year of copies is a rounding error.

So the default is to keep more copies, for longer, in more places, than any minimisation policy would ask for.

Every one of those copies is another instance of your data that needs its own access controls.

Not just another line on the storage bill.

And the team that owns them often is not the team that secures the data.

Backups frequently belong to a storage or infrastructure group running scheduled snapshots and retention policies.

Sometimes nobody on the database side can see where a given backup landed once it left the primary.

That team’s goal is recoverability inside a retention window and a recovery-time objective.

Confidentiality is not in the job description.

So you get the combination attackers like best.

Complete data.

Long history.

An owner measured on something else.

Retention policy looks like a cost decision.

It is a security decision wearing a cost decision’s clothing.

5. “But Attackers Are After Production Data, Not Backups.”

This one has numbers.

Sophos’s 2025 survey covered 2,158 organizations hit by ransomware.

Attackers tried to compromise the backups in 94% of cases.

They succeeded in 57% of those attempts.

Work that through and it is roughly half of all victims: 0.94 × 0.57 ≈ 0.54, so about 54% of the organizations surveyed lost their backups to the attacker.

Success reached 79% in energy, oil, gas and utilities, and 71% in education.

Then the outcomes split.

Where backups were compromised, production data was actually encrypted 85% of the time.

Where backups survived, 52%.

Median recovery cost: $3 million with compromised backups, $375,000 without.

That is a factor of eight: $375,000 × 8 = $3,000,000.

The ransom payment rate went from 36% to 67%.

Read those together.

Losing the fallback and losing production are not two independent risks you can multiply.

They move together, because the privileged access that reaches the backup system usually reaches production too.

And the backup is not a side dish for the attacker.

It is the thing that decides whether you can decline to pay.

The 2017 wave against open MongoDB instances made that leverage visible without any sophistication: attackers connected to unauthenticated databases, wiped or took the contents, and left a ransom note.

More than 10,000 databases were hit within weeks.

The leverage was the bet that the victim had no other copy.

Modern operators simply do the same arithmetic before encrypting anything.

Attackers are after whatever stands between them and payment. Your backups are the main thing that does.

6. “But Maersk Recovered From NotPetya.”

It did.

Look at how.

Maersk reinstalled more than 4,000 servers, 45,000 PCs and 2,500 applications in ten days.

Remarkable work.

And it depended on a single domain controller in Ghana.

That controller survived because it was offline when the malware spread.

A power cut had disconnected it.

That was the air gap.

Nobody designed it.

Nobody could have scheduled it.

The recovery is a measurement of what Maersk’s actual recovery capability was on the day, as opposed to what any plan said it was, and the answer was that it hinged on an outage in one office.

Citing Maersk as proof that backups get you back is citing a lottery win as a pension plan.

The broader picture is less cinematic.

Only 16% of ransomware victims recover within one day.

More than half take a week or longer.

That is an aggregate across many incident types, not a target.

It is still a better baseline for your own planning than the one global shipper whose identity system was saved by the electricity going off.

If your fallback survives only because it happened to be unreachable, you did not have a fallback. You had luck.

7. No, This Does Not Mean Backups Are Futile.

They are not.

They are among the most valuable controls you have.

The same survey that shows how often they are attacked shows what they are worth when they survive.

$375,000 median recovery cost instead of $3 million.

A 36% payment rate instead of 67%.

Production encrypted in 52% of cases instead of 85%.

Attackers do not spend effort on things that do not matter.

They go after the backups precisely because the backups work.

So the conclusion is not “backups fail, give up.”

It is that the fallback has to be separated from the credentials and control plane of what it protects on purpose.

Not by accident.

Not because a power cut in Ghana happened to pick the right afternoon.

A backup that shares production’s administrators, production’s console and production’s identity plane is a second copy of the data inside the first copy’s trust boundary.

A backup that does not share them is a fallback.

The difference is not the storage.

It is who can reach it.

8. What You Should Actually Do

Put the backups in a separate account or tenant. The credentials that administer it are ones your production administrators do not hold.

If one person, one role or one console session can delete production and the backups, write that down as a finding, not an architecture.

Treat the backup platform as tier zero. It stores credentials for everything it protects.

Patch it on the same urgency as your identity provider.

Restrict interactive logins to a short, named list.

Monitor it as a target, not as plumbing.

Alert on the events that attacks on backups produce. Deletions, expired restore points, retention changes, new administrators, and bulk reads out of the backup system.

A nightly success report is not a detection control.

Set retention by need, not by storage price. Cheap storage makes keeping everything the default.

Decide how far back you actually need to restore, keep that, and apply access controls to every copy you retain, including replicas and exported snapshots.

Give the backup system a security owner. The team measured on recoverability is not automatically the team measured on confidentiality.

Name who is responsible for access to the backups, not just for their completion.

Rehearse restores with the people who will run them. NIST SP 800-34 separates testing, which validates capability, from training and exercises, which validate personnel readiness, and its sample policy calls for testing recovery capabilities and personnel at least annually.

Uptime Institute estimates, from 25 years of outage data, that human error contributes to between two-thirds and four-fifths of downtime incidents.

In its 2024 survey, 48% of respondents named staff not following an agreed procedure and 45% named incorrect or inadequate procedures.

So run the restore with the on-call team following the written procedure, with production credentials assumed unavailable.

If the procedure needs them, you have found the shared boundary before the attacker did.

9. The Model Is Not Complicated.

Production is what the attacker reaches first.

The backup system is a system, with its own credentials, console and database.

It holds the data and the logins for everything it protects.

If it shares production’s credentials or control plane, it is inside production’s blast radius.

Operators know that, and they go after it in almost every attack.

A backup is a fallback only when reaching production does not also reach it.

Separate the account.

Classify the platform as tier zero.

Alert on deletion and retention changes.

Retain by need.

Give it a security owner.

Rehearse the restore with the people and the procedure, not only the storage.

Those are not extra controls on top of having backups.

They are what makes the backups sit outside the load path of the attack.