The Role of Segmentation in Zero Trust

Zero Trust is often associated with identity verification, least-privilege access, and continuous authentication. At Object First, we start from an Assume Breach mindset, recognizing that attackers may already be inside the environment. Underneath those principles sits another requirement that receives far less attention: segmentation. 

As organizations consolidate infrastructure to reduce operational complexity, understanding what must remain separated becomes increasingly important. In a Zero Trust architecture, segmentation is not limited to physical separation. It can also be defined through security and resilience zones, trust boundaries, administrative controls, and carefully restricted communication paths. The goal is to ensure that even if attackers compromise credentials, privileged accounts, or other security secrets, they cannot use those compromises to modify or destroy protected backup data. 

This approach enables backup software and storage systems to operate together without violating required security boundaries. A Zero Trust backup architecture therefore requires clear trust boundaries, well-defined communication paths, and storage that remains immutable and protected even when other layers of the environment have been compromised.  

Segmentation, immutability, and logical air gapping serve different purposes 

Segmentation, immutability, and air gapping are frequently discussed together, but they solve different problems. Segmentation establishes trust boundaries. Its purpose is to contain compromise and restrict lateral movement between systems. Immutability protects backup data from modification or deletion. Logical aAir gapping creates separation between environments to limit exposure. 

A backup storage solution can be immutable without being properly segmented, and it can be segmented without being air gapped. Strong cyber resilience depends on understanding the role each control plays. 

Within a Zero Trust framework, segmentation answers a fundamental question: if one component is compromised, what remains protected? For backup environments, that question is especially important because backup infrastructure is increasingly interconnected with production systems. 

The backup environment contains multiple trust zones 

Many organizations treat backup infrastructure as a single system. From a security perspective, several distinct trust zones exist within a modern backup architecture. 

Production applications occupy one layer. Backup software occupies another. Immutable backup storage forms the innermost layer because it serves as the foundation of recovery. 

The onion model of trust zones 

An onion-layer model helps illustrate these relationships. 

At the center sits immutable backup data. Around it resides backup applications, production workloads, hypervisors, storage platforms, administrative tools, and management systems. Each layer operates under different security assumptions. 

Production environments require administrators to provision systems, delete workloads, modify configurations, and perform operational tasks. Those privileges are necessary for day-to-day operations, but they also create risk. Zero Trust acknowledges this reality and assumes credentials will eventually be compromised. 

Some security models focus on preventing compromise. A Zero Trust recovery strategy assumes compromise has already occurred and asks a different question: what survives afterward? 

The answer must always include the backup data. 

Backup software requires production access but a separate trust boundary 

One of the most important concepts in backup security is understanding the role of backup software. 

Backup software is often viewed as part of the recovery environment. Operationally, however, it shares many of the characteristics of production systems. It requires privileged access, interacts with multiple platforms, and can perform powerful administrative actions. 

If attackers gain control of backup software, they can disable jobs, alter policies, remove retention settings, and disrupt recovery processes. 

For that reason, backup software should be treated as part of the broader production layer from a trust perspective. 

This assumption influences how Zero Trust architectures are designed. Recovery cannot depend on backup software remaining uncompromised. Recovery must depend on backup storage remaining unaltered even if backup software is breached. 

When every credential is assumed to be exposed and every administrator account is assumed to be vulnerable to phishing, immutable storage becomes the final layer protecting recoverability. 

Why software and storage must remain separate 

A common mistake is treating backup software and backup storage as a single security domain. 

When backup servers have direct control over storage, an attacker who compromises the backup application may gain a path to the backup data itself. The same risk emerges when shared identities, management planes, or unrestricted administrative access span both environments. 

Strong segmentation creates a boundary between backup software and backup storage. Communication should occur through well-defined interfaces with narrowly scoped permissions. 

This principle becomes especially important as organizations pursue more integrated and consolidated infrastructure models. 

Physical separation is one approach. Logical separation is another. The critical factor is preserving independent trust boundaries between components. 

