Backup Infrastructure Needs Its Own Containment Boundary

Most backup strategies start with copies, retention, and restore speed.

Attackers start with reachability.

Can a compromised production administrator reach the backup console? Does the backup platform trust the production identity provider? Can ordinary server networks connect to repositories or storage management interfaces? Can a shared virtualization manager delete both workloads and their recovery points?

If the answer is yes, the backup environment is not outside the blast radius. It is simply another management plane inside it.

That distinction matters because ransomware operations do not stop at encrypting endpoints. Mandiant’s review of 2025 ransomware investigations says attackers consistently tried to reduce victims’ ability to recover, including by deleting backups. The same report found that attackers used RDP with compromised or attacker-created accounts for lateral movement in approximately 85 percent of the intrusions it examined.

This is not primarily a storage-capacity problem. It is a trust-path problem.

Production And Recovery Are Different Security Domains

A backup platform needs access to production data. That technical dependency often turns into architectural over-trust:

production and backup administrators use the same identities;
backup servers join the production Active Directory domain;
repository and management interfaces are reachable from broad internal networks;
the same privileged workstation administers production, virtualization, storage, and recovery;
backup service accounts have standing access across the estate;
production and recovery environments share DNS, hypervisors, cloud tenants, or automation tooling.

Every shared dependency becomes a path an attacker can reuse.

Mandiant’s 2026 guidance for destructive attacks is explicit: if backups share an identity plane with production or remain mutable, an attacker can delete or encrypt them. It recommends isolating storage management networks and backup infrastructure, requiring phishing-resistant MFA from designated privileged access workstations, using separate hardened key management, and keeping secondary recovery in an isolated tenant or subscription with independent identities.

The design goal is simple:

Compromise of the production environment must not automatically grant access to the recovery environment.

That is Zero Trust applied to resilience. Network location, domain membership, and an existing administrator session should not create implicit trust.

Immutability Does Not Replace Isolation

Immutable storage is essential. It is not the whole architecture.

An immutable recovery point can still be surrounded by vulnerable control paths. An attacker may not be able to alter protected objects during the retention period, but they may still be able to:

disable future backup jobs;
change retention settings for new recovery points;
compromise the backup catalog;
steal encryption keys;
delete unprotected copies;
attack the virtualization or storage management plane;
poison data before it becomes immutable;
block or delay the restore process;
compromise the systems used to administer recovery.

Immutability protects the object. Segmentation protects the paths to the object and the systems that make recovery possible.

CISA’s StopRansomware Guide recommends frequent offline or cloud-to-cloud backups and logical or physical network segmentation to contain intrusion impact and limit lateral movement. Those controls reinforce each other. A backup is safer when the attacker cannot reach its management interfaces, identities, repositories, or restore environment from the compromised production plane.

Build Four Separate Policy Boundaries

A practical backup-security design needs more than one “backup VLAN.” It should separate at least four functions.

1. Data ingestion

Backup workers need narrowly defined access to protected workloads and data sources. The direction, protocol, and initiator should be explicit.

Where the platform supports it, prefer a pull model controlled by the backup tier over unrestricted connections initiated from production. If agents must push data, restrict them to the exact collectors and ports required. A compromised application server should not be able to browse repository shares, connect to the backup console, or address other protected workloads through the backup network.

2. Administration

Management interfaces belong on a dedicated path.

Only hardened privileged access workstations or controlled jump systems should reach backup consoles, storage management, hypervisors, key management systems, and recovery orchestration. General user networks, production servers, monitoring platforms, and shared IT administration subnets should not have ambient access.

Administrative identities should be separate from daily accounts and from production administration. Phishing-resistant MFA helps protect authentication. Network policy makes sure the authentication interface is reachable only from the expected source.

3. Repository and storage traffic

Repository access should be limited to the backup components that write, replicate, validate, or restore data. It should not be exposed as a general-purpose file share.

Encrypt backup data with keys held outside the production trust domain. Restrict access to the key management service independently from access to the repository. Otherwise, compromise of one service account may provide both the encrypted data and the key needed to use it.

4. Recovery and validation

