Secure Remote Access in 2026: VPNs, ZTNA, Bastion Hosts, Privileged Access Gateways, and the Identity-Based Alternative

Count the systems controlling who can access your production infrastructure. In most environments, it's not just one.

A VPN gateway handles network-level access. A bastion host brokers SSH connections. For privileged sessions, many teams rely on tools like CyberArk or BeyondTrust. For internal web applications, platforms like Cloudflare Access or Zscaler often sit in front of the app. Each tool has a valid role. The problem starts when all of them become permanent layers in the same access path.

Over time, that layer gets harder to reason about. Credentials live in different places. Audit data is split across systems. Patching and ownership follow separate paths. When a security audit requires a complete access history for one engineer on a specific day, the data often exists, but not in one place. Even with centralized logging, turning those events into a reliable timeline takes quite a lot of work.

That is the problem this article addresses. Not whether any one of these tools is effective, but whether maintaining all of them in parallel is an architecture worth sustaining, and what a consolidation path actually looks like.

Each category below is evaluated across five dimensions: security model, engineer experience, scalability, compliance coverage, and total cost of ownership, including operational burden.

VPNs: The network tunnel that overshares

VPNs remain useful when the goal is simple network reachability. The issue is that network reachability is a broad control. It answers whether a user can enter a network path, not whether they should reach a specific server, cluster, database, or internal service once they are inside.

Security model

Teleport’s ZTNA guide makes the core distinction clearly: VPNs grant network-level access rather than resource-level access. Once connected, a user usually lands inside a subnet with reachability to more than one system. If a VPN credential is compromised, the attacker does not automatically get access to everything, but they do get a better place to start probing from. The final blast radius depends on what else is protecting those reachable systems.

VPN logging reflects the same limitation. Logs can show that a user authenticated and moved traffic through the tunnel. They usually do not show what happened after that access was granted. During incident response, teams still need to answer which systems were touched and what happened inside those sessions. That usually means pulling evidence from several other places.

VPN authentication also tends to rely on long-lived credentials, including pre-shared keys, client certificates, or directory-backed usernames and passwords. Rotation usually happens on a schedule, not when policy changes in real time. Immediate revocation can also require updates across gateways and clients. For non-human access, such as CI/CD pipelines, these credentials often end up in environment variables or secret stores, where their lifetime can extend well beyond a single session.

Engineer experience

VPN clients add friction to routine access. DNS can behave differently between local and tunneled environments. Split tunneling is easy to get wrong. Engineers moving between local tooling, remote Kubernetes clusters, and cloud environments often end up managing overlapping routes and client configuration instead of just reaching the resource they need.

Accessing resources inside the VPN typically involves multiple steps. Establishing the tunnel is separate from authenticating to the target system, which may still require its own credentials and tooling. Identity is not consistently applied across layers.

Scalability, compliance, and TCO

At scale, VPN gateways become aggregation points for both users and traffic. As engineering teams and automated workloads grow, those gateways have to handle more connections and more throughput. That introduces performance constraints and creates another system that needs to be sized, monitored, and maintained.

Licensing can create a different issue. Many VPN models are built around human users, while modern environments include a growing number of machine identities. CI/CD pipelines, automation jobs, and other non-human access patterns do not always map cleanly to that model.

From a compliance perspective, VPNs provide connectivity but not detailed session visibility. If an organization needs command tracking or session-level auditing, it usually adds another layer on top, such as a bastion host or privileged access tool. The VPN still has a role, but the access model becomes harder to audit as more layers are added.

Bastion hosts: The jump box that became a high-value target

Bastion hosts solve a real access problem: they give teams one place to route SSH traffic instead of exposing every server directly. The tradeoff is that the jump box becomes part of the security model, not just a routing convenience.

Security model

SSH key distribution is a structural part of the bastion host model. Access is usually granted by placing user public keys on the bastion and, in many cases, on downstream nodes as well. Over time, those keys spread across systems. Revocation becomes a distributed process, and there is no guarantee that every copy was found and removed. Without a certificate-based approach, there is no built-in expiration or centralized revocation mechanism.

The bastion also concentrates access into a single control point. Every SSH session passes through it, which makes it a high-value target. If the bastion is compromised, an attacker may gain a foothold with authenticated access to systems reachable from that host, depending on how access is configured.

Logging reflects the limitations of the underlying SSH model. Native sshd logs capture connection events, but not full session context. Many organizations add logging pipelines or session recording tools to improve visibility, but those tools still need to be deployed and maintained alongside the bastion.

Engineer experience

The bastion workflow adds configuration and indirection to routine access. Engineers typically define jump-host chains in their SSH client configuration to reach internal systems. In larger environments, those configurations become harder to maintain across regions, accounts, and projects.

Attribution can also become inconsistent. When shared accounts are used on the bastion, audit logs reflect the system account rather than the individual user. Even with per-user access, workflows for Kubernetes clusters, databases, and internal applications sit outside the bastion pattern and require separate tools and authentication steps.

