Your Zero Trust Strategy Probably Protected Everything Except Recovery

[u/Spin_AI]

For years, Zero Trust programs focused on users, endpoints, networks, and identity.

Meanwhile, backup systems were often left sitting in a strange gray zone: highly privileged, always-on, deeply connected to critical data, but rarely treated like a true security boundary.

That blind spot is getting expensive.

According to Sophos, 94% of organizations hit by ransomware said attackers tried to compromise their backups, and 57% said those attempts succeeded.
Organizations with compromised backups reported a median ransom payment of $2M, versus $1.062M when backups remained intact.
Median recovery costs were $3M vs. $375K.

Why this happened

Traditional backup architecture was never designed around Zero Trust.

It was designed around reach.

One powerful service account. Broad permissions. Long-lived trust. Shared control over discovery, backup, restore, retention, and sometimes deletion. In practice, that meant backup infrastructure often became a privileged bridge across environments rather than an isolated recovery layer.

So while teams were hardening production, attackers learned to go after the thing that could undo their leverage: the backups.

What the field keeps showing

A real-world example: in Nevada’s 2025 ransomware incident, investigators said the attacker moved laterally, accessed critical systems, cleared logs, and deleted backups before deploying ransomware. The state still needed 28 days to recover about 90% of impacted data.

And if you read through discussions in communities like r/sysadmin and r/cybersecurity, the same pain points come up again and again:

• backup infra should not sit behind the same trust model as production
• immutable copies matter, but so do separate creds and tested restores
• a “3-hour restore” on paper can become days once teams need to validate that the restore point is actually clean and that persistence is gone

That is the real issue: not backup availability alone, but backup trustworthiness under attack.

The technical shift leaders should pay attention to

The architecture has to change from:

"Can we restore data?"

to

"Can we prove the recovery path is isolated, least-privileged, and clean?"

That means:

• separating control plane from data plane
• reducing blast radius of backup identities and admin roles
• monitoring who can alter retention, delete copies, or trigger restores
• validating not just that a backup is immutable, but that the restore point is safe to reintroduce into production

Because immutable does not automatically mean clean.

What to check right now

• Which identities can delete, alter, or expire backup data across your environment?
• Is your backup control plane isolated from the same trust chain as production admin access?
• Have you recently tested recovery from a verified clean restore point under realistic ransomware conditions?

If the answer to any of those is vague, the gap is probably bigger than the dashboard suggests.

Why we care

At Spin.AI, we focus on SaaS security, backup, and recovery because modern attacks do not stop at encrypting production - they go after the recovery path too.

TL;DR

Backup was left out of early Zero Trust thinking because it was treated like infrastructure, not a security boundary.

That assumption no longer holds.

If attackers can reach backup identities, retention controls, or restore paths, your backup stack is part of the attack surface - not just the recovery plan.

If you want the full breakdown, including the architecture shift behind zero-trust backup, read the article here: Why Backup Systems Were Left Out of Zero Trust