When does ZTNA create more risk than it reduces?

Why ZTNA becomes riskier when it is only half the access model

ZTNA is meant to replace broad network trust with per-request, identity-aware access decisions. It creates more risk when it is treated as a remote-work add-on instead of the standard way users, partners and services reach resources. In that state, the organisation preserves old trust paths for some traffic while enforcing new rules for others, which is where inconsistency starts to creep in.

That inconsistency is the real failure mode. If one path uses ZTNA and another still relies on implicit network location, different teams end up making different decisions about the same application, user or device, and the control becomes harder to reason about than the VPN or perimeter model it was supposed to replace. A useful migration plan is to treat this as an access architecture change, not just a new remote-entry product. See the ZTNA Guide for the core deployment patterns that avoid split-policy design.

ZTNA also becomes risky when it is bolted onto a broader remote-access stack without aligning the surrounding architecture. If branch, data centre and cloud paths continue to follow separate rules, you lose the main benefit of policy consistency and gain exceptions that are easy to overlook during incident response or audit. The control only reduces risk when the same trust decision follows the request regardless of where the request originates.

Where split-policy ZTNA creates hidden bypasses

The most common hidden risk is a bypass path that is still trusted because it was never brought into the ZTNA policy model. That may be a legacy VPN path, a direct branch tunnel, a cloud security group exception, or an application that still trusts source network location more than user and device context. Those paths are often justified as temporary, then quietly become permanent.

A second issue is that audit evidence stops being comparable. One access path may produce strong request-level logs while another only shows coarse network events, so the organisation cannot reliably answer who accessed what, from where, and under which policy. NIST SP 800-207 Zero Trust Architecture is useful here because it frames access as continuous verification, least privilege and explicit policy enforcement rather than as a single front door.

The architecture problem gets worse if ZTNA is only applied to humans. Service access, admin workflows and east-west application flows may still rely on older trust assumptions, so the environment looks zero trust in one slice and conventional in another. That split is usually where exceptions, manual approvals and weak compensating controls accumulate.

What to fix before calling ZTNA a risk reduction

First, define the access domains that ZTNA must cover. If the goal is only to protect remote users, say so openly and treat the result as partial risk reduction rather than enterprise zero trust. If the goal is to reduce trust in the network itself, then branch, data centre, cloud and third-party access need to be designed around the same decision logic.

Second, verify whether the policy engine and enforcement points are actually authoritative for every path that matters. If another control plane can still grant access independently, ZTNA is not the single source of trust decision making, and the organisation will inherit drift over time. The Zero Trust Identity Guide is a practical reference for aligning identity-centric policy across users, workloads and devices.

Third, validate whether migration has removed the old exception culture or merely renamed it. If teams still need special bypasses for production apps, vendors or remote support, the organisation should assume those exceptions are part of the threat surface and track them as such. The SASE and SSE Guide is relevant when ZTNA is being introduced as part of a wider network and security architecture, because policy steering and migration scope determine whether the rollout simplifies or fragments access control.

Risk and Threat Considerations

Split-policy ZTNA increases exposure because it creates places where access is still granted by legacy trust assumptions. Attackers do not need every path to be weak, only one path that is easier to abuse, less monitored, or exempt from the newer policy model.

Failure mechanism: A remote-user ZTNA layer is deployed while branch, data centre and cloud access keep their own exceptions, so policy drift, hidden bypasses and uneven logging accumulate across the environment.

Impact: The organisation gets a false sense of risk reduction, while auditability, incident containment and access revocation all become harder because no single trust model actually governs the full request path.

Practitioner Guidance

What to verify: Confirm that the same access decision is enforced at every ingress point that can reach the protected application or service. If a path can still rely on network location, treat that as an exception requiring explicit ownership and expiry.

Decision rule: If ZTNA cannot yet cover a path, classify it as a transitional control rather than as completed zero trust work. That avoids overstating the maturity of the programme and keeps the residual risk visible to operations and audit.

What good looks like: One policy model, one access decision process, and one comparable audit trail across remote users, branches, data centres and cloud. If those three conditions are not true, ZTNA is likely reducing risk in one area while adding it in another.

Practitioner takeaway: ZTNA helps only when it replaces old trust assumptions rather than layering on top of them; if exceptions remain the real access model, the programme has improved branding more than security.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?