Restoring into production during an active incident creates risk. The restored workload may contain attacker persistence, compromised credentials, vulnerable configurations, or malicious scheduled tasks.

Mandiant describes an isolated recovery environment as a separate enclave with no shared authentication, tooling, infrastructure, or persistent network paths to production. It recommends independent identity, restricted break-glass administration, known-good artifacts, and an isolated validation area where teams can inspect workloads before reconnecting them.

That turns recovery into a controlled transition between trust domains instead of a direct copy back into a compromised network.

Microsegmentation Makes The Boundary Enforceable

Macro-segmentation can place backup and recovery systems in dedicated networks, tenants, accounts, or sites. Microsegmentation handles the flows that remain inside and between those zones.

A useful policy model could look like this:

backup workers can reach assigned workloads on documented backup protocols;
protected workloads can reach only their assigned backup collector, if push traffic is required;
backup workers can write to specific repositories but cannot administer them;
repository systems cannot initiate connections to production;
backup administrators can reach consoles only from dedicated privileged workstations;
backup consoles can reach managed components only on required control ports;
key management accepts requests only from named backup services and recovery workflows;
monitoring receives narrowly scoped telemetry without gaining management access;
the isolated recovery environment has no persistent route to production;
restore connectivity is enabled only through a documented, time-bound process.

The Department of War Zero Trust framework separates control, management, and data-plane flows and calls for isolation testing to verify that traffic is actually restricted by policy. That distinction maps well to backup architecture. Backup data movement, administrative control, storage management, telemetry, and recovery orchestration are different flows. Treating them as one trusted network defeats the point of the boundary.

Test The Failure Path, Not Only The Happy Path

Successful nightly jobs do not prove ransomware resilience.

The useful test starts with hostile assumptions:

Assume a production domain administrator is compromised.
Assume one virtualization administrator session is stolen.
Assume an attacker controls a protected server and its backup agent.
Assume production DNS, identity, monitoring, and endpoint management are unavailable.
Attempt to reach the backup console, repositories, key management, and recovery environment.
Verify that immutable recovery points survive.
Restore a priority service into isolation.
validate the workload, credentials, dependencies, and data integrity before reconnection.

Mandiant’s destructive-attack guidance recommends practicing end-to-end restoration of mission-critical services with isolated, immutable backups and out-of-band communications, while testing recovery time and recovery point objectives. The exercise should also validate policy enforcement:

Which connections were blocked?
Which emergency routes had to be opened?
Who could authorize them?
Did recovery depend on production identity or name resolution?
Could shared management tooling cross the boundary?
Were all temporary paths removed after the exercise?

A restore test proves that data can come back. A containment test proves that the attacker cannot follow it.

Start With The Reachability Map

Do not begin with a product list. Begin with the flows.

Inventory:

backup servers, proxies, agents, repositories, storage, and catalogs;
cloud vaults, object stores, snapshots, and replication services;
virtualization, storage, and key management systems;
identities, service accounts, certificates, tokens, and trust relationships;
administrative workstations and jump paths;
monitoring, patching, endpoint security, and automation dependencies;
network routes between production, backup, and recovery;
the minimum services required to restore priority applications.

Then classify every path as data, control, management, monitoring, or recovery. Remove paths that have no current owner or technical requirement. Constrain the rest by source, destination, identity, protocol, and time.

This is where microsegmentation earns its place in cyber resilience. It turns “the backup environment should be isolated” from an architecture statement into testable policy.

Recovery Is A Crown-Jewel Workload

Organizations often protect production because production runs the business.

During a destructive incident, recovery runs the business.

Backup consoles, repositories, immutable stores, encryption keys, virtualization managers, and recovery orchestration therefore belong in the same risk class as identity infrastructure and other Tier 0 systems. They need independent identities, narrowly defined network paths, hardened administration, continuous visibility, and rehearsed isolation.

Three copies of data do not create three recovery options when one compromised identity can reach all three.

Detection tells you that production has been compromised. Containment decides whether recovery is still yours.

Sources

This article was generated with the assistance of AI and reviewed by the author.

microsegment.io