Why Zero Trust Breaks Down at the Backup Layer

Zero Trust’s Promise and the Blind Spot

Overview of modern zero‑trust architectures and their focus on users, devices and networks

There is a reason why zero-trust is the current security paradigm for business security. By relying on the “never trust, always verify” mentality, it removes the implicit trust associated with being “inside the perimeter” – with perimeter being the older security approach that implied legitimacy for everything inside the network.

Zero trust approach uses context-aware, continuous authentication of all users, devices and requests. It was designed to mitigate the most prevalent attack vectors – compromised credentials, lateral movement, and over-privileged accounts-all of which can be realistically reduced with zero trust deployment.

How backup systems became a privileged blind spot in zero‑trust deployments

The problem here is that zero-trust environments are typically designed around the production environment. When organisations document the edges of their trust perimeter – they consider user access to applications, communication paths between services and various devices within the network.

The backup infrastructure is largely absent from that mental model – even though it typically runs its own set of service accounts with authority on dozens (if not hundreds) of systems, running entirely under its own schedules, with its own infrastructure. Additionally, backup models are rarely included in the same threat-modelling exercises as the rest of the stack.

The result is a class of systems that are highly privileged, widely connected, and also relatively under-monitored – working in the shadow of a rigorous security posture.

Why Backups Are the New Crown Jewels

Modern ransomware tactics that specifically target backup repositories

Ransomware groups knew the worth of backup repositories far sooner than many security teams did. Initial ransomware simply encrypted production data and then asked for money; backups were the perfect response for such tactics.

Then, attackers adapted. Many modern-day ransomware playbooks include phases of reconnaissance that enable the attacker to discover backup infrastructure before deploying the encryption payload – to destroy, delete, exfiltrate backup repositories, or use them for ransom.

It’s not uncommon for all the recovery options to be completely paralyzed by the time the modern ransomware payload hits the production servers.

The “Golden Rule”: backups are only valuable when they can be restored

A non-recoverable backup is not a backup, it’s an empty promise of one. Backup data that has been encrypted by ransomware, deleted by an attacker, or silently corrupted can no longer offer any path to recovery. Organizations often discover this at the worst possible time – such as during or after a cyberattack.

Backup value is measured not by how much space or how many backup sessions there are, but by its recoverably. This is why there is a necessity to check the integrity of a backup on a regular basis using conditions that are close to a real recovery scenario.

Regulatory pressures (DORA, GDPR, HIPAA and others) driving backup independence

Backup and recovery are becoming more clearly defined in regulatory frameworks as time goes on.

For example, DORA (Digital Operational Resilience Act) requires financial entities to be capable of achieving operational resilience, including recovery from critical failures, with specific testing requirements.

GDPR’s (General Data Protection Regulation) requirement to have data integrity and availability also apply to backed up data copies.

HIPAA (Health Insurance Portability and Accountability Act) requires covered entities to have retrievable identical copies of the protected health information in electronic form.

What these frameworks have in common is that backups must be provably independent of the production systems they are intended to recover. A backup is not of much use if it can be deleted by the same threat that deletes the production data.

How Traditional Backup Architectures Defy Zero Trust

Centralized service accounts and broad backup privileges

Traditional backup architectures were built for coverage and operability first, not for strict least-privilege design. In many environments, backup platforms end up holding a collection of broad privileges: local administrator rights on selected Windows systems, root or sudo on some Unix hosts, hypervisor snapshot permissions, database backup roles, cloud API access, and access to backup catalogs and repositories.

That does not always mean one single account with universal domain-admin-equivalent power. The risk is the aggregate effect. If the backup control plane, credential store, or a highly privileged backup administrator account is compromised, an attacker may gain broad read access across many systems and the ability to sabotage recovery at the same time.

Coarse role models and shared credentials in legacy systems

Legacy backup platforms are much older than any modern identity or access management framework. Most role models in such environments are coarse – administrator, operator, read-only viewer – without the ability to stop one team from viewing another team’s data, or without being able to restrict a backup operator to a specific set of environments.

