Implementing Zero Trust Network Access in Cloud-Native Environments

What is Zero Trust Network Access?

Zero trust network access (ZTNA) is an access model that grants connectivity to specific resources based on a continuously verified identity and device posture, rather than on a user's position inside a network. The guiding principle is "never trust, always verify": no user, device, or workload is trusted by default, even if it sits inside the corporate network.

Traditional perimeter security worked like a castle and moat. Once you were inside the network, through a VPN (virtual private network) or by being on the office LAN, you were broadly trusted and could reach far more than your job required. ZTNA discards that assumption. Identity becomes the perimeter. Access is granted to one application or resource at a time, scoped to what the verified identity is allowed to do, and re-evaluated continuously rather than granted once at the door.

ZTNA is the access-enforcement piece of a broader zero trust architecture (ZTA). Where zero trust architecture is the overall strategy and set of principles, ZTNA is the concrete technology that connects a verified user or workload to a specific resource without exposing the rest of the network. That focus on identity-based access to individual resources is what makes ZTNA the practical starting point for most teams adopting zero trust security.

It helps to place ZTNA among the terms it travels with, because they are easy to conflate:

• ZTNA (zero trust network access) is the technology that grants identity-based, least-privilege access to specific resources. It enforces the policy at connection time.
• ZTA (zero trust architecture) is the broader strategy and set of principles, defined in standards like NIST SP 800-207, of which ZTNA is one enforcement component. ZTA is the blueprint; ZTNA is one of the tools that builds it.
• SASE (secure access service edge) is a cloud-delivered framework that combines networking and security functions, including ZTNA, secure web gateways, and firewall-as-a-service, into one service. Gartner introduced the term in its 2019 report "The Future of Network Security is in the Cloud." ZTNA is a feature within SASE, not a synonym for it.
• SDP (software-defined perimeter) is the earlier architectural concept ZTNA grew out of, an identity-based logical perimeter set against the traditional network-defined perimeter. It hides resources behind a controller that authenticates users before granting access. ZTNA is the modern, productized evolution of the SDP idea.

The model rests on a few core assumptions: 

First, the network is assumed to be hostile, so being "inside" it confers no trust. Second, trust is never permanent. It is evaluated per request and can be withdrawn the moment context changes. Third, access is granted at the resource level, not the network level, so authorization is always specific rather than blanket. Fourth, every access decision is logged, because you cannot enforce least privilege if you cannot see what is happening. These assumptions are the same ones that underpin Google's BeyondCorp work and the NIST zero trust guidance, and are why ZTNA scales to environments that perimeter security was never designed for: remote-first workforces, ephemeral cloud workloads, and non-human identities that authenticate thousands of times an hour.
 

Components needed to implement ZTNA

To implement ZTNA you need a system built around an identity-aware proxy that allows only trusted devices and verified identities to reach the resources behind it. Four components do the work:

• Internet-facing access proxy. Because ZTNA trusts no device or user by default, the proxy can sit on the public internet without network guardrails policing who can reach it. The resource stays dark until access is explicitly granted.
• Continuously verified identities. Rather than basing access on whether you are inside or outside the network (the VPN model), ZTNA removes trust by verifying identity continuously throughout a session. Access control is always on.
• Device identity and trust. Devices also receive an identity and must be declared trusted before they can reach resources.
• SSO and a user database. Most ZTNA implementations integrate a single sign-on (SSO) provider, such as Okta, for identity management and user lifecycle.

How does ZTNA work?

ZTNA works by placing a broker between the user and the resource so that no one connects directly to anything until their identity and context are verified. Nothing is exposed to the open network; the resource stays dark until access is explicitly granted. In a zero trust model the emphasis is on who you are, not where you are.

The core component is an identity-aware proxy (sometimes called a trust broker). Every connection request flows through it, and it enforces policy before any traffic reaches the resource. A typical ZTNA flow looks like this:

• Authenticate the identity. The user or workload proves who it is, ideally with phishing-resistant, certificate-based credentials rather than a static password, often reinforced with single sign-on (SSO) and multi-factor authentication (MFA).
• Evaluate context and device posture. The proxy checks signals such as device trust, location, time, and risk before deciding.
• Apply least privilege. Access is granted only to the specific resource the policy allows, never to the whole network. This is the principle of least privilege in action: every identity gets exactly the access it needs and nothing more.
• Broker the connection. The proxy establishes an authenticated, encrypted path to the resource. The resource itself is never directly reachable, so it cannot be scanned or attacked by anyone who has not already been verified.
• Verify continuously. Trust is not granted once and forgotten. The proxy re-evaluates the session, and access can be revoked the moment context changes, for example if device posture degrades or the certificate expires.

