Twenty years into doing this work, the thing that still gives me the clearest signal that an organization’s security posture is stuck in 2010 is not the CVE count on their container images. It is the authorized_keys file. Find a production host with a ~/.ssh/authorized_keys containing a dozen entries, half of them belonging to engineers who left two years ago, and you have found the company’s real attack surface. Not the shiny SIEM dashboard. The file nobody owns.
I spent years trying to fix this with bastion hosts. We built elaborate jump boxes, wrapped them in VPNs, enforced MFA, wrote runbooks about how to get there. And it helped, to a point. But a bastion host is still just another SSH server with a bigger authorized_keys file, positioned as the chokepoint you are supposed to audit. It creates a false sense of rigor while the actual problem, static long-lived credentials and no real session visibility, persists behind it.
The model that actually solves this is built around ephemeral certificates instead of persistent keys, continuous authorization instead of perimeter-based access, and session recording that captures not just who connected but what they did. This is what Teleport and HashiCorp Boundary are implementing in production environments today, and this article is a practical guide to both: what they are, how they differ architecturally, which one fits which context, and how to migrate off the bastion host before it becomes your next incident.
Why Bastion Hosts Are Not Zero Trust
The framing of zero trust security is that you should never trust any actor by virtue of network location alone. A user inside the VPN is not trusted just because they are inside the VPN. Every request needs to carry its own proof of identity, and that identity needs to be re-evaluated continuously, not just at login time.
Bastion hosts fail this model in three ways.
First, they authenticate with persistent SSH keys. A developer generates an RSA keypair once, adds the public key to the bastion, and that key is valid until someone manually revokes it. That someone is usually nobody, because there is no process for systematic key rotation and the consequences of missing a rotation are invisible until they are not. The bastion host pattern made operational sense when it was invented, but it was never designed around the identity threats we face now.
Second, they have no native understanding of what happens after authentication. A bastion host gets you a shell. What you do with that shell is invisible unless you have bolted on a session recording solution, which most teams have not. When you need to know what a compromised credential was used to access at 3 AM on a Tuesday, you are looking through syslog hoping something was captured. Usually it was not.
Third, they do not model authorization at a meaningful granularity. Access to the bastion is binary: you either have an SSH key that works or you do not. There is no concept of “read-only access to the database on a specific host for a specific ticket” that expires when the ticket closes. Just-in-time (JIT) access, where someone gets the minimum permissions needed for the minimum duration required, is not a feature a bastion host can provide.
What Zero Trust Infrastructure Access Actually Looks Like
The architecture that replaces the bastion host has three components working together.
Short-lived credentials. Instead of a static SSH key, a user authenticates to a control plane using their identity provider (Okta, Azure AD, Google Workspace, whatever your organization uses). The control plane issues them an X.509 certificate or a short-lived SSH certificate that is cryptographically bound to their identity and expires in hours or days, not years. If an attacker steals the certificate, they have a limited window to use it. When the certificate expires, there is nothing to rotate, nothing to revoke, no cleanup task that falls through the cracks.
Centralized policy enforcement. Authorization is evaluated at a central policy engine, not scattered across authorized_keys files on individual hosts. When you need to grant a contractor access to a specific subset of databases for a specific engagement, you do that in one place and it propagates to all the relevant resources. When the engagement ends, you remove it from one place and it is gone everywhere, immediately.
Session recording and audit. Every session is recorded. Database queries, shell commands, Kubernetes API calls, RDP sessions, all of it flows through the access proxy, which records the session and exports structured audit events to whatever SIEM or logging pipeline you use. This is not just a compliance checkbox. When something goes wrong, the investigation is a query against structured logs, not a desperate grep across syslog files.
Teleport: The Infrastructure Identity Platform
Teleport started as a replacement for the SSH bastion, but it has evolved into something considerably broader. As of mid-2026, the Teleport Infrastructure Identity Platform covers SSH, Kubernetes, databases (PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch, and more), internal web applications, and RDP. All of these go through the same control plane, which means a single audit trail and a single policy model for everything.
How the Architecture Works
A Teleport deployment has three tiers:
The Auth Server is the certificate authority. It issues short-lived certificates, enforces access policies, and maintains the audit log. This is the most sensitive component. In HCP Teleport (the managed offering), Teleport runs this for you. In self-hosted deployments, you are responsible for its availability and security.
The Proxy is the public-facing component that handles user connections and routes them to the appropriate resources. Users connect to the proxy using tsh (the Teleport CLI) or the web UI. The proxy authenticates the user against the auth server and brokers the connection.
The Agent runs on the target resource. For SSH access to a server, you install teleport on that server and configure it to register with the auth server. For database access, the agent runs on an intermediate node (or as a Kubernetes deployment) that has connectivity to the database. The agent never exposes itself directly to the internet; it dials out to the proxy, so you do not need to open inbound ports on production servers.
This outbound-dial model is significant. It means you do not need a VPN, you do not need to poke firewall rules for every new resource, and an attacker who compromises the network segment the databases live in cannot directly reach the Teleport agent from the internet.
Certificate-Based Authentication in Practice
When a developer runs tsh login, Teleport authenticates them against the configured SSO provider. After successful MFA, the auth server issues a certificate that encodes the user’s identity, their roles, and an expiry time (configurable, defaults to 12 hours). This certificate is stored in the local SSH agent. When the user then runs tsh ssh user@hostname or kubectl commands with Teleport’s kube proxy, the certificate is presented automatically and Teleport evaluates whether the user’s roles permit the requested access.
No static keys are involved. The developer does not need to manage a keypair. When they leave the organization and their identity provider account is deprovisioned, their Teleport access is gone immediately because the next login attempt will fail, and their existing short-lived certificate expires within hours anyway. This solves the offboarding problem that makes every security engineer’s eye twitch.
Kubernetes Access
For Kubernetes, Teleport is particularly powerful. Instead of distributing kubeconfig files with long-lived service account tokens, you connect to clusters through Teleport. The user runs tsh kube login cluster-name and then uses kubectl normally. All kubectl commands are mediated by the Teleport proxy, recorded in the audit log, and governed by Teleport RBAC roles that map to Kubernetes RBAC. Combined with Kubernetes RBAC, this gives you a complete access model from identity provider all the way to Kubernetes resource.
Database Access Without Embedding Credentials
For database access, Teleport does something that took me a while to fully appreciate: it can provide database access without the engineer ever seeing the database password. The Teleport database agent holds the credentials (or, better, generates short-lived IAM auth tokens for cloud databases) and the engineer runs tsh db connect to open an authenticated session. The audit log captures every query. The engineer never had a credential to leak.
This integration with workload identity federation patterns is where things get interesting for IAM-native cloud databases. For Aurora PostgreSQL or RDS MySQL with IAM authentication, Teleport can generate the IAM auth token on the fly, so there is no stored password at all.
The AI Agent Access Problem
Teleport’s most interesting 2026 addition is the Agentic Identity Framework. As AI agents proliferate in production infrastructure, the same problem that existed for human bastion access exists for agents: they need to access cloud resources, databases, and APIs, and the naive solution is embedding API keys and static credentials in agent runtimes.
Teleport’s answer is to apply the same certificate-based identity model to AI agents. An agent receives a short-lived identity just as a human developer does. Teleport’s Beams feature provides an isolated ephemeral Firecracker microVM runtime for each agent execution, wired into the same identity plane. This connects directly to the AI agent security challenges that infrastructure teams are now dealing with at scale.
HashiCorp Boundary: Credential Brokering and Dynamic Hosts
HashiCorp Boundary takes a different architectural approach that I find compelling in enterprise contexts where heterogeneous infrastructure, dynamic cloud resources, and existing identity infrastructure create complexity that Teleport can struggle with.
The Controller-Worker-Target Model
Boundary decomposes the access problem into three entities:
Controllers are the control plane. They manage the identity, policy, session, and catalog data. HCP Boundary (the managed offering, which HashiCorp recommends for operational simplicity after the version 1.0 release) hosts the controller plane for you.
Workers are the data plane. They are lightweight processes you run in your network segments, close to the resources being accessed. Workers proxy the actual TCP traffic between the user’s client and the target. They receive configuration from the controller but do not themselves evaluate policy. This separation means you can have workers in isolated network segments, behind firewalls, in different cloud accounts, without those workers needing to be reachable from the public internet.
Targets are the resources you want to protect. A target is a definition in Boundary’s catalog that maps to one or more addresses. When a developer needs to SSH to a production database server, they connect to the target prod-db-primary, not to a specific IP address. Boundary dynamically selects which host to route to based on host catalogs, which can integrate with cloud APIs (AWS EC2, Azure, GCP) to dynamically discover hosts as they scale.
This dynamic host catalog feature is something that matters in practice. In environments with heavy autoscaling or spot instances, where the set of valid hosts is constantly changing, having a system that automatically enrolls new hosts and removes terminated ones is operationally valuable. You do not need to update SSH host lists manually.
Credential Brokering vs. Certificate Generation
Boundary’s approach to credential handling is called credential brokering. When a session is authorized, Boundary can pull a credential from a Vault secrets engine, inject it into the session, and give the user a one-time-use credential that is scoped to that session. The user presents the injected credential to the target. After the session ends, the credential is revoked.
This integration with HashiCorp Vault is where Boundary shines. If you already have Vault managing your SSH CA or your database dynamic secrets, Boundary layers access control and session brokering on top of that existing infrastructure. You are not replacing Vault; you are using Vault as the credential source and Boundary as the access governance layer.
In contrast to Teleport’s certificate-based model (where Teleport is itself the CA), Boundary is more of a credential broker than a certificate authority. This makes Boundary more modular but also more complex to integrate.
Just-in-Time Access and Permissions Management
Boundary’s permissions model supports just-in-time access grants natively. An on-call engineer can request access to a production target through an automated workflow, Boundary can grant it for a bounded window (say, four hours), and that access is automatically revoked when the window expires. No tickets left open, no cleanup task, no “I’ll remove that access when I have time.” It is built into the model.
This JIT pattern is what I care most about for protecting sensitive resources. Permanent standing access to production databases is a liability. Non-human identity governance requires the same JIT discipline for service accounts and automation. Boundary applies the same model to both.
Comparing Teleport and Boundary: The Decision Matrix
I have deployed both in production and the choice is rarely obvious from the feature list alone. Here is how I think about it.
Choose Teleport when:
- You want a single control plane that covers SSH, Kubernetes, databases, web apps, and RDP in one pane of glass
- Your primary access use case is developer access to cloud infrastructure (Kubernetes especially)
- You want the certificate-based model without managing a separate Vault deployment
- You are a startup or mid-sized company that wants to be operational quickly without deep integration work
- Session recording and structured audit events are a first-class requirement
- You are starting to deal with AI agent infrastructure access
Choose Boundary when:
- You already have HashiCorp Vault and want to integrate rather than replace the credential management layer
- You need to manage access to non-SSH targets: internal APIs, RDP hosts, Windows servers, legacy protocols
- Your environment has complex network segmentation where the worker model (data plane in your network, control plane hosted) gives you better isolation properties
- You have enterprise Vault usage patterns (dynamic secrets for databases, PKI) that you want to extend to access governance
- You need dynamic host catalogs for highly dynamic cloud environments
- You want HCP-hosted control plane for operational simplicity while keeping data plane workers in your VPCs
In practice: Many organizations end up with both. Teleport handles the developer-facing SSH and Kubernetes access for the engineering team. Boundary handles privileged access to the more heterogeneous infrastructure layer, integrated with Vault credential brokering. This is not an either/or problem in large environments.
There is also AWS Systems Manager Session Manager worth mentioning. If you are running entirely on AWS EC2 and have no Kubernetes or non-AWS resources to worry about, SSM Session Manager provides session recording, no SSH key management, and integration with IAM policies, all without deploying any third-party software. Its audit integration with CloudTrail and S3 is solid. It is the right answer if you are AWS-only and want to avoid operational overhead. But it has no answer for Kubernetes access, database access, or non-AWS infrastructure.
StrongDM is another player in this space with a strong managed offering and good support for a wide range of database protocols, but it carries a higher per-user cost that puts it out of reach for smaller teams.
Migrating Off Static SSH Keys: The Practical Path
The hardest part of this migration is not the technology. It is getting every developer to update their workflow simultaneously, because you cannot have both models running indefinitely. Here is the migration path I have seen work.
Phase 1: Deploy in shadow mode. Stand up Teleport or Boundary alongside your existing bastion. Configure it to cover a subset of non-critical hosts first. Get the engineering team using it voluntarily. The CLI experience of tsh ssh user@server is actually better than managing SSH keys once engineers get past the initial setup, so adoption is usually not the hard part.
Phase 2: Audit existing keys. Run secrets detection tooling across your repositories and CI systems to find any hardcoded SSH keys or certificates that will break when you remove static key access. Catalog every authorized_keys entry and map it to an identity. This is ugly work but you need to do it.
Phase 3: Migrate service account access. For automation that uses SSH (Ansible, deployment scripts, CI runners), configure SPIFFE/SPIRE workload identity or equivalent machine credentials through the access platform before you cut off static key access. Breaking automated deployments on the day you remove static keys is how this project loses organizational support.
Phase 4: Remove static keys. Once every human user and every automation job is going through the access platform, disable SSH key-based authentication on the relevant hosts. This is the clean break you need to actually close the vulnerability, not just add a layer on top of it.
Phase 5: Enforce at the bastion. Remove the bastion host entirely, or repurpose it as nothing more than a Teleport proxy node with no SSH key authentication enabled. The bastion that used to be the sole chokepoint becomes just one proxy among many.
Audit Trails That Actually Tell You Something
One of the operational benefits of both platforms that I did not fully appreciate until I was mid-incident investigation is the quality of their audit data.
Traditional SSH access through a bastion gives you authentication logs: who connected, when, from where. What you do not have is session content, command history, or database queries in a structured queryable format.
Teleport’s audit log is structured JSON that captures the entire session lifecycle: login events, session start and end, every command executed in a shell session (with timing), every kubectl command, every database query. It ships to S3, Elasticsearch, or any SIEM via a streaming export. When you need to answer “did anyone drop a table on the production database during the maintenance window last Tuesday,” you run a query, not an archaeology project.
Boundary integrates with your existing logging pipeline through session metadata and can capture network-level session data, though command-level recording for shell sessions requires the credential injection approach with terminal recording enabled.
Both platforms satisfy SOC 2 and compliance audit requirements for privileged access controls. Auditors asking for evidence of who accessed what production system get structured exports rather than “we looked at the bastion logs and we think it was fine.”
What This Changes for Machine and AI Agent Identity
I want to close with something that is becoming urgent in 2026 specifically. The proliferation of AI coding agents, autonomous deployment tools, and agentic infrastructure automation means the “who is accessing my production database” question is no longer just about humans. AI agents need to access cloud APIs, databases, and internal services. And the naive answer, give them a service account with a long-lived API key and wide permissions, is exactly the human-key problem we spent years solving, now recreated at scale for machines.
The right architecture for AI agent access is the same certificate-based, JIT, session-recorded model. An agent that needs database access should get a short-lived credential scoped to exactly the data it needs for the duration of the task. Its access should be recorded. When the task completes, the credential expires. This is the non-human identity security problem at its most critical, and the access platforms that have been solving this for human SSH access are now extending the same model to agent runtimes.
Teleport’s Agentic Identity Framework, which issues certificates to agent runtimes and records their actions through the same audit pipeline as human sessions, is the most mature answer to this problem as of September 2026. Boundary’s credential brokering model is equally applicable to automated agents if you wire the agent runtime to request credentials from Boundary rather than reading them from environment variables.
The teams that will have the least painful AI security story in 2027 are the ones building on an access platform today, not the ones still managing authorized_keys files.
The Bottom Line
Twenty years of watching production security incidents teaches you that the vulnerability that bites you is almost never the one that got the CVE score. It is the SSH key that never got rotated on the legacy host. The contractor who left and never got offboarded. The CI service account with direct database access because it was easier than setting up the right thing.
Zero trust infrastructure access platforms are not magic, and they are not cheap to deploy. But they solve the actual problem. Ephemeral certificates mean no stale keys to rotate. Centralized policy means offboarding is one operation, not twelve. Session recording means investigations are queries, not guesswork.
Replace your bastion host before the next breach teaches you why you should have. The tooling to do it right is mature in 2026 in a way it was not five years ago.
Related: Zero Trust Security Architecture | Bastion Hosts and Jump Boxes | Non-Human Identity Security | HashiCorp Vault and OpenBao | SPIFFE and SPIRE Workload Identity
Get Cloud Architecture Insights
Practical deep dives on infrastructure, security, and scaling. No spam, no fluff.
By subscribing, you agree to receive emails. Unsubscribe anytime.