The issue of shared credentials makes this situation even more complicated: a single backup operator account’s password can be known to multiple administrators, password rotation is difficult, auditing is minimal, and the potential damage radius of a single credential compromise is massive.

Technical incompatibilities of on‑premises backup architectures

Traditional on-premises backup architecture inherently includes networking protocols and patterns that oppose core zero-trust concepts:

• open network access
• flat backup segments
• agent-based architecture that predate modern authentication protocols

While some elements like air gapping, immutability and segmentation can be applied to these systems to a certain degree, the legacy systems still have a number of foundational design principles that make full zero-trust extension to the backup tier highly problematic.

Threat Patterns Exploiting Backup Blind Spots

Ransomware playbooks: killing the backups before encrypting production data

Sequencing matters. Competent ransomware operators plan an extensive reconnaissance phase (sometimes measured in multiple weeks) prior to initiating the main encryption payload. In this time frame, they map out the environment, locate backup systems, compromise the credentials needed to access them, and then attempt to delete or corrupt these backup repositories.

The visible attack is only launched when the victim is left with no recourse of recovery. Focusing on backups first is now a standard practice for most sophisticated ransomware operators, not a rarity – an organization that retains its backups has significantly more negotiating power than the one that does not have them.

Data theft and double‑extortion through compromised backup repositories

There is a lesser-known reason as to why backups are a key attack target now: they contain structured and aggregated replicas of data from across the organisation, whereas production data is often dispersed across databases, file shares, and applications.

Double extortion attacks (encrypting production data and threatening to release exfiltrated data) routinely utilize the backup repositories as the exfiltration target. This is how backups, intended as a safety net, become the most efficient path to sensitive data.

Insider threats and credential compromise in backup environments

Backup systems provide an excellent target for insiders due to the privileges they need to have. A legitimate backup operator has read access to significant amounts of organisational data, usually with poor audit trails that are insufficient to alert abnormal actions.

Backup credentials then compound this issue: they often have a long lifespan, are rarely rotated, and known to multiple people once shared – making them an enticing prize to any intruder who already has a foothold in the environment.

Principles of Zero‑Trust Backup

Least‑privilege design and separate identities for backup operations

Applying least-privilege principle to backup means disaggregating the single, over-privileged backup service account into different identities with dedicated purposes. A backup write identity should have permission to initiate backups and write to a repository; it should have no option to delete a repository, change its retention policies, or restore from a repository. A restore identity needs to be system and time-bound, and management of backup configurations needs to be segregated from both write and restore operations.

This level of granularity requires platforms that actually have models for fine-grained identity – but not all of them do, so the choice of platform itself becomes a meaningful security consideration.

Multi‑factor authentication and granular role‑based access control

Multi-factor authentication should be mandatory for human administrative access to the backup platform: the web interface, privileged consoles, APIs, and any remote administrative path into the backup environment.

Non-human identities should be treated differently. Service accounts and machine credentials usually cannot use MFA in the same way as human users, so they should instead be protected through vaulting, strict scoping, host-based restrictions, short-lived secrets where possible, and scheduled rotation.

Granular role-based access control should then limit who can delete backup data, change retention, modify storage targets, or run restores, with permissions scoped to defined clients, jobs, pools, or restore destinations rather than granted globally.

End‑to‑end encryption and immutable storage for backup data

Backup data should be encrypted in transit and at rest, with encryption keys managed independently from the backup infrastructure. An attacker who compromises the backup server should not also inherit the ability to decrypt its contents.

Immutable storage (i.e., object lock on cloud storage, write-once media, hardware immutability) provides write-once storage for a specific duration of time, meaning that the backup data can neither be altered nor deleted. It’s one of the more dependable technical controls available to prevent ransomware attacks from successfully targeting backup storage, as it limits the actions that the attacker can perform (even if they obtain valid credentials).

