What Is ZTNA? Zero Trust Network Access Explained

Building sovereign zero-trust access? WZ-IT builds self-hosted ZTNA platforms for distributed sites, remote teams and OT. See our remote management platforms

ZTNA (Zero Trust Network Access) grants access per application or resource - based on identity, device posture and context - instead of giving access to the whole network the way a classic VPN does. The guiding principle is default-deny: nothing is reachable until a policy explicitly allows it. A policy broker evaluates every request before the connection is established, checking identity (via an identity provider), device posture and context factors such as location or time. ZTNA is the practical implementation of the Zero Trust Architecture described in NIST SP 800-207 (2020): no implicit trust based on network location.

Table of Contents

• The Principles of Zero Trust
• How ZTNA Works
• ZTNA vs. VPN Compared
• Building Sovereign, Self-Hosted ZTNA
• Use Cases: Remote Workforce and OT
• Vendors and the EU Angle
• ZTNA at WZ-IT
• Further Guides

---

The Principles of Zero Trust

Zero Trust moves defenses away from the static network perimeter toward users, devices and individual resources. The NIST definition is clear: no asset or account is trusted based solely on its physical or network location. From this follow four core principles:

• Never trust, always verify: Every request is re-evaluated, whether it comes from the office LAN or the internet. There is no "trusted internal network".
• Least privilege: Identities receive only the minimal access needed, per session and per resource - not a whole subnet by default.
• Micro-segmentation: Resources are isolated individually. Being allowed to reach one application does not reveal the neighboring systems.
• No implicit network trust: The network is assumed to be compromised. Authentication and authorization of both user and device happen before each session.

The immediate security gain is containment of lateral movement: even if a device is compromised, the attacker reaches only the explicitly released resource instead of the flat network.

How ZTNA Works

ZTNA implements these principles with three interlocking building blocks:

• Policy Decision/Enforcement Point (broker): A central control plane decides per request whether access is allowed and enforces that decision as close to the resource as possible, evaluating identity, device posture and context.
• Identity via an IdP: ZTNA delegates identity verification to an identity provider, connected over OIDC/OAuth2 - with SSO and MFA. The same centrally managed identity applies everywhere.
• Outbound-only, no open inbound: A connector or agent at the site actively reaches out to the broker. Services stay "dark" and are not reachable from the internet; no inbound port needs to be opened. This dramatically reduces the attack surface.

Two access patterns are common: agent-based (a client on the endpoint brings the user into the identity-based overlay - typical for infrastructure and server access) and service-initiated/clientless (access to a web app through an identity-aware proxy in the browser, with no client on the endpoint at all).

ZTNA vs. VPN Compared

A classic VPN authenticates once at login and then trusts the device on the network - with broad access. ZTNA verifies continuously and exposes only individual applications. Gartner predicted that by 2025 at least 70% of new remote-access deployments would be served predominantly by ZTNA rather than classic VPN - up from less than 10% at the end of 2021 (Gartner Market Guide for Zero Trust Network Access, 2022).

ZTNA does not necessarily replace the VPN overnight. Gartner recommends a phased migration, often starting with external contractors and individual user groups.

Building Sovereign, Self-Hosted ZTNA

ZTNA is not one vendor's product but an architecture pattern - which is exactly why it can be built entirely from open-source, self-hostable components. A proven stack:

• NetBird as the identity-based WireGuard overlay: it connects devices, servers and sites default-deny, with access policies, micro-segmentation and posture checks (OS version, client version, location). The entire control plane is self-hostable. Details in our guide What is NetBird? and on our NetBird expertise.
• IdP for identity: Authentik or Keycloak provide SSO and MFA over OIDC. That puts the "verify" component in your own hands - the central identity source for all policies.
• Pangolin for clientless app access: the identity-aware reverse proxy publishes internal web applications in the browser, authenticating before the app and granting access only to explicitly released services. Its Community Edition is open source under AGPL-3.0 (a paid Enterprise Edition runs under the Fossorial Commercial License) - see our Pangolin expertise and the guide on exposing internal services without a VPN.

This combination covers both access patterns: agent-based for infrastructure (NetBird) and clientless for web apps (Pangolin), both identity-bound through the same IdP. The control plane, keys and audit data stay in the EU.

Use Cases: Remote Workforce and OT

Two scenarios benefit most. For the remote workforce, employees and external contractors move off the full-tunnel VPN: instead of opening the entire corporate network to everyone, each identity gets only the applications it needs. External contractors are a classic starting point because their access carries elevated risk.

In OT (operational technology), micro-segmentation is the key. Production plants, machines and IoT devices have historically run in flat, weakly segmented networks. ZTNA breaks that open: a technician reaches only the released machine or HMI per identity, never the entire plant network. Sites connect outbound-only, with no open ports, and every access is auditable. This very shift - away from the flat VPN, toward identity-based per-resource access - is the central trend in secure remote access and relevant to regulatory requirements such as the NIS2 directive. This article is general information, not legal advice.

Vendors and the EU Angle

The ZTNA market is shaped by large, mostly cloud-based platforms: Zscaler Private Access, Cloudflare Access and Palo Alto Prisma Access. They are mature, but tie access to the vendor's cloud - identity, connection and audit data flow through their infrastructure, often outside the EU.

For sovereignty- and compliance-sensitive environments, the self-hosted model is the alternative: the same zero-trust approach, but built entirely from open-source components (NetBird, Pangolin, Authentik/Keycloak) on your own infrastructure in the EU. You keep control over keys, policies and logs - with no functional compromise on the zero-trust model.

ZTNA at WZ-IT

At WZ-IT we build ZTNA as a sovereign, self-hosted platform: NetBird as the encrypted, identity-based network backend, an IdP such as Authentik for SSO/MFA, and Pangolin or a browser gateway for clientless app and machine access - all default-deny and auditable. Sites connect outbound-only, with no open ports. The ABCO Water Systems case study in Australia shows what this looks like in production for distributed plants. We handle design, build and operation end to end as part of our remote management platforms.

Further Guides

• What is NetBird? - identity-based overlay as a ZTNA backend
• Expose internal services without a VPN - clientless app access
• NIS2-compliant remote access - regulation and zero trust
• NetBird expertise and Authentik expertise

Building sovereign zero-trust access for sites, teams or OT? Get to know us or take a look at our remote management platforms.