Scalability, Compliance, and TCO

Bastion deployments tend to follow infrastructure boundaries. Organizations often operate separate bastions across environments, accounts, and regions. Each one needs provisioning, patching, monitoring, and ownership.

The model also becomes harder to extend beyond SSH. Kubernetes APIs, databases, and internal applications usually require additional systems. That fragments the access layer further and increases the number of components that need to be secured, audited, and maintained.

From a compliance perspective, bastions provide a control point for access, but not a complete audit solution. Achieving session-level visibility usually requires additional tooling. That increases complexity and spreads audit data across multiple systems.

ZTNA point solutions: Better than VPNs, but still incomplete

ZTNA improves the access model by narrowing what a user can reach. Instead of placing someone inside a network, it puts a policy check in front of a specific resource. That works well for many web-based workflows. The gaps usually appear when teams try to apply the same model to infrastructure protocols.

Security models

Zero Trust Network Access architectures represent a meaningful improvement over traditional VPNs. Access is identity-aware, resource-scoped, and enforced at the application layer rather than the network boundary. A compromised token typically grants access only to the specific resource it was issued for, rather than an entire subnet. That reduces the risk of broad lateral movement.

Platforms like Cloudflare Access, Cato Networks, and Zscaler Private Access implement identity-aware access policies for private applications. For HTTP and HTTPS workloads, this model works well. Internal web applications can sit behind a ZTNA proxy without giving users broad network access.

Engineer experience

The model becomes less consistent outside of HTTP-based workflows. Protocols like SSH, Kubernetes (kubectl), and direct database connections require additional handling beyond browser-based access. Some vendors support these protocols through tunneling agents or proxy mechanisms, but these often follow separate enrollment paths and introduce additional operational steps.

As a result, teams still end up with different access patterns for different resource types. Web applications may go through ZTNA, while infrastructure access continues to rely on SSH proxies, bastion hosts, or other tools. This brings back the same problem in a smaller form: multiple workflows and split audit visibility.

Scalability, compliance, and TCO

ZTNA solutions are effective at reducing reliance on broad network access, but they do not fully address privileged access or infrastructure access on their own. Organizations still need mechanisms for credential management, privilege elevation, machine identity in CI/CD pipelines, and session-level auditing for non-HTTP protocols.

In practice, ZTNA often reduces the size of the access stack without unifying it. The VPN footprint may shrink, but SSH, Kubernetes, databases, and privileged workflows still need their own controls. Operational complexity remains distributed across multiple systems.

Traditional PAM and Privileged Access Gateways: Necessary but Heavyweight

PAM tools solve a real problem: They help teams control privileged access, record sensitive sessions, and reduce the risk of shared or overused credentials. The tradeoff is that many PAM architectures still revolve around managing credentials rather than changing the access model itself.

Security model

Privileged Access Management (PAM) platforms exist to control high-risk access: over-privileged accounts, shared credentials, and the lack of accountability in privileged sessions. Platforms like CyberArk and BeyondTrust provide credential vaulting, session recording, approval workflows, and just-in-time access provisioning. These controls address well-understood risks.

The architectural constraint is that these systems are built around managing credentials rather than eliminating them. A credential retrieved from a vault is still a credential. It may be short-lived, rotated automatically, and tightly controlled, but it exists for the duration of the session and must be protected accordingly. The security model focuses on controlling credential use, rather than replacing credentials with identity-bound, ephemeral access.

Engineer experience

PAM deployments add another layer to the access workflow. Many implementations rely on proxy systems, session brokers, or web-based access interfaces between the user and the target system. These controls improve security and auditability, but they can pull engineers away from the native workflows they use for SSH, Kubernetes, and database access.

Approval processes usually live inside the PAM platform. Integrating those workflows with tools like Slack, Jira, or PagerDuty is possible, but it often takes additional configuration and maintenance. For teams that spend most of their time in terminals, these extra steps can feel heavy compared to direct access patterns.

Support for modern infrastructure patterns varies. Some platforms have expanded into Kubernetes and cloud-native environments, but coverage is not always consistent across resource types. Ephemeral workloads and non-interactive access patterns can still require separate handling.

Scalability, Compliance, and TCO

PAM platforms are designed for enterprise-scale environments, but that capability comes with operational and financial cost. Deployment often involves several components, including vaults, proxies, agents, and policy engines. Each one needs configuration, maintenance, and monitoring.

Licensing models frequently scale with both users and managed resources, which can become significant in large environments. In many architectures, PAM systems complement existing access layers like VPNs or bastions rather than replacing them. That leaves multiple systems to operate and integrate.

From a compliance perspective, PAM provides strong controls around privileged access and session visibility. That said, when combined with other access mechanisms, audit data can still be distributed across multiple systems, requiring correlation to build a complete picture of access activity.

