Why Backup Systems Were Left Out of Zero Trust

When security teams started implementing zero-trust frameworks five years ago, they focused on users, endpoints, networks, and identities. Backup systems stayed out of scope.

That exclusion wasn’t accidental. It was structural.

We’ve spent years analyzing backup infrastructure and have noticed that it has consistently been treated as operational plumbing rather than critical security infrastructure. The answer isn’t technical complexity. It’s a mental model problem that created a blind spot in how organizations thought about trust boundaries.

The Mental Model That Created the Blind Spot

Early zero-trust programs framed the problem around users accessing applications and data. Designs focused on identity verification, endpoint security, and microsegmentation in front of business services.

Backup systems didn’t fit that narrative cleanly.

There were no obvious end users. Just scheduled jobs running in the background. Infrastructure or storage teams managed them, not security. Organizations treated backup as out-of-band utilities instead of Tier-0 assets that touched every critical workload.

That separation meant backup rarely appeared in initial zero-trust reference architectures or vendor messaging. The omission reinforced the idea that backup was an operational concern rather than part of the trust boundary.

The perimeter mindset lingered longest around backup. Organizations assumed that because backup servers sat deep inside the data center or VPC, behind firewalls, they were implicitly trusted and didn’t need the same “never trust, always verify” rigor applied elsewhere.

If production was protected, backup inside that perimeter was considered safe by association.

Ransomware actors exploited exactly that assumption. They went after backup consoles and repositories as under-protected admin surfaces. Only once breach reports started showing backup compromise as a frequent factor did backup begin appearing in zero-trust discussions.

The Technical Incompatibility Nobody Wanted to Admit

Even if security teams had wanted to apply zero-trust principles to backup, traditional architectures made it technically awkward.

Traditional backup was built around the idea that backups “need to touch everything.” That design concentrated enormous, persistent power in a small set of accounts. The default was one or two all-powerful service identities that could read, write, and often delete every workload they protected, across zones and tenants.

Backup engines typically ran under a single service account with broad OS, database, and hypervisor rights.

Local admin. Domain admin. Full database privileges. Root-equivalent on Linux. Full cloud IAM roles. Because that account had to authenticate to many different systems and APIs, organizations granted “whatever is needed everywhere” once, instead of scoping per workload or operation.

The same identity often performed all actions—discovery, backup, restore, retention changes, and sometimes deletion of backup sets. There was no clean separation between “read for protection” and “write/delete for administration.”

That collapses least privilege into “this one principal can do everything, always.”

Inside backup consoles, traditional role models were coarse. “Backup Admin” with full control. Maybe an “Operator” who could run jobs. Little or no tenant, environment, or object-level scoping. Admin roles routinely spanned on-premises, cloud, and SaaS connectors in the same UI.

One compromise granted broad authority across all protected data, violating any notion of compartmentalization.

Backup service accounts and admin credentials were usually long-lived, shared, and heavily exempted from normal hardening. Password rotations. Conditional access. Just-in-time elevation. Organizations avoided these controls because “we can’t risk breaking backups.”

Scheduled jobs needed to run unattended, so organizations stored high-privilege credentials in the backup system or OS key stores and then avoided changing them.

That persistent, always-on trust relationship to every critical asset is the opposite of least privilege’s “just enough, just in time.”

Once those credentials exist, they effectively become a standing golden ticket for any attacker who can extract or reuse them.

What Changed: The SaaS Backup Architecture Shift

Modern SaaS backup platforms separated “who can see data” from “who can control the system” by moving to a dual-plane, identity-aware architecture that legacy on-premises backup didn’t have the primitives for.

Control plane versus data plane.

That structural split lets an operator or policy engine orchestrate backup and recovery without ever holding the same entitlements as the app identity that reads or writes tenant data.

In classic on-premises backup appliances and software, three things were fused. Identity: admins authenticated via the same directory that governed access to storage, hypervisors, and apps. Control surface: the service that scheduled jobs, defined retention, and managed repositories typically ran in the same trust boundary and process space as the workers that mounted volumes and read production data. Storage layer: catalog, configuration, and backup repositories were usually co-located on the same infrastructure stack.

Because those layers lived inside one environment and one IAM model, the easiest path was a powerful service account that could both enumerate data sources and reconfigure or delete repositories.

SaaS backup platforms emerged in an ecosystem where multitenancy and zero trust were baseline assumptions.

Modern SaaS architectures define a control plane (tenant metadata, policies, orchestration APIs) separate from a data plane where connectors and agents actually move bits. Control-plane services never need direct access to raw customer content. They deal in descriptors, tokens, and job state.