Air‑gapped and geographically distributed copies

Air-gapping isolates one or more backups from a network-reachable path, whether through tape rotation, physically removing media from a machine, or using specific air-gap appliances. The air-gapped copy is immune to network-born threats, including any that were executed through a compromised backup service account. The geographically separate storage provides resilience to physical phenomena that could affect the primary and secondary storage concurrently, and, together, the two controls create the core of the 3-2-1-1-0 model.

Automated monitoring and regular restore testing to prove recoverability

Backup infrastructure monitoring should include:

• anomalous access pattern detection
• confirmation of the integrity of the backup content
• alerting on job failures
• configuration and access policy changes

Regular restore testing should be scheduled based on data criticality, verifying not just that data can be read but that a full recovery to a functional state is achievable within the organisation’s recovery time objectives.

Modern Solutions and Architectures

SaaS backup platforms with control‑plane/data‑plane separation

Cloud-native and SaaS backup platforms increasingly separate the control plane from the data plane. The control plane handles policy, orchestration, scheduling, and administrator interaction, while the data plane handles storage and movement of protected data.

When that separation is real and technically enforced, compromise of one layer does not automatically imply compromise of the other. But it would be a mistake to imply that SaaS alone solves the problem. Isolation quality, tenant separation, key management, recovery design, and access controls still determine whether the architecture is meaningfully resilient.

Alternatively, attacks on the backup data would not grant access to the control plane. This way, the data plane can also be physically and logically separated from the production environment – something that’s very difficult to implement in a typical on-premise architecture.

Immutable and air‑gapped storage options for ransomware resilience

Cloud object storage that supports object lock (S3-compatible or similar) offers an inexpensive way of implementing immutability for organizations leveraging cloud or hybrid backup. Once data has been written and locked – it can’t be changed/deleted for the duration of its retention, be it by the backup software, the cloud provider’s console, or even compromised credentials (assuming the lock configuration supports this).

Vendor-managed air-gapped services, tapes, physical rotation to an offsite location, and isolated cloud accounts without access from production offer different levels of air-gapping. The choice toward a specific measure is made according to recovery time, budget and the threat model.

Zero‑access architectures that go beyond zero trust

In the most extreme case of zero trust backup, the backup vendor itself is unable to read or decrypt customer data stored on its premises. If end-to-end encryption where customers provide their own keys is used, and the architecture isolates the customer’s data from any customer-accessible environment on the vendor’s infrastructure – an attacker who compromises the backup provider’s facilities would not be able to get to the customer’s data.

This solution has significant customer implications; it’s the customer’s responsibility to secure the keys, or the data becomes irrecoverable. However, it also significantly narrows the trust surface area in a backup relationship.

AI‑driven monitoring, predictive analytics and automation in backup

Machine learning-based anomaly detection applied to backup telemetry can pick up signals that are not evident with rule-based monitoring. For example, slowly changing data volumes indicates slow exfiltration, changes in access patterns that precede a cyberattack, or a deviation from typical backup job behavior.

While any individual signal may not be definitive, it does bring potential problems to the forefront earlier than threshold-based alerts. For ransomware – where the dwell time can last for weeks prior to payload deployment – early notification is beneficial.

Automation speeds up the response time to backup-related incidents – such as quarantining affected backup jobs, performing integrity checks or escalating alerts – without the need to wait for human confirmation. For ransomware, given that the timeframe between initial access and full payload, faster automated response has a direct operational value.

Why Bacula Is Best Suited to Address the Backup Blind Spot

Bacula Enterprise is built with the architectural flexibility to support zero-trust-aligned backup design in any kind of environment where this is required. Its open-source foundation is auditable, its modular architecture supports granular deployment models, its granular access controls, multiple authentication options, support for immutable storage targets, and one of the industry’s largest feature sets around cybersecurity maps directly to the controls that matter most for backup security.

Secure, auditable architecture with strong encryption