A key design choice is how trust is proven. Strong ZTNA implementations issue short-lived certificates rather than relying on standing credentials, so access automatically expires and there is no long-lived secret to steal. Modern zero trust tooling also layers in phishing-resistant authentication like WebAuthn and passwordless login, real-time auditing of everything that passes through the proxy, and role-based access controls (RBAC) for granular, per-identity authorization. Because every request passes through the proxy, every action can be logged, producing a record of who accessed what, when, and from where.

Two properties of this model deserve emphasis, because they are what separate ZTNA from a firewall rule or a network ACL. The first is continuous verification. In a perimeter model, you are authenticated once at connection time and trusted for the life of the session. In ZTNA, the policy engine keeps watching, so if the device falls out of compliance, the certificate expires, or the risk score changes, the session can be cut without waiting for the user to log out. The second is that authorization is identity-based, not address-based. The proxy does not care what IP a request comes from or which network segment it lands on. It cares who is making the request, what device they are on, and whether policy permits that identity to reach that specific resource right now. That decoupling of access from network topology is precisely what makes ZTNA work across multi-cloud and hybrid environments, where IP addresses are ephemeral and the notion of "inside the network" has stopped meaning anything. You can read more about how Teleport extends BeyondCorp and the Federal zero trust strategy.

What’s the difference between VPN and ZTNA?

The short version: a VPN grants broad access to a network, while ZTNA grants narrow access to a specific resource based on verified identity. That single difference drives every other contrast below.

A VPN connects a remote user to the corporate network and, once connected, that user can typically reach anything the network routing allows. If an attacker steals VPN credentials or compromises a connected device, they inherit that same broad reach and can move laterally across the network. ZTNA never places the user "on the network." It brokers access to one resource at a time, so a compromised account cannot pivot to systems it was never authorized to touch. Lateral movement, the mechanism behind most damaging breaches, is structurally limited.

The differences go beyond security posture:

• Security. VPNs grant broad horizontal access once you are inside; an attacker who breaches the tunnel can pivot freely. ZTNA trusts no one regardless of location and keeps verifying after the initial check, so identity-based authentication is structurally more secure than password-based, IP-enforced VPN architecture.
• Cost and operations. VPNs require concentrators and gateway hardware that become bottlenecks as remote work scales, and backhauling all traffic through a central point adds latency and cost. ZTNA scales with identity rather than network plumbing, so capacity grows with policy, not appliances.
• Granularity. A VPN's access control is coarse, since you are on the network or you are not, and fine-grained segmentation has to be bolted on with separate firewall rules. ZTNA limits access per identity and per resource with RBAC or attribute-based access control (ABAC).
• Location. VPNs often require on-premises concentrators to complete the architecture, adding cost and complexity. ZTNA is cloud-native and deployed in the cloud, allowing access from any location.
• Flexibility. Because a ZTNA proxy lives on the public web and protects resources rather than network segments, it makes bring-your-own-device (BYOD) enforcement straightforward. VPNs often require provisioning and maintaining company-managed machines for each employee.
• Visibility. A VPN typically logs connection events but little about what happened inside the tunnel, while ZTNA produces per-session, per-resource records, often including full session recording, which is exactly what auditors want to see.

None of this means VPNs disappear overnight. Many teams run ZTNA alongside a shrinking VPN footprint, moving high-value systems behind identity-based access first and retiring the broad tunnel as confidence grows. The end state, though, is clear: access defined by who you are and what you are allowed to reach, not by whether you managed to get onto the network.

 For a deeper comparison, see VPN versus zero trust and our take on the evolving nature of remote access. Teams replacing legacy remote access often start with the VPN and bastion alternative use case, where ZTNA replaces both the VPN and the jump box while keeping a full audit trail for compliance.

What are some ZTNA use cases?

ZTNA fits anywhere access should depend on identity rather than network location. The most common use cases include:

• Secure remote and hybrid work. Give employees and contractors access to the specific apps and infrastructure they need, from anywhere, without putting them on the corporate network or backhauling traffic through a VPN concentrator.
• Third-party and vendor access. Open applications to contractors, collaborators, auditors, and suppliers without a DMZ or VPN, so everyone enters the same way, with least-privilege access to a single system for a defined window, then revoke it automatically, every session recorded.
• Cloud and multi-cloud access. Provide consistent, identity-based access across AWS, Azure, GCP, and on-premises resources without stitching together per-cloud network rules.
• Replacing VPNs and bastion hosts. Retire the broad VPN tunnel and the shared jump box in favor of brokered, audited, per-resource access, hiding internal applications behind a software-defined perimeter.
• Infrastructure access for engineers. Connect developers and SREs to servers, Kubernetes clusters, databases, and internal dashboards with short-lived credentials and full session recording.
• Machine and workload access. Extend the same identity-based model to non-human identities, covering service-to-service and CI/CD authentication, so machines and workloads get scoped, short-lived access instead of standing API keys.
• BYOD and untrusted networks. Authenticate users on personal devices and protect end-to-end encrypted access even over network carriers you do not fully trust.
• IoT and edge security. Extend identity-based access to devices at the edge.
• Mergers, acquisitions, and rapid onboarding. Grant access across newly combined environments by identity, without merging networks first.