Instead of reusing the same monolithic admin account, SaaS backup integrates with cloud identity providers and SaaS provider scopes. That allows narrowly scoped app identities for data-plane operations and distinct identities and roles for tenant admins and operators.

Multi-tenant SaaS forced clear API boundaries and per-tenant isolation for configuration, telemetry, and data movement. That fits naturally with least-privilege RBAC and separate privilege tiers for “view data,” “configure policy,” and “operate the platform.”

The microservice that queues a restore request doesn’t itself hold the long-lived token that can read from Google Workspace or Microsoft 365. It only instructs a data-plane worker that runs under a scoped identity.

The Threat Pattern That Forced the Conversation

The shift in mindset lagged the architecture by several years. Organizations really started treating backup as an active attack surface once ransomware operators began systematically destroying or encrypting backups first.

That pattern started showing up repeatedly in public guidance and breach analyses around the mid-to-late 2010s. It spiked again as double-extortion campaigns matured in the early 2020s.

Backup moved from “last line of defense” to “first target in the late phase of an attack.”

Boards and CISOs started explicitly asking whether backup infrastructure itself was isolated, monitored, and hardened like any other critical system.

Two recurring attacker behaviors forced the mental shift. Kill the backups before pulling the trigger: ransomware playbooks began to include a distinct late phase focused on discovering, disabling, or corrupting backup and recovery mechanisms so victims had no clean path to restoration. Attackers used stolen credentials and lateral movement to reach backup servers and storage, then deleted snapshots, disabled services, or encrypted repositories.

Turn backup into a data-theft point: as double-extortion became standard, backup and storage systems became attractive for exfiltration because they aggregate large volumes of sensitive data in one place, often with weaker monitoring than production.

The data tells the story. 94% of organizations hit by ransomware said cybercriminals attempted to compromise their backups during the attack. 57% of those attempts were successful.

Organizations whose backups were compromised paid a median ransom of $2 million (almost double the $1.062 million paid by those whose backups remained intact). Overall recovery costs were eight times higher: $3 million versus $375,000.

Once incident reports started describing backup compromise as a deliberate stage in the kill chain rather than collateral damage, security leaders stopped treating backup as passive insurance. They started treating it like any other privileged system.

Why Fragmented Tools Can’t Deliver Zero-Trust Backup

When organizations realized their backup infrastructure was compromised, most tried to “harden what they had” first. They retrofitted zero-trust ideas onto their existing backup stack.

Security guidance emphasized isolating backup networks, tightening admin access, enabling MFA, and adding monitoring around privileged actions. All on top of the same products. Organizations layered immutable storage, air-gapped copies, and longer retention onto their existing systems.

That fit better with short-term budget and change-control constraints, even if it didn’t fix underlying architectural coupling.

Fragmented point solutions fail because none of them owns the graph that connects “who can do what, where, and with which data.”

They can only show local health. Not whether your backup architecture is actually resilient as a system.

Continuous posture monitoring and least-privilege enforcement are system-level properties. Stitching together siloed views from backup tools, IAM tools, and security tools almost always leaves blind spots in between.

Each backup or monitoring product reports within its own schema (jobs, repositories, alerts). There’s no normalized model that correlates jobs, identities, tenants, and storage across vendors. Without that, you can’t reliably answer “Which identities can delete or corrupt this set of backups, across all systems?” or “Which business apps have no clean, recent, immutable copy?”

You just get tool-by-tool status.

Least privilege is about potential blast radius. Which paths let an attacker move from a compromised identity to backup control and then to data destruction. Point tools see only their slice (IAM misconfigurations or backup failures). Not the composed path across identity, network, SaaS APIs, and backup consoles.

Backup products can show job success. IAM tools can show who has access. EDR and SIEM can show suspicious activity. But there’s no authoritative layer that evaluates “Are my RPO and RTO objectives and ransomware-resilience requirements actually being met right now?”

In practice, teams end up exporting CSVs and building spreadsheets or custom scripts. Those are brittle, lagging, and rarely maintained. “Continuous” posture monitoring degenerates into periodic spot checks.

How Success Metrics Changed

Early adopters kept RPO and RTO, but they stopped treating them as the only success criteria. The measurement framework expanded to “how quickly can we detect, contain, and restore from clean backups with bounded blast radius.”

They moved from backup SLAs to cyber-resilience SLAs that explicitly assume active attacks on the backup layer.

RPO and RTO are still core because business impact is still about data loss and downtime. But they’re now measured under attack assumptions. “RTO for SaaS ransomware incident with isolated restore” instead of just “RTO for a storage failure.”

Early zero-trust backup programs added metrics that RPO and RTO alone can’t capture.