Bacula’s open-source core means its codebase can be independently audited – a meaningful advantage in security-sensitive environments where trust in a vendor’s claims needs to be verifiable rather than assumed. The Director (which handles backup policy, and scheduling) the Storage Daemon (the backup media itself) and the File Daemon (that runs on the systems to be protected) all operate as individual processes and can be hardened independently.

Bacula separates orchestration, client-side processing, and storage handling across the Director, File Daemon, and Storage Daemon. In a standard backup flow, the Director authorizes the job, and the File Daemon then contacts the Storage Daemon to send data. That separation matters because policy control and data movement are distinct functions that can be isolated, hardened, and network-restricted independently.

To protect the data itself, all Bacula Enterprise traffic is protected by TLS PKI and can encrypt data at rest with AES-256. Encryption keys are handled separately from the backup environment.

Support for quantum-resistant cipher algorithms is also a standard feature now, which is becoming increasingly relevant as organizations retain sensitive data for long periods. Data protected with the ciphers that exist today could otherwise become non-resistant to quantum computing-based attacks in the future, which could break those ciphers. Together with the fact that Bacula Enterprise encrypts the data with symmetric keys and long keys (AES-256), which is known as a quantum-resistant technique, the level of protection becomes very high in these times of technological uncertainty.

Comprehensive immutability and air-gapped, multi-tier storage

Bacula supports immutability controls across all storage tiers: S3 object lock for cloud storage, WORM configurations for disk, and write-once media with physical offsite rotation for tape. This consistency is crucial if your infrastructure spans multiple storage technologies, as a gap in one tier can ruin your entire posture.

Bacula’s native storage architecture inherently supports multiple tiers: disk-to-disk-to-tape, cloud replication, isolated destinations for air-gap targets  – all of which enables organizations to take advantage of 3-2-1-1-0 within a single console.

Granular role‑based access control and multi‑factor authentication

Bacula Enterprise’s access control model provides the granularity that zero-trust backup needs. Roles can be scoped to specific clients, pools and job types, allowing organisations to implement least-privilege identities for different backup functions. MFA is supported for administrative access, and its administrative interfaces can be integrated into broader identity and access-control designs. This is a strong fit for least-privilege administration because it gives security teams practical ways to narrow the blast radius of a stolen administrative credential.

Monitoring, SIEM/SOAR integration and compliance reporting through BGuardian

BGuardian, Bacula’s integrated security and monitoring component, provides behavioural analytics and anomaly detection across backup operations. It generates structured logs suitable for ingestion into SIEM platforms and supports SOAR integration for automated response workflows – meaning backup telemetry can be treated as a first-class signal in the organisation’s broader security operations rather than managed in a separate console.

Built-in automated compliance reports can document backup coverage, retention compliance, restore test results and access control configurations – reducing the manual effort of demonstrating adherence to DORA, GDPR, HIPAA and similar frameworks.

Automation, response tools and AI readiness for backup security

Bacula’s scripting and API functions enable integration of backups with other security automation systems. Response actions – quarantining a backup job, triggering an integrity check, escalating an alert – can be automated based on BGuardian signals without waiting for manual intervention. Its architecture is also capable of further improvements driven by AI technologies with their subsequent maturity, such as predictive analysis for backup health or anomaly detection for backup data at scale.

Implementation Roadmap Using Bacula Enterprise

With the right platform in place, the remaining question is sequencing. The roadmap below outlines a practical path from assessing your current backup posture to a fully hardened, zero-trust-aligned deployment – covering identity, storage, access controls, monitoring and ongoing adaptation.

Assess current backup posture and classify critical data

Document current backup infrastructure: which systems are backed up, which accounts are used, what is the data storage location, and what security controls are in place. Prioritise data based on sensitivity and regulatory requirements and categorise accordingly – this dictates retention periods, RTOs, and protection level applied to each backup set.

Design separation and least‑privilege identities for backup operations

