What is Zero Trust Network Access (ZTNA)?
ZTNA is an access approach that applies zero trust principles to connections between subjects and specific private resources. It authenticates the subject and device as required, evaluates policy and context, and limits reachability to approved resources instead of granting broad network access. ZTNA does not make traffic or users trusted, and it is not automatically secure. Policy quality, enforcement placement, identity, device state, and operations still matter. Identity-aware infrastructure access applies verified identity and policy to web consoles, SSH endpoints, Kubernetes APIs, and database protocols. Each protocol needs its own enforcement path to authenticate, authorize, and carry its traffic.
Why it matters
Broad private-network access can expose many services after one connection. ZTNA narrows access to named resources and evaluates the requester and context before it establishes that path.
How it works
- The requester connects to a policy enforcement point instead of receiving general private-network reachability.
- The system authenticates the subject and evaluates device, request, resource, and policy context.
- After an allow decision, the enforcement point connects the requester only to the approved private resource.
Example
A support vendor reaches one private dashboard through an identity-aware proxy but receives no route to the database or other internal services.
Pomerium boundary
Pomerium provides identity-aware access to specific internal applications, servers, services, and workloads. Policy is attached to each route, so Pomerium can evaluate and proxy the approved resource request without a broad private-network tunnel.
Limits and non-claims
- ZTNA does not remove vulnerabilities or unsafe authorization inside an approved application.
- Weak identity, device signals, context, or policy can still produce an unsafe allow decision.
- Resources and protocols outside the enforcement coverage need other access controls.
Evaluation checklist
- Does access target one named resource instead of extending general network reachability?
- Which current identity, device, action, and context inputs drive each decision?
- Can a direct path, stale session, broad route, or missing application authorization exceed the ZTNA grant?
