SBTechnical Marketing Writer
Many vendors talk about hardening and Zero Trust as if they are interchangeable. They aren’t. Hardening is one component of Zero Trust, focused on strengthening defenses and controlling who gets in. Zero Trust goes further by forcing teams to assume breach and ask what happens when attackers get in.
Modern attacks routinely bypass hardening controls through privilege escalation, credential theft, and unpatched vulnerabilities. Once an attacker reaches high‑privilege in a system, the difference between hardening and Zero Trust becomes critical for assessing risk and ensuring recoverability.
The problem isn’t that hardening is unimportant or not part of Zero Trust — it is. The problem is that many vendors encourage organizations to stop at hardening. They label hardening as Zero Trust, which leaves the organization with a false sense of protection.
“Attackers don’t break in and stop. They move layer by layer until they reach the systems with the most value.”
Hardening: what it is and where it helps
Hardening is the disciplined reduction of risk across the environment. It includes least privilege access, MFA, segmentation and monitoring—controls that are meant to prevent compromise. These measures slow an attacker’s progress and limit the blast radius during a ransomware attack.
However, hardening rests on a premise: that the controls will prevent compromise. Everyday systems, teams, and infrastructure rarely behave that cleanly. Maintenance windows introduce exceptions, patches lag, and configurations drift. Also, attackers do not rely on a single point of entry. They chain vulnerabilities, credentials, and misconfigurations until they reach a system with meaningful authority.
Hypervisors, identity providers, and database platforms all share the same structural limitation: they require privileged control to function. Once attackers breach these layers, the environment behaves exactly as the attacker wants. This limitation is not unique to any one product category—it is inherent to systems designed for broad operational authority.
For example, a hypervisor must be able to create, modify, and delete workloads; a database system must be able to alter schemas, data, and permissions. That operational power is necessary, but it also means that once an attacker reaches the server with elevated privileges, that infrastructure can be accessed or dismantled. The same dynamic applies across all high‑privilege control planes. These layers are designed for operational control, and that same control becomes a liability when compromised.
Hardening many times leads to a false conclusion – that compromise will not occur. The reality is breaches will occur, and once an attacker reaches a system designed to exercise broad control, they can disrupt or change operations.
Zero Trust: what it is and how it works
Zero Trust is often reduced to a collection of hardening techniques. However, Zero Trust is not a checklist of controls—it is a mindset built on Assume Breach. Assume Breach means accepting that attackers will enter the environment, escalate privileges, obtain credentials, and reach high value systems. The key is to design plans to recover from the breach.
This is where the industry hesitates. Many vendors avoid the Assume Breach conversation because their systems cannot survive it. Hardening is a comfortable security claim. Assume Breach is not. Therefore, they highlight MFA, segmentation, and detection, avoiding the question of what happens when those controls fail. The result is a narrow interpretation of Zero Trust that stops at the point where the attacker succeeds.
Zero Trust at Object First is defined differently: a storage system with Zero Access to perform destructive actions, so no administrator, no attacker, and no process can modify or delete backup data, even with full credentials.
This is enforced through S3‑native immutability, a dedicated storage appliance, and Secure‑by‑Design controls that remove privileged pathways entirely. This prevents root access, shell access, and administrative actions, including deletion and modification.
Zero Trust must hold at the layer where hardening controls have failed.
The layers of protection in backup data storage
Modern data protection doesn’t sit on a single plane. It spans multiple layers of control, each with its own responsibilities and its own failure modes. Object First’s security layering is modeled after the CISA’s Zero Trust Maturity Model, which is a useful way to understand where hardening and Zero Trust make the rules.
Identity: the first control plane attackers try to compromise
Everything begins with identity. Credentials, tokens, MFA, directory services—this is the front door to the environment. Hardening belongs here, and it does a lot of good. But identity is also the layer attackers target most aggressively. Phishing, token theft, session hijacking, and privilege escalation are routine. Once an attacker impersonates a legitimate user, the rest of the environment starts to open.
Devices: the layer where drift, exceptions, and operations create openings
Endpoints, servers, hypervisors, and appliances all fall into this category. In theory, every device is hardened, patched, and monitored. In practice, devices are where operational reality shows up: delayed patches, temporary firewall rules, maintenance windows, and configuration drift. These gaps accumulate over time, and attackers know how to find them. A compromised device becomes a foothold that blends into normal operations.
Networks: segmentation slows attackers, but it doesn’t stop them
Segmentation, micro segmentation, and traffic controls are designed to limit attacks from lateral movement once they’ve gained access to a system. They help, but they don’t eliminate the problem. Once an attacker has valid credentials or a privileged token, the network becomes less of a barrier and more of a speed bump. The assumption that segmentation will contain a breach rarely holds up against a determined bad actor.
Applications & Workloads: where privilege becomes concentrated
This is where the environment’s authority starts to converge. Hypervisors, orchestration systems, and backup servers all live here. These systems must be able to create, modify, and delete workloads or backup jobs. That operational power is necessary, but it also means that once an attacker reaches this layer with elevated privileges, the impact becomes severe. Hardening reduces the number of easy mistakes, but it cannot change the fact that these systems are inherently privileged.
Backup data: the only layer that must remain intact when all others fail
The data layer is where Zero Trust must be absolute. If attackers compromise identity, devices, networks, and applications, the backup data and its chain of custody must survive. That requires a storage architecture that does not allow destructive actions even when the attacker has full credentials.
Veeam and Object First are designed for exactly this scenario. Both assume a breach has already occurred, and that recovery may need to start even if Veeam itself has been compromised. In a worst‑case event—every secret exposed, every credential stolen, and every control plane is breached—the backup data in Ootbi remains immutable and undeletable, giving a trustworthy foundation to recover from.
That survivability is what separates Zero Trust from hardening. Hardening claims no breaches will occur; Zero Trust requires assessment that attackers will breach the target, they still cannot destroy the data required for recovery. Veeam explicitly documents how to recover Veeam itself in a severe breach, and Object First provides the immutable storage layer that makes that recovery possible.
What organizations should look for
When evaluating backup storage, the most important indicator is whether the system is designed with a genuine Assume Breach mindset. Systems that rely on privileged access, detection, or software layer immutability remain vulnerable to the same failure modes as the layers above them. Using a solution that enforces Zero Access ensures that no one—not even an administrator—can perform destructive actions on backup data
Backup administrators must plan for the worst-case scenario: restoring from a compromised environment where all credentials are exposed. If all secrets are known, the attackers know them too. The storage system must be built to withstand that reality.
Equally important, organizations must be able to prove that survivability—not just trust the claim. A credible platform allows organizations to validate immutability, test destructive scenario recovery, and confirm that data remains recoverable even when the environment is fully compromised. If a vendor restricts or prohibits this kind of testing, that limitation becomes a security signal in itself.
Where the industry goes next
As Zero Trust becomes more strictly defined, vendors will need to demonstrate, not simply assert, how their systems behave under full privilege compromise. They will need to document privileged pathways, prove immutability independent of backup software, and show survivability when every credential is exposed.
Backup storage must function as the last line of defense, not another system that collapses when attackers gain full access.