Security benefits of ZTNA

Security is the headline benefit and it pairs well with modern cloud infrastructure access:

• Identity-based authentication. ZTNA bases trust on verified identity rather than an outdated password or shared secret. Modern secure enclaves, Windows Hello, or Face ID prove a user's or device's identity biometrically for Device Trust.

• Hidden infrastructure. Systems and applications stay invisible to the public without being connected to a corporate network, freeing the network while keeping applications dark.

• Control and granularity. A centralized proxy makes users, devices, and resources easy to manage, while attribute-based access controls or role-based access controls enforce the principle of least privilege.

• App segmentation. Secure boundaries are drawn around individual applications or groups of applications and managed by policy, rather than around networks.

Challenges and risks of ZTNA

ZTNA is not without trade-offs:

• Single point of failure. The trust broker handles every connection, so it must be designed for high availability; latency can also be introduced if the proxy is a bottleneck.
• Implementation complexity. Modeling identities, trust, and authorization policies can be complex for teams new to the approach. Adopting an established platform like Teleport eases the transition.
• Organizational change. Moving past VPNs and perimeter habits, and adopting modern authentication from the FIDO Alliance, requires education and buy-in.
• Upfront cost. Adding MFA and continuous verification has a cost; choosing a well-established platform keeps that cost predictable.

Considerations when evaluating ZTNA solutions

When evaluating a ZTNA platform, weigh a few factors:

• Vendor specialization. Security, IAM, and network management are often sold separately. Favor a platform that covers all the bases for your implementation rather than forcing you to assemble several point tools.
• SSO and identity providers. Does it integrate with your existing identity provider?
• Cost and setup. How much effort is it to stand up, what does it cost, and does it meet your requirements?
• Logistics. Does it support your operating systems, and do agents need to be installed?

How is ZTNA different from Zero Trust Application Access (ZTAA)?

The difference between ZTNA and ZTAA is in the third word: network versus application. Per Gartner, ZTNA creates an identity and context-based logical access boundary around an application or set of applications, focused on identity-aware access to the network and its resources. ZTAA narrows the focus to protecting the applications themselves, notably web apps. In practice the terms are used together, since ZTAA takes place within a ZTNA setup and applies zero trust security to the applications inside it.

Implementing Zero Trust Network Access with Teleport

Teleport Zero Trust Access implements ZTNA by establishing a unified identity layer in front of your infrastructure, so access is granted on cryptographic identity and least privilege rather than network location. It is built for cloud-native infrastructure rather than retrofitted from a data-center appliance, and it extends the model to all four identity types: humans, machines, workloads, and AI agents.

At the core of Teleport is the Teleport cluster, with three parts that map onto the ZTNA model:

• The Teleport Proxy is the identity-aware proxy. Every connection to a server, Kubernetes cluster, database, application, or Windows desktop passes through it, so nothing behind it is directly reachable and resources stay dark until access is verified.
• The Auth Service is the certificate authority. Rather than vaulting and handing out standing credentials, it issues short-lived cryptographic certificates scoped to a specific identity, enforcing zero standing privilege. There is no long-lived secret to steal, and access expires on its own. Teleport eliminates secrets rather than managing them.
• Agents run alongside resources and enforce policy locally, registering each resource with the cluster so it can be reached only through the proxy. They speak the native protocols of what they protect, including SSH servers, Kubernetes, databases, Windows desktops, and web apps.

A user authenticates to the cluster using an identity provider of their choice (OIDC, SAML, or GitHub SSO) or local WebAuthn, both passwordless rather than secret-based. Once identity is verified, the user can reach only the resources their Teleport role allows, and just-in-time access requests can grant temporary privileged access to specific resources or roles.

Deployment is deliberately straightforward. Teleport ships as a single binary with an open-source core (20,000+ GitHub stars) and a managed cloud option, so teams can stand up identity-based access quickly rather than assembling a stack of appliances. As one data point, Turo deployed Teleport and connected it to MySQL in under two hours. Consolidating ZTNA, infrastructure access, and audit into one platform also reduces tool sprawl and lowers both license cost and operational overhead.

Conclusion

Zero trust network access replaces the broad, location-based trust of a VPN with narrow, identity-based access to individual resources, verified continuously. The payoff is a smaller attack surface, contained breaches, and stronger, more auditable compliance, which perimeter tools struggle to deliver in cloud-native and multi-cloud environments.

The practical move is to make identity the perimeter and least privilege the default, then prove it with audit and session recording. Teleport Zero Trust Access implements ZTNA with an identity-aware proxy, short-lived certificates, and zero standing privileges across humans, machines, workloads, and AI agents, while Teleport Identity Security gives you the visibility to back it up.