Immutability and integrity coverage: percentage of critical workloads with immutable, air-gapped, or independently segmented backup copies, and how often those copies are integrity-checked. Time to detect tampering or deletion attempts against backup data.

Identity and blast-radius metrics: number of identities with privileges that span both production and backup control planes, and trend over time as least-privilege is enforced. Maximum blast radius of a single admin or token.

Detection and recovery quality: mean time to detect ransomware or malicious activity affecting protected data, including detection in backup snapshots themselves. Percentage of recovery tests that successfully restore from verified clean recovery points.

Unified, zero-trust-oriented backup platforms gave early adopters two capabilities that directly shifted metrics. Continuous, policy-based posture scoring: platforms started exposing posture scores for backup environments tied back to policy. Success became “percentage of crown-jewel applications meeting zero-trust backup policies continuously.”

Recovery outcomes as primary KPIs: instead of reporting “99% job success,” early adopters reported “time to safe recovery” for realistic ransomware scenarios and two-hour SaaS ransomware recovery targets as top-level objectives.

The Next Blind Spot: Zero-Trust Recovery

The next structural assumption to break is that “if my backups are immutable and my blast radius is small, I can safely restore whatever is in them.”

In three years, the uncomfortable realization will be that the real risk is restoring the compromise itself from “protected” copies that have been quietly poisoned over time.

Today’s zero-trust backup programs still largely assume clean equals immutable plus isolated. The working belief is that if copies are immutable, vaulted, and access is tightly constrained, then those copies are trustworthy enough to restore at scale.

But long-dwell ransomware, supply-chain malware, and insider abuse can persist for weeks or months before detonation.

Many “good” restore points can already contain staged implants or exfiltrated data paths. Attacker dwell time averages 11 days according to Sophos and 24 days according to Mandiant. Immutable backups faithfully preserve compromised data during this entire window.

Current resilience metrics focus on how fast critical services come back. Not on whether what comes back is forensically clean and free of the original foothold. That creates a blind spot where organizations proudly hit aggressive recovery SLAs while quietly re-introducing the adversary into the environment.

A backup is “provably clean” when the platform can show, with evidence, that the restore point sits on a known-good lineage and passes ongoing behavioral and threat checks. Not just that it’s immutable.

That requires an architecture that combines multi-version scanning, lineage tracking, and anomaly baselines over time. Not just one-off malware scans at restore.

Trust is earned over time, not at restore. Backups are continuously evaluated as they’re created and as new threat intel appears. A point can move from “unknown” to “suspect” to “known-good” or be revoked as clean. Lineage matters as much as contents. The system tracks how each backup relates to previous versions, when suspicious behavior began, and which identities and processes touched the data and policies along the way.

What to Do About It

When boards and CISOs ask “Is our backup architecture resilient?”, the first diagnostic question should be: “When was the last time you proved, end-to-end, that you can recover a crown-jewel system from a clean backup within your stated RTO, and who saw the results?”

If the answer is vague, untested, or buried in IT detail, you’re assuming resilience rather than observing it.

Boards and CISOs often hear “we have backups” and “we follow 3-2-1” as assurances. But resilience is about demonstrated, time-bound recovery. Not configuration claims. Asking for a recent, observed recovery test exposes whether backup posture is monitored as a business outcome or just as an IT checkbox.

Organizations that can’t answer that question need to treat backup architecture as a security design problem, not a storage feature.

The work isn’t about ripping out existing investments. It’s about recognizing that immutability solved destruction, not tainted content. The next layer is verification architecture that treats backups as part of a living graph (version history, identities, detections, and runtime behavior), all of which must align before a backup earns the label provably clean.

Zero-trust backup isn’t a separate category. It’s proof that backup, posture management, and access control must integrate. Fragmented point solutions can improve local hygiene, but they won’t deliver the systemic, identity-to-recovery visibility you need to claim the architecture is resilient.

Start by mapping which identities can delete or corrupt your backups across all systems. Measure immutability coverage for crown-jewel applications. Track identity blast radius as you enforce least-privilege. Test recovery from verified clean restore points under realistic ransomware scenarios.

If those metrics aren’t on your dashboard yet, you’re still running traditional backup with better controls. You’re not running zero-trust backup.

Treat backup infrastructure like any other critical security system. Isolated. Monitored. Hardened. With unified visibility across backup operations, access patterns, and security posture. That’s where consolidation becomes operationally necessary, not just architecturally elegant.

The organizations that figure this out now will measure recovery time in hours when the next incident hits. The ones that don’t will measure it in weeks, if they can recover at all.

References

1. Sophos. (2024). The Impact of Compromised Backups on Ransomware Outcomes.

Was this helpful?

Yes No