Separate zero trust from ZTNA

Protection need

Zero trust architecture removes implicit trust based only on location or ownership and protects named resources with explicit policy. Zero Trust Network Access, or ZTNA, is a product and deployment pattern that brokers access to selected private applications or services. A ZTNA system can implement important zero trust functions. It is not the full architecture by itself.

The evaluation must identify the protected resource and complete system. A browser gateway can protect web routes and leave service-to-service calls, direct origins, cloud APIs, administrative ports, application permissions, control planes, and recovery outside its scope.

Security objectives and requirements

• Inventory human, workload, device, agent, and administrative paths to named resources.
• Make explicit decisions from trusted subject, resource, action, and current context.
• Enforce each result at an unavoidable path.
• Limit authority and duration rather than granting broad network membership.
• Protect configuration, identity, credentials, context, evidence, and recovery.
• Retain routing, segmentation, firewall, endpoint, workload, application, and data controls where their properties are needed.

Evaluate a ZTNA design by these requirements. Do not infer them from its name, tunnel model, or marketing category.

Security invariants and evidence

Every covered request traverses the intended enforcement point. The decision names the correct subject, resource, action, policy, and context. Direct routes reject clients. A route allow does not bypass application object authorization. Disabled or revoked authority stops within a stated bound. Evidence ties the final action to the decision.

Use route inventory, network tests, policy tests, logs, target records, configuration provenance, session and credential tests, and recovery exercises. State which protocols and targets the product cannot mediate.

Failure cases

• A user receives a broad private-network tunnel through a product called ZTNA.
• The broker checks login once and treats the session as permanent trust.
• Web access is protected while SSH, APIs, cloud consoles, or direct origins bypass it.
• The gateway allows a route and the application accepts every object action.
• Device or risk context is stale and its failure result is undefined.
• Product administration, deployment credentials, and recovery remain broadly trusted.

Design tradeoffs and residual risk

Clientless application access reduces endpoint software and covers only compatible application paths. Client tunnels support more protocols and can expand reachable network scope. Central brokerage simplifies policy and creates a high-value dependency.

Replacing a VPN with a broker can reduce implicit network trust and does not complete identity lifecycle, workload security, application authorization, data protection, monitoring, or recovery. Residual risk is the set of resources, paths, actions, and control planes outside the broker.

Pomerium boundary

Pomerium provides identity-aware access to named HTTP and supported non-HTTP routes. It can implement access-broker and zero trust policy functions on those paths. Operators must isolate upstreams, cover every required protocol, protect application actions, manage identities and credentials, and retain complementary controls. Deploying Pomerium does not by itself make the full environment a zero trust architecture.

Exercise

Take one proposed ZTNA deployment. Inventory its users, workloads, protocols, routes, direct paths, application permissions, context sources, administration, logs, and recovery. Map each part to a zero trust requirement.

Mark every requirement the product does not satisfy alone. Test one named route, one unsupported or alternate protocol, one direct origin, one application object action, and one revocation event. Write the residual architecture work without using product-category claims.

Evaluation checklist

• Is zero trust defined as an architecture and ZTNA as a bounded access pattern?
• Does the evaluation name covered resources, actions, identities, protocols, and paths?
• Are direct access and application authorization tested independently?
• Are network, endpoint, workload, application, data, and recovery controls retained where needed?
• Do conclusions describe measured properties instead of product labels?