Zero Trust Is a Model, Not a Magic Shield
Zero trust has become the dominant security architecture philosophy. The principle is sound: never trust, always verify. Every access request is authenticated, authorized and continuously validated regardless of where it originates. No implicit trust based on network location. No assumption that inside the perimeter equals safe.
Organizations have invested heavily in zero trust platforms. Zscaler provides cloud-delivered zero trust network access. Cloudflare Zero Trust replaces VPN with identity-aware access. BeyondTrust provides privileged access management within a zero trust framework. Microsoft Entra ID (formerly Azure AD) enforces conditional access policies. These are serious platforms with serious engineering behind them.
But zero trust is a model. And models have assumptions. When those assumptions do not hold, the model breaks. The question is not whether zero trust is a good idea. It is. The question is whether your implementation of zero trust actually delivers the security it promises.
Where Zero Trust Falls Short
The Insider Problem
Zero trust verifies identity before granting access. Once identity is verified, access is granted. This means a legitimate user with legitimate credentials accessing resources they are legitimately authorized to access is, by definition, trusted.
An insider threat, whether a malicious employee, a compromised account or a social engineering victim, operates within the boundaries of their authorized access. Zero trust does not protect against a finance employee exporting the customer database if they have read access to the customer database. It does not prevent a system administrator from modifying configurations if they have administrative privileges. It does not stop a developer from inserting a backdoor into code if they have commit access to the repository.
Zero trust reduces the blast radius by limiting access to what each identity needs. But "what each identity needs" is defined by policy. And policy is defined by people. When policies are too broad, the blast radius expands accordingly.
The Misconfiguration Problem
Zero trust platforms are complex. Zscaler requires application connector configuration, policy definitions, user group mappings and integration with identity providers. Cloudflare Zero Trust requires access application definitions, policy rules, device posture checks and tunnel configurations. BeyondTrust requires privilege elevation rules, session recording policies and just-in-time access workflows.
Each configuration decision is an opportunity for error. An access policy that grants "all applications" to a user group instead of specific applications. A conditional access rule that exempts certain device types from compliance checks. A just-in-time access workflow that auto-approves requests from certain roles. A service account that was granted broad access during deployment and never scoped down.
We find these misconfigurations in every zero trust environment we test. Not because the teams are incompetent, but because the platforms are complex and the pressure to enable access quickly often overrides the discipline to scope it narrowly. The same configuration decay that affects firewalls affects zero trust policies.
The Overly Broad Access Problem
Zero trust promises least-privilege access. In practice, achieving true least privilege is extraordinarily difficult. Defining the minimum access each role needs requires detailed understanding of every workflow, every application dependency and every data flow. Most organizations approximate least privilege rather than implement it precisely.
The result is roles with more access than necessary. A "developer" role that can access production databases because some developers occasionally need to troubleshoot production issues. An "IT support" role that can reset passwords for all users, including executive accounts, because the role was not segmented by organizational unit. A "contractor" role that has the same access as full-time employees because nobody created a separate policy.
Overly broad access does not violate the zero trust model. Every access request is still authenticated and authorized. The problem is that the authorization is too permissive. Zero trust enforces the policy. It does not evaluate whether the policy is correct.
The Gap Between Components
Zero trust is not a single product. It is an architecture composed of multiple components: identity provider, access proxy, device trust, microsegmentation, privilege management and continuous monitoring. Each component may come from a different vendor. The gaps between components are where attacks succeed.
An attacker who compromises a device that passes device posture checks gains trusted device status. An attacker who steals a session token after authentication bypasses the identity verification step. An attacker who moves laterally within a microsegment that is too broadly defined operates within the "trusted" boundary of that segment.
These gaps are not theoretical. They are the exact techniques we use during penetration tests against zero trust environments. And they work more often than organizations expect.
Zero Trust Is the Architecture. A Pentest Is the Proof.
This is the statement we make to every client who tells us their zero trust deployment eliminates the need for penetration testing. Zero trust is the architecture you built. A pentest is the proof that it works.
Without testing, you are trusting that your policies are correct, that your configurations are tight, that your access definitions are appropriately scoped and that the gaps between components are too small to exploit. That is a lot of trust for an architecture built on the principle of trusting nothing.
What We Test in Zero Trust Environments
When Sherlock Forensics tests a zero trust environment, we focus on the areas where the model is weakest:
- Policy enforcement verification. We attempt to access resources outside our authorized scope to verify that policies are correctly enforced, not just correctly written.
- Privilege escalation within the identity framework. We test whether a low-privilege identity can gain higher-privilege access through role manipulation, group membership changes or token abuse.
- Conditional access bypass. We test device posture requirements, location-based restrictions and risk-based access rules to verify they cannot be circumvented.
- Lateral movement within microsegments. We test whether segmentation boundaries hold under active attack, or whether overly broad segment definitions allow movement between resources that should be isolated.
- Session handling. We test token lifetime, session persistence, re-authentication triggers and whether compromised sessions can be used to maintain access beyond the intended window.
The result is a validation report that tells you exactly where your zero trust implementation works as intended and where it does not. That report is the proof your board, your auditors and your security team need to make informed decisions.