ESChief Product Officer
SBTechnical Marketing Writer
Every vendor claims their product is “secure” to a point, but the word has lost meaning. Security has become a marketing descriptor rather than a measurable property. In backup and storage systems, where the stakes are highest, transparency is the only way to turn security from a slogan into something organizations can evaluate.
Administrators need to understand not just what a vendor claims, but what assumptions those claims rely on, what the architecture is designed to withstand, and how those goals have been validated.
To evaluate Zero Trust and Zero Trust Data Resilience architectures, vendors must articulate what they assume will happen during an attack, what they assume will not happen, and how their system behaves when those assumptions are challenged. Without that clarity, organizations are left trying to interpret vague assurances rather than concrete evidence.
When vendors aren’t transparent, customers are forced to separate reality from noise. Transparency is what allows them to understand what’s actually true.
Zero Trust begins with assuming a breach will happen.
Zero Trust is often reduced to a set of hardening features such as MFA, TLS, role-based access control; however, the overarching principle that matters most is an Assume Breach mindset. This means assuming compromise not only of the network environment but of the vendor’s own product. If an attacker gains administrative access, steals credentials, or impersonates an operator, the storage system must still protect the backup data. A Zero Trust design cannot be successful when every party does not buy into the “Assume Breach” mindset.
This is why architectural decisions matter more than hardening checklists. The least amount of privilege must be enforced so that no single individual can destroy a company’s backup data. Segmentation of function ensures that backup software and backup storage are not part of the same trust domain.
Segmentation of authentication domains prevents a compromise in one identity plane from cascading into another. And network segmentation reduces the pathways an attacker can use to reach critical systems.
Hardening features do not answer the core question: What happens when the attacker already has the keys?
This is why Object First is passionate about Zero Trust and demonstrates it through independent testing that the system behaves as designed, even when all secrets are known.
Why transparency has historically been discouraged
Meaningful security testing requires independence, transparency, and repeatability. Internal vendor testing alone is insufficient because it cannot be separated from internal pressures and incentives.
Independent third-party testing provides an external evaluation of whether the system behaves as claimed, particularly under adversarial conditions. These reports must be published in full, not selectively excerpted to create an incorrectly constructed, positive facade.
Organizations should also have the option to test the system themselves or engage a third party to do so. Many organizations will not have the time or resources to perform such testing, but the ability to do so is essential. If a vendor’s license agreement prohibits testing, that restriction should be treated as a warning sign. A system that cannot be tested cannot be trusted.
Object First walks the talk
Independent testing is also the only reliable way to validate claims around immutability, Zero Access, and segmentation. These are not features that can be evaluated solely through documentation; they must be demonstrated via external penetration testing that simulates conditions found during an active ransomware attack. This is especially important for Absolute Immutability, which assumes the attacker knows everything the administrator knows and still cannot alter or delete backup data.
Open documentation and defining the attack surface
A vendor must also be able to define its attack surface clearly. Without this definition, neither internal nor external testing can be meaningful. A well‑designed backup storage system has a small, tightly scoped attack surface with clearly documented boundaries, protocols, and behaviors.
A vendor that does not document these components is asking organizations to trust a black box. Without documentation, organizations cannot understand how the system works, what it exposes, or how it should be evaluated. When vendors avoid documentation, they are effectively keeping organizations “in the dark” about how the system is designed and behaves.
Hidden or incomplete documentation creates a simple but serious risk: organizations do not know what they are relying on. They cannot test what they cannot see, and they cannot evaluate what they cannot define. Transparency does not require overwhelming IT and security teams with unnecessary detail; it requires documenting the real attack surface and keeping that documentation aligned with believable deployment patterns and threat models.
How buyers should evaluate vendor security claims
Every vendor is ultimately asking customers to trust them. The question is whether that trust is earned. IT and security teams should look for clear explanations of the vendor’s security architecture, including what the vendor assumes will and will not happen during an attack. They should expect a definition of the attack surface, documentation that reflects real‑world usage, and license terms that allow independent testing.
Most importantly, customers should expect independent third‑party testing that validates the system’s immutability, Zero Access controls, and segmentation under adversarial conditions. They should also look for a vendor’s commitment to the CISA Secure by Design pledge, which signals a willingness to address security challenges openly.
A vendor’s claims should be supported by actions, not words. Transparency is what turns those claims into something verifiable.