Zero Trust
How to understand, apply and evolve Zero Trust to protect your organisation’s systems, data and users.
Page 18 of 18
ZTNA anti-patterns
The security benefits of a ZTNA architecture can be undermined by poor design and implementation choices that conflict with zero trust principles. These designs are referred to here as ‘anti-patterns’.
The following 4 anti-patterns highlight common architectural flaws and misconfigurations, outline the risks they introduce, and suggest alternative design approaches.
This section will help organisations design, deploy, and operate ZTNA solutions that deliver meaningful risk reduction, and align with our ZTNA guidance.
1. Anti-pattern: recreating the ‘walled garden’ trust model
As illustrated in Figure 1, this anti-pattern occurs when components such as Secure Service Edge (SSE) or Secure Access Service Edge (SASE) are deployed as a direct replacement for traditional VPNs in a ‘walled garden’ model, but the underlying access model remains unchanged. Users authenticate at connection time and are then granted broad network access.
This design has the following features:
- Access is based on network reachability rather than explicit per-application policy evaluation.
- Once connected, users can discover and access multiple services.
- Lateral movement is largely unconstrained.
- Network location is implicitly treated as a trust signal.
This recreates the ‘walled garden’ model that ZTNA is intended to replace.
Why this is a problem
If a user account or device is compromised, an attacker may inherit broad internal access. The resulting blast radius may be little different from a traditional ‘walled garden’ model.
Recommended approach
In a ZTNA architecture, access should be:
- explicitly authorised by policy
- scoped to the minimum set of resources required
Delivering meaningful risk reduction typically requires architectural change, including segmentation and policy-driven access control, not just a change in remote access technology.
2. Anti-pattern: trusting network location
As shown in Figure 2, this anti-pattern occurs when access to an application or service is granted solely because a request originates from a ‘trusted’ IP address or network location, rather than being evaluated by a policy engine using multiple security signals.
Examples include:
- implicitly trusting corporate office IP ranges and VPN address pools
- allowing internal cloud network ranges to bypass conditional access policies
Why this is a problem
An IP address does not provide assurance of:
- the user’s identity
- authentication strength
- device compliance or health
- user risk
Relying on network location reintroduces implicit trust and recreates a perimeter-based model, which is inconsistent with zero trust principles.
If an attacker gains access to a trusted network location, they may be able to access resources without policy engine evaluation, increasing the risk of unauthorised access and lateral movement.
Recommended approach
All access requests should be evaluated by the policy engine regardless of their source IP address or location.
Network location may be used as a supporting signal to inform policy decisions, but it must not act as a standalone trust decision or provide a route to bypass policy enforcement.
Access decisions should be based on multiple signals, including user identity, authentication strength, device posture, and user behaviour risk.
3. Anti-pattern: exposing private applications to the internet
As shown in Figure 3, this anti-pattern occurs when internal services that are not designed to be internet-facing are made directly accessible from the public internet.
Examples include:
- publishing internal applications with public IP addresses
- exposing management interfaces to the internet
- making private APIs directly reachable from untrusted networks
Why this is a problem
Even where a policy engine controls access, vulnerabilities in the private service itself may be exploited before policy enforcement occurs – for example, through authentication bypass flaws. In these cases, the policy engine is effectively circumvented and the benefits of ZTNA are lost.
Recommended approach
Private services should not be directly exposed to the internet. Access should be brokered through a hardened internet-facing component, such as a connector or proxy, that is specifically designed to operate on untrusted networks. Only this component should be publicly exposed, not the application itself.
Such components should have the following features:
- Do not require services to have public IP addresses.
- Permit access to a service only when the access policy is satisfied.
- Minimise network-level exposure of private applications.
The external attack surface should be reduced and all access explicitly authorised and policy-driven.
4. Maintaining legacy access routes that bypass the policy engine
As shown in Figure 4, this anti‑pattern occurs when legacy access mechanisms are retained alongside a ZTNA solution, allowing users or systems to bypass the policy engine.
Examples include:
- VPN access that provides broad network connectivity
- direct network routing to internal services
- static firewall rules permitting access without policy evaluation
These routes are often maintained for operational convenience, to support legacy systems, or phased migration.
Why this is a problem
Legacy access routes reintroduce implicit trust and undermine the security benefits of ZTNA. Maintaining parallel access paths also increases architectural complexity, making it harder to understand, audit, and govern who can access what.
Recommended approach
All access to corporate resources should be mediated by the policy engine. Legacy access routes should be removed wherever possible. Where they must be retained, access should be tightly restricted to the minimum necessary.
Access decisions should be consistent, centrally governed, and aligned with the access policy.
