Zero trust was introduced as a way to fix the assumptions that made traditional perimeter security so fragile. It offered a model where verification replaced trust, where privileges were tightly scoped, and where blind faith in any entity inside the network would no longer be acceptable. But despite years of discussion, many organizations still treat zero trust as a slogan rather than a design principle. This gap shows up most clearly in the confidence placed in cloud security vendors, who often sit in the most privileged position across an organization’s environment, even though recent events show that this trust is not always justified. The term zero trust is now used so broadly that the original concept is difficult to recognise, and the industry needs a reset before the term loses its meaning altogether.
The SonicWall breach: a reality check
A breach detailed by SonicWall in September 2025 seems a clear example of how far zero trust has drifted from its original intent. SonicWall disclosed that an unauthorized party accessed firewall configuration backup files for all customers who used SonicWall’s cloud backup service. Although encrypted, the files contained highly sensitive information about device settings and network policy.
SonicWall controlled the storage, the access pathways, and the encryption protections applied to those backups, creating a single point where customer security relied entirely on vendor safeguards and vendor decisions. It was a chilling reminder that when a vendor becomes the sole guardian of critical configuration data, the entire model rests on the assumption that the vendor will never fail. It also raised a question that goes far beyond one incident.
The vendor trust problem: can this ever be zero trust?
Too many organizations assume that cloud-delivered security is safe because it’s modern. The SonicWall breach turns that notion on its head by revealing the damage that ‘assumed’ trust can cause. When a vendor can view or reset customer configurations and when vendor administrators hold the ability to reach into managed environments, the model starts to resemble the old perimeter mindset rather than true zero trust. Super admin access paths used by vendors for support create dependencies that customers cannot see or control. These paths only reinforce the very implicit trust that zero trust was meant to eliminate. The SonicWall breach incident shows that the industry has developed a habit of shifting trust from internal systems to external providers without reducing the amount of trust required.
What zero trust was meant to be
As touched on above, zero trust was created to counter the weaknesses of implicit trust. Its core principles are clear. Never trust, always verify. Use least privilege to minimise what any account or service can reach. Break environments into segments to contain movement. Apply continuous identity checks rather than rely on one successful login. Assume that no environment, account, or device is inherently safe. Zero trust was intended to reshape architecture from the ground up. It was not meant to be a bolt-on feature or a label applied after adding multi-factor authentication or erecting a firewall. The purpose was to reduce the blast radius of any compromise and to remove the dependency on privileged entities that sit typically above scrutiny, such as the vendors themselves.
The architecture gap: where today’s models fall down
Most cloud security models fall short because they reintroduce exactly the kind of centralised trust that zero trust was designed to remove.Vendor-controlled access paths are often built for convenience so that support teams can troubleshoot issues and, crucially, these paths exist outside of the customer’s oversight. They can override local controls and they sometimes operate with broad, persistent privileges. This means a single credential compromise or administrative failure can open a route into multiple customer environments. This pattern is illustrative of a wider architectural issue where the industry accepts vendor super admin access as normal.
What real zero trust should look like today
A more faithful approach to zero trust would start by removing unnecessary vendor visibility. Customers should control their own encryption keys so that configuration files and sensitive data cannot be accessed by external administrators. Zero knowledge designs should ensure that vendors cannot view customer content even when providing support. Identitychecks should be continuous rather than one-time events, and segmentation should exist at every layer. One thing often overlooked about zero trust is that it should apply to vendors as strictly as it applies internally – there should be no override path that bypasses customer control, even during emergencies. A return to principle-driven design would reduce the gap between what zero trust promises and what current architectures deliver. It would also rebuild confidence in a term that still matters, provided it’s used with accuracy and restraint.
The author
Benjamin Schilz is CEO of Wire