Map backup service accounts to the operations they actually need to perform, then build granular replacement identities for each function – as distinct write, restore, and administration identities. Establish which teams may perform which actions on which datasets, then design the Bacula role model to enforce the boundaries.

Configure encryption, immutability and air‑gapping across storage tiers

Enable TLS for all Bacula inter-component communication, and configure at-rest data encryption. Define immutability policies per storage tier – object lock duration for cloud-based, WORM configuration for disk, physical rotation schedule for tape. Identify air-gapped copy’s destination and ensure that it is truly isolated from network-accessible pathways.

Implement multi‑factor authentication and granular access policies

Implement MFA for administrative access into Bacula. Set up granular role-based access controls with a least-privilege model in mind, as per the definition above. Then review and rotate legacy service account credentials with a clear schedule to regularly change these credentials going forward.

Integrate monitoring, automate responses and schedule regular restore testing

Set up BGuardian alerts on abnormal backup activity, and create consistent routing for those events toward organizational SIEM and SOAR. Establish automated response playbooks on common types of likely events – abnormal access, unwanted deletion attempts, and job failures on critical systems. Develop a schedule to test restores based on criticality, maintain records of restore tests, and establish metrics against which abnormalities can be measured.

Continuously review and adapt backup security to emerging threats and regulations

Backup security is not a one-time configuration. Attackers are changing their methods, the regulations are changing, and even the data environments are changing over time. Create a regular review cycle for the backup security – conducted at least once a year and also every time there is a major change to either the environment or the applicable regulations.

Conclusion

The security bar raised by zero-trust programs is high, but backup infrastructure is still frequently treated as an exception to those rules. That is the blind spot attackers exploit. Backups concentrate data access, administrative control, and recovery capability in one layer, so weak controls there can undermine a much stronger production security posture.

Closing that gap means treating backup as a first-class security domain: least privilege, isolated administration, strong authentication for human operators, encrypted communications, immutable or offline recovery points, and regular restore testing. This includes using least-privilege access controls, ensuring recoverability, verifying immutability, and carefully observing the behavior of the backup systems – similar to how it’s done for the production environments.

Bacula Enterprise is designed with the architecture and detailed controls to support this design extremely well – pairing open and auditable technology with granular access controls, immutability, encryption, and monitoring that are expected from the zero-trust backup environment. Together with deployment practices through restricted administration, hardened storage targets, and disciplined operational controls zero-trust will be confidently extended to the backup infrastructure of any secure conscious organization.

Frequently Asked Questions

What is the difference between zero trust, zero access, and immutable backups?

Zero trust is a security model for verifying all access attempts constantly, irrespective of network origin; when it comes to backups, it ensures that the backup system is treated to the same level of identity verification, least privilege access and monitoring as everything else in the environment.

Zero access goes further than that – describing systems that ensure even the vendor providing the backup capability cannot view or decrypt customer data, simply because encryption keys reside solely with the customer.

Immutable backups are a very limited and specific measure made to prevent potential tampering with backup data during a specific time frame.

Can backups still be trusted if the production environment is already compromised?

Depends on the architecture. If the backup is stored on non-rewritable media, encrypted with an independent key, and logically or physically separated from the environment that’s being compromised – it would remain safe if the production environment goes down. If the backup requires the same credentials as production systems to access it – it might as well go down with the rest of the system, since its usefulness in that case is near zero.

The “independence” that allows for successful restoration is architectural – a data copy that’s accessible outside of the compromised environment is what makes recovery possible.

How do attackers typically discover and target backup systems?

Discovery usually occurs during the reconnaissance phase, once the initial access phase is complete – attackers query Active Directory and network shares for backup-related hostnames, scan for known backup software ports, and review compromised credentials for backup-related accounts. Backup agents running on protected systems also reveal the presence of backup infrastructure. Once located, attackers identify what credentials can provide repository access, prioritizing collecting or escalating those before triggering the main payload.