Assume Breach

No matter how mature a security program is, it’s not realistic to design around the assumption that attackers will always be kept out. Perimeter defenses fail, credentials get phished, software has undiscovered vulnerabilities, and insiders make mistakes.

The Assume Breach principle starts from a different premise: treat a breach as a question of when it will happen, and design the environment so that a breach anywhere does not automatically become a breach everywhere. The goal is to contain the blast radius of any single failure. This principle focuses on limiting the consequences once a threat actor is already inside, whether that threat actor is an external attacker, a piece of malware, a compromised service account, or a malicious insider.

Why This Matters for Backup Infrastructure

This principle matters even more for backup infrastructure. Backups hold copies of everything, which makes them one of the most valuable targets in the environment. If attackers can reach and destroy or encrypt them, the organization loses its last way to recover from ransomware.

That’s exactly why modern ransomware operators go after backups first, before they even encrypt production. Their goal is to remove the organization’s ability to recover, which increases the pressure to pay. This means that:

  • Backup Control Plane and Backup Repositories are as much a target as databases or file servers.
  • A single flat network, shared credentials, or a non-immutable repository can turn a contained incident into a total loss event.
  • Assuming breach is not pessimism. It is what allows an organization to keep its recovery capability intact when it needs it most.

A Zero Trust architecture treats the backup environment as a high-value target that must survive even when the production environment does not.

Defense in Depth is the organizing principle for this section. Micro-segmentation, encryption and training are three of its layers.

  • Defense in Depth - Layering independent, overlapping controls across every tier of the backup infrastructure so that no single point of failure can compromise the whole environment.
  • Micro-Segmentation - Dividing the environment into small, isolated trust zones with tightly controlled communication paths, so that lateral movement from a compromised system toward backup infrastructure is difficult or impossible.
  • End-to-End Encryption - Ensuring that backup data, in transit and at rest, remains confidential and unusable to anyone without proper authorization, even if it is accessed, copied, or exfiltrated.
  • Education & Training - Building the human layer of defense: ensuring that staff, and particularly those with privileged access to backup infrastructure, can recognize and respond appropriately to social engineering, phishing, and other common attack vectors.

All Layers Working Together

None of these controls should be seen as a checkbox exercise. They are complementary and meant to be implemented together: none of them alone is sufficient.

Defense in Depth is what holds the others together, on the expectation that if one layer is bypassed, the next one still stands:

  • Micro-segmentation limits how far an attacker who breaches one system can travel.
  • End-to-end encryption ensures that even successfully exfiltrated data is useless to the attacker.
  • Education and training reduce the likelihood of the initial compromise, and improve the speed and quality of the human response once an incident is detected.
  • Immutability and redundant copies, specified in System Resilience, are what remain when all of the above have failed.
  • Monitoring, detailed in depth in Proactive Validation, is what tells you which of the above has already been bypassed.

Together, they form a layered security posture where the compromise of any one control (a misconfigured firewall rule, a phished credential, an unpatched service) does not, by itself, lead to the loss of backup data or the organization’s ability to recover.

What This Section Does Not Cover

Assume Breach focuses on containment and survivability, not about building the components themselves. Deliberately out of scope here, and owned elsewhere in this guide.


Table of contents


Back to top

Copyright © 2019 - 2026 Solutions Architects, Veeam Software.
Please note that information provided in this guide is not produced or verified by Veeam R&D but is a result of community effort based on the field observations.