It is also important to distinguish between network domains and security domains. The two are not the same. Backup software often requires broad network connectivity to backup storage so it can efficiently write, read, and restore data. That necessary connectivity does not mean both systems belong to the same security perimeter. Even when backup infrastructure can communicate directly with storage at the network level, their security boundaries should remain separate. 

A system can reside in the same appliance, cluster, or platform while still maintaining architectural separation. Communication through defined protocols and limited privilege models helps ensure that compromise in one domain does not automatically spread into another. 

For Object First customers, the S3 protocol serves as a key boundary. Backup software interacts with storage through a controlled interface rather than through unrestricted operating system access. That separation helps preserve the integrity of immutable backup data even when systems outside the storage layer are compromised. 

The security challenge behind infrastructure consolidation 

IT teams face growing pressure to simplify operations. Consolidation reduces administrative overhead, decreases vendor sprawl, and streamlines infrastructure management. 

Virtualization transformed server consolidation. Shared storage platforms consolidated data infrastructure. Integrated appliances continue this trend today. 

Each consolidation effort delivers operational benefits, such as shared infrastructure. Each consolidation effort may also remove layers of separation. For example, if you run a virtualized storage service on a hypervisor, anyone with hypervisor-level privileges can modify or delete it. 

Security teams must therefore evaluate consolidation decisions carefully. Consolidating the wrong components can collapse trust boundaries that were previously protecting critical assets. 

The challenge is particularly relevant for backup environments because recovery infrastructure must operate differently from production infrastructure. Production systems are designed for availability and operational efficiency. Backup storage is designed to survive compromise. 

Those goals require different security assumptions. 

Successful architectures balance efficiency with isolation by preserving the boundaries that protect recovery. 

Common segmentation failures 

Many segmentation failures are not caused by obvious mistakes. They emerge from decisions that appear operationally efficient. 

Examples include: 

• Shared administrator accounts across production, backup, and storage environments 

• Excessive privileges granted to backup servers 

• Direct operating system or root-level access to backup storage 

• Consolidated identity systems without appropriate isolation controls 

• Shared management planes spanning multiple trust zones 

• Hardware management interfaces left exposed or inadequately secured 

One frequently overlooked area involves out-of-band management technologies such as IPMI, iDRAC, and iLO. 

These interfaces provide deep hardware-level control over infrastructure. If attackers gain access to this layer, protections above it may become irrelevant. Storage systems, servers, and workloads can all be affected through the underlying management plane. 

Security boundaries must extend beyond applications and networks. Hardware management layers deserve the same scrutiny as any other privileged system. 

Verifying segmentation in practice 

Organizations should regularly validate that backup storage remains isolated from compromised identities, applications, and infrastructure layers. 

Key questions include: 

• Can backup administrators modify immutable backup data? 

• Does backup software have operating system access to storage? 

• Can a compromised identity span multiple trust zones? 

• Are storage and backup environments managed through separate security controls? 

• Are hardware management interfaces secured and monitored? 

• Can the compromise of a backup server directly alter backup storage? 

If the answer to any of these questions is yes, additional segmentation may be required. 

Object First reinforces these protections through a purpose-built architecture that eliminates common attack paths. With no general-purpose operating system exposure, no root access, and no shell access available to customers or attackers, critical storage functions remain isolated from many of the mechanisms commonly used to compromise traditional storage platforms. 

Segmentation protects the last line of defense 

In a Zero Trust model, every security layer must be evaluated through the lens of assumed breach. 

Administrators can be phished; it is still the most common cyberattack method. Credentials can be stolen. Applications can be compromised. Infrastructure can fail. 

Recovery depends on ensuring that the storage layer remains protected when those events occur. Segmentation provides the boundaries that make that possible. It limits lateral movement, contains compromise, and preserves the integrity of immutable data. As organizations continue to consolidate infrastructure, the most important question remains unchanged: when everything around the backup environment is under attack, what still stands? 

The answer should always be absolutely immutable backup storage. That is the foundation of resilience and the core purpose of segmentation in a Zero Trust architecture.