How the Four Categories Compare

Measured against security model, engineer experience, scalability, compliance, and total cost of ownership, each category addresses a specific access pattern while leaving gaps that require additional tooling.

Each gap in coverage introduces another system into the stack, increasing operational overhead and fragmenting visibility across multiple tools.

Identity-based platforms: A single control plane for infrastructure access

Identity-based access changes the starting point. Instead of asking where the user is connecting from, it asks who the user is, what they should access, and how long that access should last.

Security model

Identity-based access platforms shift the model from managing credentials to issuing short-lived, identity-bound access at connection time. In Teleport's case, the auth service functions as a certificate authority that integrates with existing identity providers like Okta, Entra ID, GitHub, or any OIDC/SAML system.

When a user authenticates, Teleport issues short-lived certificates tied to that verified identity and associated roles. Those certificates expire automatically. Access decisions are evaluated at session time based on identity and policy, rather than relying on credentials distributed in advance.

The same model extends to non-human access. Machine and workload identity can be provisioned dynamically, allowing CI/CD pipelines and automation jobs to obtain short-lived credentials for the duration of a task. This reduces reliance on static secrets stored in environment variables or external systems.

Privilege elevation follows the same pattern. Instead of granting persistent access, users request elevated permissions for a limited time. Approval workflows can be integrated into existing systems, and access decisions are recorded centrally.

Coverage and Engineer Experience

A single authenticated session can provide access across multiple resource types, including SSH servers, Kubernetes clusters, databases, and internal applications. Instead of switching between tools and credential types, access follows the same identity and policy model.

This also simplifies auditability. Access events and session activity are captured in a centralized system, so teams can trace who accessed what, when, and under which permissions without stitching logs together across several tools.

Teams that prefer graphical interfaces can use desktop clients. Others can keep working in terminal-based workflows. The access model stays consistent regardless of interface.

Compliance and TCO

Centralized authentication, authorization, and audit make identity-based platforms easier to align with access control, least privileged access, and session traceability requirements. Instead of assembling audit evidence from multiple systems, organizations can rely on one control plane for access visibility.

From an operational perspective, this approach consolidates multiple access layers into a smaller number of systems. In many environments, it can replace the need for a standalone bastion and reduce reliance on VPNs and credential-centric PAM workflows for infrastructure access. The result is fewer systems to maintain and a more consistent access model across environments.

Getting off the bastion: A concrete starting point

Moving away from a bastion-based model does not require a disruptive cutover. The transition can be incremental.

A common starting point is to deploy a Teleport cluster alongside the existing access setup. The bastion does not have to disappear on day one. Teams can enroll a small set of target systems first and validate certificate-based access in parallel with the current workflow.

From the engineer's perspective, the change is straightforward. Instead of chaining SSH connections through a jump host and managing local key files, access starts with authentication against a central identity provider. Teleport issues a short-lived certificate for the session, and access to infrastructure resources is authorized based on that identity and its associated roles.

The underlying systems do not need to be replaced. Existing OpenSSH nodes can be configured to trust the Teleport certificate authority or enrolled through Teleport agents, allowing them to accept identity-bound, time-limited credentials instead of static keys. As more systems move into this model, reliance on authorized_keys files decreases, and bastion-style access patterns can be reduced.

The migration path is additive. Teams can:

• Deploy Teleport alongside the bastion
• Enroll a subset of nodes
• Validate access patterns and audit visibility
• Gradually remove static keys and direct SSH exposure

Once access is consistently mediated through the Teleport control plane, the bastion becomes redundant rather than critical infrastructure.

This avoids a single, high-risk replacement step. Teams can move from a distributed, configuration-driven model to centralized identity-based access one group of systems at a time.

From Access Sprawl to Identity-Centric Control

Secure remote access in modern infrastructure is an architectural challenge, not a single tool problem.

VPNs, bastions, ZTNA platforms, and PAM systems each solve a real problem. But they solve it at different layers, with different assumptions about how access should be granted, tracked, and revoked. The result is a stack where identity, authorization, and audit are spread across multiple systems, each with its own model and operational burden.

Hardening each layer improves security locally. It does not resolve the fragmentation between them.

The shift toward identity-based access changes that foundation. Instead of granting access through network placement, static keys, or vaulted credentials, access is evaluated at connection time based on verified identity and policy. Credentials become short-lived, scoped, and disposable. Audit becomes centralized. The control plane moves from infrastructure configuration to identity enforcement.

That does not mean every existing tool disappears overnight. But it does change how you evaluate them. The question is no longer which tool secures SSH, web apps, or databases. It is whether access across all of them can be governed consistently.

Teleport is built around this model: unifying access to infrastructure resources under a single identity-aware control plane using short-lived certificates instead of long-lived credentials.

If you want to see how this works in practice, you can deploy Teleport in your own environment and evaluate how access changes when identity defines it rather than configuration.